Slick Forums

I like to invite you to take a look at my work in progress. It's an entity/component framework (for Slick).

---
I know I will get asked this question "What about Artemis?". Artemis is a more abstract framework, not really for 2D, Slick, and quite difficult to master. Artemis is really an experimental framework. Artemis and Apollo are not directly related (except those familiar with Greek mythology know that they are siblings), although my experience and insight with Artemis surely has proven useful in constructing Apollo.
---

But enough of that, let's talk about Apollo, what's the big deal?


Spatials and priority fill

One of the big problems in 2D game development, IMO, is the "painters algorithm" or "priority fill" issue.
http://en.wikipedia.org/wiki/Painter%27s_algorithm

I make a lot of top-down games, and I usually have entities like a tank, tower structures, etc. A typical problematic tank entity would comprise of a hull and a turret. There are two issues:
1. How do you ensure that the whole tank gets rendered after the terrain.
2. How do you ensure that all the turrets get rendered after all the hulls? (So a barrel of one tank won't strangely disappear beneath the hull of another tank).

Apollo solves this quite efficiently by using "Spatials" and priority buckets.

Each entity can be given a spatial for rendering, and each Spatial must specify which Layer it belongs to. The rendering part of the framework then uses this and makes sure spatials are rendered on correct layers.

Nodes are supported, and are important to understand. For that tank entity you really have two spatials, the hull spatial and the turret spatial. You can make a TankHullNode which has a child spatial called TankTurretSpatial. TankHullNode gets rendered on Layer.UNITS_HULLS while the TankTurretSpatial gets rendered on Layer.UNITS_TURRETS.

Now, it's also quite easy to create a HealthBarSpatial which can be attached to the TankNode, or perhaps you can arrange this differently. You see where this is going, you really have a scenegraph here, so it's without limits how you can structure you spatials and attach to an entity.


Managers
Apollo comes with a variety of managers for tagging, grouping, player, teams, etc. You can even make your own custom managers and add it into the world, and get it from anywhere using the world instance.


Components
Components are the main ingredient in entities. They contain the state and logic. You can make a "family" of same type components, like "Health" and "RegenerativeHealth", but other components do not know which one they're using.


There's a small example included in the code, but it doesn't really show how well this framework scales. I'm developing this framework alongside my work on Towerfield, so I will add things as I see they are missing, or refactor heavily. So far I'm amazed by the power of Spatials and Nodes, and the Layering. I will probably open up the code for this.

It's a very lightweight framework so there's not much need of learning.



I will probably be adding some sort of messaging and there's still missing lots of functionality in EntityManager, like getting all components of certain type, etc.



I only provide SVN access now: http://gamadu.com/svn/apollo/trunk/src/com/apollo/


Note: It's a work in progress, by no means is it recommended that you use this in your own game YET. It's simply not ready. For now I'd like to get feedback, quell questions, suggestions, for now.

Ok, I've made some significant updates tonight.

The framework can be now considered "usable" for testing and evaluation purposes, and perhaps to try out in a small game.

Count on the library to change, so bet on broken code if you use it and update later.

Interesting! Have you gotten into the nitty gritty performance comparisons between Artemis and Apollo?

I also noticed that this is very different from Artemis. No more systems?

Performance should be similar.

Apollo has the managers, to do operations on all entities or to do some grouping on them.
Components now have the logic (that was in the systems).

But really, the only similarities between Artemis and Apollo are the naming.

Managers are really useful and customizable.

Here's a SelectionManager I made yesterday, that simply sets entities to be selected if they are less than 30 pixels away from the cursor, and if they're not it deselects them.




You could also add a "selectedEntities" bag in there and have a method return it, so anywhere in the game code you can simply retrieve a bag of selected entities doing something like:

Huh, I just saw this now. Interesting stuff.

In relation to Artemis, what made you decide to move the logic to the components? The revelatory thing to me in the first place was getting it out. And as a follow up, what does the component logic even do? Is it just relatively more sophisticated processing of itself, or is there external communication? From that snippet you posted, it looks identical to how it would be done in Artemis, with some minor conveniences.

And is this intended to supersede Artemis once it's 'done'? (i.e. should I be try out both? )

EDIT: I just saw your post on your forums which pretty much answers my question. It's just a different, more traditional approach, and you don't yet know which will be 'better' in the end. Fair enough.

I really, really like Artemis is all, and I'm a little scared you're going to come out and so "oh never mind, Artemis was actually rubbish" .

I'm not sure what to do with Apollo. I may throw it away as a project, or not. Currently it's just a small set of classes that don't do really anything remarkable. It's inspired by the "Game Object Component System" or GOCS described in Game Gems 5 (or 6) book.

The main difference between the two ideas is that you have systems in Artemis executing component logic, but in Apollo/GOCS you have that logic in the components, thus it makes Apollo/GOCS more traditional/object-oriented than Artemis, and some might prefer that.

Apollo is NOT usable at all at it's current state, I've removed a lot of stuff like the spatials from the framework to make it more generic, but might put them back in, not sure. It's being worked on along other game projects I'm working on.

Artemis is a much more fully formed framework, use that.