Leadwerks is the easiest way to make games that look amazing. With a rapid development pipeline, support for C++ and Lua programming, and plenty of learning materials, Leadwerks is the perfect platform for your next project.

Report article RSS Feed How to Structure a Game

Basic game structure is a topic that many people have trouble with, yet it somehow gets overlooked. In this lesson, I will show you exactly how to set up and structure code for commercial games.

Posted by JoshKlint on May 2nd, 2013
Basic Client Side Coding.

Basic game structure is a topic that many people have trouble with, yet it somehow gets overlooked.  In this lesson, I will show you exactly how to set up and structure code for commercial games.

We're going to use Leadwerks 3 in this lesson because it makes C++ game development faster, but the ideas here are applicable to any programming environment.

Direct vs. Component-based Programming

Although the component-based script system Leadwerks supports is a convenient way to get simple demos running quickly with Leadwerks, it can be limiting when you try to make a full game.  Fortunately Leadwerks supports direct programming, in both C++ and Lua.  This gives a lot more power and control than component-based systems.  To really take advantage of this power, we need to understand some basic principles on how to set up and structure our game.

We start with a base class for all objects in our game.  We'll call this the "Node" class, and derive it from the Leadwerks::Object class.  The Node class is not an entity, but it has an entity as a member.  Think of a Node as your own game object that is associated with an entity.

Class Structure

For this lesson we'll create an imaginary class called "Foo" derived from the Node class.  The "Foo" class could represent an enemy, an NPC, a bullet, a grenade, or anything else.  We can use the same structure for all of these things.  The Foo class has one function called "Update".  This is where all our game code that updates that single instance of this class would go.  This code could control the trajectory of a bullet, the AI of an enemy, or anything else.  The point is all the code that controls that object is compartmentalized into this function, and it gets called over and over again, for each instance of the class.

In order to keep track of each instance of the Foo class, let's use a standard C++ list.  This is listed in the header file as a static member, so that each instance of the class can access this list:

code:
static std::list list;

Each instance of the Foo class will also have a list iterator so we can remove it from the list when it's deleted:

code:
std::list::iterator it;

In the Foo() constructor, the object will add itself to the list of all objects in this class:

code:
Foo::Foo()
{
    list.push_front(this);
    it = list.begin();
}

And in the destructor, we will use the iterator to remove the object from the list:

code:
Foo::~Foo()
{
    list.erase(it);
}

Why do we need a list of all the instances of our Foo class?  Well, this means we can now iterate through each one, at any point in our program.  This is very powerful because it means we can create new instances of the Foo class at any time, and our game will adjust to keep them all running, without hard-coding a lot of specific behavior.  Iterating through the list is done with the following code:

code:
//First we declare an iterator so we can cycle through our loop
std::list::iterator it;

//Loop
for (it = Foo::List.begin(); it!=Foo::List.end(); it++)
{
    //The Foo object is gotten with (*it)
    (*it)->Update();

    //Alternatively, you could declare a Foo* variable and set it to this value
    //Foo* foo = *it;
    //foo->Update();
}

The Main Loop

This code should go somewhere in your main game loop.  You'll end up with a loop like that for each class your game uses, if it's a class that needs to be continuously updated.  (Some types of objects can just sit there until something happens to make them react.  For those situations, I recommend using a collision callback or other means to activate them.)  So your main loop will look something like this now:

code:
bool App::Loop()
{
    std::list::iterator it;

    for (it = Foo::List.begin(); it!=Foo::List.end(); it++)
    {
        (*it)->Update();
    }

    world->Update();
    world->Render();
    context->Sync();
}

We're going to do one more thing to make our code a little cleaner.  Because we'll probably end up with a dozen or more classes by the time our game code is done, we can take that loop and put it into a static function:

code:
void Foo::UpdateEach()
{
    std::list::iterator it;
    for (it = List.begin(); it!=List.end(); it++)
    {
        (*it)->Update();
    }
}

Our main game loop becomes a little easier to manage now:

code:
bool App::Loop()
{
    Foo::UpdateEach();
    world->Update();
    world->Render();
    context->Sync();
}

By the time our game is done, the main loop will look something like this:

code:
bool App::Loop()
{
    Enemy::UpdateEach();
    Player::UpdateEach();
    Projectile::UpdateEach();

    world->Update();

    Explosion::UpdateEach();

    world->Render();
    context->Sync();
}

You might wonder why I didn't just create a list in the Node class, and have an Update function there.  After all, any class derived from the Node class could override that function, and a single loop could be used to update all game objects.  There's two reasons we don't do that.

First, not all of our game objects need an Update function to be called each frame.  Iterating through hundreds or thousands of unnecessary objects would hurt our performance for no good reason.  We can put an Update function in a base Enemy class, however, and have both goblins and trolls use the same Update loop, when Enemy::UpdateEach() is called.

Second, we want to control the order and time at which each class is updated.  Some classes work best when they are updated at the beginning of the loop.  Some work best when they are updated between the call to World::Update() and World::Render().  It's different for each class, depending on what you make them do, and we want to leave room for ourselves to experiment and not get locked into a design that can't be easily changed when needed.  We could try working around this by setting a priority for each class, so objects are updated in a specified order, but I wouldn't do this.  In my opinion, this is the point where your structure is done and you should think about structuring the classes for your game, and filling in their code.

So what does the Foo:Update() function do that's so important, anyways?  Foo::Update() presently does nothing, but it does everything.  This is where your game code goes.  We can use this structure for AI, bullets, rockets, explosions, enemies, tanks, planes, ninjas, pirates, robots, or giant enemy crabs that shoot laser beams out of their eyes.  In fact we can also use the same structure for those laser beam objects the crab is emitting!

Conclusion

The main point of this is to show how to graduate from writing simple single-file demos, and to start thinking in terms of classes.  Your game code should be written in such a way that it doesn't matter how many objects there are of each class, when they get created, or when they get destroyed.  Each class Update() function is written from the point of view of that single object, looking out at the world around it.  This simple concept can be used to make just about any type of game, from first-person shooters to MMOs.

Post comment Comments
JoshKlint
JoshKlint May 3 2013, 11:58am says:

We also provide a system of hooks. I recommend making use of the Collision and UpdatePhysics hooks, when appropriate. There is an UpdateWorld hook is available, and does pretty much the exact same thing we set up here. You could use this to control the Update() function for all objects, but you may find you need control over the time and order in which objects are updated, for the reasons described in this article.

+1 vote     reply to comment
kovmat86
kovmat86 May 10 2013, 7:54am says:

Nice pattern for managing objects in the game! Two things are not clear for me:
1. "static std::list list;" => Compiler complains of missing template parameter. If I tried "static std::list<Foo*> list;" then I'm not able to declare the list as a static member of the Foo class.
2. Isn't dangerous to define the list as static? Stackoverflow.com

0 votes     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Platforms
Windows, Mac, Linux
Contact
Send Message
Official Page
Leadwerks.com
Licence
Commercial
Release Date
Released Jan 6, 2014
Engine Watch
Track this engine
Tutorial
Browse
Tutorials
Report Abuse
Report article
Related Engines
Leadwerks
Leadwerks Commercial Released Jan 6, 2014
Related Groups
Leadwerks Software
Leadwerks Software Developer & Publisher