Slick Forums

Artemis in its current state is (excluding bugs) what it is, an experiment that was successful IMO, it's been ported to probably a dozen languages already and used in dozens of projects, perhaps even a hundred! It does nothing more or less than it needs to do other than to experiment with entity systems paradigm.

Question is... should it do more? What other things should it be capable of doing? I'm not talking about adding 3d scenegraph renderers or physics systems, but more things to assist in game engine development and the entity system paradigm without going out of scope.

Refactoring/Redesign? Maybe I went a little overboard in trying to squeeze out performance, at the cost of simplicity in the internals. E.g. using int for bits instead of something like BitSet (which limits systems to 64), and using home-brewed "Bags" in a strange manner (where most of the bugs come from). But anyway, I think there's room for improvements to make it more slick in design and also to make it less bug-prone (because trying to maintain everything by yourself and not making use of something like BitSet, that is battle-proven, can introduce bugs). Problem will be to maintain good performance (or even improve performance).

Annotations and such? I haven't made much use of annotations in java, but I'm pretty sure it can be used for something to make things simpler. But annotations aren't everywhere. One of the success of artemis is that it's relatively easy to port to other languages... which may not have anything like annotations.


So, discuss, suggest and debate ideas

In our case, we have our own version of Artemis with some bugs fixed and with some new features like disable/enable entities to be easily reused (with all their components and all). We also added some unit testing to avoid breaking stuff when we try to fix a bug or try to add a new feature and we also have plans to improve a bit the getComponent() performance, since we use it a lot and we think is really useful in some situations.

Some stuff like the Tags and Groups could be an add-on, not part of the core, maybe you could have the TagComponent and a TagSystem or something with a separated concept to access each one (the tags or the groups), like all other systems and stuff. Not sure if I was clear.

We added also a layer over Artemis to allow Scripting, like adding scripts to entities to perform some specific logic instead adding a new system. I believe that was a really good feature but it is over Artemis, so I am just sharing, not saying it should be added to the core.

We are using Artemis, but not in its original state. The idea was to try to discuss all this stuff we added and/or fixed with you but you weren't on the forums a lot in the last 6-12 months, so we end up doing the modifications we thought were needed.

_________________

We added also the concept of EntityTemplate to define Entities, for example, you can create a template for Orcs, the template defines the entity should have a SpatialComponent(), an AnimationComponent(orcWalkAnimation, orcAttackAnimation, ...), etc, later on the code you could do stuff like orcTemplate.apply(entity) to create an Orc. I believe that is interesting too, not needed to be added on the core either but again, I just want to share stuff we did because it could be useful as ideas.

Also, we are using a concept of Store to reuse entities already configured, for example, if an Orc dies during the game, instead of calling entity.delete() and have to re create the entity again later when we need another Orc, we move the death entity to the store and if we need a new Orc we reuse that one, we only reset some state but we avoid to create new components and new assets, etc. Stores work over Templates but Templates can be used without Stores.

I believe one interesting thing to have is a good editor to at least to prototype stuff, I really want to do something like that since some time ago but I am not sure how to do some stuff exactly and that kept me away from doing anything.

_________________

Good ideas. I think those kind of features are necessary as well, templating and reusing/or prespawning.

Yep, I forgot to said, the Stores are pre populated to avoid the creation time during the game.

_________________

I'm not sure if it should do more, but if, it should possibly be optional so one don't have to use it, to keep it simple and modular.
Probably the best solution is that you make a whole game (with Multiplayer and Saving <- I'd love to see examples for these both) to see what Artemis could do more or better.

I am using Artemis for making a Snake-clone (which is quite simple though) and so far, I'm loving it.

IMHO.
I think best use of your time appel is make a complete set of examples or tutorials too.

I love to see some uses of Artemis with annotation, it's seems to be a good idea!

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

The problem I'm facing now in my C++ port is that I can't enable polymorphic component types for just one system.
For example you could have 2 different render components. But you still want them to fall under one system by doing something like:
(my C++ call in constructor)
setComponentTypes<IRenderComponent, TransformationComponent>();

Currently
IRenderComponent is the interface/base component for all render components.
Since every object creates its own hashcode ( this is how I store my bitsets and retrieve them) The aboves type bits will only work for actual IRenderComponent. Which is Abstract and can not have actual context. Therefor this won't work.

Every derived Component from IRenderComponent will have its own bitset/bit id. Meaning for every render component you would have to create their own system ( or derive from a basic render system)

I don't believe that's possible with the Java version either. Any thoughts on this? Any global ideas on how to solve this? I do think it can come in handy.



Nice Idea. I should add a EntityTemplate class for my port.



But this means the Orc is still in your system bag ?
somewhere in your process you do something like:



EntityManager is still in charge of removing actual entities from the systems right?

I apologies for m post. It feels a bit sidetracked.

@Sidar

We modified Artemis to accept the new Entity state of being disabled, and what we did was added new flags and new methods to the EntitySystem API in order to tell a system an entity was enabled/disabled. After an entity was disabled, it is not being processed any more since it is automatically moved to other place.

From the user side you don't have to do anything extra, just call e.disable() and e.enable() and if you want to do custom logic when an Entity was disabled you can implement the disable(e) method from your EntitySystem.

If you are interested, we have a branch in our mirror of artemis in Github -> https://github.com/gemserk/artemis/tree/gemserk

About your render question, maybe you can extract a class with information of which kind of render is and the data for that render and let the RenderSystem to keep using the RenderableComponent. So for example, intead of having the SpriteRenderableComponent and the AnimationRenderableComponent and having to manage both in the System, you have the RenderableComponent and inside of it you add information of both sprite and/or animation, and in the RenderableSystem you check if it has a sprite then render the sprite, if it has an animation then render the animation. It is just an idea, we resolved this in other way.

_________________

@arielsan


Well I was thinking of something like



Or do you think this should be avoided?

Thanks for the link btw.
If I'm sidetracking this thread please do say so. OP wanted to know what to do with Artemis =P

Yes. I agree, at a glance, about annotations.

I think a lot can be simplified by using annotations. I'm really a code clean-ness fanatic, I like to design code like I design user interfaces, to be easy to use, intuitive, etc.

Problem is I don't have a lot of experience with annotations. I'll need to spend some time studying how and if I can use it, or recruit some help.

I was wondering... I'm not really into XML, but I used it a bit for android GUIs and found it very useful, so do you think it could be possible to use it for designing entities in Artemis? I mean, something like this:

This way the entities design would basically be managed as resources, instead of java code. The programmer could have an XML file for each entity in the game, with its list of components, and thorugh a built-in method he would be able to create the entity by reading the XML file. I don't really know if it can be implemented in some way (mainly beacuse I don't know if fields such as x and y can be dinamically set when reading the XML file, and also I don't know if it is possible to use user-defined classes as the components and entities in the XML file (maybe through a class that manages the entities/components list... But I'm not sure)), and my example is just an idea of what I was thinking, but maybe you come across with something good (surely better than my little example xD)

I'm sorry, I know a lot of java programmers with a fobia about xml files.

Data driven games with xml should be a possibility, but it's up to the programmer to implement it, the framework should not require it.

Ahaha, well ok then, I don't want programmers to have xml-nightmares

appel, I've point guy from Rogue Survivor to Artemis, you can find some thoughts here

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute