Skip to main content
Game Development

Return to Answer

added 200 characters in body
Source Link
brigadir
brigadir
  • 101
  • 2

I can propose some compromise between general single list and separate lists for each object type.

Keep reference to one object in multiple lists. These lists are defined by base behaviors. For example, MarineSoldier object will be referenced in PhysicalObjList, GraphicalObjList, UserControlObjList, HumanObjList. So, when you process physics, you iterate through PhysicalObjList, when process damaging from poison - HumanObjList, if Soldier dies - remove it from HumanObjList but keep in PhysicalObjList. To make this mechanism working you need to organize automatic insertion/removing object when it's created/deleted.

Advantages of the approach:

  • typed organization of objects (no AllObjectsList with casting on update)
  • lists are based on logics, not on object classes
  • no problems with objects with combined abilities (MegaAirHumanUnderwaterObject would be inserted into corresponding lists instead of creating new list for its type)

PS: As for self-updating, you will meet problem when multiple objects are interacting and each of them depends on others. To solve this we need to affect object externally, not inside self-update.

I can propose some compromise between general single list and separate lists for each object type.

Keep reference to one object in multiple lists. These lists are defined by base behaviors. For example, MarineSoldier object will be referenced in PhysicalObjList, GraphicalObjList, UserControlObjList, HumanObjList. So, when you process physics, you iterate through PhysicalObjList, when process damaging from poison - HumanObjList, if Soldier dies - remove it from HumanObjList but keep in PhysicalObjList. To make this mechanism working you need to organize automatic insertion/removing object when it's created/deleted.

Advantages of the approach:

  • typed organization of objects (no AllObjectsList with casting on update)
  • lists are based on logics, not on object classes
  • no problems with objects with combined abilities (MegaAirHumanUnderwaterObject would be inserted into corresponding lists instead of creating new list for its type)

I can propose some compromise between general single list and separate lists for each object type.

Keep reference to one object in multiple lists. These lists are defined by base behaviors. For example, MarineSoldier object will be referenced in PhysicalObjList, GraphicalObjList, UserControlObjList, HumanObjList. So, when you process physics, you iterate through PhysicalObjList, when process damaging from poison - HumanObjList, if Soldier dies - remove it from HumanObjList but keep in PhysicalObjList. To make this mechanism working you need to organize automatic insertion/removing object when it's created/deleted.

Advantages of the approach:

  • typed organization of objects (no AllObjectsList with casting on update)
  • lists are based on logics, not on object classes
  • no problems with objects with combined abilities (MegaAirHumanUnderwaterObject would be inserted into corresponding lists instead of creating new list for its type)

PS: As for self-updating, you will meet problem when multiple objects are interacting and each of them depends on others. To solve this we need to affect object externally, not inside self-update.

Source Link
brigadir
brigadir
  • 101
  • 2

I can propose some compromise between general single list and separate lists for each object type.

Keep reference to one object in multiple lists. These lists are defined by base behaviors. For example, MarineSoldier object will be referenced in PhysicalObjList, GraphicalObjList, UserControlObjList, HumanObjList. So, when you process physics, you iterate through PhysicalObjList, when process damaging from poison - HumanObjList, if Soldier dies - remove it from HumanObjList but keep in PhysicalObjList. To make this mechanism working you need to organize automatic insertion/removing object when it's created/deleted.

Advantages of the approach:

  • typed organization of objects (no AllObjectsList with casting on update)
  • lists are based on logics, not on object classes
  • no problems with objects with combined abilities (MegaAirHumanUnderwaterObject would be inserted into corresponding lists instead of creating new list for its type)