Because I am working to re-implement the existing "bots" subsystem into the EQEmu Server code, I have decided it was time to recognize the "Mob" object as what it really is. An abstract base class. This was necessary to allow objects like "Bot" to exist without having a good many of those dreaded "#ifdef EQBOTS" statements littered all over the code as now objects that are built upon the "Mob" object will now be required to implement specific methods that all of these type of game entities ought to have to work in the game. These include "no brainer" methods like "Death()" and "FinishTrade()", for example.
What this means to other developers who want to work in the server's code is you will be required to implement these abstract virtual methods if you extend the Mob class, or any other class that is built upon the Mob class, such as the new Bot object I am implementing. If you look at the source code, you will see that classes like NPC and Client inherit from the Mob class, but the new Bot class inherits from the NPC object, not Mob.
Another consideration is where you add logic in the future. Until now, the server code has usually implemented a single function or method that several objects would "share". As a consequence of this design, these methods had to make liberal use of class methods like "IsClient()" or "IsNPC()". Obviously, this can be burdensome to read and easy to make a code change meant for a Client object, but accidently negatively affect other objects, like NPC. Using the approach of the Mob class as an abstract object, this code can now be seperated into its own appropriate classes so when the server executes a statement such as:
myMobObject->Death();
The server will call upon the appropriate object's "Death()" method. In other words, at run time, if "myMobObject" is a NPC object, then NPC::Death() is executed and not Client::Death() or even Bot::Death().
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment