Tom Davies

Fluent asynchronous responder for network calls.

admin — Tue, 21 Feb 2012 20:32:36 +0000

Handling asynchronous calls can be a pain. When we make a call like load() there is really only two thing that can happen we get success or failed. For 90% of applications that’s all we need. The native flash API is unwieldy and messy and overly complex.

So lets start with a fresh look at what I think the API for a loader should look like.

public function Example() {
var xmlLoader:FluentXMLLoader = new FluentXMLLoader();
xmlLoader.load("http://www.w3schools.com/xml/note.xml").addSuccessHandler(successHandler).addErrorHandler(errorHandler);
}

private function successHandler(xml:XML):void{
trace(xml);
}

private function errorHandler(error:IOErrorEvent):void{
trace("FAIL!");
}

So the call load() is returning a fluent responder object to which we can add our handler. Its very simple we can added as many handlers of either type as we want or none at all. There is no garbage collection worry about because as soon as the handlers are called its automatically cleans up. Super clean.

So to create a class that uses this our loader look like this

public function load(url:String):IFluentResponder{
var responder:FluentResponder = new FluentResponder(XML,IOErrorEvent);
var request:URLRequest = new URLRequest(url);
var loader:URLLoader = new URLLoader();
var loadNativeSignal:NativeSignal = new NativeSignal(loader,Event.COMPLETE,Event);
var errorNativeSignal:NativeSignal = new NativeSignal(loader,IOErrorEvent.IO_ERROR,IOErrorEvent);
loadNativeSignal.add(function(event:Event):void{
responder.triggerSuccess(XML(loader.data));
loadNativeSignal.removeAll();
errorNativeSignal.removeAll();
});
errorNativeSignal.add(function(event:IOErrorEvent):void{
responder.triggerError(event);
loadNativeSignal.removeAll();
errorNativeSignal.removeAll();
});
loader.load(request);
return responder;
}

OK bit of native signal closure magic here so we only have local variables but dont let that put you off.

The first thing to note is the return type is IFluentResponder which gives us the ability to add handlers but not mess with the other workings. The next thing we do is create our responder object. In the constructor like signals we define the data types expected on success and failure respectively. The last thing to note is that when we load are file we call responder.triggerSuccess(); and if we fail responder.triggerError();

That’s it, dead easy. All the code is up here on github.

Update: its been pointed out that this is similar to Shauns promises. There is a javascript proposal here and a nice JS implementation here

Samphire

admin — Tue, 07 Feb 2012 21:10:05 +0000

I’m going to start with a disclaimer this is not a fully fledged polished game engine more a proof of concept and hopefully something to show the way. If you want more features then please add them

So I wanted to create a little demo showing what Entity Systems can do for you and why you should care. Now they solve a lot of structural issues but also by there nature are data driven. This means by being a bit clever we can get automated serialisation. A fancy way of saying we can save the game state with out writing any special code. If we are a bit smarter still we can create an Editor that will magically work for any components we add. What’s more this editor works “in game” as you are playing you can tweak and save you levels. Arrow keys to move and E to bring up the editor.

Obviously there is a lot missing both from the editor and the engine. But hopefully for those who don’t quite know where to start with Entity Systems this will be a nudge in the right direction.

The code for the demo is here on git hub. The code for engine is here and it uses Ember2

Ember 2

admin — Sun, 04 Dec 2011 11:17:48 +0000

Well Its been a while but I’ve been busy in the back ground and finally have something to show for it all. In the shape of Ember 2 first up I need to acknowledge some major contributors. First Alec McEachran @alecmce and his take on things with xember. Second Richard Lord @richard_lord and his clever suggestions in how to get around the performance cost of removing items from a vector.

Although the new versions API is in many ways familiar although simplified it is a complete rebuild underneath with a much more test driven approach. Also while some of the changes are a bit more subtle there are two biggie’s. All in all I made the decision that it deserves the version 2 badge.

So the first big thing is Ember is now a Robotlegs2 extension. To pre-empt the reaction of some that robotlegs has no place in games it does. Its perfect for the UI and menu’s systems etc. the issue is that the MVC doesn’t fit real time game play which is where Ember steps onto the stage. For Ember2 I wanted something that solved the issues of integrating with the Robotlegs framework whilst still being able stand alone. I also wanted a way of being able to add any functionality required without having to bake it in. Lucky Robotlegs2 appeared and its new context where functionality is constructed from extensions rather than being built in was exactly what I wanted. So rather than doing It my self badly it made sense to use it and save me a lot of work.

