Development Milestones

I'd swap it to 3,2,1,5,4

Hack out some gameplay, get stuff that does things kinda like you want.
Throw on some menus / console so you can tweak things better.
Now that you've played around with the ideas and know what is doable, design away. Figure out what you really want, and start over.
Get your gameplay working the way you really wanted and make your first level. Throw on the polish of an intro menu and then get people to give you feedback.
Now go finish the game, and fix things you think were reasonable feedback.

The key thing I learned is that the design thoughts of lets do X,Y,Z! cram you into a corner you have a hard time working out bugs from. Throwing together something really halfassed, but working is way easier. From that level you can look back at how things really tie together, and put things back into something more reasonably designed. Once you have a portion of the game fully designed, it is much easier to properly design and code later portions of it, since you already hashed out most of the major pitfalls before you reached the point where changes equate to total refactoring.

I got way futher along in my text rpg over my RTS game mostly because I spent a lot of time working on interface for the RTS and minimal time on gameplay. In my RPG ideas the interface was simply a text parser, and as such all my time was spent adding features to the gameplay. Something that flowed much like this
+add level load
+player can walk through rooms with "go"
+add level save
+add room descriptions, and the command "look"
+add triggers that hold gamestate
+tie descriptions to gamestate
+add items, and commands to "look" "take" "drop" "inventory"
+all this text is getting a little out of hand, work on a better interface.
-+color code text by type
-+add pgup/pgdn scrolling of text
-+add inventory pannel
+add win/lose triggers and triggers based on items
+add "use" to items
etc.

That isn't to say i made good games either way. But i learned enough, and made something complete enough with the RPG/adventure game idea that it was demoable as a real game, even if it did lack content at the moment. It took about two days to get that amount of stuff working right, but that is after a previous attempt that was just hacking together tonnes of random crap to figure out what was the best way to implement things so i could easily edit the levels. (check sig)

Quote:

Original post by KulSeran I'd swap it to 3,2,1,5,4

+1, especially moving #3 (functional gameplay) to the front.

Personally, I think a working prototype is much more important than a 1,000 page design document. Prototyping is, in fact, a part of design - you can't know whether your idea is workable without actually playing it.

It depends on the game and who you work with. My experience of working on projects thus far is this:


1. Design documents ready.

2. Mockups of various screens in the game to get approval from whoever has the money or power to release the game.

- This step is important to avoid unnecessary UI and art changes later in the development -

3. First playable. Crude menu system (enough to click on "Play" and "Exit"). Art may not be finalized but you can play the game to show some basic gameplay mechanics.

4. At this point, the natural progression would be Alpha -> Beta -> GM.


The features implemented in these stages vary from projects to projects. It doesn't usually go the way you described it: "get feature A done 100% and never touch it again, move on to feature B." Everything in the game sort of grow together. Changes in certain area may result in changing other aspects of the game. As a matter of fact, the first level is usually one of the last things that gets finalized because that's typically the beginner/tutorial level where you want players to be comfortable playing the game.

Sounds like a software engineering question more then anything else.

I think a lot of your approach will depend on who is doing the development. If its just an individual project, then you could probably use an agile software development process, where your documentation is "just good enough". If you've got a widespread team where communication is going to be more difficult, up front documentation will be much more important. You could probably use evolutionary prototyping, which works good for games since you can prototype the 'fun factor'.

Anyways, here are two good resources to check out.
http://www.swebok.org
http://www.agilemodeling.com

If you are working on this by yourself or with a small team, I've found that using an agile method to structure the development process is incredibly beneficial. Instead of trying to plan the entire game at once and then implement it in its entirety, an agile method of development works iteratively by breaking the game into a number of iterations. Each iteration is treated as a small software project in and of itself (so it has its own planning, development, and testing stages), but the iterations are small enough that most of the time is spent in development and not on planning.

For example, rather than trying to plan "out every event that will ever happen in the game," I would find it far more beneficial to simply put together a simple prototype of the game as a first iteration and then to expand on this prototype in further iterations.

The key to an agile method is adaptability. Iterations are small enough (both conceptually and temporally) to allow for somewhat significant revisions and changes to be made from one to the next. The agile method works really well for small teams, even on complex software--perhaps especially on complex software because it helps you avoid working yourself into a corner.