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 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.

@princecPardon 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.

@princecPardon 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?

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.

Because a call to getEntities() has to consistently return the "current" list (eg. entities0); also, I want any entities spawned to receive a call to process() in that tick. I don't really know if there's a cleverer way of doing all this but it does work very simply and intuitively.

Because a call to getEntities() has to consistently return the "current" list (eg. entities0); also, I want any entities spawned to receive a call to process() in that tick. I don't really know if there's a cleverer way of doing all this but it does work very simply and intuitively.

Cas

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?

I just tended to find that anything that monkeys with the order of things being spawned tends to produce strange unreproducible effects. So with the hard and fast rule "everything is processed in the order it was originally created", everything always works, the same way.

I have a feeling you're just trying to avoid calling .size() on the list in that loop for the sake of it

I just tended to find that anything that monkeys with the order of things being spawned tends to produce strange unreproducible effects. So with the hard and fast rule "everything is processed in the order it was originally created", everything always works, the same way.

I have a feeling you're just trying to avoid calling .size() on the list in that loop for the sake of it

Not at all. I don't think you'd mentioned the necessity to keep in spawned order, just to call process() on the spawned object and keep things in a consistent order. Therefore, adding to the current list seemed a wasted operation. I also like to keep away from changing list contents while iterating over them, even if the way you're doing it here is safe.

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 see. I'm thinking how I can implement this in my code. Since I have separate ArrayLists for each type of game object, I would have to prepare same number of ArrayLists I have so that I can buffer all of them. My concern is the cost of having 2 ArrayLists per type of object(enemy, enemy bullets, player bullets, and item). It's not that my program is going through a serious need of tuning, yet, but I'm trying to think of the best way. I just don't want to loop too many unnecessary times when detecting collision. There will always be a lot of player's/enemy's bullets flying around.

I do think it's a good idea to loop game objects by order of spawn especially if I decide to interact between same types of entities or if I was keeping all my entities in one list.

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.

I see. I'm thinking how I can implement this in my code. Since I have separate ArrayLists for each type of game object, I would have to prepare same number of ArrayLists I have so that I can buffer all of them. My concern is the cost of having 2 ArrayLists per type of object(enemy, enemy bullets, player bullets, and item). It's not that my program is going through a serious need of tuning, yet, but I'm trying to think of the best way. I just don't want to loop too many unnecessary times when detecting collision. There will always be a lot of player's/enemy's bullets flying around.

I do think it's a good idea to loop game objects by order of spawn especially if I decide to interact between same types of entities or if I was keeping all my entities in one list.

Shouldn't an Object[] just be 64-bit references, so it's just 8 bytes times the size of the array? I mean, my laptop has 4GB RAM, that's enough room for 536 870 912 array elements... Even in just one megabyte you can store 131 072 elements, so you should NOT worry about memory usage. I agree with Cas, a double-buffered ArrayList is most likely the best solution.

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...

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:

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