Needed ideas about combat/skill/spell "entrophy" management

My short answer:

actions with sub actions

The longer answer

Personally I disagree with your system and believe whole heartedly in the input system as a good basis for game triggers, let me explain:

All game triggers can be represented as cause and effect, the cause being the trigger and the effect being the product of the triggered action.


Trigger      Action            Effect

Key Press->Player Attack->HitEvent

HitEvent->OnHitAction->hp loss in the target

I do this is by using a WorldInput, WorldEvents are sent to the WorldInput, where they are dispersed to the listeners. The listeners check for a few parameters: event type, range, envolvement.

Type: is it the kind of event we are looking for ie Attack event instead of say and message event

Range: the distance between the listener and where the event was dispatched

Involvement: what is my involvement in the event, was i hit? if so then the OnHitAction is invoked

Another example is agro: if i heal the tank, the mob's listener receives the heal event(although same as a hit event) and decides that the healer should be the new target.

As for what happens in the OnHitAction which even if you don't like my system you can still probably benefit from the way i design this.

The OnHitAction contains many sub action such as dodge, parry, armor, all executed in order.

You can use this system for lot of stuff like a damage reflection wall lets say.

as for generating a message output: the individual actions just have to place "hit for 50" or "dodged" in the HitEvent and the OnHitAction would then(after all the subactions have been applied) display the action that actually happened. For each subaction it would set an indicator as to weather or not the event has been fully resolved, so if the dodgeAction resolves the event then it would set and indicator and in the OnHitAction it would check for resolution of the event after each subaction.

I probably didn't do justice in explaining my idea but I think it is good. It makes organizing the game triggers much simpler and the code more clear. Also it makes creating new features very easy since you don't have to go back and modify code.

Thanks you both for your ideas.

I extract the idea from your posts… I'm complicating things  :slight_smile:

I like the idea of reducing everything to a formula… is a good one. I don't know if will work in all the cases (and may be harder to balance), but will solve some of the complexity of a complex (complicated by me) game system. I'll have to reduce it.

Yep, I thought about events… If a player gets damage from a foe, all the other players nearby have to be "listening" for the event, and their clients show the info. The server also listens, for things like Fungi's agro. Your right… my isAttacked() is wrong.

I think I'll finally go for a Javascript solution: "lockpick.js" implements "Skill" interface, whose method "resolve" (triggered with a client message) will take the player, the environment (day/night, for example… maybe not applicable in this case), and a "target" (the lock itself). The method will check player skill, look for a lockpick kit in the inventory, the lock difficulty, and resolve the action. This result will be broadcasted. The server takes this too, to mark the lock as "opened".

I'll test the performance of compiled javascript (I think it can be done in Rhino), but I need the flexibility of changes on the fly. For example, a new item is introduced in the system that grants an unskilled player the hability of lockpick (think of explosives, for example). Hmm… maybe this is another js for the item…

After things are balanced, maybe this could be hardcoded.

Thanks again… I'll look for some time for tests.

you can still do explosives in a formula:


if(lockLevek < item.pickAbility*(player.level.lockPick + item.pickmod));


pickmod = 1 for explosives, 0 for tools that require a skill player