01-15-2016, 11:44 PM
(This post was last modified: 01-15-2016, 11:47 PM by LogicParrot.)
I am considering refactoring the current mob architecture to avoid reaching a big ball of mud. I believe an inheritence tree is not the best tool for modeling the mobs. Some problems:
- The current code is hard to follow.
- The state system does not cover all use cases and has to be supplanted by flags (isInLove and the like).
- Wolves can't breed, because they do not inherit cPassiveMonster.
- Many mobs have methods/fields they'll never use because cMonster is fat. I believe cMonster is fat because people in the past solved inheritence related problems by moving code upstream. For instance, I can solve the wolf breeding problem by putting the breeding code in cMonster, but then zombies would have more stuff they don't use. For the sake of long term maintainability, I believe the issue should be solved at its core, and the inheritence model should be ditched.
I'm still cooking a solution in my head but here are the initial thoughts: I'm considering a state-machine like architecture, where there's a common state map, but each mobtype has only some of the states enabled (and some states have parameters, e.g. bait type). See attached photo (mutable, likely to change).
With this architecture, each mobtype is defined solely by its enabled state combination and their parameters. (And possibly few exceptions like overriding some transitions between states (e.g. wolf idle > attacking requires sending the angrywolf packet).
- The current code is hard to follow.
- The state system does not cover all use cases and has to be supplanted by flags (isInLove and the like).
- Wolves can't breed, because they do not inherit cPassiveMonster.
- Many mobs have methods/fields they'll never use because cMonster is fat. I believe cMonster is fat because people in the past solved inheritence related problems by moving code upstream. For instance, I can solve the wolf breeding problem by putting the breeding code in cMonster, but then zombies would have more stuff they don't use. For the sake of long term maintainability, I believe the issue should be solved at its core, and the inheritence model should be ditched.
I'm still cooking a solution in my head but here are the initial thoughts: I'm considering a state-machine like architecture, where there's a common state map, but each mobtype has only some of the states enabled (and some states have parameters, e.g. bait type). See attached photo (mutable, likely to change).
With this architecture, each mobtype is defined solely by its enabled state combination and their parameters. (And possibly few exceptions like overriding some transitions between states (e.g. wolf idle > attacking requires sending the angrywolf packet).