Talking and Coding

Back when I was creating the multiplayer pacman, as well as the Braid clone, I first went into the world of component based entity systems. The idea behind this system is basically that any object is not made out of a single class. Rather it's several classes working together to represent a single object.

For the bachelor thesis, we implemented this system to it's full extend. We were able to produce new objects at runtime, which presents a huge advantage. Instead of having to code every single little tiny object, we simply link it's components together.

To do this, we basically need two classes: Component and Entity. I'll introduce you to the Entity first

class Entity: public EventListener { friend class Engine; public: Entity(); Entity(std::string name, std::string meshName, Ogre::SceneNode* parentNode); virtual ~Entity(); void addComponent(BaseComponent* component); void registerListener(const Event::EventType& type, EventListener* listener); virtual void receiveEvent(Event* event); virtual void setParentNode(Ogre::SceneNode* newParent); Ogre::SceneNode* getNode() const; void setOgreEntity(Ogre::Entity* ogreEntity); Ogre::Entity* getOgreEntity() const; void setGraphicComponent(GraphicComponent* graphicComponent); GraphicComponent* getGraphicComponent() const; void setName(std::string name); std::string getName() const; static Entity* create(std::string name, Ogre::SceneNode* parentNode) { return new Entity(); } void setNode(Ogre::SceneNode* node) { this->node = node; } void removeComponent(BaseComponent* component); private: GraphicComponent* graphicComponent; Ogre::SceneNode* node; Ogre::Entity* ogreEntity; typedef std::vector<BaseComponent*> ComponentVector; typedef std::vector<EventListener*> EventListenerVector; ComponentVector components; std::map<Event::EventType, EventListenerVector> eventListeners; std::string name; };

Now, this class is basically only a container for components, with some added functionality for Ogre3D (this was done to ensure that any entity will be in Ogre3Ds scenegraph).

The class also handles events that get either passed to the Entity or its components.

The next thing is of course the component itself. Watch the almighty BaseComponent class:

class BaseComponent: public EventListener { protected: Entity* parent; public: virtual ~BaseComponent(){ parent = NULL; } virtual void setParent(Entity* parent) { this->parent = parent; } virtual Entity* getParent() { return parent; } virtual void receiveEvent(Event* event) { } };

Yeah, it's really not much to look at. But this shows the power of this system. I can add ANY component to an Entity. The component only has to register itself to the events it's interested in. With that communication system, any component can talk to another, without the two knowing about the others implementation. This is the real strenght of the system.

Let's see a little example here. Obviously in a 3D system, objects move around quite a lot. We also want 3D sound, so the position of an audio emmiter has to be updated as well. So, as soon as the object is translated, the corresponding event will be sent. This is what happens afterwards:

void AudioComponent::receiveEvent(Event* e) { if(e->getType() == Event::TRANSLATE) { std::map<std::string, Audio*>::iterator it = audioList.begin(); Ogre::Vector3 position = getParent()->getNode()->_getDerivedPosition(); for(;it!= audioList.end(); it++) { it->second->getAudio()->SetPosition(position.x, position.y, position.z); } } BaseComponent::receiveEvent(e); }

As you can see, as soon as the audio component knows it has to update its position, all it has to do is to get the (wolrd)position of its parent entity and apply that to each audio it's currently playing. No other component has to be able to do that, so this code is neatly separated from the other systems. To demonstrate, let's see the same method for the GhostObjects

void GhostComponent::receiveEvent(Event* e) { if(e->getType() == Event::TRANSLATE) { btTransform transform; transform.setIdentity(); Ogre::Vector3 position = parent->getNode()->_getDerivedPosition(); Ogre::Quaternion orientation = parent->getNode()->_getDerivedOrientation(); transform.setOrigin(BtOgre::Convert::toBullet(position)); transform.setRotation(BtOgre::Convert::toBullet(orientation)); ghostObject->setWorldTransform(transform); } }

Same method, but what happens is entierly different. It will also update the position of the involved pyhsics objects. But again, this is encapsulated here.

One can imagine a ScriptComponent, where the component loads a script (Lua, Javascript, Phython,...) and executes that once it gets an event. This would make the engine very easy to work with, but for now it's a bit of a stretch.

As you may have seen, this system allows to easily extend the engine, while at the same time remain very flexible. You don't need a huge monolithic inheritance structure, but rather small encapsulated classes that each do one specific job. I'll admit that it could lead to an overly huge structure overall (like having thousends of classes), but I think the flexibility of this system makes it worthwhile.

