OmegaRPG
OmegaRPG copied to clipboard
cwc
Convert individual monsters to subclasses of Monster
- Each monster should have its own class (e.g.
MonsterHornet.cpp) - The
Monsterclass should be made more generic (i.e. have virtual methods for attacking the player that will be overridden) - Each monster should subclass Monster in order to provide e.g. specialized attacks, movement behavior, etc.
First, I like your idea. Just a design question though: Why wouldn't we just load that data from a file instead rather than making new monster objects in code for each individual monster? Obviously you have your special monsters that cause events, but in general it seems like that would be easier to add more generic monsters by reading data from a separate file rather than writing a brand new child class for every mob.
Sorry I'm just now getting around to replying.
Dynamic NPC/object loading actually is something I'd like to implement at some point. There are a lot of benefits, not least of which is ease of modding. For now though, I think as part of the initial refactoring to an object-oriented model it's easiest to keep things hardcoded. Dynamic loading is a pretty big feature to add, which I'm generally trying to avoid at this point (though obviously not completely freezing on features, yet).
Should this same technique be used to abstract the object class? Each item has its own effect but based on the way it's implemented, each item can only produce one effect. It's effect ID is sent to a huge switch statement which calls the corresponding effect. That seems wrong to me but I can't see another way to do it. Suggestions? See https://github.com/vsrz/OmegaRPG/commit/b6cad93844f24b0973022c3e6e1df3ce04fd85a3 Omega/src/Thing.h
Yes, I need to create an issue for individual Object subclasses. My thinking was along the lines of: Object defines a virtual use method that takes various parameters such as a user and target (depending on the context they might be the same, or one might be null - potentially tricky but can probably be worked around), then the use method is overridden by the subclasses.
It looks like you've got it headed in the right direction with that commit. Let me read it more thoroughly; I'll leave further comments there.