Game structure, any thoughts?

As a practice project, I'm working on a turn-based battle game with a hexagonal map.

Right now I'm in an early design phase. I'm trying to figure out how to structure everything before I start thinking up functions and such.

Well, the way I'm doing this is the model (game logic) is entirely independent and is unaware of the control system that modifies it (via mouse clicks and keyboard presses), and also unaware of the view system which represents it to the user (by sound and graphics). In the end, I will slap it all together into a working game after each component is finished, and use some kind of scripting to manage gameflow and set everything up.

So, this brings up the challenge of how to organize the game while maintaining flexibility. Had I smashed it all together, I could use graphics, sound, and game logic together without much worry, but this does not work in my design. Certainly, it wouldn't be right to give the model control over sound and graphics (it doesn't even know these exist!), so an event like a rocket being fired has to be externally controlled by something that has access to both the model and view (which is divided into independant audio and visual components).

For example, let's say the player wants his unit to shoot a rocket at an enemy unit. I have to figure out how the game will handle the game logic (decreasing ammo, hit/miss, damage dealt, etc.), the graphics (such as the attack animations), and the sounds (such as the rocket firing and the resulting explosion) in an organized manner.

Here's how I see this happening, controlled by some external master, such as a script. I've labeled what I consider seperate actions on behalf of the script.

The sprite for the attacking unit is rotated to face the enemy (1 - Graphics). Now the attacker's rocket count goes down (2 - Logic). Next, a sound is played for the rocket firing (3 - Sound). Now the projectile is shown moving from the attacker to the enemy (4 - Graphics). Now, the game logic is informed of the attack and told to resolve the attack using information about the two units and the weapon involved (5 - Logic). Now, there is a branch. If there is a hit, an explosion sound is played (6A - Sound) and an explosion animation is shown (7A - Graphics). If there is a miss, the rocket can be shown simply moving past the target until it reaches its maximum range, at which point the rocket dissapears (6B - Graphics). If the enemy is destroyed in the attack, some script for the enemy exploding might be run.

Does that make any sense? And more importantly, is that a good way to go about things? Any suggestions/advice? I spent a while working on this post, so any input would be really appreciated.

All the internal game engine should control is scripting, logic, sound, networking (if applicable), and drawing the graphics. I like to include input as well, but in your case, you don't want it. The reason you put the graphics drawing in the engine, is because it is faster.

Okay, this is how you could do it. The engine has enough functionality to load and execute scripts, draw some images to the screen, have some logic, and sound. Just enough to be able to draw the graphics, not actually defined what to draw. Okay, now the game engine cannot run by itself. To start up the game you must have a startup script. This script basically tells the game to initalize the graphics, set the graphics mode, etc., and then it goes to a menu script. The menu script represents the main menu. It tells the game engine to draw your titlescreen, and all the buttons (for like new game, load, etc.). Now, since you do not have input in the actual engine, just handle input like they are events. Like if the mouse clicks, instead of the game engine just picking up that the mouse clicked wherever and do whatever it needs to do, it makes an event. Have an event, like GE_BUTTONSELECT if the mouse selects a button. Then the parameters for it would be, what button did the mouse click? After the script determines what you clicked on, the script goes to another script. This script starts a new game (just imagine we started a new game). It sets up some variables, asks the user their name, stats, etc. Then, it'll start a level script, which is the script that handles the level. This level script is in charge of loading up the map, setting up all the actors, adding objects to the screen, displaying the HUD, AI, etc. There are two ways of having the data in yor script (not the commands, the data. Like a NPC's stats). You can make it a part of the script, or you can make data files outside the script. The first route is the easiest. Just make some sort of area in the script that contains all the data objects. This is sorta how EXE's work. The second way (my favorite) is using external files. Let's say you have a Evil Warrior named Bob. Well, if you need Bob in your script, you just simply make a command from the script that loads up Bob. Okay, now you have Bob, and he can be used from anywhere in your script. Doing it this way, you can share an object from different scripts, without having to have each script have the data for it. This can be expanded. I plan on having my engine allow special effects to be in data files, like explosions, that way I can use a generic explosion I make in lots of script files without having to code a new explosion every time. Okay, back to the script. The game is going for a while, and the user decides "I wish to go up". Well you press W on your keyboard. The engine picks this up, checks your key configuration script, sees what event that button triggers, and sends GE_MOVE to your character, Steve the Hated Dude. The parameter is EP_UP which means to move up. When the next game loop executes, the character processes the event, and moves up. There is no way you can keep input completely away from the engine. There must be some way that input is processed. Even if you handle the input in the script, the engine must interpret the script, and to do that, it must be able to take in input.

Now some things should be pre-made within the engine, like a tile engine. One script has the command "StartTileEngine" and the tile engine starts up. Now all the script has to do is tell the tile engine about all the tiles, and the tile engine will display them.

When the user wants to quit playing, the game makes a GE_QUITGAME event. When this is processed, the game goes to the quitting script. This script basically shuts everything down.

If you plan your engine right, the engine will become the body of your game, and the scripts will become the brain.

PS: Oh yeah, and your way does make sense :D

Thanks a lot. That really helped to put it in perspective and that's definately the kind of flexibility I was thinking about. Right now before I start writing classes and functions, I'm reading "Data Structures for Game Programmers". It's amazing how much I learned about things I already knew about. And wonderfully enough, he explains everything with SDL, which is exactly what I'll be using.

Also, what's a good way to organize the engine? Obviously I'll do work in seperate files, but is it a good idea to seperate them into namespaces, or maybe even classes (as they do have to store data like tiles, map layouts, active characters and units on the screen, etc.)?

So basically, I should let the scripting handle just about anything that has to do with gameflow and initializing, such as creating "events" that control the flow for attacks (such as in my previous example), creating menus, switching from battle to battle, etc?

Also, for the sake of flexibility, I'm intending to add on-off switches and variables that can be modified by the scripting. For example, if a certain goal was achieved, you could turn that switch on for use in a gameflow decision later. I've recently read about bitvectors. Is it worth it to create a bitvector for an array of "on-off switches" like this?