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.
\$\begingroup\$
\$\endgroup\$
9
-
\$\begingroup\$ I have an ID member on my entity system, but I never bother using it. What language are you using? \$\endgroup\$PrettyPrincessKitty FS– PrettyPrincessKitty FS2011-07-03 16:57:02 +00:00Commented Jul 3, 2011 at 16:57
-
3\$\begingroup\$ IDs of what? Type of component? Unique to the entity? Unique to the component? \$\endgroup\$Tetrad– Tetrad2011-07-03 17:09:21 +00:00Commented Jul 3, 2011 at 17:09
-
\$\begingroup\$ @Tetrad: Isn't my question clear enough? No IDs. \$\endgroup\$Paul Manta– Paul Manta2011-07-03 17:24:19 +00:00Commented Jul 3, 2011 at 17:24
-
2\$\begingroup\$ @Paul, if you tell us what kind of IDs you're talking and what you need them for and why you think they're bad maybe we can help you. So no, your question isn't clear enough as-is. \$\endgroup\$Tetrad– Tetrad2011-07-03 18:53:00 +00:00Commented Jul 3, 2011 at 18:53
-
2\$\begingroup\$ @Paul: If an entity has an ID, you don't have to be aware of the particular subtype that the object has, only the type that it derives from (assuming the parent type contains the ID). This doesn't break polymorphism in any way. So I don't understand what you're trying to say in the last sentence of your question. The "problem" you've identified with the use of IDs is not really a problem. Perhaps that is one of the causes of downvotes? \$\endgroup\$Olhovsky– Olhovsky2011-07-03 20:33:38 +00:00Commented Jul 3, 2011 at 20:33
|
Show 4 more comments
2 Answers
\$\begingroup\$
\$\endgroup\$
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 Dictionary).
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.
answered Jul 3, 2011 at 18:47
BlueRaja - Danny Pflughoeft
8,0652 gold badges38 silver badges41 bronze badges
\$\begingroup\$
\$\endgroup\$
2
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.
-
\$\begingroup\$ I'm not trying to make 'good' IDs. I'm trying to get rid of IDs. \$\endgroup\$Paul Manta– Paul Manta2011-07-03 17:25:18 +00:00Commented Jul 3, 2011 at 17:25
-
3\$\begingroup\$ @Paul: So get rid of them. Of course, the obstacle to that is whatever actual purpose they're serving for you, but you haven't told anybody what that is, so we can't answer your actual question, which is "how do I meet the needs that IDs are fulfilling for me in an alternate fashion?" I was, however, addressing the fact that your stated motivation for getting rid of IDs -- that they ruin polymorphism -- is an artifact of your implementation, not an inherent part of their nature. If the reason you want to get rid of them is addressed but you still want to get rid of them, what's going on? \$\endgroup\$chaos– chaos2011-07-03 18:37:19 +00:00Commented Jul 3, 2011 at 18:37