Good game design process for a do-it-all programmer

Question

I am pretty new in game development - on Android platform and thinking about one-man game development. I know I can't professionally do everything such as graphics, sounds, and music but I think I can worry about them later once I finish its coding.

My current road block is setting up game design process. I've read some books and lecture notes on game design such as A Theory of Fun, and Book of Lenses, but still not sure about the process.

Of course, making game ideas is kind of separate process in long term so I can assume I already have an idea for a game in this question. But for conceptualization, what can I do? I think people usually make a design document and story boards for this. But for android platform, I am not sure design document is necessary - maybe design summary would be enough. In that case, would story boards (or doodles of game screens) be enough for design process? What else do I need to do in the game design?

Answer 1

I've made a few mobile games, made a little bit of money on the apple app store, and have started to almost exclusively use this process. But as all development processes go, you will develop your own after a while.

This is a copy from an email I sent to one of my team members.

1. Write out a short description of the game
2. Write out the main gameplay events
3. prototype the ideas on paper and see if they logically make sense. "Play" through the events on paper
4. Write a basic use case for each of the events
5. Draw some concepts of the artwork for the game
6. Draw use case diagrams for each of the basic use cases
7. Detail the required system interactions to make the use cases possible (don't skip any interactions that seem like black magic "click the screen and unicorn spawns on the terrain". There are a lot of data transformations going on to get the unicorn to the exact terrain location under the mouse.)
8. start writing out a class diagram (avoid God classes such as "GameCoordinator" and instead make a class for each logical object and break apart as much of the interaction between these classes as you can, this was a painful lesson)
9. make a playable demo of the game with limited functionality
10. have some friends play and break it
11. iterate...iterate...iterate on gameplay events
12. draw out the interface.
13. make the interface work
14. start sending out review requests to all of the mobile app review websites
15. polish the interface
16. test the hell out of it on MANY mobile devices, not just yours
17. cry at the bad reviews
18. fix the big problems
19. smile at the good reviews
20. Update the game

All of that being said, you probably won't appreciate this type of plan until you rapid prototype your first few games. I'm torn between telling you to use this plan and saying just prototype it and iterate as Tetrad said. I will say, avoid getting too stuck on design processes for your first game or two. Coming up with a design process is less significant than the experience you get in learning why you need to have a process. Still I wish I had a process for my first game because I had to refactor most of the code once it started making money and I needed to update a few things.

Answer 2

Personally I would start with just rapid prototyping.

For smaller games, design docs are really only good at forcing you to think about the problem as a whole. There isn't any reason to write everything down if you can encapsulate it all in a prototype.

Get some game ideas in your head, and implement the core loop. If there seems like there's something there, iterate on it. When you have something fun, build the boring parts around it (menu screens, options, etc.) and ship it.