Slick Forums

Cool!

This is exactly what i've been looking for. Thanks for making the effort to port the T-Machine articles into a usable java entity system. (I was worried i'd have to do this on my own).

Definately going to take this for a whirl. Keep us updated on any changes you make to the library.

Many thanks

A small note:
I'm now using a tag to identify "player", instead of a component. So the example of the PlayerShipControlSystem is outdated.

Here's an example of what I'm now doing:



Make sure you tag the player entity when you create it:

Ok, that makes sense. So all the 'empty' place holder components can be removed and one can get a reference to the entity via the 'Tag'.

i.e. the Player and Enemy components that are just used to identify a entity to the system.

Nice.

Just tearing the example game apart in a test project now. This is some really nice stuff hey.

But a BIG paradigm shift: To think in terms of data and aspects.
I definitely think its the way to go though. I may post one or two questions later when i get more time, but for now, good job guys. I'm enjoying using the system right now.

I've got some ideas of my own on how to improve the API, but i'll play around further before i post again

Any chance you have some more example code lying about preferably using some proper animated sprites and sound? I'd love to see the code for the entity systems behind that. Oh... and what about a example code showing game state (StateBasedGame) and how the systems would work with that.

This can all be encapsulated within a Slick GameState. Don't really need to do a lot, since setting things up and updating and rendering is done in the three methods, init, update, render, which all exists in a GameState.

Regarding the sounds, I'm doing that in another game I'm doing using Artemis. I simply have a "SoundSystem", which processes all SoundFile components, that contain the filename of the sound. The SoundSystem then creates a new Sound() for it and plays it.

Here's the code for it:


Sound file component:


Create the sound entity:



This arrangement not only separates logic from data, it also removes any dependency on a certain sound library. If you decide later not to use Slick, you can easily refactor your SoundSystem... and only that. That's the only place where the dependency on Slick's sound libraries lies.

I've updated the library, some minor glitches fixed.

http://gamadu.com/games/starwarrior/

(all Artemis assets are up to date)

I must have started work on my own version of the Adam Entity System around about when you did, Apple. I've spent more time on XML parsing, and less on optimization however. Would you mind if I looked at some of your solutions and borrowed from it? Right now I can render about 2500 entities with 6-10 components in a 2 threaded solution.

I'd like to share what I've got, but right now the code is kind of messy and mostly undocumented, but I hope to have a Asdroid clone ready in not too long.

Edit: Just browsing the code, and I see you have used an indexing solution to the getEntitiesPosessing problem, probably for the same reasons I did. Speed =)

Question: How much faster is Bag over Hashmap?

Edit: Image of progress

I've set it up on SVN:
http://gamadu.com/svn/artemis/


@Uberrated

Screenie looks nice.

Bag is much faster than Hashmap. Iterating sequentially over a bag is as fast as iterating over an array[]. Hashmap is not good at that, and if you're using Hashmap then you're bound to make a system that is poor in performance. I use Bag for all my game code where I need speed. Java's collection is not good. LinkedList is dead slow, and ArrayList is really bad when it comes to removing. Bag is the perfect, but the downside is that it doesn't guarantee ordering, but you can get around that problem by not needing ordering.

I've not looked at how I could do multithreading, having systems processing in parallel in a lock-step gameloop. In theory, it could be done, but I need to think how to ensure thread-safeness of data in the components. But since the components are so concise and limited, it might be very easy.

I tested Artemis creating about 6000 rendering entities per second, and deleting them, on my machine (Q6600/8800GT). Creating/deleting entities that have nothing to render this performance can go up to millions per second.

Thanks for the svn access.

I think I have to seriously consider moving all my stuff over to your system, I just have to look at the workload. Right now I have BIG stack of components & systems, but perhaps I'll get the biggest performance boost by switching to Bag.

Profiling has shown that Entity.getAs, which is a double hashmap lookup under the hood, is eating some performance, the rest is eaten by GL calls, which have to do what they gotta do. Switching to bag should improve this.

As for threading: I currently have a simple yet workable way where I have all my systems in one thread, and my rendering system in another, like so:



