Thanks, all very good info. Don't want to go too off topic, but if I plan to implement path finding for enemies, would it be best to have another data structure containing all path blockers/targets indexed by their location? Or is this redundant? Should I be utilizing the original lists in some way? Is it okay to have two data structures that contain the same objects for different purposes? Or should I just have one structure that can serve multiple purposes?

You're in Python, which makes some of this a little less obvious than languages like C or C++.

Generally it is best to have a single instance of the objects in one location. Everywhere else have references to those objects.

In Python with reference counted objects, it can be trickier because the actual instance is hidden from you, items become a strong reference.

Python complicates matters if you don't understand object lifetimes, as what seems like creating new references is sometimes actually creating new instances, and sometimes when you think you create a new instance you get a shared instance with a reference count.

> Is it okay to have two data structures that contain the same objects for different purposes?

Yes, if you are talking about references to the object. I may have the 'real' collection of game objects in an object pool. Then I have a spatial container that uses references to those real objects. When building a return value of nearby items, I build a container and put references to the real objects into that, then return the container. I may have a container that uses references to the items in a player's inventory, or for the minimap display, or for something else.

Those should generally be shared through references as Python does with reference-counted instances. They should not be new, duplicated instances broken off from the original.

The rest of the questions have answers that fall from that.

> have another data structure containing all the path blockers/targets indexed by their location?

Sure, you can have a collection that references the objects if you want. Or you can have a collection that contains their indexes, although that is slightly more risky in the event that indexes change.

This is up to how you implement your pathfinding. You may have logic that allows for multiple conditions. Some games build pathfinding and account for temporary/movable objects on the path by ignoring them, only computing paths based on immovable objects. When the character approaches a movable object they might request the movable thing get out of their way if that is an option, or might find a short path around the object. Or in some games the two units may co-exist in the same cell or move through each other or squeeze by their friendly companions. Or in some games, perhaps you've got a tank with a move request through enemy soldiers, it will just drive over them.

In other games with more complex routines, moving units are considered differently so they will automatically handle choke points during path finding. They may identify a narrow gap and be programmed to handle it with more logic, following each other if going the same direction, queueing up and taking turns from each direction, or other more complex behavior.

You may have a pathfinding routine that accepts several different flags, searches only for immovable objects, or does something else.

The task of pathfinding over a navigation mesh is relatively easy compared to the work of navigating the mesh with all the other moving parts on the map.

> should I just have one structure that can serve multiple purposes?

Probably not, the structure often provides information by its nature. However, you might decide that for whatever it is you are doing the one structure provides what you need in many different cases. With good abstractions a collection of items can be generic enough to be reused everywhere. I mentioned SOLID above. Alberth gave an application of SOLID by telling you to work with abstract actions rather than specific values. Those still apply.