 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic Page: 1 2 »» |
Last Thread Next Thread |
| Incremental Development |
|
 |
wolf XNA/DirectX MVP Member since: 1/8/2000 From: Carlsbad, CA, United States |
|||
 Posted - 6/25/2002 3:19:50 AM |
||||
| Great article ! I enjoyed reading it. - Wolf |
||||
|
||||
|
ragonastick Member since: 5/17/2000 From: Sydney, Australia |
|||
|
Posted - 6/25/2002 6:18:01 AM |
||||
Just out of curiosity, how long does compiling usually take for someone using VC++6, on small/medium/large projects (specify your definition of the size too). I have only done really small stuff in C++, so compiling time was no problem. But for my work, I use VB, where compiling time is usually insignificant unless I'm dealing with a huge project (and for those people who think that it is because the language is interpreted... it isn't). So when developing in VB, I've often found myself doing syntax checking just by compiling or mashing my hand on the keyboard to leave a bookmark so I can quickly come back to it before I compile next - that's how quick it is  I wasn't aware that it was such an issue though. So I might change my habits Trying is the first step towards failure. |
||||
|
||||
|
BaelWrath Member since: 6/26/2001 From: England |
|||
|
Posted - 6/25/2002 9:12:48 AM |
||||
| I think the artical is quite informative but I expect the basic game design to break down to the level recommended. Also I am a firm believer in 'compile early, compile often'. With new compilers you may as well re-compile the section of code you are working on to spot those stupid errors (if you run the compiler on its most stringet settings, even better)why be left finding errors that relate to syntax when you should be looking for logic errors. Regards |
||||
|
||||
|
MENTAL Member since: 4/8/2000 From: Herne Bay, United Kingdom |
|||
 Posted - 6/25/2002 9:44:55 AM |
||||
| quake 1 compiles in under 2 minues on my machine (PIII 733 256mb), and quake 2 takes about the same time too. |
||||
|
||||
|
dhscompguy Member since: 5/2/2002 From: USA |
|||
 Posted - 6/25/2002 11:00:03 AM |
