Hello Again, World!

Done! Exams are done! University is done! It’s all over! I’m FREE!

Now I can finally get to work. There’s so much to do! I suspect I’ll be a little bit giddy around here for a week or so, since I’ve been looking forward to fixing this place up for some time now. So welcome everyone, and if it looks like a bit of a ghost town, look again in a week. Below is a list of the things I’ve got planned for the next few months:

  • Write some more posts about things!
  • Fix outstanding pim2smsbr bugs (especially the character conversion errors/warnings)
  • Move piemaster.net from WordPress to Drupal, and go nuts with customisation
  • Particularly get a support forum integrated with the site. WordPress kinda sucks at this. The default Drupal forum is a bit ugly, but Drupal is a programmer’s framework. It gets the job done right.
  • Clean up all the site content
  • Release the new version of Forgbook that my team and I developed as a university project (then extend it to the moon)
  • Write up some more detailed information about the other projects I have lined up
  • Actually start on some of those projects!
  • Revisit Jario and clean it up a bit (related to one such unannounced project)
  • Just mess around and experiment with things!

My future is currently undecided. Whatever I choose to do I have a few months off now to play around with proper, focused software development, and after that I will either find my way back to uni to take a Masters of Software Engineering, or take a bit of a break and keep exploring the wonderful world of software.

I kind of want to build a startup out of one of these ideas, just for the experience. I don’t expect to become a millionaire overnight, or even a thousandaire over a year, but developers live to have their work seen and used by others, and for that to happen that work has to be a tight, focused application that solves a problem and solves it well. I know I can do that given enough time, and I can only imagine what the journey will bring with it.

First however I will get out of bed and have a shower, then diagnose which part of my PC exploded (literally) a couple of weeks ago. Thank you all for your support, whether or not it was deliberate, but even just having people view the site definitely keeps me going. There’s so much to do, and I’m going to make it happen. I hope you can get some value out of what is to come. Cheers, and Happy World Toilet Day!

Artemoids now on Softpedia!

Softpedia logoJust dropping by with a quick note that Artemoids is now available on Softpedia!

I was entirely unaware of this until I received an email this morning telling me as much, and honestly I don’t understand why, but hey! If someone enjoyed it enough to bother submitting it, then I’m not complaining! Then again, it’s listed as a game for Mac, so maybe Macs really are that desperate for entertainment once the thrill goes out of making photo albums and home movies.

Anyway, in celebration of being branded Piemaster Studios without my knowledge, I’ve set up a Piemaster Studios Facebook page so you to can show your support for the fastest-growing independent software developer in the last two hours!

Also good to know is that the extensive codebase of Artemoids was “tested in the Softpedia labs using several industry-leading security solutions and found to be completely clean of adware/spyware components”. So there you go – finally a crappy Java game that you can play in your browser without infecting your computer! Badge displayed proudly below:

Softpedia 100% Clean Award

Not So Back

