This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Object Design for Web-based Games

The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

We've built a narrative sci-fi MMORPG named Tau Station. Like most indie devs, we were quickly hit with the problem of developing complex items. If your weapons are only weapons, or your armor is only armor, you can create separate classes for them, inheriting from a common "Item" class having properties such as name, description, mass, and so on. Your subclasses would define item-specific behaviors and be populated with data from the database. It's simple and easy.

But what if you want to create a military grade combat suit? Yes, it functions as armor. But it can shoot back, so it functions as a weapon. And it can patch up minor wounds, so it also functions as a medkit.

How do you handle building complex objects with multiple behaviors?

Some people recommend multiple inheritance, but then you're not only dealing with the well-known problems of multiple inheritance, but you're also creating a class for only one item. If you have many complex items, this also doesn't scale. Having to create a special class for every item, write tests for it (you do write tests, don't you?), and verifying that it doesn't have unintended consequences on gameplay is not an easy thing to do. It's time-consuming and, more importantly, expensive.

You want your game out there now, not in six months after you've written all of your custom classes.

The Entity-Component-System

If you've been developing games long enough, you've heard of the Entity-Component System (ECS). First developed for the excellent game Thief: The Dark Project, the ECS is a powerful way of introducing complex object behavior without complex programming. We have three parts to it:

Note that in ECS, you're dealing with data, not objects. That's very important to remember.

Now imagine you're building a game for children where they are photographing animals in the forest. Each "entity" might be an animal, a plant, a trap, or any combination (a Venus Fly Trap could be both a plant and a trap). The core game loop might look like this (code examples in Perl):

Entities are merely bundles of data and the helper functions, such as is_animal, is_plant, and is_trap identify if an entity has a particular component.

But we're a web-based game. Our game is driven by Tau Station citizen's clicking on links, not on a game loop. So how do we handle this?

ECS for the Web

The Database

We don't have a game loop, but that's not really a problem. Instead, we check behavior "as needed" and the main concern is how we create our entities. For that, we have a simple view which pulls all related data in a single SQL query:

There are a few things to note about the SQL. First, all items have a unique, human-readable "slug" that we use in the URL. The "Combat Suit" slug, for example, is combat-suit. That's used in the bind parameter (the question mark) in the SQL.

The LEFT OUTER JOIN parts mean that the related columns will all be NULL if the row is not found.

Finally, for many items, this SQL could be extremely inefficient. However, all of our items are immutable, meaning that we cache the results of the above query and player inventories contain "item instances" which might have more information (such as damage level).

The Code

The code to use the above data is fairly simple. In our strategy, we have "global properties" such as "name", "mass", and so on. That's in our items table. Each item might have an armor component (component_armor table), a weapon component (component_weapon table), and so on. We have an Item class (it should have been named Entity, but I digress) and though it's a class, it only has read-only accessors for fetching item properties, and predicate methods for testing components:

Because we used LEFT OUTER JOINs in our code, the is_armor predicate method will return false if the component_armor_id is NULL. This means, finally, that if someone wants to equip armor, we can easily check this: