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?


2 Answers 2


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.

  • 1
    \$\begingroup\$ Feel free to mark it as the answer if you think it's right! It took a lot of painful tries to come up with something that worked for me though. By the way, this is heavy on the programming and skips a lot of art and music steps, those work in at the same time as the iterations for me though \$\endgroup\$
    – brandon
    Commented Jan 9, 2012 at 19:24
  • \$\begingroup\$ I like both answers a lot. But I don't think I will do step 2, 4, 6 for my games at this point. From step 8, it is more of implementation and other activities than design. Only reason I accept this as an answer is that this seems a superset of the other. As you suggested, I will first start with Tetrad's approach and then see if I need any additional steps in your answer. \$\endgroup\$ Commented Jan 10, 2012 at 17:42
  • 2
    \$\begingroup\$ @Paul good plan. Some of it is meant as a joke but still provides hints towards what you'll experience. I'de look into the events more if I were you though. Say I wanted to make a RTS I would have events like "Create structure,upgrade structure, sell structure, cancel build, move unit, build unit form structure" etc. Writing these out and then further describing how they work on a system level may be helpful before you dive into code. Good luck though! It's always an experience on your first solo projects \$\endgroup\$
    – brandon
    Commented Jan 10, 2012 at 17:51

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.

  • 4
    \$\begingroup\$ I would write at least a few notes before you start programming, but yeah a full design-doc will just get in the way of prototyping. \$\endgroup\$
    – jhocking
    Commented Jan 9, 2012 at 18:37
  • 3
    \$\begingroup\$ That's intuitive but coming from formal programming background, I feel like I need to do something before coding. I guess design summary and to-do list would be enough with this approach. Thanks. \$\endgroup\$ Commented Jan 9, 2012 at 19:57
  • 1
    \$\begingroup\$ A design summary and todo list are exactly what I had in mind by "a few notes". Although keep the todo list fluid; just write down enough tasks to get started and then get started. You'll add more stuff to the list as you go. \$\endgroup\$
    – jhocking
    Commented Jan 10, 2012 at 1:44
  • \$\begingroup\$ @Paul I assume you're thinking of UML-like constructs when you say that you're coming from a formal programming background? All those diagrams (in my humble opinion) only serve the purpose of showing your work to others without having to explain the code. I think design docs serve the same purpose. They can be used to show your game to someone if you want money or other kinds of support from that person. \$\endgroup\$
    – TravisG
    Commented Jan 10, 2012 at 15:24
  • \$\begingroup\$ @heishe I understand that I don't need to show my work to others at this point. I was more concerned with design deliverables for myself to review the game later. Anyway, I am satisfied with the answers I got. \$\endgroup\$ Commented Jan 10, 2012 at 17:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .