I am writing a simple 2D game (for mobile platforms) for the first time. From an abstract point of view, i have the main player controlled by the human, the enemies, elments that will interact with the main player, other living elements that will be controlled by a simple AI (both enemies and non-enemies). The human player will be totally controlled by the player, the other actors will be controlled by AI. So i have a class CActor and a class CActorLogic to start with.

I would define a CActor subclass CHero (the main player controlled with some input device). This class will probably implement some type of listener, in order to capture input events. The other players controlled by the AI will be probably a specific subclass of CActor (a subclass per-type, obviously). This seems to be reasonable. The CActor class should have a reference to a method of CActorLogic, that we will call something like CActorLogic::Advance() or similar.

Actors should have a visual representation. I would introduce a CActorRepresentation class, with a method like Render() that will draw the actor (that is, the right frame of the right animation). Where to change the animation? Well, the actor logic method Advance() should take care of checking collisions and other things.

I would like to discuss the design of a game engine (actors, entities, objects, messages, input handling, visualization of object states (that is, rendering, sound output and so on)) but not from a low level point of view, but from an high level point of view, like i have described above.

My question is: is there any book/on line resource that will help me organize things (using an object oriented approach)?


  • \$\begingroup\$ Search SE and the web for Component Architecture or Component Oriented Design or the like.. I think it will fit in nicely with what your thoughts currently are on design. \$\endgroup\$ – James Nov 18 '11 at 19:33
  • 2
    \$\begingroup\$ Component architectures may be a bit heady for someone new to OOP and writing their very first mobile game. Components are a solution to complex problems that our friend here won't experience until he's got some experience under his belt, IMO \$\endgroup\$ – Patrick Hughes Nov 18 '11 at 20:28
  • \$\begingroup\$ @PatrickHughes Reading his description of having an object for the actor, then an object for the actors AI and then an object for the Actors representation... Well that sounds like a person already thinking in component design who might be better off just looking into them directly to answer the question of where does the animation data go \$\endgroup\$ – James Nov 18 '11 at 22:00
  • 2
    \$\begingroup\$ @James It's certainly a good first step in that direction and normally I'd totally agree because I <3 that stuff; but it's also the first step to breaking down a design to objects. To someone making a simple game for the first time using components is like using an elephant to hammer in a nail, messy for all concerned and you need to borrow heavy equipment. \$\endgroup\$ – Patrick Hughes Nov 18 '11 at 23:03
  • \$\begingroup\$ You might want to check out this. A great collection of component-based design information. \$\endgroup\$ – Mike Cluck Nov 19 '11 at 1:50

"Organizing things using an object oriented approach" is a subset of Computer Science. It has nothing to do with "games," it is simply how programs are put together.

Since you're talking about an "abstract point of view" search online for references to OOAD (object oriented analysis & design), or if you like books the Head First series is really really good. This will give you mental tools to break down problems into object oriented designs.

Those designs you can then implement in your OOP language of choice, for mobile phones that's probably Java or Objective C.

Now that I've completely divorced the "game" thing from your question, the programmer's stack might be a better place to get OOP design answers. Then back to here at gamedev stack for specific questions on efficient rendering, GUI options, game state handling, audio and things like that.

After that go take a look at the mobile platform SDK that you're writing for. Even odds bet that they have sample code for a simple, 2D graphics display and probably a scrolling map with sprites and a main loop.

Another resource will be to check out commercial mobile game engines, they typically have design overviews showing how their systems fit together and they will have forums that you can use to get an idea of how people are using their system design and the problems they have.

  • \$\begingroup\$ I think i didn't expressed myself clearly. Writing 2D (and 3D) games in general should be an 'old' established practice. Using an OO approach for this purpose too. What i am really asking is: where can i find informations about how people already "solved" this design problem (classes identification and design, how to handle world updates, messages, etc..). It is like writing a low-level 3D engine: people are writing 3D engines since 15 years (more for 2D games), so i think that has emerged a 'standard' way to design such softwares. Just to have a good starting point... \$\endgroup\$ – lukeluke Nov 18 '11 at 23:23
  • 1
    \$\begingroup\$ It's not a solved design problem. Game development is best seen as an R&D effort to maximize sometimes conflicting needs in deeply connected systems. The balance between hardware and software is constantly changing and beyond that the fact that the typical game industry lifetime is only 5 years means that a lot is reinvented every cycle. So the best idea really is to take lessons from outside the industry and apply them because inside the industry you won't find a consensus. \$\endgroup\$ – Patrick Hughes Nov 19 '11 at 0:15
  • \$\begingroup\$ R&D apart, i am speaking more about pure design, not thinking too much about optimization. Let's talk clearly: there are thousands of 2D games, all with animated characters, physics, AI, input, sound output, game logic and so on. How would you describe, using an OO approach, this situation? Since i think there are a lot of 2D games (engine (low-level part) + game logic (high-level part)) programmed from 1980, i thought that some good book could present this in a clear and robust (that is, used in real projects with success) and that could be a good starting point... \$\endgroup\$ – lukeluke Nov 19 '11 at 7:56

So the simplest approach to OOD Game engine would be what you sketched out in your question.

  • you got actors, derive human actors from that and npc actors and other objects

  • each object has either 'draw()' or informations to draw it and used in an graphics engine

  • same goes for sounds, inputs/controls and so on

  • the main work happens in the game loop, which calls 'draw()','processinput()' etc. for every object or a system to do that forine of those functions

All of this has nothing to do with an engine in particular, but just for simple games in general, and has many flaws.

What you should do is look on this site for general pattern used for games. It's a really good site for people coming with your approach of design, what the problems are and the alternatives. It doesn't provide a tutorial of that sort, but rather examples and pitfalls.

In the comments someone said that component based design would be to difficult to do, but learning why it's a thing can't do harm either.


It's not a solved problem because designs optimize for various things, optimization being one. But other designs optimize for coupling, reuse, fast to implement, easy to extend, statically typed, dynamically typed, etc. There's no common approach. Heck, you can't even find a definitive answer of what OOP is with regards to general programming. You'll only ever find patterns and ideas that have come and gone. One general source of that would be gameprogrammingpatterns.com


Not the answer you're looking for? Browse other questions tagged or ask your own question.