How To Develop An RTS Game - Brief Guide

Red Alert 2 (Westwood Studios) and Age of Empires 2 (Microsoft) were two games which defined the era of computing just getting used to GUI (mid/late 90's).

Originally designed for DOS, Red Alert was built by Westwood Studios - RTS pioneer through titles including Dune. The game was a breakthrough due to its realtime nature.

Add to that a killer storyline, amazing graphics and near-mythical gameplay mechanics and you have a winner. As a software developer, it's easy to be in awe at games like this... but it's another knowing how they work. This tutorial is a brief introduction into what I know about it.

OOP (Object Orientated Programming)

The most important thing you need to appreciate with any game is that they are programmed using OOP principles. OOP stands for object orientated programming, and basically the opposite of flow-based programming:

·         Flow based programs work with the flow of an application. They will focus on user input and manage their system based on forms - typically refreshing the UI each time an input is provided.

·         Object orientated programs work by loading a base application and using that to load a series of variables (objects). These variables are held in memory and can be interacted with on the screen in realtime.

The core of OOP is the ability to "invoke" classes. Classes are a type of variable which allow you to store "attributes", and use those attributes in "public" (class) and "private" (instance) methods.

The way almost all games work is to invoke a number of data objects into memory, populate them with the appropriate attributes (hit points etc) and then proceed to call the various instance / class methods on them as the user interacts with them in-game.

Data + Renderer                                                           

On top of a core OOP architecture, RTS games work with two elements - a data backend and "renderer" front end. Understanding how these work together is the core of whether you'll understand how to make an RTS game work from a programmatic perspective.

Imagine an RTS as a simple application. Ignore the graphics and artwork etc - focus on how you'd make the objects move around on-screen.

It works like this - the application loads up. This gives you the ability to manage your credentials (load past games, change your details etc). The job of the application (in an RTS) is to then create new "games". These games exist between two or more players, and acts like a giant chessboard onto which you're able to add new buildings, units etc.

Each "game" loads up two sets of data (your data & the other player's). The job of the game is to help you manipulate this data to beat out your enemy.

Data (Buildings / Units / etc)

When a new "game" is loaded, the data for you and your enemies are loaded into memory. For example, you may have a data-set which looks like this:

·         Player #1
- Buildings
- 12
- 34
- 81
- 19
- Units
- 109
- 109
- 109
- 109

·         Player #2
- Buildings
- 12
- 34
- Units
- 10
- 12
- 24

Each number above corresponds to an ID for a data object. In relational databases, the ID will act as a foreign_key.

The way you manage these objects is to have a central data store (for example a relational database) which stores the buildings as specific objects on their own.

This way, when you create a new building, what you're doing is creating a new reference in the database. For Rails, you'd have the following setup:

·         players_table

·         factions_table (has_many buildings, has_many units through buildings)

·         objects_table (this will be superclassed as buildings & units)

·         games_table (acts as a join table for players) (belongs_to:player_1, belongs_to:player_2)

·         actions_table (this records the actions of the game "player 1 started building x")