||||
| I think this article was great for the novice\intermediate programmer that has already programmed a few small games and would like to work towards something bigger and better. I don't think the absolute beginner should have to worry about workflow, though. What is the best way for you to program your *first* game? Just do it! Just bang it out anyway that you can! That's the way I did it. I'm assuming lots of others have done the same. Getting into a routine is great because you'll need it later on but jumping right into planning on your first tic-tac-toe game isn't necessary. Your code may end up looking downright ugly but if the game works then that's all that matters, right? |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 6/25/2002 12:27:13 PM |
||||
| ragonastick: A full build of a project I worked on(in C) took 7-8 minutes locally, up to 25 minutes when compiled remotely on a server (when others were taxing the server). If you plan the structure of source files however, you should rarely have to do a full build. (I think...) A nice feature of VB is it compiles before you tell it to (while you're coding), which makes the actual build very quick. |
||||
|
||||
|
Guardian_Light Member since: 7/22/2000 From: Ontario, Canada |
|||
 Posted - 6/25/2002 2:13:37 PM |
||||
| First and foremost, great job Drew! I was going to mention incremental design in an upcoming article (follow-up to Removing the 'Tech' From Design Document) but you did it so well, I'm not going to worry about it =) (I can focus on other aspects =) Second, have you read Code Complete? Your article just seemed to have some of the points made throughout the book. Next though, quote: Well, to be frank, no. I wrote my first game by trial and error, but if I had done a little planning, it would have been much better. Many of the really tiny projects never are developed beyond the basics, because the code that's been written is such a mess, that adding other stuff is more difficult with each addition. (If you don't plan for them.) Famous fact: The last 10% of a project take 90% of the time. It shouldn't have to. I've been writing commercial games with 15K+ lines of code per project for over two years now, and the difference between 1000 lines and 15 000 is very significant, but if you do the 1000 line projects right, the more difficult ones use the same principles, if not always techniques. If all that matters is what you get in the end, why go through life? ~Michael Sikora [edited by - guardian_light on June 25, 2002 2:17:26 PM] |
||||
|
||||
|
tobiaso Member since: 11/14/2001 |
|||
|
Posted - 6/25/2002 2:36:02 PM |
||||
| Nice article! But why not take incremental development a bit further down the road... by incorporating the game design stage tech spec etc in what the people at Rational call iterations. Warning! I will probably ramble some ;-) One of the biggest problems is that games don't turn out to be fun to play despite the funky graphics/tech specs etc. How can we know what is funny if we don't test it? If this is going to work the game design document _can not_ be a holy bible that can not be altered during the project (and I don't mean simple tweakings of damage/physics etc). The game design document should be a living document throughout the project! The released game will probably not be the game first concieved by the game designer. The game should be playable from day one! Not with all features or the final features but with the most important features. If the thing you do 90% of the time in the game is not fun then the game is not going to be fun when the rest is added either. You may camouflage it for a while but the game will be boring! A build should be made every night and involved people should play the game every day for 30mins or so. well.. I could go on and on about this but thats it for now... Regards! /hObbE [edited by - tobiaso on June 25, 2002 2:38:46 PM] |
||||
|
||||
 |
Khawk Staff Member since: The dawn of time
From: Port Orange, FL, United States |
|||
 Posted - 6/25/2002 3:57:09 PM |
||||
quote: Exactly. Nice article, btw. It seems to me that the more successful development processes are iterative, meaning from launch to maintenance developers go back and change things in previous phases if they need to be changed, but also incremental at the same time. For instance, if you incorporate the game design phase, you have to create the design document or at least start to. A design document is essentially a requirements document, and if you can ever find a requirements document that doesn't change, then you are the man. Well let's say you get to the prototype phase and you see that some game design element ment isn't going to work. An iterative process allows you to take a step back to make changes to your design document and other specifications before forging ahead with any new ideas. The benefit of doing this? You have documentation of your changes, so later down the development road when you're testing for release and you find a hard to detect defect, you'll be able to track how that particular defect was injected into your system. Incremental development is good in my opinion, because it allows you to break down the system into manageable pieces. Adding iterative development is good in my opinion, because it allows you to make changes to these already manageable pieces. It's a win-win situation. Kevin "Khawk" Hawkins CEO and News Director, GameDev.net Author, OpenGL Game Programming Developer Diary |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 6/25/2002 4:11:54 PM |
||||
quote: We have something at my company that's fairly large (A couple thousand C files, IIRC.) It takes us about 2 hours to do a full recompile on a 2 GHz PC. |
||||
|
||||
|
dhscompguy Member since: 5/2/2002 From: USA |
|||
 Posted - 6/25/2002 9:31:07 PM |
||||
| << Well, to be frank, no. I wrote my first game by trial and error, but if I had done a little planning, it would have been much better. Many of the really tiny projects never are developed beyond the basics, because the code that's been written is such a mess, that adding other stuff is more difficult with each addition. >> Please define 'much better'. If a person has developed a tiny project to the point where it has all of the basics of a game, or in other words *is* a game, then they have done their job. They can move on to a bigger project with a better understanding of what goes into making a game. You did it the "messy" way and now you're writing games 15,000 lines long. Maybe that first round of success enabled you to get to that point in some weird way. Even if most beginners went the way of formal planning before trying to write their first game, they probably wouldn't understand what the hell good it did them. Hence, they would have no appreciation. Let them suffer through messy code and soon enough they will be reading books on project management, design patterns, etc. << If all that matters is what you get in the end, why go through life? >> Please define 'the end of life'. Denny "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." |
||||
|
||||
|
CaptainJester Member since: 11/29/2001 From: Ottawa, Canada |
|||
 Posted - 6/25/2002 10:59:20 PM |
||||
| Great article Drew. I always worked this way, but always wondered if other people did this way, or if there was a better way. It's nice to know that this is suggested method of developement and that this is how the pros do it. Thanks. quote: Check out Extreme Programming(XP). The basic concept is to get as much of the design done as you can as well as as fast as you can. Then start working to see what works and to see how dark areas in the design pan out. Then you cycle through design, code and debug as often as needed. --- Make it work. Make it fast. "Commmmpuuuuterrrr.." --Scotty Star Trek IV:The Voyage Home |
||||
|
||||
 |
Gaiiden GDNet Content Lead Member since: 8/30/2000 From: Lincroft, NJ, United States |
|||
 Posted - 6/25/2002 11:18:36 PM |
||||
| Thanks a lot for all the positive feedback guys, always appreciate it cause it makes me write more tobiaso and Kevin made some very nice comments. If I somehow implied in my article that the design doc should be set in stone then I dunno what I was smoking, because I just sent off an email to a newbie asking questions about my You Got Game! article series, and I included a little tidbit: ...but make sure that things [in the doc] remain flexible, hardly any game comes out as it was originally spec'ed. if it was just an aside, then it is well welcomed, because it's definetly a good point Either way it's cool, heh.*wanders off and ponders his next topic* _________________________________________________________________ Drew Sikora A.K.A. Gaiiden ICQ #: 70449988 AOLIM: DarkPylat Blade Edge Software Staff Member, GDNet Public Relations, Game Institute 3-time Contributing author, Game Design Methods , Charles River Media (coming April/May 2002) Online column - Design Corner at Pixelate Unnoficial IGDA chat! [polaris.starchat.net -> #igda] NJ IGDA Chapter - NJ developers unite!! [Chapter Home | Chapter Forum] |
||||
|
||||
|
ragonastick Member since: 5/17/2000 From: Sydney, Australia |
|||
|
Posted - 6/26/2002 3:43:45 AM |
||||
Compile speed answerers: Cool, thanks people.quote: I *think* this may be wrong. There is a feature called "background compile" which sounds like it would do that, but it is actually referring to compilation while your program is running - basically it compiles JJIT (a term I just made up - Just Just In Time). Everything starts out being interpreted, but instead of interpreting a line and forgetting about it, it is remembered. So if you run every part of your code, then once you are finished, it is the same as running your program compiled. I thought the term for this was Incremental Compilation, but I've just checked a book which describes that differently, but I really don't believe that book (it claims QBasic uses 1's compliment, among other herecies )Trying is the first step towards failure. [edited by - ragonastick on June 26, 2002 4:00:54 AM] |
||||
|
||||
|
Guardian_Light Member since: 7/22/2000 From: Ontario, Canada |
|||
|
Posted - 6/26/2002 1:24:43 PM |
||||
quote: It's a fact that well polished games stand out from the rest. "Much Better" might include things like: * No bugs. I don't how many "my first/second" game's I've tried that didn't work on any of my computers. * Support for many different hardware setups. (Scale of quality in game can change according to user's machine.) * If applicable, extra's include high scores, in game help and tutorials, varied game play, multiplayer support, user friendly interface, support for multiple input devices and their respective key bindings... I could go on and on... * Source code that's documented and easy to follow. This is why so many hobby teams fail. No guidelines for style, documentation, variable naming etc. For the sake of fairness, I put together a 25K line game with a few pages of documentation, mostly for requirements. (I did this on contract BTW) It took me six months. I've written similar games with 15K lines in about a month. Granted, I re-used code from other projects, but I designed with the future projects in mind. For every one of the little "first game" projects that we hear of success, I suspect 10 more fail. quote: Well... Yes, it did. I learned that there had to be a better way. Now, I'm passing experience on to those who are just beginning, so they can waste less time then I did. I know that I would have appreciated it. quote: This might be OK, except that people are habitual. The sad truth is, some people will just keep doing it the "way they know" for the rest of their life. (This is worst when they have no formal education in computer science or software engineering...) quote: Death. If all that matters is what you get in the end, why go through life? ~Michael Sikora |
||||
|
||||
|
Origin Member since: 6/20/2002 From: Germany |
|||
|
Posted - 6/26/2002 1:30:16 PM |
||||
| The article gives good advice, that's for sure. Nonetheless I think that nobody is insane enough to code an entire project before compiling the first time... The worst thing I once did was rewriting a module in a different language in one step. I tried to translate the module line by line and I ended up in hundreds of errors just as mentioned right at the beginning of the article. But that was the only time I did such a stupid hack. I expect the average programmer to make use of "incremental development" in any case. I would even go one step further and shorten the average time between builds. Of course, this depends on the size of the project and on the necessity of having to recompile all source files (worst-case scenario). But generally, having a good project and code structure, the time of a recompile after adding or modifying one to three files should be minimal. Visual Studio can be configured to make use of precompiled headers and when using makefiles, only files affected by changes (through the dependency scheme) are to be translated into machine code. So what would I suggest? I would recommend a recompile even after adding one single non-trivial function. And I would recompile after setting up a new module. These are cases where the author of the article would rather continue coding. But I think that it's always a good thing to verify that a module or a function is actually working before digging deeper into code. It's somewhat annoying having to debug a bunch of newly added funtions just to recognize - after having found not a single mistake - that the bug actually sat somewhere in a class declaration or something. But that's only my personal opinion. As I already said, I'm sure that everybody's clever enough to discover himself that "incremental development" is the only way to arrive at one's destination. Additionally, everybody should be able to find his personal average time between builds. And that depends on skill, on the difficulty of the project - and on concentration, maybe.  |
||||
|
||||
|
dhscompguy Member since: 5/2/2002 From: USA |
|||
|
Posted - 6/26/2002 4:47:43 PM |
||||
quote: Maybe the problem isn't a lack of process. Perhaps the new guy just bit off more than he could chew. I'm not saying that you should program your first commercial game with some hacker methodology. For a beginner programming tic-tac-toe I think it's acceptable, though. quote: Do you really think those young punks are going to listen to you anyway? Fools never listen to the wise.quote: I'd agree with the last poster that said people are smart and want to find ways to make life easier. There will come a point when they say "This crap is just too hard to handle! There's got to be a better way!" If that point doesn't come then you just have to push that person down a flight of stairs or something 'cause I think they might enjoy it. quote: Death. Can you define death? What is it? When are we *really* dead? Maybe what you call death isn't an end but a beginning.. or a midpoint.. or something really deep like that. Man, is this off-topic or what??!! |
||||
|
||||
|
Gaiiden GDNet Content Lead Member since: 8/30/2000 From: Lincroft, NJ, United States |
|||
|
Posted - 6/26/2002 5:46:00 PM |
||||
quote: Except me  Well okay I didn't code the entire project, but enough stuff to make my compiler drop out due to too many errors. This was like 4 years ago when I was just starting out.quote: So are you serious or just wanna be annoying? Anyways here's allll the info you'd ever need. |
||||
|
||||
|
Guardian_Light Member since: 7/22/2000 From: Ontario, Canada |
|||
|
Posted - 6/26/2002 7:15:14 PM |
||||
| Most people can agree to disagree on Computer Science, but questions about life, always gets them so touchy... I'm not getting invloved in this one =) If all that matters is what you get in the end, why go through life? ~Michael Sikora |
||||
|
||||
|
dhscompguy Member since: 5/2/2002 From: USA |
|||
|
Posted - 6/26/2002 7:43:25 PM |
||||
| Well, what fun is debate without annoyance? I was trying to be a pain but it's still a serious question. Too bad nobody can answer it! They can go on and on about it in newsgroups, though. Try a search at groups.google.com if you so desire. |
||||
|
||||
|
BaelWrath Member since: 6/26/2001 From: England |
|||
|
Posted - 6/27/2002 2:12:55 AM |
||||
| I could tell you what it is but then you'd just have no meaning to your lives and no reason to go on would you? ho hum Normal service will now resume ( hopefully ) .... Regards |
||||
|
||||
|
dhscompguy Member since: 5/2/2002 From: USA |
|||
 Posted - 6/27/2002 9:27:55 AM |
||||
| Define 'Normal Service'. Har. Har. I'm all for the death of this discussion. Whatever that means. |
||||
|
||||
|
Gaiiden GDNet Content Lead Member since: 8/30/2000 From: Lincroft, NJ, United States |
|||
|
Posted - 6/27/2002 10:20:19 PM |
||||
| Dude don't be side-tracking my article thread. Bad things happen to people who do that I will start deleting or editing irrevelant posts to keep this on topic |
||||
|
||||
|
Ecko Member since: 9/7/2000 From: Etiwanda, USA!!!!!!! |
|||
|
Posted - 6/28/2002 1:23:47 AM |
||||
quote: my last game was 24,000 lines (w/out comments) and took around 2 min to compile. |
||||
|
||||
|
Page: 1 2 »» All times are ET (US) |
Last Thread Next Thread |
|
