What's this game about?
You control a evil mastermind that's bent on taking over the world! Or at least his city.
To accomplish that, he will find and recruit as many minions as he can, and send them or lead them on missions, for the good of mankind. And of course, himself.
Where is it set?
This game is set in a small city in our age and time. You will move all over it, it's almost completely visitable, and under it, as your base is in the sewers.
What do you control?
You control small, big headed minions, each with his unique personality and stats.
How many do you control?
At any given moment, you can control up to 8 minions, tough you will usually be controlling your avatar, the evil mastermind.
What's the main objective?
Conquer the world!
This is one of the games I’m currently developing. I’m not going to say anymore about the general game design, as it’s an idea I hope to use for personal stuff, and because this blog is about the technical side.
So, let’s get technical then. The game is written in C# and XNA. It might or might not be the definite language for the game, as right now I’m using the whole thing as a prototype. The game is for windows, I’ll worry about porting and the like when I’ve actually got something.
Hum, the architecture then.
Ignore the green boxes. Right now I’ve got, starting from Game, the branches that end at: EntityManager, MapGrid and Modes done, including the Entities (as far as collision and animations are concerned), and all that hangs from MapGrid.
A quick overview of the stuff so far, and I’ll update as I code along.
SceneManager
A state machine that changes Scenes. It has only one scene active at any given time, and Scenes are discarded, not saved, when a new one is selected.
Scene
States the game can be in. Structural purpose.
PlayScene
The main scene of the game, it provides content, NOT logic. This might be a bit hard to understand, but basically, once playing, we need a second state machine to keep track of how we play. More often than not, from one play mode we don’t change the content but instead the changes are more subtle, and while we don’t want to just cram all the possible options for every situation in the PlayScene, it doesn’t make sense to swap to a new Scene and reload all assets, logic or whatever.
For example, in the game I could have the fighting, normal and dialog modes. In all of them the same graphics are still loaded, the player still is on screen, etc… The changes here are more along the lines of player control, dialogs shown, Bot decision paths…
That’s why I introduce…
Mode
Mode is the thread of your process, so to speak. PlayScene is always in a Mode, and modes can be swapped in and out easily. Modes dictate the logic the resources of the PlayScene must follow. They hold all the logic of PlayScene, and are used as different “logic paths” for the game components to follow.
And logically, Modes don’t have any “content” themselves, apart of the needed to run their own logic. You could say they are the cartridges in your gameboy, and call the shots in all the components of PlayScene.
CityMap
It’s a collection of zones, as well as an actual map where to choose a location. Only basic functionality to support one scene is implemented right now.
Zone
It’s a place with a map, scenario items and entities, so the class has the necessary tools to handle them.
MapGrid
Holds the tiles, the scenario items and a tile-collision map generated from the load files of terrain and scenarios.
And… that’s all for now. Entity deserves his own post, and the rest isn’t really developed yet. I’m still deciding what to code next… maybe some input, or perhaps some basic path finding and random movement.
