How should a game work? (Brainstorming)

There's not really a whole lot of stuff out there (if there is, I can't find it) about how to put together a game. Unfortunately this post isn't so informative. It's a brainstorming post where I try to plan how I should go about designing something. That means that you shouldn't expect to find too many pearls of wisdom in this post. This is me trying to figure something out, not me offering a brilliant solution.

At the heart of it the game is just an endless loop that says:

1. Handle user input
2. Process AI
3. Update game values
4. Draw graphics

The loops vary and can be more or less sophisticated depending on how you decide to make it. I'm not going to talk about this loop beyond what I've said already because someone else a lot more knowledgeable about the topic has already made a great write-up about it. I already have my own crude game loop figured out. At the moment I'm more concerned about how best to organise what happens inside point  #4. I'll give the other steps a brief mention, however.

#2 AI
The AI is an entirely different problem that I'll cover in the future. At the moment I have simpler things to consider. If you take all the complexities aside and think about what the AI step should actually do, it's just a whole heap of calculations to determine the positions of units and what they're doing.

#3 Update game values
This is also something I've decided to leave for the future because I haven't thought about it enough in detail yet. Basically this is just the part where we determine if units are still doing something. This step might even be merged into the AI step because they'er related. An example of this is soldiers shooting a building. If the soldiers are still in range to shoot at the building then the building needs to be losing health, for example.

#4 Draw graphics
Anyone can draw some graphics. The difficulty comes with figuring out what to draw. Some kind of system is needed that keeps track of all the sprites in the game and draws them when needed. This system needs to:

a) Unit & Building sprites list
The best way I can think of to draw all the sprites is to add them to a big list of sprites to draw. If a player makes a new soldier, this soldier sprite is appended to the list and subsequently drawn. If this soldier dies, then he needs to turn into a corpse sprite for a while before disappearing entirely (or I could leave him there as a permanent stain upon the battlefield, which is also cool). In any case, the very first thing #3 should do is draw everything in this list and figure out a good way to add & remove sprites from this list. This list shouldn't be a simple array, but something more intelligent like a vector/dictionary.

There should also be another list that will be drawn after the list I just described, and this is the effects list. So explosions, fire, smoke, rain and whatever else should be drawn here.

b) Draw from the perspective of the player
In an RTS game this means that the player can only see his own units, and also see whatever is in the light of sight of the player's units. I think the easiest approach to this is to go for the fog of war type of thing where everything is drawn and then a layer of fog goes over the top, shrouding everything that shouldn't be visible from sight. This gives me then the simplicity of being able to draw everything onto the map, then selectively reveal parts of the map to the player instead of selectively drawing only based upon what a player should be able to see.

There's two styles of fog. The first is to have a completely black map which you have to explore thoroughly or else you see nothing. The second is to have a grayed out view of the entire map, but you can still see features of the map - just none of the units or buildings. The former was much more common in older games like Warcraft 2, Starcraft, Age of Empires and C&C: Tiberian Sun. The latter is basically the 'status quo' of all modern RTS games and features in basically everything. I haven't seen the old style fog of war in years.

The question is, which should I use? It'd make more sense to go with the latter in some ways because of the modern setting of the game. It seems quite silly that a space-fighting force couldn't do a simple radar scan of the map to determine its terrain features before landing. Although not at all related to the fog of war, one game had a very cool feature, in my opinion, that is deserving of a special mention. In C&C: Tiberian Sun the minimap was actually disabled until you built a radar structure. This means that you could only have a minimap if your radar structure was functioning. I might go with this idea and put it in my game because it actually makes a lot of sense and is quite a cool idea.

Concluding #4

That should be enough planning for me to get started on the next part of my little game project: The sprite list and the fog of war.