Ashley 1.0.1 released

Hi, it’s David Saltares aka @siondream.

What? You don’t know what Ashley is? Here is a brief, straight from GitHub.

A tiny entity framework written in Java. It’s inspired by frameworks like Ash (hence the name) and Artemis. Ashley tries to be a high-performance entity framework without the use of black-magic and thus making the API easy and transparent to use.

Long story short: Ashley is awesome.

Stefan Batchmann started the project on February 2013. Since he is rather busy making actual games, he asked me to look after the project and I gladly accepted.

Entity systems are really cool and can help you write cleaner game code, avoiding the classic inheritance hierarchy hell. This article does a pretty good job at explaining the benefits of entity systems.

It’s funny how strongly opinionated developers seem to feel towards entity systems. Some love them, some hate them. Have a read, experiment with Ashley and decide for yourself.

The readme will help to you get started. Please, do not hesitate to open an issue if you find any problems. If you send a pull request, you will have our unconditional love.

During the past couple of months me and a bunch of awesome collaborators have been working on a proper Ashley release and now it’s done. Here is the list of the new shiny features.

Mind that some of them break the previous API. However, this is our first official release, we’ll push hard to keep the API backwards compatible from now on.

  • Gradle: we got rid of the Eclipse projects and now use Gradle to manage our dependencies and build process.
  • Maven Central: Ashley is now available from Maven Central, which makes it dead easy for your project to depend on it. In Gradle, add the following dependency: compile “com.badlogicgames.ashley:ashley:1.0.1”.
  • Jenkins build: Mario kindly offered us some server time to make sure Ashley is always stable.
  • Unit tests: there are unit tests for pretty much every component in Ashley. They are run after every commit by our Jenkins job.
  • Immutable collections: core Ashley classes now return ImmutableArray and ImmutableIntMap references, making it harder for client code to break the system.
  • Family filtering: now we get the collection of entities that have a set of components, have at least one component from a given set and do not have a single component from another given set.
  • GWT compatibility: you can now use Ashley for HTML5 games through the magic of GWT and Libgdx.
  • Depends on gdx core: this has allowed us to remove all the duplicated optimised container classes and gives us a GWT compatible reflection API. Some might say it’s a big dependency but we do believe the pros outweigh the cons.
  • Cleanup and bug fixes.

I try to keep an up-to-date TODO list with a very informal roadmap. Here is what to expect next:

  • Performance tests and comparison with Artemis
  • Make javadocs available online
  • Complete wiki


