A bit of warning - this is going to get a bit involved and very technical.

When I was in the middle stages of designing the Java Rabbit Engine (http://jrabbit.minds-eye-games.com/), I began considering how I would manage groups of active game objects. There are a number of stipulations for a rigorous game engine:

Necessary:

Hold as many objects as needed (basically, no max limit).

Dynamically resize to hold new objects.

Dynamically remove objects when they are no longer needed.

Iterate through the current objects in the list, performing operations wherever needed.

These would be nice:

Maintain order of addition.

Not allow duplicate objects.

Allow random access.

Allow for fast checking of whether or not an object is present in the list.

When an iteration is started, iterate over the same objects that were initially in the list, even if some of them are removed or new ones are added during iteration (basically, cache removals and additions until iteration is over). (Remember this as Point X, it's potentially incredibly useful and I decided I wanted to have it.)

And, obviously, all of these need to be as fast as possible, and not increase as more objects are added to the list. Basically, they need to be O(1) instead of O(n) in operation time, if possible.

So, these ideal points in mind, I started looking at existing methods. From what I found, JME and Slick both seemed to use ArrayList fairly often. It makes sense. Once the objects are on the list, it's basically array-fast to iterate through them.

However, how dynamic are they? ArrayList in particular seems a particularly bad choice, because when you need to add more objects than its max limit, it spazzes out and needs to allocate and reseed an entire new array. Also, when you want to remove objects, it has to search through the entire thing to find it, and then it needs to move objects around to fill the gap! The larger the list gets, the longer these adjustments will take. Therefore, though it doesn't have a technical limit, it has a practical one.

The concept I would use for this is: For an iteration-based data structure to allow for "unlimited objects," the maximum number of objects it can iterate through and maintain a viable operation speed should be effectively the same as the number of objects it can have while performing dynamic operations (additions and removals) and keep that viable operation speed.

So ArrayList, the common choice, seems to be non-optimal. What other choices are there?

Let's look at a few:

LinkedList:Good:

Not quite as fast as an Array or ArrayList, but still quite competitive.

Adding new objects is a breeze, being O(1) and totally independent of the number of other entries in the list.

Can append an entirely different LinkedList to its end without any increase in operation time.

Bad:

Removing objects is O(n).

Allows for duplicate entries.

Does not allow Point X.

LinkedHashMap:Good:

About LinkedList fast.

By Keying objects to themselves, adding and removing objects can approach constant time.

Does not allow for duplicate entries.

Checking if an object is contained in the list is essentially O(1).

Bad:

Cumbersome API.

Does not allow Point X.

In all seriousness, lobotomizing a LinkedHashMap seemed like the most feature-complete option. However, I felt I could do better than that, so I made my own data structure.

The result is something I call LockingList (and yes, it has been designed to accommodate Point X).

/***************************************************************************** * This class is supposed to handle large, dynamic amounts of objects and be * able to iterate through them very quickly without being disturbed by changes * to its structure. Duplicate entries are not supported. Random access is also * not supported. * * At its heart, LockingList is a LinkedList. However, the weakness in Linked * Lists is that removal operations are inefficient when compared to add methods * - it has to iterate through the entire list, checking each node. To attempt * to combat this, when objects are added to the list, a HashMap keys the object * reference to the node that contains it. Thereafter, when remove() is called, * it finds the node from the HashMap and does a quick and easy cull. * * It's a little extreme to make a custom data structure for a single purpose, * but all the common "fast" data structures I know of have some flaws in a * gaming environment (especially since I wanted to remember order of addition). * ArrayList is fast, but it takes time to resize. LinkedLists are fast and * highly dynamic when adding, but removal requires a search through the list. * LinkedHashMaps have some O(1) operations, but have needless overhead. Adding * to the mix is the fact that I needed something that could be modified during * iteration without causing errors. Ultimately, I decided to marry a HashMap * and a LinkedList. The result is a very stripped down data structure that, * nevertheless, performs very well. When no changes are occurring, it performs * at LinkedList speed (which is quite fast), and even when the list is being * rapidly changed, its operations tend towards O(1) complexity (and are fairly * fast at that). * * @author Chris Molini * * @param <T> * The type of object to hold in the list. *****************************************************************************/publicclassLockingList<T> implementsContainer<T>{/** * The currently active list of items. Because iteration runs through the * actual list of objects, we cannot safely allow this list to change while * we are going through it. Therefore, we need to cache changes and apply * them after the list is safe again. **/protectedUListmain;

/** * A list to cache addition operations. When the list is "locked," all add() * operations are applied to this. **/protectedUListaddCache;

/** * Likewise, this caches removal operations. * * NOTE: When we are unlocked, we want to simply remove objects from the * main list, but when we lock the list we need to add them to a storage * structure. So, we modify this list on instantiation to provide that * functionality. **/protectedUListremovalCache;

/** * This reference is meant to switch between main and toAdd. When locked, * the list automatically (without unnecessary checks) delegates addition * operations. **/protectedUListadding;

/** * When the list is locked, if a clear() is demanded, we cannot destroy the * list immediately - we need to remember it until we unlock the list (and * immediately clear the list on release). **/protectedbooleanclear;

/************************************************************************* * Handles adding an entire list of objects of the same generic type. * * if the other list is locked, only the main list is applied. Pending * additions and removals do not factor in. * * @param list * the list of objects to add. *************************************************************************/publicvoidadd(LockingList<T> list) {adding.add(list.main); }

/************************************************************************* * Handles removing an entire list of objects of the same type. * * If the other list is locked, only the active list is applied. Pending * additions and removals do not factor in. * * @param list * The list of objects we wish to remove. *************************************************************************/publicvoidremove(LockingList<T> list) {removing.remove(list.main); }

/************************************************************************* * Checks if an object is on the list. * * @param object * The object to check for. * * @return If the object is on the list. ***************************************************************/@Overridepublicbooleancontains(Tobject) {returnmain.contains(object) || addCache.contains(object); }

/************************************************************************* * Clears the list if unlocked. If locked, it clears the current state of * toAdd and toRemove, and remembers that it should clear the main list on * release(). *************************************************************************/publicvoidclear() {if (locked()) {clear = true;addCache.clear();removalCache.clear(); }elsemain.clear(); }

/************************************************************************* * Returns the size of the main list. If the list is locked, there is no * concession to pending adds and removals. * * @return How many elements are in the active list. ***************************************************************/@Overridepublicintsize() {returnmain.size; }

/************************************************************************* * Returns the predicted size of the list. If the list is not locked, this * returns the same value of size(), but if it is, it returns the estimated * final size after pending operations have been resolved. * * NOTE: This list can be inaccurate. It assumes that all pending add and * remove operations will be successful, which may not be the case * (depending on whether the objects involved in the operations are on the * list or not). * * @return The estimate for list size when it is unlocked. *************************************************************************/publicintpredictedSize() {returnmain.size + addCache.size - removalCache.size; }

/************************************************************************* * Returns whether or not the active list is empty. Possibly inaccurate if * the list is locked. * * @return If the active list has elements. *************************************************************************/publicbooleanisEmpty() {returnmain.size > 0; }

/************************************************************************* * If locked, redirects removal and addition to the main list, and causes * any cached operations to be applied to the main list. *************************************************************************/publicvoidunlock() {if (locked()) {adding = main;removing = main;

if (clear) {clear();clear = false; }

main.add(addCache);addCache.clear();

main.remove(removalCache);removalCache.clear(); } }

/************************************************************************* * Checks to see if the list is caching changes. * * @return Whether or not operations apply to the main list. **************************************************************************/publicbooleanlocked() {returnadding != main; }

/************************************************************************* * Allows iteration through the LockingList in the usual manner. Auto-locks * the list. * * @return The iterator through the main list. ***************************************************************/@OverridepublicIterator<T> iterator() {lock();returnmain.iterator(); }

/** * This keys object references with their positions on the list, making * removal operations much faster. Without this, we would need to * iterate through the entire list to search for each removal. **/privateHashMap<T, UListNode> removalMap;

/********************************************************************* * Returns whether or not the specified object is on the list. * * @param obj * The object to check for. * * @return If the object is on the list. *********************************************************************/protectedbooleancontains(Tobj) {returnremovalMap.containsKey(obj); }

/********************************************************************* * Attempts to remove an object from the list. * * Ordinarily, removal from a LinkedList requires searching through the * entire thing, removing an object once and if it is found. To try to * speed up the process, we use a HashMap to store the locations of * objects on the list, and use that for quickly finding which node to * remove. * * @param object * The object to remove. * * @return True if the object was found and removed, false otherwise. *********************************************************************/protectedbooleanremove(Tobject) {UListNodetoRemove = removalMap.remove(object);

/***************************************************************** * Used to efficiently append items to the end of the list. * * @param object * The object to add. * * @return The reference to the next node in the list. Simplifies * appending. *****************************************************************/privateUListNodesetNext(Tobject) {next = newUListNode(object);next.last = this;returnnext; }

/********************************************************************* * Defines an iterator through our list. * * To get the best possible speed, there are no checks to throw * ConcurrentModificationException, though editing the list while * iterating can potentially throw a bug. It will manifest in a * NullPointerException and immediately crash the program. * * This would ordinarily be a severe problem, but the entire list as a * whole is designed to not cause those problems during execution, and * so operations should remain steady if the developer uses the * available methods. * * @author Chris Molini *********************************************************************/privateclassUListIteratorimplementsIterator<T> {/** * The node used to iterate. **/privateUListNodenode;

/***************************************************************** * Returns whether or not there are more elements in the iterator. * * @return If the next element will be null. *******************************************************/@OverridepublicbooleanhasNext() {returnnode.next != null; }

/***************************************************************** * Returns the next object and advances iteration. * * @return The next object in the iteration. *******************************************************/@OverridepublicTnext() {node = node.next;returnnode.obj; }

/***************************************************************** * The iterator does not support modifying the list. *******************************************************/@Overridepublicvoidremove() {thrownewUnsupportedOperationException(); } } }}

So, what do you guys think? Is the above an improved method? Or is vanilla ArrayList better, and there are advantages/disadvantages in the different methods I'm not aware of?

When an iteration is started, iterate over the same objects that were initially in the list, even if some of them are removed or new ones are added during iteration (basically, cache removals and additions until iteration is over). (Remember this as Point X, it's potentially incredibly useful and I decided I wanted to have it.)

Sounds like you just reinvented the ConcurrentHashMap/etc. in java.util.concurrent. Also, I have never found ArrayList (or any sensibly chosen collection) to be a bottleneck in a game - have you actually profiled this? Do you have a valid use case where this kind of collection makes a noticeable difference in frame rate?[/list]

I ran a few tests, constantly adding objects (it was a stress test), and I noticed some stutters as the number of objects got very high. Granted, the stutters only happened once each jump, but I still felt that they shouldn't be there.

When an iteration is started, iterate over the same objects that were initially in the list, even if some of them are removed or new ones are added during iteration (basically, cache removals and additions until iteration is over). (Remember this as Point X, it's potentially incredibly useful and I decided I wanted to have it.)

Sounds like you just reinvented the ConcurrentHashMap/etc. in java.util.concurrent. Also, I have never found ArrayList (or any sensibly chosen collection) to be a bottleneck in a game - have you actually profiled this? Do you have a valid use case where this kind of collection makes a noticeable difference in frame rate?[/list]

I have. It's a huge problem in particle systems, especially if you want them sorted.

There is an inherent flaw in your design. You are tracking added and removed objects in different lists. If you add and remove the same object a certain number of times, you can't be sure what you end up with after you 'unlock' your datastructure. It depends on the order in which you process the lists holding the added/removed items, not the order in which you added/removed your items.

You should have a single list holding 'events': the item and whether it is currently in an added or removed state. Map<Object, Boolean> modifications or List<Pair<Object, Boolean>> for example. Once you unlock it you can iterate over the map, adding and deleting the elements to/from your 'main' collection.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

When an iteration is started, iterate over the same objects that were initially in the list, even if some of them are removed or new ones are added during iteration (basically, cache removals and additions until iteration is over). (Remember this as Point X, it's potentially incredibly useful and I decided I wanted to have it.)

Sounds like you just reinvented the ConcurrentHashMap/etc. in java.util.concurrent. Also, I have never found ArrayList (or any sensibly chosen collection) to be a bottleneck in a game - have you actually profiled this? Do you have a valid use case where this kind of collection makes a noticeable difference in frame rate?[/list]

I have. It's a huge problem in particle systems, especially if you want them sorted.

Big particle systems should be statically allocated, IMHO. They're specialised enough to require their own data structure, and I certainly wouldn't use this LockingList for them.

There is an inherent flaw in your design. You are tracking added and removed objects in different lists. If you add and remove the same object a certain number of times, you can't be sure what you end up with after you 'unlock' your datastructure. It depends on the order in which you process the lists holding the added/removed items, not the order in which you added/removed your items.

You should have a single list holding 'events': the item and whether it is currently in an added or removed state. Map<Object, Boolean> modifications or List<Pair<Object, Boolean>> for example. Once you unlock it you can iterate over the map, adding and deleting the elements to/from your 'main' collection.

When an iteration is started, iterate over the same objects that were initially in the list, even if some of them are removed or new ones are added during iteration (basically, cache removals and additions until iteration is over). (Remember this as Point X, it's potentially incredibly useful and I decided I wanted to have it.)

Sounds like you just reinvented the ConcurrentHashMap/etc. in java.util.concurrent. Also, I have never found ArrayList (or any sensibly chosen collection) to be a bottleneck in a game - have you actually profiled this? Do you have a valid use case where this kind of collection makes a noticeable difference in frame rate?[/list]

I have. It's a huge problem in particle systems, especially if you want them sorted.

Big particle systems should be statically allocated, IMHO. They're specialised enough to require their own data structure, and I certainly wouldn't use this LockingList for them.

Personally, I don't like statically allocated data structures for potentially dynamic lists. The only thing you get out of using an Array(List) vs. a LinkedList is a modicum of speed, and it locks you into a static-size mindset. I particularly feel this way about particle systems, actually.

To give you an example of why I like dynamic particles: consider Micron, the game I released alongside the engine this is included in. When a lot of the things die, they give off a burst of particles. All of those particles are part of a single system. I simply add new particles at wherever is required. Because it is a dynamic list, I don't have to worry about running out of space, and I can just dump more in whenever I need to.

I know what you mean, but IMHO I don't agree. And yes, you never can handle an infinite amount of objects, but the finite limit that you can reach is impacted by the setup that you use, so attempts to push that limit are to be encouraged, right?

But in all honesty, I would never, ever use an Array to handle game objects because of removal time. Having to search for an object so that you can remove it can become a big deal when many objects are active at once, especially if you want to remove more than one at a time. If the object list is not dynamic, then an Array is the most perfect data structure imaginable. However, I have been trying to design for situations where it is not.

But in all honesty, I would never, ever use an Array to handle game objects because of removal time. Having to search for an object so that you can remove it can become a big deal when many objects are active at once, especially if you want to remove more than one at a time. If the object list is not dynamic, then an Array is the most perfect data structure imaginable. However, I have been trying to design for situations where it is not.

Well I'm only concerned with data structures in action packed arrays so to speak; for example the inventory item data structure could be whatever - not important.And in these action packed arrays, a given object shall only be removed when a certain event happens; meaning we have straight causality.

My point is, there is no removal time, because you never search.For example some logic results in an enemy dying, the next line of code is a check if he's dead, and then, null that object.I don't have to iterate separately to remove it; I remove it when I'm already iterating, to update this object.item = null; obviously is isn't as easy with arraylist, because you cannot remove an object while iterating the collection.

Quote

but the finite limit that you can reach is impacted by the setup that you use, so attempts to push that limit are to be encouraged, right?

I don't know, at some point, practically speaking, things will get so convoluted... Depends on the game I guess, but there is always a limit...In super mario there would never be more than like 30 enemies on one screen, at one time I guess. Multiply this by the length of one map and you have your limit. Maps have similar lengths by game design...I just see limits everywhere internallyif the whole screen is full of stuff, doesnt really make such sense to add double that... maybe for benchmarking

Hmm. That's interesting, but it strikes me as a bit implementation-dependent. It wouldn't work for a randomly generated game, for example, where there are no limits.

Plus, when you add capabilities for things like projectiles, where entities can spin off other entities at will, you're either forced to limit the number of active projectiles per character (a limitation I feel is very artificial and have always disliked) or allow for some form of overflow. Maybe you simply double the maximum number of entries in the array, but it seems more rigorous to me to simply use a dynamic list.

Regardless, this is getting off topic. I didn't mean to say that I feel static-sized lists are bad; if they work for you then they work, and the end product is all that matters. My intention in starting this topic was to offer a different look at a dynamic list-type data structure. I added it to my engine and I got better and more flexible performance, IMHO. I put up this topic as a discussion of my method. I'm still going to use it, because it's been working very well for me so far, and I thought others may be interested. Also, if other people have any optimization advice, I would be glad to see how it works when implemented.

ArrayList has very fast adding, but very slow removing, is ordered, and iterating over it is quick (plus you can use indexes to remove objects semi-quickly if you know the index). the contains method is slow.

HashSet (it actually is just using a HashMap in the background, you can write a faster implementation of this by yourself or I can give you one) has decent adding, very fast removing (tops out arraylist if you are adding as often as removing) is unordered, and does not iterate as quickly. the contains method is fast.

No. Not unless you have a high % of collisions (which would ruin a hash anyway). Iterating over an array is a lot faster than a linked set of references, so even if it's a larger array with possible nulls, in general it'd be faster. Unless of course the array is very large with very few elements - which is a different problem. You can make it reduce size the array after a certain number of elements have been removed.

I don't have to iterate separately to remove it; I remove it when I'm already iterating, to update this object.item = null; obviously is isn't as easy with arraylist, because you cannot remove an object while iterating the collection.

You can remove object when iterating from Array List. I did lot of benchmarks and conclusion was that for-each loop is not good for Array List. Instead I ask size and then make normal for loop. If you need to remove something you need to update size and index. Just size-- and index--. Its not maybe that clean but it work and can save hefty amount time.

I don't have to iterate separately to remove it; I remove it when I'm already iterating, to update this object.item = null; obviously is isn't as easy with arraylist, because you cannot remove an object while iterating the collection.

You can remove object when iterating from Array List. I did lot of benchmarks and conclusion was that for-each loop is not good for Array List. Instead I ask size and then make normal for loop. If you need to remove something you need to update size and index. Just size-- and index--. Its not maybe that clean but it work and can save hefty amount time.

Well I prefer bare arrays anyway. But using this, I would always fear that something would get screwed up, like removing the wrong, or whatever; and such a behavior is then hard to spot - like what really happened - which was removed which shouldn't be removed

I don't have to iterate separately to remove it; I remove it when I'm already iterating, to update this object.item = null; obviously is isn't as easy with arraylist, because you cannot remove an object while iterating the collection.

You can remove object when iterating from Array List. I did lot of benchmarks and conclusion was that for-each loop is not good for Array List. Instead I ask size and then make normal for loop. If you need to remove something you need to update size and index. Just size-- and index--. Its not maybe that clean but it work and can save hefty amount time.

Well I prefer bare arrays anyway. But using this, I would always fear that something would get screwed up, like removing the wrong, or whatever; and such a behavior is then hard to spot - like what really happened - which was removed which shouldn't be removed

I just like the control and accessibility of an array so much.

Index removing with arrayList is as simple as with array. I prefer Libgdx Array with any objects and with things like coordinates I just set up many normal single dimensional float[] with circleBuffering.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org