I'd like to know if someone has found a way to build a component-based entity system in their game(s) without using IDs. I find that IDs tend to do away with one of the major (possible) advantages of OOP: not having to be aware of the type of a certain object.
|
|
Your entities need ID's in some form or another, if you want to persist them to disk, or pass them over a network. Thus, what you probably want is not to get rid of ID's, but to dynamically generate them so you don't have to set them manually in the code every time you create a new Entity-class. I've done this in my latest C# project by creating a special List class that assigns a unique index to every item added to the list. Unlike a normal list, when an item is removed, the indices for the rest of the items don't change (Internally it's implemented using a Thus, as long as the entities are added to the list in the same order every time the executable is run (or, for networking, between all clients), they will always have the same ID. The problem with this solution is that it's not in a human-friendly format. To fix this, you could use reflection to prepend the type-name. |
||||
|
|
|
I use IDs (for entities, not components), though I could do without them if I didn't want weak referencing for purposes of persistence + lazy loading. Mine do not defeat polymorphism as you describe, though. Try having your IDs provided by a universal registry and accessed via a standard interface. |
|||||||
|
