Tuesday, September 24, 2013

What makes a game;

and the not-that-easy road to out first playable prototype.

Hello again!
Today we are going to talk about what makes a game and our next steps towards our first prototype. This is the first post of the real game making; that btw consists of planning and developing. First things first, we are going to start with the planning. I'll try to make a concise series of posts, try to go through it all while making the games and prototypes.

Guide Level: Intermediate,
For those who know a little C++ and knows a little Object Orientation or, at least, Data Structures.

A game is... well, everyone knows what a game is; hard to explain. Still, what are the components of an average computer or console game? Since this is a game programming blog, I'll talk about the way I see a game: as a software.

Any game, on high level, can be modeled as three integrated main blocks: System, Logic and Output.

Simplistic high-level model of a game.

In this model:
  • The System block is responsible for anything related to the OS and Hardware, where most platform-specific code comes in. Ideally, when porting your game to other platforms, this will be the only block that would change.
  • The Logic block is the game's logic itself, the inner workings, rules, simulation. It depends on the System block to handle tasks like creating timers and managing memory; and also depends on the Output block to gather input and update the game multimedia layer.
  • The Output block prepares the Interface and Sounds to be played by the System block, as well as gets input from the player.
As you can see, both the Logic and Output blocks depend on the System, but the system does not depend on them. In a sense, it can be said that both the Logic and Output blocks are part of the System block; but I like to separate things as much as possible.

To know which block will end up more complex is really game-specific, as simple tiled RPG's would require a good Logic block, but small System and Output blocks. A war FPS, on the other hand, would need tougher System and Output blocks, in order to give the game the realism and precision it requires, the Logic would basically respawn players, do physics simulation and ragdolls.

It is useful to model your game in order to create a good software architecture. A bad architecture would kill your development, requiring lots of time consuming fixes and changes, so in the end you can have an acceptable result. The model you'll choose, is entirely up to you, but try not to overcomplicate; specially when we just started, too much effort to do things the right way can halt our progress.

Let's Start!

We'll start by choosing a simple prototype project, one that can be done. "What's a prototype?", you ask me. Well, by prototype I mean a really basic game, that is far from complete, but illustrates its concept. Prototypes can have a single level and no sound, awful graphics and still be used as a concept showcase.

Our first prototype will be a space game inspired on the classic Asteroids. First thing we should do is actually design our prototype (duh). We'll not be creating a Game Design Document (GDD) or a Technical Design Document (TDG) or we would be killing flies with bazookas.
In our game, we will control a spaceship flying through multiple asteroids and try to destroy as many as possible. We can destroy them with our gun or, differing from the classic, colliding with them. That's the basic idea of the game.

  • WASD controllable, no more turning around and accelerating;
  • Pointer shooting, shooting with the mouse will be really easier;
  • Ranged and Collision focus bar, to add a minimum of customization;
  • Hull Integrity bar, no more instant deaths, but no respawns either;
  • Asteroid Integrity bar, asteroids will have different resistances.

Simple enough, this is our prototype. Let's now think on our model now, for a second.

This game has little need for user interface, it's just a ship, its projectiles, asteroids and a hull integrity bar. The input is 5-buttons, 4 directionals and shoot. Piece of cake here.

The game logic needs some basic physics simulation, respawning of asteroids is pretty easy tho. Still, if we add a focus bar, we'll need a better physics simulation.

Light weight rendering, timed sounds, some timers, nothing too hard.

Basic Architecture

As I said before, trying not to overcomplicate, let's define the following structure:
  • A Media Manager to manage the window, rendering, sounds, etc;
  • An Input Manager to detect the player's input;
  • A game world, with these two components:
    • A physics world, to keep all the positions of our entities;
    • A data world, to manage everything other than physics. 
  • A game manager, to wrap them all together and interface them to system specific code.
As you can see, it is not easy, but doable (I hope!).

So, as you probably realized by now, our System is our Game Manager, our Logic is our Game World and our Output is, both, the Media and the Input Managers.

Note: the media manager will be really dependent on the System block, so we'll need to create an interface class inside the System block to interface it with the OS and Hardware while keeping them decoupled.

What's coming next?

Since this is a programming guide, I simply jumped over all the design process. Still, I can't jump over the process of creating the project with Code::Blocks. Following, we should build and properly link our libraries and start the programming. Probably create the media manager and, following, the input manager. The game world comes next, I guess it'll be the hardest part of the guide. Lastly the game manager.
Once the game manager is up, the game prototype should be all up and ready.

What'll we need?

I will be using Allegro for this prototype, but it really saddens me that they still have a mandatory requirement of DirectX SDK. This SDK isn't installing properly on lots of machines since they try to rollback your runtime files, the system forbids it, halting the installation (S1023). It requires the complete removal of all Visual C++ runtimes, which we will need to reinstall right after. Tedious process. I recommend downloading the binaries if you do not want to go through all the trouble to install the DirectX SDK.
The binaries and source code are both available here:
We'll be using Allegro 5.0.10, If you'll be using the binaries, get the them for MinGW 4.7.0 .

I will rebuild Allegro here since I need to confirm it is as I remember.

Maybe, we can integrate Box2D to manage the game's physics. Still, given the simplicity of the game, it would be too much. Box2D would be used just as an initial tutorial.

Answering the question, we will need Code::Blocks and MinGW, along with the Allegro 5.0.10 binaries for our version of MinGW, 4.7, and maybe Box2D built and working, but this one is not certain yet.

Over and Out.