Slick Forums

(This is a brand new project and is not based on the previous Artemis project.)

Me and Spiegel (Tiago Costa) have been working for a few weeks on this framework. It's meant to separate data, logic and view. It's currently just experimental and is meant for review purposes only, use at your own risk.

It's inspired by Adam Martin's "Entity Systems are the future of MMORPG" articles published on http://t-machine.org/.

This framework requires different thinking when it comes to game programming. No longer are entities just self-contained objects, but consist of data/state components which are processed by systems/aspects.

Entity is an irrelevant object, it however still exists for design simplicity and convenience.

Components are attached to entities and they contain data or state for that entity. Imagine a components like Transform and Velocity.

Systems "process" certain "aspects" of entities. You can imagine one aspect being "Movement", and you would create a MovementSystem which processes all entities containing the Transform and Velocity components.

Currently there are 4 types of systems you can extend from:
- EntitySystem: the very basic raw system, which simply allows you to handle the processing loop however you want.
- EntityProcessingSystem: used to process individual entities of a certain aspect sequentially. If you always need to process all entities use this.
- IntervalEntitySystem: a very basic and raw system but is only executed at certain intervals, e.g. it runs processing every 100 ms. This way you can tune your game better for performance.
- IntervalEntityProcessingSystem: like EntityProcessingSystem but runs in intervals.
- DelayedEntitySystem and DelayedEntityProcessingSystem: executes only after a specified period.


This is a very fast system and offers a lot of flexibility, whilst keeping your code clean.

Artemis here: http://gamadu.com/artemis/

We're looking for feedback, so please provide if you can.

Any questions? Please ask here.

very cool approache . My last Entity-System was based on:
"Entities has a list of components"... .....

Nice idea with the different systems/managers to control the different components of an entity.
I understand that the entity is nothing more but the "brackets" around components that belong together and make up the game object.

Can components "talk" to each other and inform other components about value changes (like MVC or dependency mechanisms or listeners)?

One flaw in the current design of Entity.getComponent(Class) is that you can only have one component of a kind in an entity. Might be useful sometimes to have a list of components of the same class inside an entity...

Please keep us posted how helpful this new component based framework is regarding your game development. Does it make coding life easier or not? Where are pitfalls or areas that cause trouble?

Oh and by the way: I think it's great that you, appel and Spiegel, as the two main "component based framework guys" in this forum team up!

Cheers,
Tommy

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

1. Do not use Entity.getComponent(), use the ComponentMapper as it's much faster.

2. Components do not contain ANY logic, only data/state. The logic to process that data/state resides in the systems. Although, you may have getters and setters, and some custom setting/getting methods.

3. Therefore, components do not talk to each other. There's nothing like that. You can have system communicating, but that should be an exception.

4. Entities do not contain components, they reside elsewhere behind the scenes.

5. Having multiple components of same type in a entity is usually an indication of a design flaw.


We plan on ironing out the API so it's cleaner and simpler.

I just had a look at the game's source code which does use Entity.getComponent()
Snippet from PlayerShipControlSystem.java, method process(Entity e):


Naah, you kind of cheat a bit here. You have ComponentMappers to retrieve certain components of an entity. For example you access the health component of the player ship to change the value if you are hit by a bullet. I would call that communication between components No matter what, somehow you need to pass information between components - otherwise you would have a static system!

Huh?
Code snippet of StarWarriors EntityFactory.java:

Are you sure that entities don't have components?

How would you design a ship with two cannons? Create a component for double shot? Or simply use two single shot components?

Please don't get me wrong, appel - I don't want to criticise you or the framework - it was just the way I understood the framework and how I interpreted your source code. Maybe I just misunderstood something, so I already apologize ahead if this sounds too harsh.

Peace,
Tommy

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

1. Use ComponentMapper when you need to retrieve components from entities often. This is a fast way to retrieve it. ComponentMapper uses a direct array referencing.

2. You MAY use Entity.getComponent() when you're setting certain values of new entities. Creating new entities is something you do relatively rarely. Entity.getComponent() uses a Map lookup. This is not a performance issue when done intermittently.

3. There is no component communication. Component A does not talk to component B. System X manipulates components A and B.

4. Entity.addComponent() does nothing within the entity instance, it simply hides the call to the entityManager.addComponent(this, component). This is, as I said, for convenience.

