Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There must be some best practices on how you create your game architecture/skeleton. One of the best resources that I found is: My primely focus is for iOS games using cocos2d.

What is your know how on this topic?

share|improve this question
up vote 3 down vote accepted

In addition to MVC pattern as the other reader suggested, I would suggest you learn a little bit about discrete event simulation - because your game engine heart is basically that.

In brief, that means:

Your game is described by a model. A model is composed of game objects. In a real time strategy, this would be terrain, units, static objects (trees), buildings, players, etc. As time progresses, the model is repeatedly changed.

Model your game elements as simulation entities which are scheduled to do actions at a given point in time. When selected at some point in time, each game element produces an action based on the current state of the game (the model). An action changes the game state, produces an event and schedules the game object that produced the action again at some time in the future.

You can also have triggers - whenever a matching event (that an action created) is detected, a trigger is triggered (e.g. an action that moves a player character around produces a MoveEvent which can be detected by a CharacterEnteredRegion trigger, that then does something with the game state again - for instance, creates more monsters).

I found this approach quite extensible and adaptable. In fact, it can be used both for real-time and turn-based games.

share|improve this answer

First off, study MVC architecture. I've done a lot of UI design and this has really helped me to understand these roles well.

If you can, explain your code to someone -- even if they don't understand what you're talking about. I explain things to my wife all the time, and even though she's probably not even listening, it helps to clarify things for me simply by organizing my thoughts into words.

Lastly, don't be afraid to rip the guts out of your code. If you find that something doesn't seem to work right, come up with a better way to do it and re-implement it, even if you have to tear half of it out to do so. A good revision management system can help here.

share|improve this answer
I worked in ASP.Net MVC for a period of time + other MVC frameworks. Is the Web MVC approach a similar one to Game MVC? M = Ship Model, Enemy Model; V = View Layer where that ship will be; C = Handles User Inputs, Input Layer; Does this looks right? – Andrei T. Ursan Apr 8 '11 at 14:15
I'd say so. Just make sure that (1) the view works on nothing but the model and that (2) the controller affects nothing but the model. Also, if you have view-specific model (texture ID's, for example) try to keep them out of your base game objects (model). – stephelton Apr 8 '11 at 14:24
Agreed, most game experiments I've had were based on the MVC. – axel22 Apr 8 '11 at 15:25
I wouldn't say MVC is the most logical approach to game architecture by far. – The Communist Duck Apr 8 '11 at 15:28
MVC is not really used in game architectures. In fact, I've never met a professional game engine even remotely using MVC. I've encountered some MVP in production code, and then promptly helped gut it because it was holding back development. I'd encourage you to read this: as a means of helping out – A.A. Grapsas Apr 8 '11 at 15:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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