>>95548454>and thought it was an antipattern because I was new so I never did it againIt likely is an anti-pattern for mobs, because you are treating them the same way with regard to program correctness (i.e. they are all getting drawn the same way, loaded/saved the same way, etc).
That's why I wanted to see the mob classes. Why do they need to be different types, and how different do they need to be? If there is a Vampie and a Zombie, do you actually want an underlying Undead type from a program correctness standpoint? If so, then make them different classes and put them in different collections.
Are they only an Undead from a game standpoint, and it should not be a compile error when you do something else with them? Then make it the same type.
Want to enforce certain game logic at compile time with your various monsters? Consider templates and static polymorphism. etc.
>I understand.You really don't. Stop thinking of patterns and anti patterns and consider these things to simply be tools. One Mob vector may or may not be appropriate, you need to understand it for what it is and recognize the trade-offs. You might wind up with other collections for monsters, and decide to generate a vector of MobAppearances from the various monster collections you have, and hand that off to your draw code instead of iterating through a vector and calling draw on each one.
In the above case, MobAppearance would be just a lightweight drawable that knows nothing about what it represents and is simply used for batching draw calls.
I'll say it again. These things have tradeoffs, we'd have to see what is being done to really make a bold claim about what is best here.