Second on the list is some clever trickery. With some magic behind the scenes I have been able to ditch the cumbersome linked lists and still keep performance practically the same. The best part is the nodes are now in juicy vectors and they can now be injected directly into the systems. No casting and funny loops any more just inject and “for each” you way over them.

Other more minor changes are that Entities are now objects in them selves. This may sound like a minor thing but it allows for pooling of whole Entities which was previously impossible and can help performance. Also taken for Alec’s xember is the auto inspection of the node classes so there is now minimal typing required when creating your nodes. All these things add up to make Ember 2 simpler and neater so it can just get out of the way and allow you to get on and code. If you want to get started check out the bunnies demo code on github. Have fun.

Admin Portal

admin — Fri, 19 Aug 2011 09:26:37 +0000

Administration portal for a payment system. Built a Flex client with the robot legs framework and signals. Also built the corresponding BlazeDS back-end. Features included a skin-able UI for client specific branding. User level permissions and customisable menu settings. Highly customised charts.

London Flash User Group talk

admin — Fri, 19 Aug 2011 08:47:46 +0000

Tink very kindly let me talk at the FLPUG last month about entity systems. Its now up online and you can watch it here.

http://www.lfpug.com/entity-systems-%E2%80%93-a-better-way-to-develop-games/

It was a pleasant surprise to meet people that other people are working with these ideas and even using there own versions of Ember. Hopefully I managed put it on the radar of at least a couple more.

Bunny madness

admin — Sun, 24 Jul 2011 15:07:27 +0000

The latest version of Ember comes with a huge increase in speed. The idea came when I was thinking about linked lists and I realised that I could also cache a pointer to the components in the list nodes. So we now have an Entity system with little in the way of processing overhead. In fact in benchmarks the performance difference compared to standard game engines is negligible.

Here are two benchmark demo’s complete with source code.

5500 bunny blitting Demo

55 per frame bunny fountain Demo

Getting started with Ember

admin — Thu, 03 Feb 2011 19:30:29 +0000

Note:Some of this is a bit out of date. I’ll do my best to update it ASAP. There are now uptodate demos complete with source code here

the Game

If your new to entity systems then you may want to read my posts on Game Architecture and Entity Systems first to get an over view. You can download the code for this example GettingStarted

Ok so first step to making games on the Ember frame work is to create you games main class. This has the same role as an applications context in robotlegs. Its main role is the initialization and tearing-down of you game.

package{
import com.tomseysdavies.ember.base.Game;

public class MyGame extends Game{
override protected function startUp():void{

}
}
}

we can now launch the game from felx like so and pass it a reference to the display object that we want to become the games view.

"1.0" encoding="utf-8"?>
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600" xmlns:local="*">
>

contextView="{gameView}" />
>
id="gameView" />
>

Components

So our game is now launching and has a reference to its view so we can now look at creating our first component. A component is a value object its highly portable and normal has no methods only data. For this tutorial we will need two.

package components
{
public class PositionComponent
{
public var x:Number = 0;
public var y:Number = 0;
}
}

package components
{
import flash.display.Bitmap;

public class GraphicsComponent
{
public var asset:Bitmap;
}
}

Entities

Now lets go back to our start up function. So here we first create that our components then next we create an entity and add our components to it. Think of an entity as an empty container to which we can add components. We create entities with the entityManager.

override protected function startUp():void{
var positionComponent:PositionComponent = new PositionComponent();
positionComponent.x = 100;
positionComponent.y = 100;

var graphicsComponent:GraphicsComponent = new GraphicsComponent();
graphicsComponent.asset = new Tree();

var entity:IEntity = entityManager.createEntity();
entity.addComponent(positionComponent);
entity.addComponent(graphicsComponent);

}

Systems

The final building block in Ember is the systems these have all the logic for the game that acts on the entities data. Ember uses SwiftSuspenders for its dependency injection if you have used robotlegs then hopefully this should be familiar and its well documented there so I wont cover it into much detail. All systems must implement ISystem and the onRegister and destroy functions that come with that. Any initiation code needs to go in to onRegister which is automatically called after the injection has occurred. The destroy() function is used to clean up any event listeners etc. Have a quick look at the code bellow then I will explain it.

