April 16th, 2009 by Boon

I haven’t updated my ‘daily creativity’ blog for some time now. Not because I haven’t been doing creative stuff in my spare time, but simply because what I’m doing isn’t very fun to look at. Code. URGH. So for the sake of looking productive to the two people who sometimes read this blog, I thought I’d expand a bit on the entity > component based design methodology I’ve been following since my last code refactor. I know – exciting stuff. Hold onto your cushions, people. This is going to be WILD.

Originally, I was approaching my game design from the angle of programming a game. Seems reasonable, no? Well, the thing with brute force programming (excuse my terms, I’m making this up as I go if that isn’t obvious) is that once I have my core gameplay programmed, if I decide to add a feature, change a feature, or redesign the game in any way it becomes an exercise in pain, wading through page after page of spaghetti code (I didn’t make that one up, it’s really a term) to find the right spot to make changes and then hope that whatever I type isn’t the equivalent of a tactical nuclear warhead to my game.

The term “Spaghetti Code” refers to a program where the flow of code jumps all over the place, without any clear separation of individual gameplay entities. And for the sake of simplicity, an entity is simple a ‘thing’. A pickup, a background image, the player, the scoreboard… Brute force programming tends to be an old-school approach to code design, as far as I understand it. Where code follows a deceptively simple step-by-step, method-by-method, do-this-and-then-do-that methodology. It works, and it’s easy enough to follow for amateur coders like myself, but in the long run it can get messy and confusing with a giant wall of code that makes my brain melt.

So after some reading and some thoughtful planning, I decided to review how I was attacking this game. And rather than program a GAME, I decided I should instead focus on programming a flexible ENGINE that could support my game, and with little effort be adapted to support any other games I decided to make in the future.

Hense the Entity > Component design methodology.

The way my Entity > Component engine works is also deceptively simple.

I add an entity. A ‘thing’. And then I add components to it to define how it behaves. For example, Newton’s famous apple might be an Entity (the container that simply says “I am an apple”) with a Gravity component telling it to fall, and a Collision component telling it to stop when it hits the ground.

By following this methodology, it becomes relatively trivial for the designer, versus the programmer, to define new gameplay mechanics. If Iain is building a level for his game in my engine (Iain is a real person, not a fictional analogy device) and he says “Hey, I need a talking door puzzle in my game”, then rather than me needing to get into the guts of the engine and program a talking door, I can give him a reusable and adaptable “Talking Object” component which he can add to his “Door” entity.

The real power – as I’ve discovered – in the Entity > Component design is that EVERYTHING in the game becomes capable of managing itself. Newton’s apple knows what it is, knows it needs to fall and hit the ground, and does that without me ever having to tell it to do anything in particular once I’ve built that Entity > Component relationship.

Another benefit is the reusability of those components. Maybe I can use Iain’s “Talking Object” component to make that apple yell “FUCK ME, THAT HURT” when it hits the ground. Or maybe not, since that would be naughty.

The point is that with the core engine being a simple relationship of entities, and entities having their actions defined by components, the engine itself can stay elegantly minimalist, while all the functionality of the game can be built via components. Components can be added as needed for new functionality, and be plugged into one another to change functionality in realtime.

Consider another example: a pile of gold coins that explode from a monster when it is hit.

• In this design, the MONSTER entity would have a SPAWNER (a component designed to ’spawn’ other entities in the game world).
• The SPAWNER is activated when the MONSTER dies, and spawns a handful of COIN entities.
• The COIN entities fly through the air, obeying MOTIONFORCES and GRAVITY components until they collide with the ground.
• The PLAYER entity collides with the COIN entity and triggers a hit on the COIN’s COLLISION component.
• The COLLISION component then triggers a SPARKLE entity via another SPAWNER (just so it looks pretty) and a DESPAWN component to remove the coin.
• The PLAYER entity triggers it’s COUNTER component to increase the number of coins collected by one.

It might seem convoluted, but to do this in brute force coding would be nightmarish for me, and impossible for anyone who doesn’t know how to hard code that functionality in my engine. But building this kind of relationship becomes trivial for the designer. By trivial I mean still-requires-a-lot-of-planning-to-build-new-entities, but once created, they all become ‘drag and drop’ into the game world.

And once again, the real delight: they do their thing on their own, entirely self sufficient, without me ever having to use “If (Coin is collected) then do stuff” hard coded gameplay logic.

In sagaEngine, the basic program structure (also known as, if I’m correct, a ’scene graph’) is:

World > Stage > Layer > Gameplay Elements

All of those things are entities, and being that entities automatically look after their children (entities and components) then the entire programmatic logic boils down to:

World.Update();
World.Draw();

And if you didn’t understand a word of what I said, either through incomprehension of codey speaky, or my horrible inability to clearly and concisely articulate an idea, then just trust me – it’s nice and I rock.