Urgh. I’ve been sick for the past week and a half, descending into a feverous chest infection, and just now starting to improve. Unfortunately a whole pile of work has stacked up, so I’m not going to be nearly as active as I would have liked to be :(. Just letting you know on the off chance you were hanging out for some amazing updates. I’ll be back eventually, but not for a while.

I’m also considering migrating this site to another CMS (Drupal 7 is looking quite suitable), but there’s lots of research and decisions to make before then. Excitement!

Back and Back

You’ll all be glad to hear skiing was a success, and that I’m back behind the wheel. Unfortunately (for this site, at least), I’m also back to another semester of university, so I won’t have nearly as much time to update things as I have in the past month. The silver lining is that I’ll be learning a whole bunch of exciting, new (hopefully) things about software engineering and Web development which will make me more productive (and interesting) in the future.

And yet there’s so much to do and talk about! I’ll keep this post nice and generic, but know that I have a whole bunch of exciting projects just waiting for a chance at development, and come the end of semester I plan on making as many of them happen as possible over the 3+ month holiday. In the meantime, I’ll keep working on Piemaster projects occasionally, and writing about some of the things I’m learning. Who knows, it could even be a good form of revision.

We also just hit the milestone of 1,000 visits! Total. For the whole site. Ever. That may not sound like a very big deal to anyone else, but it’s a nice achievement for me, so I’d like to thank each and every one of you who was responsible for a hit. I’m extremely happy to have been able to help a few different people with a few different things while entertaining myself along the way, and I hope I can keep it up. Now that I have something to work for, there will hopefully be fewer news blackouts. I love you guys!

Ski Free or Die Hard

Ski Free screenshot

That's going to be me! Hopefully sans enormous rocks. And yetis

So today I decided, what with it being winter and all, that… no, sorry, I’m not remaking Ski Free. Yet. I’m not legendary enough to tackle such mind-bogglingly superior game design.

However I will be away skiing freely myself up Mount Buller for the next week, so there’s unlikely to be any updates until after I get back.

When I do get back, hopefully I’ll have some details to reveal of a couple of projects I’m working on alongside Jario. Jario has served its proof of technology purpose excellently, and I’ve been having a stab at converting that codebase into something different without any initial planning to see how easy it is to do. At present it’s hard to say, since most of my effort is going into integrating the JBox2D physics library via Fizzy (re-maintained), which poses some conceptual challenges of its own, but is starting to work very nicely. I’ve always wanted to work with a physics engine, but never have, so it should be fun.

Anyway, thank you to anyone reading this, and I’ll see you bright and early when I get back!

Jario Update: Sounds and Semi-Passability!

Yes, thank you Chrome, only one of those is a word, and yet Jario now has both! Sounds were ridiculously easy to add through a generic SoundSystem with a handful of static sounds (courtesy of http://www.freesound.org/) and a static queue-push method, and then the single-line calls were peppered throughout the systems as required. The result is a game which is a lot more fun to play! Despite still being about 60 seconds long.

Go ahead, try it out!   Launch Java Web Start button

The issue of passability is a more technical one. Previously, all detected collisions were handled directly by each of the colliding entities. This is great for many cases, but there are some times when you don’t want to handle a collision, or when you want to not handle it under certain conditions, and for which adding in a bunch of conditional guards is ugly and inefficient.

My solution was to sneak an extra layer into my collision handling hierarchy (which I’ll talk more about when it’s a little more polished), right up the top, to manage collision persistence. In this context, persistence means that when two entities collide, all future collisions that are detected until they stop colliding can be grouped into a single collision, and handled only once at the beginning. This is important for a number of gameplay mechanics.

For example, the two cases I added just now were semi-passable platforms and improved handling of player recovery. Semi-passable platforms are those ones that you can jump through from below, as well as stand on top of. One way to get this behaviour is to say “if the collision is not from the top edge, do nothing, otherwise block the entity”. This may work, depending on your collision detection mechanism, but for the time being mine is very basic, and detects the edge of the collision based on the X and Y distance the two entities are overlapping by. The result is that if you jump through from the bottom, a bunch of collisions will occur for the handful of frames you’re passing through, and as you are about to exit from the top, one of those collisions will be detected as “top edge”, and the default behaviour is to place the player on top of the platform. The behaviour we want is for the player to keep jumping, eventually fall back down, and then be placed on the platform.

My solution is a little more complex than perhaps it needs to be, but it’s a good starting point. When a collision occurs, the handling systems can register the collision as a “passing through” case, after which future collisions will not be handled by the entity that is passing through (the ‘passer’) until the entities separate. However, the entity being passed through (the ‘passable’) will continue to receive handling calls in case the circumstances of its passability change. It can therefore also check whether the colliding entity has been previously registered as a passer. All of this handling is contained in PersistentEntityHandlingSystem class, which all current collision handlers extend.

In the case of the platforms, this is straightforward. On the first collision, if the player collides with a non-top edge of the platform, the platform registers the player as a passer, and the player continues unhindered. Once the player exits at the top, they are unregistered from the platform, and the next collision will be handled appropriately on the top edge.

Player recovery is a little trickier. By “recovery” I mean the period of invulnerability you get after being damaged with >1 health. During this time, you shouldn’t be able to stomp enemies from inside (i.e. walk into them from the left, then jump and kill them on the way out). So for this case, when the player collides with an enemy, he first checks whether he’s in recovery mode, and if so, if the enemy is not already registered as passing through, then the registration occurs. The enemy passing through the player means that the enemy is oblivious to the collisions (and so can’t die until the player leaves and comes back), but the player’s handler is still called each frame. Therefore when the test for recovery fails (i.e. recovery time has expired), then the enemy is unregistered as a passer, and the collision can be handled normally.

But wait, there’s more. It’s possible for recovery to expire while the player is standing right in the middle of the enemy, and if the position is right, it will register as a top-edge collision, and “handling normally” means the enemy will get stomped. This is not the desired behaviour – if the the player is standing inside the enemy when recovery expires, the player should get stomped instead. To work around this, I added a parallel map that records which passable-passer relationships should be unregistered in the next frame. This gives the player collision handler a chance to handle the collision manually and correctly (take damage) before unregistering. If the player manually takes damage AND unregisters in that frame, by the time the enemy handles the collision it will appear unregistered, and the potential top-edge problem persists. By delaying it one frame, the player’s damage will have been fully accounted for, and the enemy collision will not occur at all.

Problem solved! You can see all that in PlayerHandlingSystem if you like. Like I said, it’s quite complex and I’d like to simplify it a bit, but it’s a start. By experimenting with this approach, I’ve gained even more of an appreciation of the Artemis framework. You really can tackle your problems one at a time, in isolation. Even in the case of a two-entity collision, the collision handling of the two entities can be neatly decoupled. The future is looking bright!

Piexcerpts Are Here

As you may have noticed if you got as far as reading this post, I recently mashed my fist against the WordPress settings and plugins pages until the site bent to my iron will. It will now display only the excerpts of posts instead of full articles on all pages except those of the individual posts. Hopefully this makes the side more readable, as I have posted and intend to continue posting some pretty long articles.

In case you’re an interested WordPresser, I’m using the Excerpt Editor plugin which not only smartens up the automatic excerpt generator, but also provides a convenient interface for editing past posts, with and without excerpts. It’s got a couple handfuls of features which are nice to have. Consider it recommended. Now please excuse me while I go and create some manual excerpts for old posts so they look a little less rubbish.

Jario Update: Kinda Working!

I’ve just pushed an update to Jario with some pretty nice changes since I last mentioned it. As usual, you can check out the source if you’re interested or just Launch Java Web Start button!

I’ll be quick:


  • All the important items – coins, mushrooms, fire flowers and stars.
  • Goombas, Koopas and even empt shells, with the ‘proper’ graphics and animations.
  • Vastly improved input and collision handling.
  • Added a marginally more satisfying ending, though it still doesn’t do anything.
  • Fixed many, many bugs (but not the intermittent collision mesh one yet).


  • Cleaned up collision handling systems into a hierarchy of similar handlers for increasingly concrete entity types. I’ve found it to be very flexible and reusable so far, which is nice, since the logic of a game is little more than input and collisions.
  • Refactored image and animation spatials into a hierarchy of intermediate abstract classes, and added a SpatialComposer to group the different spatials of individual entity types and handle different states.
  • Inserted a hierarchy layer for spatial effect handling. Currently only processes changes in rendering alpha value, but does so quite nicely.
  • Played around with a TimerSystem to be used in conjunction with a Timer component, allowing systems to easily register callbacks with individual entities to be executed after a given delay. Makes it very easy to add temporary properties to entities. For instance, giving the player X seconds of invulnerability (hurt with >1 health, or press I) reduces to a single static function call. Still need to play with Artemis’ DelayedEntityProcessingSystem to see if that does a similar thing.

That’s all the significant bits so far. Still plenty more to go, though! Some of the above will need to change in order to support a complete level, which will be interesting. I also need some better game state transitions, though that’s nothing to do with Artemis. I’ll talk a little bit about some of the more interesting points soon, such as the collision handling and spatials, since those two are key to getting a game working smoothly.

Entity/Component Game Design That Works: The Artemis Framework

Artemis logo

In my previous post, Entity/Component Game Design: A Primer », I reviewed some of the main differences between traditional object-oriented game design and the emerging paradigm of entity/component game design. I deliberately avoided talking about Artemis, and focused instead on the weaknesses of the alternative approaches, because I believe Artemis is able to resolve many of those problems.

Here I want to talk about the Artemis framework for a while. I keep saying I’ll write about it, but I wanted to get a little more familiar with it first. Well, I’ve been playing with it pretty solidly for about three weeks now, and I feel like I’ve got enough experience to form some kind of an opinion. Although there’s a brief overview on it’s homepage, I want to present my own perspective of it, and talk about some of my reasons for falling in love with it.

Big thanks to the authors Arni Arent (appel) and Tiago Costa (Spiegel) for all their hard work and support!

The Artemis approach

The Artemis framework inherits the concept of Entities representing bags of Components, but it does away with the OO concept of encapsulating behaviour within the components. Instead, it adopts a data-driven design involving the separation of the data and logic of each component.

In essence, the Components serve as little more than bags of data. They have no update function, no internal logic, just getter and setter functions to expose their current values.

The logic is instead encapsulated in the Systems that accompany the entities and components. A ‘System’ is simply an object that reads and updates the data in any relevant components. You could say it’s simply the update function of the relevant components refactored into its own object.

I say “relevant components” because of how the systems do their processing. Instead of the game iterating imperatively through all of the entities and updating each in turn, the systems take more of a functional programming approach. Each system specifies a set of components that it’s interested in, and then in each frame it processes only those entities that contain all specified components.

Furthermore, each system exists to perform a specific role, updating all instances of the relevant components before passing control to the next system. You could say that the components are processed in cross-sections across all entities at once, rather than entities (and all of their child components) being processed in chunks.


That’s more or less how Artemis goes about its business, but without having used it, it may not be immediately obvious why this is a Good Thing. Following are a few reasons why I believe it’s a Very Good Thing. Of course, you can only truly appreciate the details after working with it, so I’ll try to keep the discussion at a high level.


The magic of systems is that they have no reservations in accessing multiple types of component at a time. The systems compose the communication between related components so that the components themselves don’t need to. Systems typically process one entity of interest at a time, and for the period in which they’re processing, they can combine any of the components within each entity however they like, with no structural side-effects.

For example, a MovementSystem could process all entities with Position and Velocity components, and each frame it would update the values of each Position component given the associated Velocity component. A RenderSystem could process all entities with Position and RenderableMesh components, and it would draw each mesh to the screen given the values from the updated Position component. In neither case do the components require any knowledge of each other.


Refactoring the logic this way essentially gives you two layers of components – data components (Components) and logic components (Systems) which read/write the data components. Since the Components are pure data, they should never need to change. A 3D Velocity vector will always have X, Y and Z components, and so will be perfectly reusable in any 3D scenario.

The logic in the systems will depend on the rules of the game world, and they can be interchanged as needed. Since each system is typically self-sufficient enough to be autonomous, changing the behaviour of a system will not necessitate a change in the behaviour of any other system.

Say you want/have to change your game from a 3D free-roaming game to a 3D side-scroller. For side-scrolling movement, all you need to do is plug in a side-scrolling MovementSystem (it could be exactly the same, but simply discard the X component of the velocity), and it will automatically apply to all entities with Position and Velocity components. No components or other systems need to change as a result of the change of MovementSystem, since no components or systems even know it exists. (You may then need to update the CameraSystem and ControlSystem as well in this example, but the same process applies.)

Not prescriptive

Because the entities are simple bags of components, and the components are simple bags of data, as a developer you really only need to concern yourself with crafting the systems. The systems can easily take care of composing the relevant components within each entity, and beyond that they have no restrictions in how they process things. This means you can focus on constructing effective systems to solve problems in creative ways.

For example, I have a single CollisionSystem which detects and records all collisions in a single pass, after which I have an OO hierarchy of collision handling classes down which collisions are passed to be handled appropriately. I have an asynchronous TimerSystem which, together with a Timer component and external handler class, lets me attach and listen for delayed events with registered callbacks on individual entities with a single static function call. This may not be the “right” way to do it (and there often is no “right” way), but that’s up to me as the developer. I have the freedom to experiment, and to choose what works best, without sacrificing any part of the framework.


All Artemis processing occurs within a managed World object. For convenience, the world object contains four managers that make your job almost too easy:

  • EntityManager manages the creation and removal of entities and their components, and allows components to be retrieved from entities by type.
  • GroupManager allows entities to be assigned to unique groups (string IDs, such as “ENEMIES”) and retrieved as a group at any time in any system.
  • TagManager allows individual entities to be assigned uniquely identifying tags (again, string IDs, such as “PLAYER”) and retrieved individually, similarly to groups.
  • SystemManager stores all of your systems, allowing them to be retrieved individually by type if necessary (for instance, the RenderSystem may need to communicate with the CameraSystem).


The Artemis library itself is very lightweight (for some sense of comparison, Artemis is 30KB compared to the ~1.5MB of Slick + LWJGL), and the internals are built for performance at larger scales. I haven’t yet reached the point where performance becomes and issue, so I can’t comment on quite how far that is, but that alone is an endorsement. Author testing has managed to create/remove a few thousand rendered entities per second, a number which goes up to millions without rendering.

On top of that, the functional programming approach to component processing has inherent potential for performance gains, if taken advantage of. I haven’t read too much into this yet as it hasn’t been necessary, but I’ll talk about it at a later date.


Despite appearances, this is just a static outline of how the Artemis framework fits together and some of the things it does well by itself. I’m not going to dive into all the different things Artemis allows you to do; I’ll try to cover some of those in separate posts in the near future.

I will however say that when using Artemis, the development process changes radically (for the better). You can tackle the implementation of one aspect of your game at a time in isolation. You have a clear implementation path to follow. As your library of components grows, adding new entity types to the game is as simple as creating a new Entity object and adding a different set of Components (or just modifying parameters), and they are automatically handled by the relevant Systems that you already have in place. At that point, it’s almost trivial to read in all your entities from a text file and be truly data-driven.

It’s a pleasure to work with, and every day I’m thinking of new ways to do things that make it even easier. If this article piqued any curiosity or excitement in your inquisitive mind, then I strongly encourage you to investigate using Artemis with Slick. Start by downloading the demo game, StarWarrior, and browsing through the source code. Then try making some small changes to transform it into a different game; perhaps something like Artemoids? Where you take it next is up to you and your imagination.

Just remember to keep an open mind, and have fun! I’m no expert, but I’m more than happy to give whatever advice I can, and the Slick forums are always friendly.


  • Artemis Entity System Framework – The official homepage of the Artemis project. It’s quite new (about a month old), and rather small as I mentioned. From the homepage you can get the compiled JAR, source (JAR, SVN, Git), JavaDoc, and the demo StarWarrior game (inspired by Space Invaders). There’s also an unofficial C# port going on.
  • Artemis thread in the Slick forums – Artemis was originally developed for Slick, and so that’s where most of the discussion is so far. I should mention however that it’s not dependent on Slick, and appel is already using it with libgdx.
    • For those of you interested in what I’ve been discussing, I joined in on page 12.
  • Entity Systems are the future of MMOG development (T=Machine) – A very thorough application to MMOs, and a primary inspiration for Artemis.
  • Anything on this site with the “artemis” tag – The count of this content will be increasing consistently in the future, because Artemis is a lot of fun to talk about.

Entity/Component Game Design: A Primer

Components of Crysis

Crysis rendered as bags of components (click for detail).

I want to talk a bit about the Artemis framework I’ve been playing with, but it won’t mean much without some background knowledge of the entity/component paradigm of game design. This post, then, is a quick review of my experience with entities and components, and how they relate to the more traditional object-oriented (OO) paradigm, and in particular, what sucks about both.

If you’re familiar with the entity/component paradigm already, you may just want to skip over to my detailing of Entity/Component Game Design That Works: The Artemis Framework » and read through this at your leisure. There’s a few connections, but I’m trying to keep it at a pretty high level for now.

Object-oriented games

In a traditional OO design, every “thing” in the game, be it a tank, a bullet, a light or a sound effect, is defined by its own class. Naturally there is a great deal of similarity between some classes, and so they can inherit common behaviour from more abstract classes. For example, a Tank and and a Car are quite similar: they both drive around, are affected by physics, have some visual form, and make sounds occasionally. This behaviour is common to all vehicles, and so can be inherited from an abstract Vehicle class.

This is quite intuitive, relatively effective, and allows the programmer to add a Truck by inheriting that same behaviour from Vehicle and assigning it a truck model. Of course, both Vehicles and Projectiles are affected by physics, so both abstract classes can inherit the properties and behaviour of a more abstract PhysicalObject, and so on.

The design of an object-oriented game will require a detailed design of this class hierarchy, with each concrete in-game object inheriting from a tree of increasingly abstract classes, right up to something like GameObject, which may just represent anything with an ID assigned to it. If this hierarchy is planned out well before implementation, then it’s quite possible to build a large, complex game leveraging OO inheritance. After all, that’s how most games are built.

However, the deeper your class hierarchy grows, the more brittle and fragile it becomes. If (read: when) the requirements change after implementation begins, reflecting those changes in the code will often require adding and/or removing functionality to some of those abstract classes. Such changes will flow on to affect all subclasses, whether or not those subclasses need the changes. The result is messy code additions that get pushed up towards the root of the (upside-down) tree in order to provide the changes to a greater number of subclasses. (The alternative is duplicating and encapsulating the changes in each concrete class that requires them, which is arguably worse still.)

Entity/component games

One of the core principles of good software design is modularity: breaking down the core components of a system into individual, independent units, and then building the system as a whole by plugging these components together. There are many benefits of modularity, including, most relevantly, flexibility. If one component needs to change, a modified component can be plugged in to replace the old component without affecting the rest of the system. So long as the rest of the system can talk to the new component in the same way as they did the old one (i.e. it conforms to the same interface), then they are oblivious that a change even occurred.

Since sometime around the turn of the millennium, the idea of breaking down the traditional game class hierarchy into a more modular design has started to spread. It’s not a particularly new idea, it has no obvious source, and now it seems to be everywhere in every conceivable form if you go digging for it. I want to focus however on the ‘traditional’ entity/component model, and later contrast it to that adopted by Artemis.

Traditional components

My first encounter with a (relatively) formal definition of entities and components in a game setting was in Game Programming Gems 6, where it was discussed as a “Game Object Component System”.

Here’s the deal. Forget about your class hierarchy, throw out your painstakingly-drawn inheritance trees, and take off your OO hat for a minute. With entities and components, we’re only interested in concrete “things” – Tanks and Cars, not abstract ‘Vehicles’. By the time you’re done, any game object hierarchies you have should be almost completely flat.

Some terminology: an Entity represents a concrete “thing” in the world, such as a Tank. However an Entity has no Tank-specific logic; indeed, an Entity barely has any logic at all, and is little more than an ID.

The real magic comes from the components it contains. A Component is a module of functionality, call it an attribute if you will. Components are things that Entities have, things like Position, Velocity, RenderableMesh, and PhysicalBody. An Entity is little more than a bag of Components; it is quite literally the sum of its parts. Importantly, the Entity has no explicit knowledge of what parts it contains, meaning all entities can be treated the same way by the rest of the game.

This is possible because the components take care of themselves, regardless of which entity they belong to. For example, the RenderableMesh component contains the capability to render a 3D model. The model is assigned to the component, and the component is assigned to the entity, so the entity doesn’t need to know what the model looks like. All the entity needs to do is call some generic update function on each of its components each frame, and each component will do its own thing. A RenderableMesh, for instance, could draw itself to the display.

The beautiful advantage of such a system is that the components are generic, they perform a single role, and they perform it the same way regardless of their parent entity. As such, the RenderableMesh of a Tank object would draw itself the same way as that of a Car object, the only difference being the shape of the mesh assigned to each component. As a result, different types of entities can be manufactured easily by plugging different reusable components into an empty entity.

This is great news for maintaining flexibility during and after development! Changes to entities will typically involve changing one or two components in isolation, without changing any unrelated components or polluting other entities. New functionality can be added with the independent addition of new components.


The unfortunate weakness of this system is that there are inherent relationships between the components which requires them to be coupled in some way or other. They are, after all, parts of a single whole. For instance, the RenderableMesh knows how to render, but it doesn’t know where to render without consulting the Position component. The Velocity component can very well keep track of velocity, but it’s not much good without being able to update the Position component.

One proposed solution is to push this ‘shared data’ up into the Entity itself, so that all components can read and write to the position variable. However this leads to an analogous problem to that of the traditional OO hierarchy; it’s a slippery slope. Once you push up position, you may realise that movement also needs to know how much health the entity has, and so you can either communicate with the Health component or push health up into the entity. And hey, rendering and collision handling need to know the physical dimensions as well. And so on.

Another solution is to allow components to hold references to each other and communicate directly, but this has multiple drawbacks associated with it. For one, it couples the components very tightly, making them difficult to reuse under different circumstances. In addition, all these references need to be assigned when the entity is created, but without the entity’s direct intervention, which is a non-trivial problem in itself. One possible sub-solution is to implement some elaborate system of runtime inter-component dependency resolution and injection, which adds a mountain of complexity to what should be a molehill of an obstacle (simply plugging in components).

An alternative to holding direct references between components is to attach a message dispatching system to each entity, allowing components to fire events when something interesting happens, and handle other events of interest fired by other components. This has the advantage of decoupling the components which is nice, but comes at the cost of, once again, increased complexity and a persistent performance penalty.

Even if you manage to get all your components hooked up and working together, completely encapsulating the logic related to each component within the component itself is fraught with the danger of your components becoming bloated with functionality. In theory, a Physics component should handle all physical interaction between its parent entity and the rest of the world, but does the knowledge of the rest of the world really belong in a component? Perhaps we can split out the physics calculations into a centralised physics manager… So then which components have logic and which don’t, and how much?

The answer?

There are many, many different approaches to working around these multifarious concerns, some of which I mentioned above, but they all seem to raise more problems of their own. Does there exist some architectural solution to circumvent these obstacles, not by climbing over them but by simply changing lanes? I’m a strong believer that any software design is possible with enough ingenuity, and I’ve found the Artemis framework to be pretty ingenious. Read on for why I think Artemis represents Entity/Component Game Design That Works ».


There are buckets of great articles out there explaining the entity/component game design paradigm from different perspectives, and it’s the kind of concept where your understanding really benefits from a broad exposure. Below is just a handful of the ones I’ve found useful in my adventures. You can, of course, find plenty more by Googling “entity component game”. Please mention any other particularly useful ones you’ve found in the comments and I’ll add them in too!