Agent-Oriented Programming: A Brief Introduction

Not quite the same, but much catchier.

Agent-oriented programming (AOP, not to be confused with aspect-oriented programming) is a programming paradigm in the same way that object-oriented programming (OOP) is; it provides a set of concepts, and a way to think about the world in terms of those concepts. AOP is a more recent development, and still an area of considerable research and standardisation. Wikipedia traces OOP back to the 1960s, while AOP came about from research into artificial intelligence by one Yoav Shoham in the 1990s. As someone who is fascinated by new ways of thinking about software and its development, AOP is of great interest to me, and I’ve been quite fortunate to fall into a year-long university project centred around it (on the Android platform, appropriately enough).

So what is AOP? What is an agent (more precisely a “software agent“), and how does one orient one’s programming around them? AOP sits one level of abstraction above OOP, such that agents are effectively abstractions of objects. Intuitively, agents can be thought of as software entities with intelligence, just as we think of science fiction AI robots. They are machines, or in this case computer constructs, but at runtime we provide them with instructions as if they were people, like everyday colleagues. In particular, we try to avoid micromanagement of communications between agents; ideally, we would like to provide them with a task to perform and allow them to talk with each other to determine how best to accomplish it.

As if computers weren’t already making humans redundant in enough ways, taken to the logical extreme you might think of AOP as a blueprint for the obsolescence of human labour. Agent-oriented software engineering (AOSE) goes through the typical software engineering phases of requirements and design, but it does so in, again, a more human fashion. It’s more similar to designing a business process workflow than a set of modules; the focus is on the dynamic communications, the flow of information through the system, rather than the static structure, and the communication takes the form of messages passed between ‘roles’. Roles are more or less what you would expect: responsibility for an area of functionality, and the separation of concerns principle applies to keep individual roles coherent and independent. These roles are eventually adopted by agents, and then each agent has its capabilities specified hierarchically (multiple levels of sub-capabilities to achieve each capability), and the abstractions are peeled away layer by layer until each agent is composed of a set of concise, almost atomic, functions. Ultimately quite similar to OOP, but overall we’re more concerned with what an agent can do, and which other agents might be interested in that service.

The main application of AOP that comes to mind is artificial intelligence for autonomous robots, and the canonical example is one such robot that inhabits some arbitrary environment which it scans for rubbish, and upon detecting some rubbish, picks it up and drops it off in a rubbish bin. Even in such a simple case (well, it’s no driverless car), it’s interesting to consider what types of components are required. One common class of agents have beliefs, desires and intentions (hence BDI agents), just like humans, and can operate autonomously with very few ‘moving parts’:

  • Beliefs represent what the agent knows to be true or false about its environment (e.g. there is some rubbish at location (X, Y)). Beliefs are updated when the agent perceives some unexpected change in the environment (much like an event-driven programming model);
  • Desires describe the agent’s goals, or the state it would like the environment to be in (e.g. no rubbish at any location (X, Y));
  • Intentions are the actions which the agent can take to affect its environment, based on its beliefs, in order to change the state of the environment to achieve its desires (e.g. if some rubbish exists, the agent will intend to pick it up; having picked it up the agent will intend to move to the rubbish bin, and then drop it off, and so on).

Firstly, it’s interesting to consider that these basic constructs alone can theoretically describe much of the field of physical human endeavour (where the environment is the physical space-time continuum that we inhabit). However it may also be interesting to consider what human activities cannot be modelled in such a way. For example, I can’t quite picture how machines will be able to emulate the mental creativity of humans (though I’m sure they will eventually), and this is difficult to model since there is no tangible environment and often no precise desires. Empathy, or the natural understanding and sharing of emotion, would also be difficult to emulate for similar reasons, but also because an emotionless machine wouldn’t have that individual experience to fall back on. It comes down to the idea of understanding, which raises the question of what is meant by the phrase machine learning. I consider this roughly equivalent to becoming statistically more accurate by the modelling of some logical process, but whether this is actually increasing any kind of understanding on the part of the machine really depends on your definition.

Of course, there are many less fluffy applications for agent-oriented programming, and I look forward to exploring some of them in future posts. It’s a genuinely thought-provoking topic, and I hope I’ve got your mind ticking over too. It’s a field that appears easy to understand (they’re just like people, right?) though very difficult to really get your head right around, but one that I think might just be worth the time.

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!