Some background:

I want to start developing games, and taking some of the advice given in this site, I've started with something simple and familiar, such as pong, tetris, etc. I want to take as much time as needed to make sure that I have the basics right before moving on to something bigger. I have medium programming experience but I realize making games is a different thing.

I find myself wondering many things like should this be in a separate class? Should this module handle this stuff or is it better to let other modules have that kind of functionality? For example, the bouncing of a ball in pong, right now is handled in the ball module, but maybe it's better that some other module did it.

Right now I have different modules: one for the graphics, one for the game logic, and others for the objects (depending on the kind of movement required, not all the objects are alike). I know I am asking a lot, any tips you have will be very much appreciated.

Short question:

What's the right or standard way of separating the modules? What have you found most effective? Is it enough to just keep the drawing (graphics) and the logic separate? Is it necessary to have a lot of classes? (for example for the objects in the game, to handle the movement, etc)

  • \$\begingroup\$ Most people will say "component architecture." I believe more in MVC, but I've never built big games. Welcome to GD.SE \$\endgroup\$
    – ashes999
    Commented Feb 19, 2012 at 22:11
  • 2
    \$\begingroup\$ Component/Entity architectures are a bit deep for someone just starting out. @Ghanima what I think you need is to read up on OOA/OOD (the A is analysis, the D is design), it won't take very long but a quick survey will give you a vocabulary to think about these kinds of problems in. Follow that with a quick survey of "design patterns" to see how people have applied that vocabulary to common problems. \$\endgroup\$ Commented Feb 19, 2012 at 22:23
  • \$\begingroup\$ @PatrickHughes I heard about design patterns in college but it's all still very new to me, I will read about OOA/OOD like you suggested. \$\endgroup\$
    – Nadia
    Commented Feb 19, 2012 at 22:30
  • \$\begingroup\$ @Ghanima I assume you already know about solid object-oriented design, test-driven development, etc. so then in that case, just pick a small game and run with it. \$\endgroup\$
    – ashes999
    Commented Feb 20, 2012 at 1:02
  • \$\begingroup\$ Here is something I posted for a similar question on engine architecture: gamedev.stackexchange.com/questions/23533/… \$\endgroup\$
    – Nic Foster
    Commented Feb 20, 2012 at 5:44

1 Answer 1


The way I generally have learned any aspect of programming including game engine design is by reading books then making something crappy and realizing it was crappy because I ignored the patterns in the books. So I read the books again.

The books I have on this topic have been very helpful:

  • Applying UML and Patterns (Craig Larman)
  • Software Engineering for Game Developers (John Flynt)
  • Game Engine Architecture (Jason Gregory)

The patterns as suggested in the comments, are very similar or exactly the same across all types of applications including games. Before you start worrying about game engine specific patterns, I would look into the more general design patterns. Pick a language you like and find a book called "design patterns in [language name]". Since the patterns are so similar, once you know them, apply them to a game like tetris as you've suggested and you'll start to see their benefits.

  • \$\begingroup\$ This might be overkill for someone new. UML too. \$\endgroup\$
    – ashes999
    Commented Feb 20, 2012 at 1:01
  • \$\begingroup\$ The list I provided was the route I took. The route I'm suggesting for him is the last paragraph. Not overkill if he understands the semantics of his favorite language decently. \$\endgroup\$
    – brandon
    Commented Feb 20, 2012 at 1:04
  • 1
    \$\begingroup\$ @ashes999 Yes, I hate UML and every UML book puts me to sleep. The Flynt and Gregory titles sound interesting, though. \$\endgroup\$
    – bobobobo
    Commented Feb 20, 2012 at 1:08
  • \$\begingroup\$ @bobobobo agreed on the hating UML books. The non UML parts of that book are definitely worth the read. I wouldn't read it like a novel of course, check the contents and you'll see which parts are worth the time. \$\endgroup\$
    – brandon
    Commented Feb 20, 2012 at 1:11
  • \$\begingroup\$ Patterns are great tools for solving problems. Though, instead of the first book, I'd recommend en.wikipedia.org/wiki/Design_Patterns . \$\endgroup\$
    – Exilyth
    Commented Feb 20, 2012 at 8:48

You must log in to answer this question.

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