Braid was an interesting example of using time mechanics in a game. I tried to replicate this in a small project of mine. I chose this project to

Research the time mechanics of braid

Get to know the now abandoned XNA framework

The most interesting feature of this Braid probably that the player can rewind to every point in time he previously passed. It's also a interesting limitation, since the player cannot replicate steps he has previously taken (this is introduced in a different mechanic though, with sort of a Doppelgänger).

There are several ways one can approach this problem.

Recording every single position of each game object during the game loop

Recording the input (Player-Input, AI-Input) at specific times

The first method is obviously the simpler way. All you need is a list of all positions the game object had at each point in time (or simpler said, each frame). To simplify that, you

The second method is harder to implement, but offers some real advantages. For one, there is substantially less data involved, since you only record something once you have some sort of input. This could happen each frame or only every other second or so. Either way, it's less data you have to care about. The real difficulty comes in the movement code though. The movement code has to be completely reversible, meaning it has to work in either direction of time. This can be a little tricky, but should be easily doable if taken into account from the start of development. To help the timestamp system, I decided to decouple the movement from the input code. Meaning, each object in the world has the same movement code, which takes some parameters (speed, jump height and such). The input code is different, as it's coded for each specific object. The player object for example takes input directly from the keyboard, while a turtle takes input from the AI-System (not exactly difficult for a turtle in a Mario game).

At first, let's see a little demo here:

So as you can see, our old friend Mario makes an appearance. I chose him for his distinctive shape and a bit for nostalgia's sake. What happens here is all the more interesting. The grey Marios you see are the timestamps that are generated by the system. Each time the player presses (or releases) a key, it changes the input vector. This vector simply holds the current desired travel direction of any moving object. What now happens is pretty simple:

