Hi,

I'm currently starting to get items into my game which need to be accessed frequently. All items are derived from one ore more base classes and i'm currently putting them in one big list. Eventually the game will have thousand of items and i'm wondering if this will slow things down.

Let's say i have a armor class -> derived from items. Does this help when traversing that huge list like this?

foreach (armor item in itemList)
{
//Do stuff.
}

Or will it still traverse over every item in the list? Am i a lot better off (performance wise) storing it all in different lists? I rather use the above method as it will be easier to access random items.

Depends on what exactly?

If a building is needing items it will look with a Manhattan heuristic for the closest item in the list. Same goes for a enemy that want to steal something or a friendly NPC that wants to find a sword. Eventually there will be a lot of requests. So am i better off putting each type in a different list? Then in the case i want a random item to dissapear pick one of those lists randomly and choose from that one?

Since i ask myself "would it be better if" a lot. Maybe a better question would be if there is a way to know the impact of certain algorithms and functions before hand? I know, experience would tell me, trial and error is the best learner but if i can avoid certain bumps in the road i would be better off .

Rather than having a flat list of every object in the game you could split the list up by location so that an npc wanting to steal objects would only search through the list of objects that are local to them, similarly a building will only search through the objects contained within it (for example).

During your testing phase you can play around with the size of your 'location chunks' to get a feel of the impact of your object requests.

An even smarter way is to segment your game world based on how many objects in that locale I.e. Some areas will be 'busier' than others, if you segment those more it will help to keep each list at a more manageable size.

The con here is that updating moving objects (I.e what sector are they in?) becomes a little more complex but it's still fairly easy to do.

This will drastically reduce your search space at the slight expense of requiring slightly more memory (for the divisions of space).

I'm a bit rusty but I think this is a very basic implementation of a search tree (it's possibly called space partitioning?). A quick search for binary (or otherwise) search trees should provide more info.