package systems
{
import com.tomseysdavies.ember.base.EntityManager;
import com.tomseysdavies.ember.core.IEntity;
import com.tomseysdavies.ember.core.ISystem;

import components.GraphicsComponent;
import components.PositionComponent;

import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.display.DisplayObjectContainer;
import flash.geom.Point;
import flash.geom.Rectangle;

public class RenderingSystem implements ISystem
{
[Inject] public var contextView:DisplayObjectContainer;
[Inject] public var entityManager:EntityManager;
private var _family:IFamily;
private var _viewPort:Bitmap;

public function onRegister():void{
_family = entityManager.getEntityFamily(PositionComponent,GraphicsComponent);
_family.iterator.add(renderEntity);

_viewPort = new Bitmap()
_viewPort.bitmapData = new BitmapData(400,400);
contextView.addChild(_viewPort);

render()
}

private function render():void{
_viewPort.bitmapData.fillRect(new Rectangle(0,0,400,400),0xFFFFCC);
_family.startIterator();
}

private function renderEntity(position:PositionComponent,graphics:GraphicsComponent):void{
_viewPort.bitmapData.copyPixels(graphics.asset.bitmapData,graphics.asset.bitmapData.rect,new Point(position.x,position.y),null,null,true);
}

public function destroy():void {
_family.iterator.remove(renderEntity);
_viewPort.bitmapData.dispose();
}
}
}

This system as it name suggests renders our entity to the screen. First we we set up a viewport where we will render our graphics (note contextview is again injected). Next the most important line in onRegister is this(note that the reference to the entityManager is injected above).

_family = entityManager.getEntityFamily(PositionComponent,GraphicsComponent);

This allows us to “look up” all entities from the entityManager that have all the specified components. Here we are asking for all entities that have both the PositionComponent and the GraphicsComponent. The entityManager returns a pointer to a family instance. We store a reference to this so we don’t have to request it every time we render the game. We can listen to signals dispatched by the family to see if entities have been added or removed or iterate over all entities in the family. We are going to add a handler to the iterator signal. we do that like this

_family.iterator.add(renderEntity);

Bellow is what that handler function looks like. Notice it accepts components as arguments in the same order as those that we asked for when we called getEntityFamily. If these don’t match you will get a runtime error.

private function renderEntity(position:PositionComponent,graphics:GraphicsComponent):void{
_viewPort.bitmapData.copyPixels(graphics.asset.bitmapData,graphics.asset.bitmapData.rect,new Point(position.x,position.y),null,null,true);
}

Once iteration has been triggered this will be called once for each entity in the family. It uses the data in the position component to copy the asset in the graphics component to the screen. So now to trigger the iteration we just call

_family.startIterator();

Our final task is to add our system to the game. So at the end of our games start up function we add

systemManager.addSystem(RenderingSystem);

OK and that’s all we need to draw our asset to the screen. Not much use by its self but next post ill show how to send events between systems by injecting signals.

Entity Systems

admin — Sun, 23 Jan 2011 16:27:46 +0000

“Favour composition over inheritance”

If you haven’t already read my previous post on the problems of traditional game architecture and why entity systems are needed. I’m going to cover the basics of an entity system before we look at 3 different implantations and the pro’s and con’s of each.

What is an entity?

An entity (sometimes called game object) represents something in the game. For every tree,tank or ninja we have an entity. An entity is container to which we can add components (behaviours) that define what it is. e.g In this rather conceptual example a Ninja gets a Renderer, Physics, Health and Stealth components which together make up a Ninja.

This is the basics of all Entity systems one of key feature is the ability to create entities and change there components at run time. So a Ninja could become a Tank! (that’s the hard sell done).

Spotter guide.

There are 3 main ways to implement an entity system I have seen and I’m going to quickly out line them all and take a critical look at the pro’s and con’s. I’m going to call them common, almost and true (yes I’m bias but I think they are appropriate names)

“Common”

Most common implantation you are going to come across. Its based on the strategy pattern and its the simplest to understand. The first time I built a entity system this is what I did. There are good example out there in flash like PushButton Engine.

How it works

All components have a common interface normal with a function update(). Calling update() on entity causes update() to be called on all its components. Components then update there data for example a render component may copy its graphics to a view port.

Pros

Simple and fast. Better than inheritance.

Cons

Scalability and flexibility (how easy it is to make changes). To explain the issue lets take an example. We have an entity with both renderer and physics components. Both need to know about the location of the entity in the world. So we have two options