public override void Update(GameTime gameTime) { //Todo: Silly thing here, the movement Vector shouldn't be touched by the object anymore //movementVector = new Vector3(inputVector, gameTime.ElapsedGameTime.Milliseconds); if(previousInput != inputVector) { CreateTimeStamp((float)gameTime.TotalGameTime.TotalMilliseconds, this.PrevPosition); } this.TimePosition = new Vector3(TimePosition.X, TimePosition.Y, TimePosition.Z + gameTime.ElapsedGameTime.Milliseconds); previousMovement = movementVector; previousInput = inputVector; }

Each time the moving objects (which is parent to all moving objects, including player, enemies, moving platforms) detects that it's input vector is changed, it makes a timestamp. A timestamp is just a simple data structure, that records the time and the input vector of the affected object. The timestamps are saved in a list, which allows me to navigate in either direction of time.

The cool part about this can be seen in the actual game code. After checking if the player wants to rewind time, I call the following method:

private void SpoolMovingObject(MovingObject movingObject, KeyboardState keyboardState, GameTime gameTime) { float carry = 0; TimeStamp p2 = new TimeStamp(); if(keyboardState.IsKeyDown(Keys.Left)) { if(movingObject.TimeStamps.Index.Next != null) { p2 = movingObject.TimeStamps.Index.Next.Value; carry = TimeStampHelper.MoveAlongVector( movingObject, movingObject.TimeStamps.Index.Value, p2, 5); if(carry != 0) { if(movingObject.TimeStamps.Index.Next != null) { TimeStampHelper.MoveAlongVector(movingObject, movingObject.TimeStamps.Index.Value, movingObject.TimeStamps.Index.Next.Value, carry); } } } } if (keyboardState.IsKeyDown(Keys.Right)) { if(movingObject.TimeStamps.Index.Previous != null) { p2 = movingObject.TimeStamps.Index.Previous.Value; carry = TimeStampHelper.MoveAlongVector(movingObject, movingObject.TimeStamps.Index.Value, p2, 50); if(carry != 0) { if(movingObject.TimeStamps.Index.Previous != null) { TimeStampHelper.MoveAlongVector(movingObject, movingObject.TimeStamps.Index.Value, movingObject.TimeStamps.Index.Previous.Value, carry); } } } } }

To explain: After checking in what direction (of time) the player wants to go (I call that spooling), I interpolate between two timestamps. Since I save the timestamps based on the time they were created, this is easily done. There is a huge trap you can fall into, that can cause game objects to run out of sync. While spooling, we move at a fixed time, meaning each update we run for example 5 milliseconds in simulation time. Now, there can be a situation where a gameobject overshoots a timestamp. You have to check for that condition, which is what the carry variable in the above method is for. What happens is, the difference to the previous timestamp is recorded, we reset the position of the object to that position and run the interpolation again with the next timestamp, but only for the amount of time we overshot (well, wasn't that a long sentence?)

I hope this gives a small overview over the whole mechanics. This is my implementation, I don't know if Jonathan Blow made it the same way. It's not as trivial as it may look at first, keeping all objects in sync is the most difficult part. I invite you to have a look at the full source code over at my github

I'm quite happy how this whole thing turned out. Granted, to use it in an actual game, more work needs to go into it. But I reached my target here, exploring an interesting mechanic.

The biggest trouble I'm having with my javascript engine is not even getting it to run at a decent rate. Even on firefox it runs acceptable, chrome is a blast. No, the real trouble is Audio.

Each browser has a bit a different audio support. Some want WAV, some MP3, some OGG. I found that OGG has the broadest support, although that could have changed. Still, it's a good format to use, so I stick with it for now.

To start off, I had to create my own audio library. There wasn't any library out there that satisfied me so far. Some even worked with flash and I try to ignore that for now (we want to further HTML5 after all).

So, I guess you're interested in how that works. I think I found quite an elegant solution, but I'll let you judge.

At first, I load a song into the engine. For the sake of this article, I refer to sound effects and music as songs. Let's have a look at the method:

function AddSong(name, path, loop){ //Check if the song isn't loaded yet if(!(name in audioList)){ audioList[name] = new Audio(); //Load the desired song audioList[name].src = path; if(audioDisabled == true){ audioList[name].volume = 0; } else{ audioList[name].volume = currentVolume; } } if(loop == true){ //If this song should loop, add an event listener to restart it audioList[name].addEventListener('ended', function(){ this.currentTime = 0; this.play(); }, false); } }

Loading and starting the song is quite simple. What is more interesting is the looping of a song. In order to get a smooth replay function, all I do is add an event listener to the song itself. As soon as the song ends, I rewind the song (set time to 0) and play it again. This allows me to do even more interesting stuff with audio events.

function AddEventListenerToSong(name, type, listener){ audioList[name].addEventListener(type, listener, false); }

I can use the internal events of a song in my engine to trigger certain things. For example, I could have a bird tweetig. As soon as he's finished, he'll fly off. The trigger for that would be the end event of the song (the tweetign)

To actually do something usefull with the songs I load and play, I need some acessors. As you may have noticed, I cache all songs in a list. Later I can access them over their name and do some basic manipulation with them:

function StartSong(name){ if(audioList[name] != undefined){ audioList[name].play(); } } function PlayChachedSong(name){ audioList[name].currentTime = 0; StartSong(name); } function PauseSong(name){ if(audioList[name] != undefined){ audioList[name].pause(); } } function StopSong(name){ PauseSong(name); audioList[name].currentTime = 0; }

With all the craze going around HTML5 and such, I thought why not try some yourself? It sounds fun so I started scripting a small 2D game engine together.

The whole thing is based on javascript and html5. I’m surprised to how easy javascript was to learn. It’s a bloody mess, but it works.

I worked through a tutorial, on which my current engine (heh) is based. I want to create a version of my CV in form of a game. Now how the help works that?

Each of my stations (primar, kanti, studies) is a level. The target of each level is to reach a certain amount of good (school)grades. I tried to be a bit crazy with the aesthetics here, as my vehicle is a GameBoy!

It’s not that pretty, the background is missing. But what you see there is some parallax things. I’m quite happy with it actually.

After you complete a level you face a boss. A boss is a special level, for example an important test or a physical excercise.

The basic idea here is that you have to climb the rope. It’s supposed to be a gymnastics hall, but as McCoy would say “I’m a programmer, not an artist, Jim”. I may be remembering that wrong.

To load the engine, all you have to do is include a javascript file and call the init method:

//Init(width, height, fps, mute audio, level index) Init(800, 480, 60, false, 1);

var Init = function(width, height, framesPerSecond, disableSound, levelIndex){ //Invalidate the gamestate gameState = GAMESTATES.INVALID; canvasWidth = width; canvasHeight = height; //This is the surface that we use to draw later on. ctx = c.getContext('2d'); c.width = canvasWidth; c.height = canvasHeight; //Set the speed of the game var speed = 10; fps = 1000/framesPerSecond; InitLevels(); InitIntro(); if(disableSound == true){ ToggleSound(); } //This should only be called after the levels have been initialized if(levelIndex != undefined && levelIndex > 0){ loadNextLevel(levelIndex); } //This effectively starts the game setInterval(GameLoop, fps); }

The last line is es

The most interesting part probably is how easy it is to manage a game-loop. I have a simple method that calls all the necessary code (opan state-pattern style).

var GameLoop = function(){ if(pressedKeys[80] == true){ ToggleSound(); pressedKeys[80] == false; } switch(gameState){ case GAMESTATES.INTRO: PlayIntro(ctx); break; case GAMESTATES.MENU: DrawMenu(ctx); break; case GAMESTATES.LEVELINTRO: levelIndex[level].intro(ctx); break; case GAMESTATES.LEVELPLAY: levelIndex[level].play(ctx); //If the l-key is pressed, skip to the next level if(pressedKeys[76] == true){ gameState = GAMESTATES.LEVELOUTRO; } break; case GAMESTATES.LEVELOUTRO: levelIndex[level].outro(ctx); break; case GAMESTATES.CHANGELEVEL: loadNextLevel(1); break; default: break; } }

Easy enough I'd say, now, this code obviously has to run quite frequently. I tried to reduce calls as much as possible, to optimize the whole thing as much as possible. I don't know how much it gained me, but it runs fluently even on an older smartphone (HTC Desire). Oh, did I mention that this work on smartphones? It totaly does.

In this post, I'd like to talk a bit about the architecture and the various frameworks used to create our engine.

I mentioned in a previous post that I've read "Game Engine Architecture" (once again, highly recommended read). From that text, we took some ideas and applied them to our engine, mainly making the engine modular and implementing a component based entity system.

At first, let's look at a high-level diagram of the engine:

The topmost layer is the overarching engine. It handles initialization, entity-management (more on entities later) and manages the gameloop (to a certain degree, more about that later).

The second (organe) layer shows what modules we implemented. The modules are separate from each other, each implenting another library. This also adds the advantage that we could swap any library with another one, for example swap BULLET with Newt or something similar.  The only expection to this rule is Ogre3D, since that library handles more things than only graphics.

As promised, I'll talk a bit about each library. I'll talk about Ogre3D in a separate post, since that library is a bit deeper integrated in our engine.

Physics: Bullet

For simulating a marble in a maze, the player need to be able to accurately predict where the marble will go if he tilts the board. As such, we need a physics engine. Bullet is an open-source engine that is widely adapted by both the game- and the film-industry.  

Bullet was easy enough to get into the engine, but hard to acutally work with. Personally, I found it very unintuitive to program for, it seems to favour a more sequential programming style, rather than a object oriented one. You have to implement your very own callback methods and keep track of previous physic states yourself. This worked out in the end, but we weren't exactly happy with the end result.

Audio: SFML

Instead of using the raw OpenAL library, we decided to use SFML. While the SFML offer plenty of possibilities, the only thing we used out of it was the audio module. We implemented the whole system in one day, with fully working 3D sound. This was a blast to work with, SFML is one hell of an awesome software library. If you can USE IT!

GUI: Librocket

We searched relatively long for a suitable GUI library, going through CEGUI and several others. None of wich made us really happy. They were either to big or to "obfuscated" for us to learn, since we added the GUI near the end of the project.

When we first learned of Librocket, we were excited. A simple GUI library,  working on HTML and CSS? This was our chance. Looking back, we have mixed feelings. When we finally got it to work (took us about 3 days), it worked as promised, but it seemed like quite a hassle. Anyway, it payed of in the end, so I'm not complaining (that much).

Input: OIS

The object oriented input system was our day one choice for handeling input, since it pretty much comes bundled with Ogre. Not that this is something bad, this library is really solid and intuitive to work with. Overall, not much to say about this, I can recommend it.

Wrapping up

The last year I was busy working on my bachelor thesis. Together with a friend, we managed to build a 3D game engine, based on the popular Ogre3D (a graphic library) and several other open source components (which I'll later show).

To do that, we took the well know toy marble-maze and spiced it up with new elements.

The challenge was to implement a game that used shader techniques to more than just graphical effects. Our minimal requirements were

Use GLSL Shaders

At least version 3.2

Produce at least one playable level.

Include the following elements into gameplay

Tiles that change the state of the marble

Holes in the level

Interactive walls (this includes doors)

Ventilators, that can push the marble in certain directions

The level needs to be editable without changing the source code.

We had to use C++ to implement the whole engine. As an added challenge, we decided to keep it multiplatform. We developed on Ubuntu and Windows (7) in parallel, keeping our code as free from platform specific code as possible. This is one point we're really proud of, having pulled that off with great success.

Woahwoahwoah, what's that? An ObjectShell? What the hell does that mean? Sit down, and let me tell.

If you read my last post, you know that I was thinking about reworking my gameobjects. So far I had a monolithic structure, which I didn't really like. So I went and started studying my pacman implementation again. First thing I saw there: I made it way more complicated then needed for such a game.

Second thing that I saw was a very neat way to control an object. I thought to myself, why the hell didn't I build that system in my new engine? After a few slaps to my face, I started recoding my gameobjects.

There I came up with my ObjectShell. The term shell is really descriptive, I think. You could also say hull or casing, but I like shell more.

The ObjectShell basically looks like this:

class ObjectShell { private ControllerComponent controllerComponent; private GraphicComponent graphicComponent; private PhysicComponent physicComponent; private EventComponent eventComponent; }

As you can see, it's composed of four different components.

The ControllerComponent controlls the (desired) movement of an object. Behind that could be a user controller (Keyboard, Gamepad), a network controller (proxy object) or an AI controller.

The GraphicsComponent represents the object on-screen. It could be as simple as displaying a simple 2D texture or a complete ragdoll.

The PhysicsComponent is used for simulating the object in a physics world and keeping track of the position of the object. It could be empty or very complicated with constraints and such

The EventComponent manages all the events raised and received by and for the current object. It registers itself with other EventComponents and sends them events when they occur.

This pretty much follows the concept explained in Game Engine Architecture, with some modifications. The complicated part isn't coding the individual components but rather to get them communicating between each other, which is equally important. For example, the GraphicsComponent needs to know the position to where it should draw from the PhysicsComponent. This, in return, needs to know the size of the object. The ControllerComponent maybe need to know some collisions in order to make decisions from physics and, of course, the PhysicsComponent needs to know the input from the Controller.

As you can see, this is non-trivial. There are a few options to choose from:

Define distinct communication interfaces This would be the broadest approach. It would mean that any component can talk to any other component, without knowledge of what this component does. It's pretty similar to an event driven system. However, this would mean a whole lot of error handeling and generic programming, which isn't really that good either, because you can use that power somewhere else.

Let the ObjectShell do the communication The ObjectShell is the only thing that knows exactly how its components should work together. It knows what comes out of one component and what should go into another component. This is my favourite approach right now. It's flexible and gives me precise control over each object. The flipside is that I have to keep my monolithic design. It's not as bad as my previous approach, since I can easily switch components without breaking other parts of my implementation.

Make the components talk to eachother directly This is the last approach I can think of. One Component has a reference to another component and tweaks its settings as it sees necesary. This is simple but also dangerous.

As said, I like the second option best. It's the mix between my other two approaches, and I think that's always the best.

Yesterday I finnished reading Game Engine Architecture, by Jason Gregory. It's a long and hard read, but worth every word if you're looking for creating a game.

After finnishing it, my first thought was "Damn, what have I gotten myself into?" I realized how much work goes into a game engine, even a simple one, such as my very own.

Although I'm quite happy with myself. I implemented a lot of the things Gregory talked about already. This is good, it means I somehow have the feeling for that.

There are things of course that I need to improve. For example the game objects (title, hinthint). I coded them as a monolith. This isn't bad, but unoptimized.

I printed out an uml diagramm of my game objects (Visual Studio 2010 delivers a very good function for that) and looking at them, it's not all bad. Everything neatly inherits from a common game object. And this object is HUGE. That's probably it's biggest fault.

When I worked on Multipac (a multiplayer version of pacman, studentproject), we neatly separated the behaviour from the movement. Meaning, we had one moving object. Depending on what controller we linked that object to, the object had a different behaviour. In the end, Pacman and the ghosts had the same exact movement code, just different controllers. This was awesome. If we wanted a new ghost, for example, we'd just have to build a new controller, hook it up to a game object and done.

This could prove very usefull for my current project. I'm asking myself though how I can make the controllers aware of their surroundings. I have the idea of doing a factory. The game object then asks for a controller. Inside the factory, I give the controller everything he needs. For example, the controller for the AI needs to know when it has to change direction, based on some collision type. I give it access to the collison system and I can check there whether it has to change direction.

I'm explaining the factory pattern. Can't believe it.

This is pretty much the best description of why I love games. Expecialy that one caption:

And at the end of it all

Gamer play what we play

Not for Game Over

But for what we take away

Although it is a bit strangly worded (poets ;) ) it describes what keeps me entertained by games. It's not the ending screen, it's the exploration, the experience, the friends and all those little things that matter more.

Thinking about it a bit more, I realised that humanity has lost something that has driven it quite far: The opportunity to explore. If you look at a map today, you won't see any white spots on it. Sure, there's still the deep sea and space, but what are your chances to ever go there?