Regardless, after 8 public betas, RL2 is finally out! Huge props to all the contributors:

https://github.com/robotlegs/robotlegs-framework/contributors

As always, you can download the release over at:

http://www.robotlegs.org/

For general support please use the Knowledgebase:

http://knowledge.robotlegs.org/

And please report any issues you might discover:

https://github.com/robotlegs/robotlegs-framework/issues

Personal Thanks

Without getting too soppy I’d like to say a special thank you to @stray_and_ruby for pioneering much of the RL2 codebase and for putting up with me in my darker moments. Also, to @camillereynders for getting involved and pushing things forward. And to @OndinaDF for the incredible energy she injects into the support forum on a daily basis. Thank you.

Here are some numbers (subject to change):

Compiled SWF Size:

So, the framework is still pretty small. Thank goodness.

The second-system effect (also known as second-system syndrome) refers to the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors.

http://en.wikipedia.org/wiki/Second-system_effect

The battle continues…

I’m so glad to hear that Robotlegs has been working well for you.

Thank you very much for the offer of a donation, but we don’t accept monetary donations. However, there are plenty of other ways to help the project. For example:

1. Write a blog post about your experiences with RL2
2. Write a tutorial on using RL2
3. Build a demo application and post the code to GitHub
4. Provide feedback on the API, and raise issues on GitHub
5. Sign up to the support forum and help to answer other people’s questions ( http://knowledge.robotlegs.org ).
6. Help us to design a new website! Or give advice on making a better website ( https://github.com/robotlegs/robotlegs.github.com ).
7. Submit pull requests to help improve the codebase
8. Write a cool extension and submit it

Have great weekend!

Speaking of the Robotlegs website…

The site is hosted on GitHub (with a simple CName tweek to point the domain to their servers) and is statically generated using Jekyll. As such, you can simply fork the repo and submit a pull request with your design or content tweaks.

This one touches on Robotlegs 2, Dispatch Speed and critical pathways in an application, and, more specifically, why it doesn’t matter that Events in AS3 are a little “slow”.

I’d recommend Robotlegs 2 – especially for modular designs. I was never happy with the modular solutions for RL1.

The library is stable (I’ve been using it in production for months); the only reason for the beta status is that I don’t feel like enough people have given feedback on the API. Also, I haven’t had much time lately to review all the code – but that should change over the holidays.

Regarding the MessageDispatcher – it is a fairly low level tool for synchronous and asynchronous message passing. It is used to bootstrap the framework for example, but it is not a replacement for Signals or Events. Each tool has its place. However, if you are worried about speed…

The Event system in the Flash Player is a very well thought out and well designed Observer pattern implementation. It is good at what it does: offering a way to observe objects. But the performance critical pathways through an application should not be implemented using an observer pattern. Which is why I don’t see Signals as a valid alternative to Events. They might be faster in some situations, but they are still observers. For ultimate speed make direct method calls! If you need an extra layer of abstraction, use callbacks.

Of course, I really need to write a detailed blog post about all of this, but the point is: Events/Signals are observers and you shouldn’t stick them in the middle of performance critical pathways. The performance sensitive aspects of a system should flow through direct method calls (and as few as possible!). For everything else, Events are good enough, and have much better tooling support than Signals if you use a modern IDE.

Haha, “I really need to write a detailed blog post about all of this”.. pffft.

https://github.com/richardlord/Ash

I built this little shooter:

http://www.boyblack.net/proto/hunted/TopDown.html

What’s That Then?

Entity Systems offer an approach to object design that fits well with games, where requirements and behaviours need to be tweaked or swapped out constantly. Traditional object oriented design falls over a little bit in that environment.

In an application (as opposed to a game), objects and collaborations are usually clearly defined and do not change after startup. Objects play specific roles, and for the most part, those roles don’t change much.

In a game, however, the behaviours of “actors” within the system can change significantly during gameplay. An enemy may be stunned, for a period, losing the ability to attack. The hero may pick up a weapon, become invincible, or learn to fly. Time may slow down, speed up, or change direction.

Class inheritance is obviously not a good choice here (it rarely is anyway). But actually, many object oriented design approaches are at odds with these requirements.

Ash

Ash breaks things down into Components, Entities, Nodes and Systems.

Components

Components are simple value objects:

Components do not contain any code, logic or behaviour. They store state, that’s it.

Entities

Entities are buckets that hold components:

An entity does not need a name or unique identifier – it is merely the sum of its components. Components can be added to it and removed from it at runtime, changing what the entity does and what role it plays.

Nodes And Systems

So, if components and entities do not contain any actual code, where does the logic go?

This is perhaps the biggest difference between the Entity System approach and typical object oriented programming. Normally, objects encapsulate and hide their data. They expose well defined APIs, but they keep their inner workings, and the data they operate on, private.

There are very good reasons for this, but what it means is that all the emphasis is placed on methods and message passing and not on the data. Sharing mutable data between objects in an object oriented system is almost always a bad idea. Somebody else may change your data “behind your back” and leave you in an invalid state.

In an Entity System data is kept separate from the systems that operate on that data. The data is not encapsulated. Any system may operate on any data that it wants to mutate.

In Ash, specifically, Systems operate on lists of Nodes. A Node is a combination of one or more Components:

When an entity is given both a Display and a Position component a Render node will be created for that entity. If either of those components is removed from the entity the Render node for that entity will be destroyed.

A System that processes such Render nodes might do this in its update loop:

We loop through a linked list of nodes, access the components attached to those nodes, and do whatever it is we want to do with those components. We don’t care about the entities that those components are attached to.

A NodeList has signals for the addition and removal of nodes from the list which is handy when you need to prepare nodes before processing them. For example, in the RenderSystem we add DisplayObjects to the stage and remove them again when Render nodes are created and destroyed:

What’s It All Good For?

Adding and removing components from entities at runtime changes the nodes associated with those entities, in turn changing which systems operate on those entities. This effectively allows us to change the roles and behaviours of entities on the fly.

Imagine the hero – the character that you control in the game:

By adding the KeyControl component the hero becomes user controlled. Later we could do this:

Suddenly our main character is no longer under our control and is instead moved about by some AIControlSystem.

Hands On

To get to grips with all of this I built a simple game using Ash and Starling. It’s a top-down shooter with baddies that circle and attack you. You can check it out here:

http://www.boyblack.net/proto/hunted/TopDown.html

It takes a while to start feeling comfortable with the Entity System approach, and I’m certainly not there yet. But I have to say, it’s really fun! It forced me to approach problems from different angles, and helped me to build something pretty flexible.

Here’s a quick breakdown of the some of the core Components, Nodes and Systems I ended up with:

Components

Under each component is a list of the properties that make up the component

Nodes

Under each node is a list of the components that define that node

Systems

Some Thoughts And Observations

Marker Classes

I ended up with some “marker” components. Marker classes generally make me feel uncomfortable, but they seem slightly less evil in an Entity System.

Garbage

Making an entity and adding a bunch of components to it creates a lot of objects. Consider the bullets in my game:

We end up creating 6 throw-away objects for every bullet. The solution here is to implement object pooling, but that adds a lot of boilerplate. I’ll probably add pooling for the bullets, but avoid it for the other actors unless it becomes an issue.

Design

It’s challenging trying to decide how to slice up behaviours. Do I need a new system for this? Should I just add some extra code to an existing system? Do I need a new Node definition?

Where To?

Check out Richard’s blog posts:

1. http://www.richardlord.net/blog/introducing-ash
2. http://www.richardlord.net/blog/what-is-an-entity-framework
3. http://www.richardlord.net/blog/why-use-an-entity-framework

I found the Asteroids example in the Ash source really helpful:

https://github.com/richardlord/Ash/tree/master/examples/no-dependencies/asteroids/net/richardlord/asteroids

To be fair, it’s not a Flash/Flex issue at all, but rather a mobile browser detail worth knowing about:

http://www.html-5.com/metatags/index.html#viewport-meta-tag

Essentially, mobile browsers assume a default viewport width of 980px at 72dpi for any given web page and scale the content according to the actual device DPI.

Good for HTML; probably not want you want for your fullscreen Flash/Flex app. Use the tag above to prevent scaling.

What surprised me most about the first Try { Harder } was just how intense the whole thing was. At other conferences you can often just sit back and learn at your own pace (provided the material is actually technical enough to keep you interested). T{H}2011 was different.

I remember feeling completely exhausted at the end of each day – but it was accompanied by that lovely feeling you get when you know you’ve worked and grown as much as you can in a single day. Sleep is pretty epic after days like that!

However, it wasn’t just the talks and workshops that did this, it was meeting and talking to those folks whose blogs you read. Those people who you chat to on twitter but haven’t met in real life. That was, perhaps, the best part for me.

Now, I’m not the most social person in the world at the best of times, so this aspect was also quite overwhelming. Fortunately the week started off with an amazing talk that helped put everyone at ease. I can’t share the details but everyone agreed: it was the perfect way to reduce the inevitable resultant anxiety of a bunch of smart nerds meeting each other for the first time. This is just one example of the thought that went into the conference as a whole.

Try { Harder } Level Up: 19th – 23rd March 2012

I believe there are a couple of spots left for T{H}LU. If you can, you should come join us next week. It’ll be fun!

http://www.tryharder.org.uk/level-up-2012/

Update: Pricing for freelancers has dropped to £699 (including accommodation).

Update2: JetBrains are supporting the event by offering personal licences of IntelliJ IDEA to all attendees!

When you put a readme file into a folder that file is formatted and presented nicely through GitHub’s file browser. For example:

https://github.com/visionmedia/uikit

Scrolling down a little we can see a nicely formatted readme file.

GitHub strongly recommends adding a readme file to the root of your repository, but what I didn’t realise until recently was that it works for any folder in your repo. GitHub already has the best online file browser out there, but this specific feature can turn your source tree into your documentation.

For Robotlegs 2 I decided to try it out:

Async
MessageDispatcher
Extensions

Almost every package in the entire repo has a readme file. The best way to learn about Robotlegs 2 is to browse the source and readme files on GitHub.

Timing

To extend any framework you need to be able to hook into that framework’s initialization process.

That Damned Context

The Robotlegs 1 context class was, to be frank, rubbish – it set defaults, configured dependencies and controlled initialization. Worse, to hook into the initialization process or change the defaults, users had to extend the class itself resulting in the proliferation of funny looking words like SignalDrivenCovariantlyMediatedModularShellContext.

How Could You Let That Happen?

Extending the context was a silly idea – and I knew it at the time. It made me sad, deep down inside, but I knew that if I waited for a better solution to emerge the framework might never ship.

Also, my goals for Robotlegs 1 were:

1. Make it small
2. Make it fast
3. Release it

A ton of compromises were made to keep the number of classes down to an absolute minimum. That’s not how I usually write code. Besides…

Small Only Goes So Far

I always start by doing the simplest thing possible – it’s a good way to feel out a problem space. “What am I trying to do?”. The “how” doesn’t matter yet, but becomes important much later when I ask “How would I like to do this?”.

When writing actual code, however, I’m constantly faced with this annoying question: “Should I break this out?”. When doing the simplest thing possible I often decide against extraction: I’ve got a specific task to complete (like getting a test to pass) and I can refactor later if the idea proves itself to be worthwhile. Also, I know that extraction inevitably leads to a new set of design decisions. And I’ll have to start with a test – for something whose purpose I am only just discovering. And it ups the class count.

Keeping class count down for it’s own sake is almost always a bad idea. However, I don’t think Robotlegs 1 would have experienced the same adoption if it had had hundreds of classes instead of the quite digestible 15 presently in its belly. OK, 24 total if you add the interfaces.

When browsing open source libraries I get happy feelings from projects with a limited number of source files – it gives me a sense that if I really wanted to I could read through the entire codebase and understand it.

But there’s a point where that simplicity inverts. Profit becomes debt. Without good abstractions in place every participant in the system ends up doing too much. At that point the question becomes: “Do I need to introduce a new layer of abstraction?”.

Now You Have Two Problems

The introduction of a system wide abstraction layer fueled by a mid feature code extraction will do one of two things: it will strengthen the system or it will weaken it. A bad abstraction might solve the immediate design issues (like duplication) just fine but end up adding complexity and reducing quality overall.

Extensions? Timing?

So anyway, I want Robotlegs to be extensible in a sensible way. Users should be able to install custom extensions easily. Those extensions need a way to hook into the context initialization process:

Some extensions may need to be configured before others. Some may need to pause the initialization process and wait for a resource to become available. Some might directly depend on others and may need to wait for those extensions to be fully configured before self initializing. Some may only come to life after the entire context has been initialized.

It’s clear that the initialization process needs to be asynchronous. But without a good abstraction in place for dealing with asynchronous processing the context will be burdened with co-ordinating a complex series of events. Event soup is not delicious.

Events, Signals, Tokens, Tasks, Promises, Futures, Callbacks

There are a number of patterns for dealing with asynchronous processes. They have wildly different properties.

Some are low level, like the callback pattern. Some are high level, like the promise pattern. Some are guaranteed to be asynchronous, while others have the potential to be synchronous. Some are only good for observing. Some can be terminated, while others can be suspended and resumed. Some can be composed and chained. Some necessitate the instantiation of throw-away objects and put stress on the garbage collector. Some put stress on the stack.

Take Your Pick

I wanted something fairly low level that enabled asynchronous processing without adding unnecessary overhead in the cases where things could be synchronous (or skipped entirely).

I tried a number of things. For the most part: floppy, verbose and annoying implementations that moved the core problems around in less-than-useful ways.

Dispatch

Slowly it dawned on me. In this case all I wanted was an asynchronous message dispatcher. With a well defined set of callback conventions I could write something resembling an Event Dispatcher but without the overhead of creating throw-away objects (events) and with the ability to suspend and resume the dispatch when desired:

Some Async Conventions

The Message Dispatcher

Initialization, Extension, Please Continue

Very well. Suppose that context initialization comprises 3 steps: preInitialize, selfInitialize and postInitialize. When told to initialize the context moves through those steps in sequence. Anyone can listen in and halt the process as required at any point. What we end up with is in essence just a simple state machine where the observers have the potential to be guards.

The End

Well, that’s where the re-write started anyway.

Robotlegs 2

p.s. I dropped a bunch of stuff from the version2 branch. I’ll be going back to pull out any functionality that might have been lost shortly. If you come across anything that’s missing feel free to adapt it to the new codebase and send a pull request. Or drop an issue on the tracker. For quick reference, here’s the old version2 branch: version2-old