25 thoughts on “Ashley 1.0.1 released

  1. Amazing 🙂 I hope you will do a good advertisement of it to make people using it with LibGDX, that kind of library can very improve the first experiences of beginners.
    To have a frame(work) on how to organize/construct our game is very useful, even for people who are professional programmer. That allow us to focus on what matter: the game.
    You may add a tutorial game using Ashley in the official LibGDX wiki?
    As Ashley now depends on gdx.core, should we expect Ashley to become an extension of LibGDX?

  2. Hey.. It’s an ES.. You know I gotta 😀 From a quick reading of the code it l seems like it will perform a lot like Artemis, so I’m curious to see what the tests / comparison notes reveal.

  3. They need to be brought up on fraud charges. I just checked and they
    more than doubled their goal and counldn’t absorb a $35,000 loss?
    Something stinks. Sounds like they ran into problems after they paid
    themselves and decided it was too much trouble to make the game. There’s
    an ocean of talented artists even if you have to adjust the style of
    the game. Send a lawyer after the artist for breach of contract and hire
    another one. On a first game you might not get paid up front for your
    work if you are the owner/creators so grow up and finish the game people
    paid you a fortune to make. FYI paying people upfront? What are you 5
    years old???? Total novices and a bad investment. cat mario online

  4. Well, good work. Sorry my silliness, but what the real advantage of use this? Can you explain that or show a real world example?

  5. Hopefully! It probably wont be an extension in the main repo, but that doesn’t take away ease of use. It is already a selection in the setup to use, and under the libgdx namespace on github!

  6. It would be very nice if libgdx would be enhanced by such a game engine. That is the reason why I don´t use libgdx in the moment, it is a framework not a game engine. You have to write your own game engine to use libgdx without spagetti-coding-hassle.I guess that all of you wrote such an engine when using libgdx, It would be simpler if a game engine is already included.

  7. Thanks for the hard work in creating this. I am really impressed, and I really want to use it. It seems like a very good way to structure your game objects and probably leads to code that is easier to maintain. After glancing at the source – I am really only concerned about 2 things (and these comments might be geared more towards all entity systems rather than just Ashley:)
    1) Garbage collection of the entities when they are destroyed and recreated could potentially have a bad impact on your game(s) performance. I realize that Ashley also has a pooled Entity engine where it reuses the Entities – but the pooling code appears to still release all the components within the Entit(ies) This could probably lead to garbage collection by the JVM. It would nice to have pooling mechanism that doesn’t release anything and is truly able to reuse the entire Entity with minor changes as needed.

    2) It seems like the main entity list would need to be sorted in order to have some control over the drawing depth. I guess I could just sort it after I insert objects in the list (so #2 is probably not a major issue)

    Thanks for giving us an easy option to experiment with Entity Systems!

  8. By the way, you surely already know that but there is Gemserk which has developped tools for Artemis, specifically for LibGDX. Those tools could be a great inspiration for Ashley, and/or that could even be the opportunity to work with Gemserk in improving the Ashley framework! I don’t know 🙂
    Here, an example of tool they added to Artemis:
    And here, they actually provide all their work on GitHub:
    I guess that could be great if you can collaborate with them 🙂

  9. “Entity systems are really cool and can help you write cleaner game code, avoiding the classic inheritance hierarchy hell. This article does a pretty good job at explaining the benefits of entity systems.”

    The link that the author gives explains exactly what you are asking:
    It is actually one of the best example and explaination you can find on the web.

    If you are familiar with Unity 3D, this framework used an Entity System.
    The advantage are mainly to have a frame already fixed, and which has proved to be a good one for many game design. It allows, for example, whatever object to be and become whatever you want whenever you want.
    Let say you have a component “PlayerControl” which make you able to control with a gamepad the entity which has it. You add this component to the player entity, you can control it. Let say the player is a magician and it has the power to control the creatures around him: it is easy to implement! remove the PlayerControl from the player Entity and add it to the creature Entity: now, you are controlling the creature! You can even add the PlayerContol to a box and you have created a telekynesie power.

    The other advantages is to make things data-driven very easyly, once you created all the component you need and all the system which manage them, it will be easy to have a level editor or a character/creatures editor usable by people which are less good in programming (the end user, or the people in your team). Because mainly, you have programmed the bricks: the editor will just allow to manipulate and arange bricks together. You have a good example of that with Unity 3d: you add and custom pre-programmed components to create new entities.

    So I hope I didn’t say too much bullshit and that my answer will help people to have a quick answer.

  10. Hi, I’m very confused now. In new libgdx there is only “create” and “render”. There is no “dispose” and other methods. Where can i find tutorials about new libgdx? I searched on github but seems like those are old tutorials?


  11. 1) When using PooledEngine, you should make your Component derived objects implement the Poolable interface and get them through PooledEngine.createComponent(). That way, components will also be pooled.

    2) You can add the entities to a queue in the processEntity() method of the hypothetical RenderingSystem and, at the end of the update() sort the queue and render the entities.

  12. 😉 glad you find it interesting! I’m sure Gemserk would be happy to discuss with you. Have a good day!

  13. How about integrating it with the previous way of working with LibGdx? I mean, the Game, Screen, etc classes, I don’t see a good way of merging them with Ashley, specially the Screen.render(delta) method. I used all that in some previous games (and it was awesome to work with)

  14. Hi David,
    You are correct – using the PooledEngine.createComponent appears to obtain the component on the pool. However with the Ashley 1.01 code – implementing the Poolable interface appears to have no effect. This is because Ashley appears to be using Pools/ReflectionPool to cache the Component classes . Based on the Pools/ReflectionPool code, this will have two limitations – 1) a maximum of 100 objects can be cached per component class type, and 2) only components that have a no argument constructor can be cached safely.

  15. Just a random question, is there any reason not to use the Pooled Engine and pooled components? Why not make the regular Engine and Component classes pooled behind the scenes?

Leave a Reply

Your email address will not be published.