Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="AbdulAlhazred" data-source="post: 5398676" data-attributes="member: 82106">After thinking about it, one more refinement. The fundamental units should be 'Events' that are atomic steps at the level of interruptability. All of these within a given action would share one ReactionQueue (actually what sort of structure it needs to be is not defined by the rules, could be a stack or a queue or any other type of collection depending on how the developer decides to order reactions). Each Event would have to send out some kind of event notification to anything that could generate interrupts (or other instant things) or reactions.So I THINK the drill would be along the lines of an Action could invoke a Power. The Power would simply call whatever Events it needed, which can do both the UI stuff and make state changes to the overall game world state. Entities could register to be notified of any of these state changes as well as occurrence of non-state-changing Event types. Thus an Event could call GameState.doDamage(target, self) at the appropriate moment and the Wizard Entity that is getting smacked will be notified, at which point it could simply INVOKE an interrupt by calling it (say because the Shield power is triggered) or it could tack a Reaction onto the ReactionQueue for the whole Action. I think that is cleaner than just having each Action/Power keep calling back with "and now I've started doing X, and now I'm done doing X." because now it can all be pooled into a quite abstract Event that can be reused for each step. Thus the code for a given Power can be fairly minimal and boilerplate (so most Powers can probably use one set of code that is just driven by some data describing it, or be easily scripted).</blockquote>

Verification