Entities and entity managers

Game Mechanics
#1

I’m trying to figure out a good way to manage entities in largely data-driven games where a large amount of objects need to be managed and i’d like peoples thoughts.

Is it worth building your own container classes for them?.. or just using built in collections classes that Java has.

Where is efficiency lost?.. in either homemade containers or Java collections.
-> And how you increase efficiency?

and finally:
Your ideas or any other thoughts on efficient entity management?..

#2

Are you multithreading? If not, then a simple ArrayList is extremely fast enough. If you don’t care about order, a Set is also excellent.

#3

Choosing the right collection class can make a difference. But I would first look at ready-to-use solutions. For my game development I use implementations from Trove, Javolution, Colt and built in Java classes.
They have different performance signatures when it comes to dealing with items. Same is true when it comes extending/scaling. Some can store primitves, some offer synchronization.

Individual use cases are critical, like:

  • iterating all items
  • index based direct access
  • key based access
  • insertion, appending or removing
  • removing of items
  • keeping ordered items
  • concurrent access, algorithmic or by synchronization

Some hints:

  • for frequent iteration of hash maps, using HashMap results in creation of tons of avoidable iterator objects
  • FastMap supports ordered maps
  • Colt’s maps can store primitives
  • LinkedList is not that good for index access
  • ArrayList isn’t the best for finding concrete items
  • choose the right initial capacity and growth behaviour
#4

If you need thousands of entities simple collections will start to have performance problems because the entities will get moved around the heap with the gc and cache misses will occur.

This might not be that important to you but it can make for surprising speedups. If that is something you want I would look at mapped objects or the entity framework in my signature. I designed it for data oriented apps.

#5

NB: if you’re doing something SUPER intensive, but SUPER low-complexity (e.g. particle effects), then don’t bother with containers, go straight to arrays/buffers. For everything else…

Only once your game is running so slowly that it’s becoming frustrating to debug and test it.

You can tolerate a lot of low performance before you get to that point. Live with it. Focus on the rest of the game. Do the optimization only when it becomes necessary.

Not “last”, but “only as soon as when you need it, and no earlier”. e.g. when I notice the minimum compile/test/debug cycle being slowed down by more than 30 seconds just because of low performance … I optimize.

Worst: selecting the right subset of items from the container
Second worst: iterating over the container

For the former, you can create custom containers - or … just use smaller containers, and pre-split your data into chunks that you frequently access as subsets.

For both items, arrays (or, better, Buffers) of flyweight impersonated objects are much faster. But don’t bother until/unless you actually need it.

#6

Thanks, for the replies and advice. I’ve got more of an idea now.