AcidFaucet wrote:
I think I'm picturing it a bit different than you are (I might not be, you haven't exactly discussed it a ton, nor does your code make anything truly explicit).
Point well taken, I was about to move into cleanup/document/review phase when a for-pay project dropped in my lap.
I know some of it's probably pretty obfuscated.
I believe what you're picturing is finer-grained control than I had imagined, but I kept things loose and made very few assumptions about how modules would be used. To take the strafe/prone example, I imagined one module for all movement instead of a module for each action. There's nothing to inhibit the finer-grained approach, but there's not much to support it either.
One approach:
Code:
class MoveModule : public Module
{
public:
// factory function used to register the module
static Module* make()
{
return new MoveModule;
}
private:
// every module needs a name
MoveModule() : Module("MoveModule") {};
void onInit()
{
// hook up events this module responds to
connect("run", makeSlot(this, &MoveModule::onRun));
connect("prone", makeSlot(this, &MoveModule::onProne));
connect("strafe_left", makeSlot(this, &MoveModule::onStrafeLeft));
connect("strafe_right", makeSlot(this, &MoveModule::onStrafeRight));
}
void onRun(const Event& ev);
void onProne(const Event& ev);
void onStrafeLeft(const Event& ev);
void onStrafeRight(const Event& ev);
}
This Module would also need to store 'live' data for the individual Entities it services, like the action history, prone status, etc. Each action is registered as an event handler, and the one module encompasses all movement functionality. Other modules for input or AI would be the likely generators of these events.
Pattern == Template, I should probably just rename the class.
The Pattern comes directly from an Entity's XML definition. So a Pattern for an Entity that uses MoveModule could contain specifics about how fast it moves, etc... it's shared meta-data for all Entities created from that Pattern (think maxHP), mainly used in instantiation of an Entity.
As it stands now, if Modules wanted to share 'live' data (currentHP) amongst themselves, they'd have to pass it using the event system. The Event class can store arbitrary data, and can also hold a signal so the recipient can 'tag-back' for whatever reason. So a strafe module could do a sort of double-dispatch by sending a 'prone_check' event with a callback. The callback does the actual strafe movement (or not) depending on the parameter passed to it.
Seems like our ideas our close, maybe some of the difference could be chalked up to word choice.... the definition of 'Pattern' that you describe is very close to an idea I've been gnawing on to allow for hierarchies of Modules... and this would allow sub-modules to query their parent directly for shared data. I was considering it for the case of a 'Weapons' module that handles aiming/firing/weaponselect functionality, with sub-modules defining behavior for each type of weapon. Encompassing all weapons in one module felt like too much, but a module for each weapon was also not ideal to me. Module hierarchies wouldn't be terrible to patch it in, just one of the things that got sidelined temporarily...
Visitor/Strategy mating:
Yeah, I agree the perfect implementation brings these two together basically for free, and with a minimum of latex.
Login
Wiki
FAQ
Search