push the data up into the entity its self. In complex games this can result inmore and more specialised data gets pushed up into the entity creating a god object.
Allow components to access other components data. When one component depends on the data in another component we get a dependency. Component A can’t function unless component B exists. As a game grows so does the complexity of the dependencies.

There are work arounds to this issue for example automatically creating component B when A is added but then we need to give it the correct data. We start to lose the ability to mix and match components on the fly that makes an entity system so powerful. Entity to entity communication for example in collision detection is also difficult.

“Almost”

This was suggest to me by a friend I’m including it here as its hard to criticise and has a lot of positives points.

How it works

This gets the big leap correct it separates the data from the logic. In the common implementation both data and logic are combined in a component here they separated into

Data – Components
Logic – Systems(behaviours)

This is counter intuitive and contrary to what’s drilled into you about OOP. However it solves lots of issues.

A renderer system could require a spacial component (position in the world .etc) and a graphics component where as a physics system may require just the spacial component. Think of the components as the model and systems as the controller in MVC terms. Systems normally implement a common interface with a update() function

Pros

More scalable the systems have no dependencies on one another and can share data. Fast.

Cons

Systems are still dependent on an entity having specific components. This can be worked around to an extent by implementing it so that when we and a system to an entity any missing components are created automatically. This however means that we have to add a system before we can start setting the components data as they may not exist before that point. The main issue with this system come with entity to entity communication for example in collision detection. A collision system attached to an entity needs to check its self against all the others entities with collision systems this can be done with events but it also can be a lot simpler as we will see next.

“True”

“A game is just a real time database with a graphical front end”

- Dave Roderick

This is a blanket statment but its fundamentally true and this architecture is the closest fit to this statement I have found.

How it works

Again we separate out the logic and the data. However rather than adding systems to the individual entities we add the systems to the game its self. The systems can the do a real time look up and requests all entities that have the required components for processing. For instance a rendering system will ask every frame for all entities that have Spacial and Graphical components it will then run though the list drawing each one.

Pros

Scalable and easy to make change due to low dependences. Truly data driven. Simple. Collisions etc. are much easier to manage.

Cons

Slow(er) looking up the entities we need for each system every frame is going to effect performance. Counter-intuitive and requires you to rethink your approach to programming.

Conclusion

All these systems are better that a traditional inheritance hierarchy. I chose the “true” system for my frame work Ember as I think its pros out way its cons when it comes to the real issues of game development. It can also be implemented so that performance issues can become negligible. you can read how to get started using Ember here.

If you want to read more on entity systems its covered in some depth here by t-machine blogs.

Game Architecture

admin — Sat, 15 Jan 2011 16:52:21 +0000

In all the games I have made I have never been that happy with the architecture. Using PureMVC and more recently Robotlegs on a more or less daily basis has shown me the benefits of a well designed common framework. The down side of MVC which both are based on is that its not suitable for game development it’s ideal for the into screens and menus and perhaps even the UI but its not designed for problems found in game development.

So what do you do? Well if you like me then you will probably come up with something like this.

OK details may vary but it should be familiar to most people who have built games. So we have a nice inheritance tree and its all looking pretty straight forward. But then may be you decide actually what your game needs is moveable platforms. OK no real problem just change Platform to inherit from Movable and were done. Well some still don’t move so we need a boolean to flag the movable ones but that not to difficult.

So what’s the issue? Well perhaps now we decide we need a enemy that doesn’t move. What’s the simple solution to that? The point I’m trying to make is inheritance sucks. Its fine if everything is predetermined and well designed but games are not like that. Even if you have designed you game by some freak in-site to the n’th degree when you start on you next game how much code are you going to be able to reuse? Finally what if you want to make these changes at run time with out having to recompile?

Let me put another way would it be better if you could pick and choose the attributes you want for each item in your game.

As you can see we could make a moveable platform just by sticking a tick in the correct box.

So this is the ideal how can we do this in practice. Well we can use an “Entity System” also called “Component Systems” and “ Entity Component Systems” and loads of other names. I’m going to use Entity System as Component has to many meaning especially in flash. As well as having many different names there are as many interpretations as to how to implement one. Not being happy with any I had come across implemented in flash I have created my own framework Ember and made it open source. In my next post I look at the various ways of implementing entity systems.

Evlove your Heirarchy

T-Machines posts on entity systems

Superfun Town

admin — Thu, 05 Aug 2010 14:36:07 +0000

Massively Multilayer Isometric database driven Social Facebook game. In game payment, multi language, fullscreen with Flex user interface.

Play on Facebook