Generally speaking, from one frame to the next, you want everything to be processed in exactly the same order as last time. WRT the OP's original design question about in-game objects.

Cas

Sun...ehrm...Oracle did an amazing job of forcing us to write our own collections for performance.

Everyone, thank you so much for the comments.

@theagentd

True, what I plan to do on my game so far is not really heavy, yet. I do want to put some effects. I'm thinking about using images instead of drawing from Graphics object(I use Java2D by the way)... thought this might not be the correct way to handle effects. I have to research over effects soon. I haven't touched anything about particle system, but I would like to take a look if you don't mind.

Regarding order,

I will have a class that holds all game objects separated according to their type. Player reference to a Player object, enemy objects in a Bag, PlayerBullet objects in another Bag, and so on...

Basically, I won't specify the index or the order when I add game objects, but they would be in order I add them. The order would start messing up when I remove elements from bag because they would switch out with the last element. Also, I loop backwards, so that I can remove an element and not miss it while iterating. (I remove within game object's update() method)I don't think the order within each type will matter since I'm not doing collision detection or any interactions between same types.

The order they are drawn is determined in Sprite class with planes. These planes stored in Hashtable with Integer index corresponding to Image objects are always in the same order every frame after spitting it out to array and sorting. I do iterate this Hashtable every frame to populate the array with keys(Integer).

I will have a code like this...



I didn't have a LinkedList as a choice since I thought its functionality doesn't suit my need. Reasons being, also mentioned in other posts, random indexing and memory storing references to next objects while I don't depend on a LinkedList.

@princec
Pardon me for my lack of understanding. Is it like for example..
1. You have a main ArrayList listA(front buffer).
2. When you iterate it every frame, create a temporary ArrayList listB.
3. Whenever it requires you to add or remove game object, you would add into listB.
4. Then copyOf listB into listA?
If this is trying to avoid extras of shifting elements, you would have to specify the size of the listB initially, right? How would this work?



It's true that I could make this work without having to worry much like this. However, I want to learn to use the right data structure more efficiently. I do need to read more.

Two things to note that look unusual at first:
1. Two checks to isActive() are required.
2. The size of entities0 can increase during processing (spawn a bullet, etc); that is why we do not use an iterator and dynamically check the size every loop iteration.

Cas

Cas: Pure curiosity.   Why the choice to spawn in the current active list rather than the next?

Couldn't you call process() as you spawn them, before adding them to the other list.  Depends where you need them ordered, I suppose - my way they'll be next to the entity that spawned them I presume?

Surely this

can be 'optimized' to

</nitpick>

Depending on the implementation of .isActive() this can make your logic up to 3000x faster.

It was a joke

I think this is what confused some people, after you provided the actual code.

Riven's small tweak is quite right, small slip of the curly brackets.

Cas

princec, thank you for explaining.

Very interesting. So basically, the advantage is that you don't call remove(). Also, it will keep it in the order game objects spawn.

Are you declaring entities1 at the same time with entities0, so you can add entities from other places/methods? Why not declare entities1 within every frame when you loop keeping it local? Is it to keep the capacity of array within ArrayList same as the list before?, so unless you add new objects somewhere else, the capacity of list would not have to increase? And to avoid instantiating every frame?

A small optimization to ArrayList.clear() that I thought of: Maybe not really clearing it like ByteBuffer? Yeah, you might want to clear out old references so the GC can get rid of them, but you can do this every x-th frame (maybe with a semi-random bias so the "true" clears don't sync up). That would get rid of looping through all the data each frame just to get rid of it.

I keep all my entities in one big list, generally. Collision I do with a grid cell approach (Revenge, Droid Assault) or simple brute force (Titan Attacks, Ultratron). I do mirror certain parts of the list into sublists of types, eg. buildings, gidrahs; but only the "main" list need be "double-buffered" in this way.

Cas

Just to chip in, I use a tactic very similar to princec:

1) Typed uniform grids for fast collision detection.
2) A long (ordered) list with all entities in the game.

This list has delayed addition and removal of entities (stored in a single queue).
Entities will have their spawn method called when they have become part of the entity list.
Entities will have their cleanup method called when they are no longer part of the entity list.
Thus entities are spawned and removed in order.

Another benefit is that the list of entities is stable throughout physics computation.
It works well under the assumption that the game objects stay in the game for a long time (several iterations).
But of course all methods have drawbacks :-)

I used to use the same approach for all games, but I'm shifting towards more modular and individual designs.
As such my game engine is starting to more and more become a game library instead...

- Scarzzurs

Doesn't all the adding and removing game objects generate massive amounts of garbage? I'm trying to understand the discussion here, but have a hard time understanding why - performance wise - any of these constructions should be better than a simple array, e.g. I'm usually doing something like this: