🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Large Project Organization
Author
Just wondering, how do you guys out there structure your big projects?
the only games ive done are a simple pong clone which had 10 variables in the whole program.
Ive done a little asteroid clone that I quit when I had to make graphics, I used a structure for my stars.
Now I know all about classes, polymorphism, linked lists,...
Should everything draw take care of itself, should everything be a class???
also does anyone else split up their classes into header files and seperate .cpp files?
this forum is for game design, which means the rules of the game, but has nothing to do with actual implementation. For programming questions go to one of the programming forums.
"Design" is a very broad term in programming. It can range from the game rules and story to the actual Class structure of the program. Thought, I have to say, that exactly what file types to store class definitions and implementations is getting into the grey area between design and implementation.
-Daedalus
-Daedalus
Everything that has to do with building a game is part of game design. Game design encompasses several different spheres of activity from story design, to interaction design, to user interface design, to architectural design. One thing that is missing quite a bit from most of the discussions on this particular board is the mapping between the type of design described by the Anonymous Poster and the design of software architecture. I'll attempt to do a little of that mapping in this post as well as show that "game design" is NOT only game rules.
In software engineering the actual development of the story line, concept art, and user interaction are a part of the entire software engineering practice known as the requirements stage. Prior to requirements analysis you want to develop a statement of scope. This statement will help give your concept a bounding box. This will keep your requirements from changing to _a certain degree_. Next comes the requirements analysis. The requirements that you develop during this stage are used to develop a concept document for the project. This is where some of the concept art is created, the user interface is story-boarded and designed, user interaction is laid out, and the main storyline is created.
This is really one of the less time consuming elements of software production even though it seems like it takes a long time. Remember a change in software requirements after production has begun is exponentially more expensive than a change during the requirements analysis stage. The requirements stage is essential. I know; I'm a project technical lead for a medium sized software company. Organizing the delivery of software from beginning to end is my job. The requirements phase is used to develop the frame work by which the software designers will approach the design of the software. At this point, given that the requirements for each component were well defined, the software designers and the leads of the art teams and storyline teams meet to discuss ways of developing in parallel. This could include the requirement that musicians save their music in wave files, artists save their files in bitmaps, storylines might require special scripting so dialogs might require a special database. The programmers can let the story and dialog writers know how to store the storyline temporarily until a tool is built. This might be creating an MS access database and then storing the dialog lines in there by hand.
After this has taken place the designers expand upon the requirements document and creat the software requirements documentation. This stage is where inputs and outputs are defined. One form of input could be that you need to load a map file and the resultant output is that the map is created and displayed on the screen. These can then be further broken down. This is both the job of programmers/software designers and the other team members. The finished document is called the specification document.
From here the software designers start designing how the software will be created. I use UML (unified modeling language) to layout the design for my software. I'm big into OOD (object oriented design) so I use c++ which can realize these designs quite well. When I have what I think is a good design down I use-case.
This initial design isn't really big. It just describes the main classes that I use. On to use cases; with use-cases what you can start to do is use the inputs that you defined earlier and follow the flow of control through your design for each use-case. By analyzing your class design using use-cases you can determine how to change your design before you code, thus saving valuable time programming.
Take the map example for instance. We now know that we have to have something that loads a formatted file, and since we might be loading lots of files we can create a code base that will load any kind of file we want. Once we have the file loaded we would need to put it somewhere. Well we could store it in a map class. We'd also need to display the map. This would mean that we would create two main parts of the program, the display engine and the game engine. The map class would actually be stored in the game engine and the display engine would ask the game engine for specific map data.
After we finish analyzing the inputs and outputs for the software with use-cases we then go one level deeper. This means that we define inputs and outputs for each of the modules or classes of the design. At this next level we use-case the inputs and outputs for each class and then develop the design for that class. You can go as deep into the class design as you want but remember to analyze the main components no-matter how deep in the class design they are located. I usually only go a few classes in on the design and then begin on certain levels of coding. DANGER: don't code the really complex stuff right away. Just lay out the project framework. Create the classes and have them all connecting to each other first. Verify that your initial design can actually be put together.
Once the coders are ready to program the writers can be writing, the artists can be drawing and the musicians can be preparing. This can all take place in parallel with a minimal amount of wasted work.
As far as whether everything should manage its own drawing. I do that but I'm not sure if everyone does that. My objects actually all connect to a graphic class that I wrote. It is a singleton class that they all point to. You can use a static pointer as a data member to the singleton for referencing the library. All the classes that need to draw tell the drawing library to draw them. At the top level one would only have to call Map->Draw();. The map would tell its children to draw .
I usually don't split my source until I have most of it working. That is personal preference. Ultimately I do divide it into source and header. This is useful in that if you want to print out the methods for the program you only have to print the header.
Well I hope that helped answer your question. I also hoped that might have clarified what "design" and "game design" mean. Design has very little to do with storyline. That should be called "Game concepts." Of course this is all just my opinion. The methods for creating software above is just a quick overview of the science of software engineering. I recommend you get a book like Steve MacConnell's _Code Complete_. He goes over this in more detail. Then if you still want more you can find a lot of highly academic work on the subject as well.
RandomTask
Edited by - RandomTask on November 20, 2000 7:33:59 PM
In software engineering the actual development of the story line, concept art, and user interaction are a part of the entire software engineering practice known as the requirements stage. Prior to requirements analysis you want to develop a statement of scope. This statement will help give your concept a bounding box. This will keep your requirements from changing to _a certain degree_. Next comes the requirements analysis. The requirements that you develop during this stage are used to develop a concept document for the project. This is where some of the concept art is created, the user interface is story-boarded and designed, user interaction is laid out, and the main storyline is created.
This is really one of the less time consuming elements of software production even though it seems like it takes a long time. Remember a change in software requirements after production has begun is exponentially more expensive than a change during the requirements analysis stage. The requirements stage is essential. I know; I'm a project technical lead for a medium sized software company. Organizing the delivery of software from beginning to end is my job. The requirements phase is used to develop the frame work by which the software designers will approach the design of the software. At this point, given that the requirements for each component were well defined, the software designers and the leads of the art teams and storyline teams meet to discuss ways of developing in parallel. This could include the requirement that musicians save their music in wave files, artists save their files in bitmaps, storylines might require special scripting so dialogs might require a special database. The programmers can let the story and dialog writers know how to store the storyline temporarily until a tool is built. This might be creating an MS access database and then storing the dialog lines in there by hand.
After this has taken place the designers expand upon the requirements document and creat the software requirements documentation. This stage is where inputs and outputs are defined. One form of input could be that you need to load a map file and the resultant output is that the map is created and displayed on the screen. These can then be further broken down. This is both the job of programmers/software designers and the other team members. The finished document is called the specification document.
From here the software designers start designing how the software will be created. I use UML (unified modeling language) to layout the design for my software. I'm big into OOD (object oriented design) so I use c++ which can realize these designs quite well. When I have what I think is a good design down I use-case.
This initial design isn't really big. It just describes the main classes that I use. On to use cases; with use-cases what you can start to do is use the inputs that you defined earlier and follow the flow of control through your design for each use-case. By analyzing your class design using use-cases you can determine how to change your design before you code, thus saving valuable time programming.
Take the map example for instance. We now know that we have to have something that loads a formatted file, and since we might be loading lots of files we can create a code base that will load any kind of file we want. Once we have the file loaded we would need to put it somewhere. Well we could store it in a map class. We'd also need to display the map. This would mean that we would create two main parts of the program, the display engine and the game engine. The map class would actually be stored in the game engine and the display engine would ask the game engine for specific map data.
After we finish analyzing the inputs and outputs for the software with use-cases we then go one level deeper. This means that we define inputs and outputs for each of the modules or classes of the design. At this next level we use-case the inputs and outputs for each class and then develop the design for that class. You can go as deep into the class design as you want but remember to analyze the main components no-matter how deep in the class design they are located. I usually only go a few classes in on the design and then begin on certain levels of coding. DANGER: don't code the really complex stuff right away. Just lay out the project framework. Create the classes and have them all connecting to each other first. Verify that your initial design can actually be put together.
Once the coders are ready to program the writers can be writing, the artists can be drawing and the musicians can be preparing. This can all take place in parallel with a minimal amount of wasted work.
As far as whether everything should manage its own drawing. I do that but I'm not sure if everyone does that. My objects actually all connect to a graphic class that I wrote. It is a singleton class that they all point to. You can use a static pointer as a data member to the singleton for referencing the library. All the classes that need to draw tell the drawing library to draw them. At the top level one would only have to call Map->Draw();. The map would tell its children to draw .
I usually don't split my source until I have most of it working. That is personal preference. Ultimately I do divide it into source and header. This is useful in that if you want to print out the methods for the program you only have to print the header.
Well I hope that helped answer your question. I also hoped that might have clarified what "design" and "game design" mean. Design has very little to do with storyline. That should be called "Game concepts." Of course this is all just my opinion. The methods for creating software above is just a quick overview of the science of software engineering. I recommend you get a book like Steve MacConnell's _Code Complete_. He goes over this in more detail. Then if you still want more you can find a lot of highly academic work on the subject as well.
RandomTask
Edited by - RandomTask on November 20, 2000 7:33:59 PM
I''m not going to flame, I''m not going to flame, I''m not going to flame. READ WHAT ANNON SAID, IT''S STRAIGHT TO THE POINT!
Designing a game has nothing to do with CODE! Yes it is reliant on code but it is NOT CODE!!!!!!!!!!!!!! Thank you.
MadKeithV, I''m trying hard here ok.
One more time for the dumbies
ar+gu+ment n. A discussion in which reasons are put forward in support of and against a proposition, proposal, or case; debate.
Designing a game has nothing to do with CODE! Yes it is reliant on code but it is NOT CODE!!!!!!!!!!!!!! Thank you.
MadKeithV, I''m trying hard here ok.
One more time for the dumbies
ar+gu+ment n. A discussion in which reasons are put forward in support of and against a proposition, proposal, or case; debate.
Paul,
Flame all you want, I don''t really mind. I think we have differing ideas on game design. I, like the original poster of the article assumed that this forum was for all aspects involved in designing a game project, which including architecural design.
I don''t think the original poster was really interested in designing the rules of the game, more so in designing the architecture of large systems so my answers were written with that in mind though I did use the post to present my idea of "software design."
Like I said in my post, I don''t think "game design" is the proper terminology for coming up with the rules and conditions that determine what a game does. I think this is just "game concepts." But ultimately this just comes down to a matter of interpretation of definitions. I''m approaching "design" as a verb, you are probably approaching it as a noun.
In case you didn''t know, the idea of using a class and using polymorphism is NOT coding. It is the basis of Object Oriented Design (OOD). These are principles used to "design" software in an object oriented manner. Data structure theory isn''t implementation details either. The choice of a data structure is a design decision. The actual implementation is a coding decision.
I strongly believe that the majority of the questions Kilj asked were NOT implementation questions, but rather "software design" questions. Ohh and by the way, if you read my post you can see that I didn''t say that CODE was design. I mentioned that coding was a part of software engineering, but did not say that it is design. My post was NOT about coding, it was about how the discipline of software engineering approaches the creation of software and how architectural design is implemented on a large scale. Granted I did mention how to approach the coding once the architectural design was created. Remember a class design is NOT code. While I realize that not every software shop creates software this way, the company I work for does.
Random Task
Flame all you want, I don''t really mind. I think we have differing ideas on game design. I, like the original poster of the article assumed that this forum was for all aspects involved in designing a game project, which including architecural design.
I don''t think the original poster was really interested in designing the rules of the game, more so in designing the architecture of large systems so my answers were written with that in mind though I did use the post to present my idea of "software design."
Like I said in my post, I don''t think "game design" is the proper terminology for coming up with the rules and conditions that determine what a game does. I think this is just "game concepts." But ultimately this just comes down to a matter of interpretation of definitions. I''m approaching "design" as a verb, you are probably approaching it as a noun.
In case you didn''t know, the idea of using a class and using polymorphism is NOT coding. It is the basis of Object Oriented Design (OOD). These are principles used to "design" software in an object oriented manner. Data structure theory isn''t implementation details either. The choice of a data structure is a design decision. The actual implementation is a coding decision.
I strongly believe that the majority of the questions Kilj asked were NOT implementation questions, but rather "software design" questions. Ohh and by the way, if you read my post you can see that I didn''t say that CODE was design. I mentioned that coding was a part of software engineering, but did not say that it is design. My post was NOT about coding, it was about how the discipline of software engineering approaches the creation of software and how architectural design is implemented on a large scale. Granted I did mention how to approach the coding once the architectural design was created. Remember a class design is NOT code. While I realize that not every software shop creates software this way, the company I work for does.
Random Task
I enjoy talking about laying out data structures as much as the next guy, yes. And yes, i am being a hypocrite here as i have been discussing similar issues in threads that are still quite recent here. What i''m on about, or what i''m trying to do is to keep this to a minimum. Why? Becuase i don''t think that it really does have anything to do with Game Design. Software engineering finishes when you tell the game designer what the game can do, Game Design starts when you take that knowledge and begin turning it into game concepts (or vice versa depending on the people you work with).
Therefore i believe that it would be the wrong thing to do to encourage this conversation to carry on here becuase its bound to bring more. Asking questions like "does anyone else split up their classes" will typically mean ZIP to many a game designers, they don''t have to know this. Just ask the people that designed games like Axis and Allies or Magic the Gathering. Are you starting to see what i mean now. Software engineering follows completely difference displines and philosophies to Game Design. Need i really say any more.
Note: My previous post was not aimed at you or Kilj directly, it was in support of the anonymous poster. It was also a cry of pain.
The fact is that i reacted the way i did as i believe the anonymous poster did becuase the original post made little relation to game design. The other thread where i''ve been involved in these issues (why i call myself a hypocrite) were much better disolved with game design issues. Since this is all in the name of community i believe that i haven''t done anything wrong but i still am a hypocrite technically speaking. And i will keep this stance!!!
One more time for the dumbies
ar+gu+ment n. A discussion in which reasons are put forward in support of and against a proposition, proposal, or case; debate.
Therefore i believe that it would be the wrong thing to do to encourage this conversation to carry on here becuase its bound to bring more. Asking questions like "does anyone else split up their classes" will typically mean ZIP to many a game designers, they don''t have to know this. Just ask the people that designed games like Axis and Allies or Magic the Gathering. Are you starting to see what i mean now. Software engineering follows completely difference displines and philosophies to Game Design. Need i really say any more.
Note: My previous post was not aimed at you or Kilj directly, it was in support of the anonymous poster. It was also a cry of pain.
The fact is that i reacted the way i did as i believe the anonymous poster did becuase the original post made little relation to game design. The other thread where i''ve been involved in these issues (why i call myself a hypocrite) were much better disolved with game design issues. Since this is all in the name of community i believe that i haven''t done anything wrong but i still am a hypocrite technically speaking. And i will keep this stance!!!
One more time for the dumbies
ar+gu+ment n. A discussion in which reasons are put forward in support of and against a proposition, proposal, or case; debate.
Yeah, but. . .
This is a grey area, and certainly debatable. I ABSOLUTELY LOATHE off-topic threads & posts, as I''ve seen many good threads degenerate from off-topic threads, and I''ve seen whole message boards crumble beneath the weight of extreme off-topic posting. But. . .
Although I actually agree w. Paul in that this might have fit better w. another forum, its not really worth all the fuss. Keeping each other in check is all good and everything, but only on obvious issues, like Help Wanted postings and such. Decisions like this are the reason we have moderators, and if this thread is better off in a different forum, I assume that it will find its way there w.out major bloodshed. I find it quite a bit more offensive to be corrected in a condescending way, w. no real attempt at a valid argument, than to log on to a game design board and (heaven forbid) find a question on systems architecture. Not really worth your cries of anguish. . .
Again, I agree in spirit. This board needs some more gritty topics to chew on. Badly. So why not start one? All I''m trying to say is that unless it is your duty to do so, why bother w. the stress of acting as a hall monitor for people who obviously are not appreciating your efforts?
This is a grey area, and certainly debatable. I ABSOLUTELY LOATHE off-topic threads & posts, as I''ve seen many good threads degenerate from off-topic threads, and I''ve seen whole message boards crumble beneath the weight of extreme off-topic posting. But. . .
Although I actually agree w. Paul in that this might have fit better w. another forum, its not really worth all the fuss. Keeping each other in check is all good and everything, but only on obvious issues, like Help Wanted postings and such. Decisions like this are the reason we have moderators, and if this thread is better off in a different forum, I assume that it will find its way there w.out major bloodshed. I find it quite a bit more offensive to be corrected in a condescending way, w. no real attempt at a valid argument, than to log on to a game design board and (heaven forbid) find a question on systems architecture. Not really worth your cries of anguish. . .
Again, I agree in spirit. This board needs some more gritty topics to chew on. Badly. So why not start one? All I''m trying to say is that unless it is your duty to do so, why bother w. the stress of acting as a hall monitor for people who obviously are not appreciating your efforts?
someone designed chess, no one programmed it. What you are talking about is design of a program. So "game program design" would refer to what you are talking about, since game modifies program and program modifies design. When you say game design though, you have the word game modifying design. You might say that game stands in for game software, but not exactly. You play a game, you run a program. You can put them together by playing a game while running a game program. Also some parts of video game design do not involve programming in any other way. Play balancing only involves changing data, such as weapon damage, to make significant changes in the program. Don''t get me wrong, I''m very interested in architecture and the like, that''s my favorite programming thing. I just don''t think it belongs in this particular forum. Perhaps a forum should be set up for it, just like a forum was set up for writers (some of whom were convinced that there was no difference between story and design).
I concede. Due to the definition of "game design" used on this board this thread most definitely belongs on another topic section. Unfortunately one does not exist for architectures and the discussion that would exist there would be quite lengthy and complex. It would probably never end up being used because, from what I gather, most people on this board aren''t disciplined enough in their production practices to actually create software designs before they start coding. Much like the analogy drawn by the anon poster in the previous thread, there are coders who believe that software design and coding are the same thing and that you don''t need to do design, they just happen when you code. But that is another topic.
RandomTask
RandomTask
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