If you run on a computer with > 1 cpu this gives signifigant performance gain, even though there are suboptimal critical sections.

I've found that multithreading the game engine isn't worth it until you've reached AAA-level games. For games that are within the reach of most indies a singlethreaded game loop is more than enough.

I spent a lot of time studying parallel game engines, and found that they bring a lot of baggage.

I've started porting over to your system, but I was wondering why you have set so many class members to private instead of protected? Makes it hard to expand upon. Reusing entites does not work for my setup right now, so I have to work directly with the source. Now, I realize that this might be a warning sign about how my code is glued together, but one step at the time

Anyway, I think you got a nice framework here, one day of fiddling and my about 35 systems and 60ish components are ported over. Some bugs to weed out still, but coming along.

As for what I'm working on: A highly flexible xml system, where every parameter can be randomized and inherited in an entity chain. Entities can spawn other entites alongside them, when the entity crashes, expires or when the length of a chain has reached a certain point. Entity creation over time is also supported. Eve rything is backed up by a .dtd file which allows for autocomplete when writing the xml. Hopefully it can be showcased alongside Artmesis, as an example of the power of Entity Component Systems.

I have to close with a question again: Have you found an elegant way to debug the entity system? I find it to be the only flaw int this otherwise magnificent idea.


Edit: I might be mistaken, or be on the wrong version, but world.deleteEntity does not remove components.

Let me know how it goes. I can't foresee all design issues and will try to make changes when it's warranted.
I'm trying to separate the public API from the internals of the framework. If I don't hide the internals, then some guys might affect something they don't know what side effects it will have. E.g., creating a new Entity instance is not permitted, the constructor is protected, and the class is final, disallowing extending. I want the framework API to guide the programmer in it's usage, not offer lots of things to do he should not be allowed to do.


Sounds nice. I've worked on a data driven game like that, using XML for entity definition. I was using Spring Was quite powerful, but too slow for my taste. I had to have a thread instancing entities in the background because it wasn't fast enough to do realtime. You'll be surprised how many entities you need to create in a space battle of 20-30 ships. Bullets, explosions, lasers, etc. Artemis will handle that stuff nicely.



Good question. There's no easy way to just look at one entity and it's components. It's easy to debug a system, but when it comes to the state of the entity you need to dig into the EntityManager, and look at the componentsByType bag. If you know the id of the entity you can look up the right index in each of the bags to see the component for it. It's very tedious, I know. I could offer some way of retrieving all the components for a entity, e.g.:
ImmutableBag<Component> components = world.getComponents(entity);
Would that help?


Thanks for catching that, clearly a serious bug. Easy to fix however, will make the changes in svn and deploy.

Groupmanager should have an isInGroup(String, Entity) function.
Reuse of entities is great, but I need everincreasing ids to identify them uniquely in time, any reason id cant be long, and just go ++?

Edit: Poking around abit I see that not reusing ids has the unfortunate effect of increasing the bagsizes quite unnecessarily. Perhaps some sort of entity sequence number in addition to id, coupled with an Entity.equals which uses said sequence number?


I preload everything into a DataElement class, which basically is a giant EntityFactory: I can handle 4-6k entities with about 10 components each on my 3 year old powerbook. The bottleneck right now is collision detection, which is an art and a hassle in its own right.


That would help. I guess my design is especially hard to deal with however, as I have entities linked to entities, quickly making EntityManager browsing a pain.


Fixing it locally opened up somewhat of a can of nullpointer exceptions. Hopefully you have a better overview and implementation.
Btw, IntervalEntitiyProcessingManager does not actually call begin and end in intervalProcess.

On that note, porting is basically complete. I'm now running Artemis Really digging grouping and tagging, finally getting rid of empty component. JProfiler shows good hotspot improvments!


Edit: I'm in love with the speeeeeed (entity counter is wrong off but still, all those ships are fireing 10 beams a second):
[/img]

I have ideas to solve the id thing.

Don't have time right now to update this, but I'll see if I can tonight.

Great! If its not too much trouble, some way to reset the system/remove all entities should be supported. There are several scenarios where this is necessary, like new level, player death, state change ect..