[DGD] Code libraries for DGD and Hydra

[Felix A. Croes]

Dread Quixadhal <quixadhal at gmail.com> wrote:

> It sounds like a fun way to test this would be a combat situation where you had a large group of actors who were all doing area effect attacks that would hit each other.  In that case, if you had a group of 20 all standing in range of each other, each one would be dealing out damage to 19 others and having 19 occurrences of damage incoming (assuming nobody misses).
>
> The part where it becomes fun is that you likely want a death event to occur once (and only once) for any actor who drops below a threshold of health, and you may want the one who landed the death blow to shout out in victory.  So each attacker has to know if their damage was the fatal blow.

Hydra has the "and only once" part covered.  No matter how this would
be implemented and which tasks would be rescheduled, ultimately Hydra
simulates a single-threaded system where all events happen
sequentially.


> In a boring non-message based system, you’d be doing things like if( (victim.health -= damage) <= 0 ) dance();
>
> In a more usual LPC system, you might do something like if( victim->receive_damage(damage) <= 0 ) dance();
>
> But to try and minimize collisions for parallel processing, I'm sure you'd need a different approach.  Perhaps having to make the victory dance become a callback that the victim's object would invoke as the death blow were processed?

It is a variant of the famous Dragon's Dinner problem.  The simplest
way to prevent rescheduled tasks would be to use call_out_other() to do
damage, and let each player process the damage done in a callout-started
task.  Feedback could be done with another callout.

However, there could be some strange effects.  If PlayerX has one
hitpoint and we are trying to kill him simultaneously, and we both
start callouts, PlayerX will be killed by the first blow and the
second one would hit him after he dies.  It may also be possible to
kill someone and never see it happen, because you die yourself
before the callback occurs.

Also note that Hydra has overhead for starting and committing a task
which is much larger than it would be for DGD.  At a certain point,
the lack of cohesion from breaking tasks up into subtasks and the
overhead for running those separate tasks could outweigh the drawback
of an occasional rescheduled task.  Many players all affecting
eachother simultaneously is ultimately going to scale poorly.  Hydra
cannot change that fundamental reality.

If you are really interested in seeing how this plays out, you don't
have to limit yourself to theorycrafting.  Hydra is out there, and
it works.

Regards,
Felix Croes