5. A ship with two cannons is a valid question and this has to do with entity nesting. We provide no way of doing this currently, but there are ways to implement it. There is always a problem with nesting, by what are you nesting? If you add child entity to a parent entity, does that mean it should be visually attached to it? That implies you have transform information in it. This is a wrong approach IMO.

How nesting is implemented is up to you. I wonder if it should be part of the framework.

My idea is that, if we imagine a spaceship with two independent tower cannons, then you really have 3 entities, the spaceship, cannon 1 and cannon 2. You can make a component(s) and system(s) that manages the nesting of these entities.

Now that explanation is much better - thanks! I think I really got it now

Regarding entity nesting: you're right - there might be a lot of components involved, even for a simple two cannon space ship or some tank with several driving chains like your previous framework example.

But I think it's a common request and it would be cool if your framework would contain one example of how you could implement it.

Indeed I simply stumbled upon it while looking at this getComponent(Class) stuff which seemed limited to me and I was simply looking for some example where two components of a kind would make sense...

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

I must also apologize for not explaining the Spatial concept.

Although it's not part of the framework, it's an important thing to mention as it deals with nesting.

You can make any sort of Spatial you like in the RenderingSystem, see StarWarrior example. The spatial contains all necessary rendering-logic and rendering-state. You have to make a distinction between entity data/state and system-specific state on that entity. A entity data/state is used in multiple systems, while a system-specific state is only used within that system.

Spatial allows you to encapsulate a system-specific state per entity. Imagine a TankSpatial. The tank has tracks that animate according to the movement of the tank. This is irrelevant information for all other systems, and is used only in rendering. You can maintain and update the state of track animation in the TankSpatial.

Just because entities can be thought of as nested, like tank base and tank tower, that's just the visual representation. It's still just one tank, and our mind (because we're used to) tries to forcefully split it up into separate independent entities.

The usage of Spatial in the RenderingSystem is an example of how you can do things in other systems, although it's only necessary for rendering purposes in that demo. You don't want to inline every possible rendering in the RenderingSystem, so you defer it to the Spatials.

I switch . I use your source as base for my next game! The "util" package is also really nice (Cubic-Inter, FastMath and so on..)...
Thank you!

I did find some bugs that I've squashed, I'll deploy a new jar tonight.

Btw. use only the TrigLUT for cos and sin, I don't use FastMath for that, as it's not as precise and it's buggy.

Please let me know how it goes using this library, I've yet to make a fully functional game using it

Ok, it's updated. If you're using it, you can update as well:

http://gamadu.com/games/starwarrior/artemis/artemis.jar
http://gamadu.com/games/starwarrior/art ... is-src.jar

(there was a problem with entities that didn't belong to any groups, but as I said, this is still just in the experimental phase, so I'll only support in this thread)

Hi

It's interesting, but how much different is from anothers component based system here on forum ? I'm not understanding difference

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

Difficult to explain, it's a totally different way of separating logic, data and view.



In the component based systems we've been seeing on these forums the components are directly attached to the entities, residing in some of a HashMap internally in the Entity class. The components have data and logic in it, and view is either in the components or in the Entity class itself.

Updating and rendering in this design requires calling each entity, update and render, or on each component.

While this design is way better than some class inheritance tree, it's still inflexible.



The backing datastructure in the Artemis framework is much more efficient. I tested that it can create a primitive entity and add to relevant systems in around 500-1000 ns. on my PC, since the datastructure for it is so machine friendly. There is 1 billion nanoseconds in a second, so that means over 1 million entities per second.

Artemis framework operates on "aspects" of the entities. A tank may have a health aspect, and multiple components may be involved. The systems implement the aspects.
This allows for much finer control of how you execute logic for your entities/components. You may only want to run certain logic every 100 ms., like fog of war creation, or health regeneration algorithm. This allows you to improve performance for you game, both framerate and memory wise.
Adding multiplayer support is just a matter of creating the right system/aspect. You can also create a dedicated server without all the graphics rendering, and ship a minimal jar, without the Rendering system/aspect.

All this isn't possible in the Entity/Component paradigm.

multiplayer system/aspect? So for example a "system" to share (using for example kryonet ) position of every entities?

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

Yes.