There must be some best practices on how you create your game architecture/skeleton. One of the best resources that I found is: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ My primely focus is for iOS games using cocos2d.
What is your know how on this topic?
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.
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.
