Simultaneous events in a realtime system, where processing order causes different outcomes

Question

I am working on a realtime dungeon crawler, focusing on a relatively complex and flexible skill system. Somewhat similar to MMORPGs with many compound spells, area effects, buffs/debuffs, ect. I am working on the last few subsystems of the engine.

I found a problem with actions happening in the same logic frame which change an actor's attributes.

For example, let's say two actors use a skill on eachother in the same logic tick, which deals 100 damage and leaves a debuff which halves damage done.
If I simply iterate over each actor and process their abilities, the one which gets processed sooner will deal full damage, the other will do so with the debuffed state, dealing only 50. Ideally, I'd like both of them to work similarly, dealing full damage and leaving the debuff.
What annoys me is the undetermined nature arising from the order of iteration.

---

One solution I thought about was to defer all the stat value changes and buff/debuff application until all the abilities are processed, since these are the only things which can affect the behaviour of abilties. So essentially I loop over actors, process their ability methods, but queue up the stat and status effect changes in a list.
Once I processed every ability I iterate over once more, this time changing the actual stats from the queued values.

This fixes the determinism problem, but causes another.

To use another example (since I can't exactly phrase the general case):
Let's say the player has 100 mana, and gets hit by ten manaburn attacks in one frame, each burning at most 50 mana, and dealing damage equal to the mana burned.
If I don't use the former fix, it'll work correctly, two will burn out the 100 mana of the player dealing 100 damage, the rest eight will do nothing.

With the fix however, since the player's mana value doesn't change yet, all ten attacks will land and deal 500 damage, more than the amount of mana the player has, which is an even more silly situation than before.

---

I'm quite an amateur, I have less experience than wit for designing complex systems. Is it possible to have determined behaviour for actions happening in the same frame while avoiding nastier consequences like the second example?

I know the player will unlikely notice the errors in the first case, and I don't think other developers bother with this issue either.

I'm still curious though, is such thing possible, a pipe dream, or just I have a warped idea about how the game logic should work?

Thank you!

Answer 1

Good question. Your 2 examples are obviously incompatible by design - either the effects of previous actions are available when calculating results of the current action, or they're not.

First, though: the phrase "I am working on a realtime dungeon crawler" implies that this sort of problem really shouldn't happen often enough to be a problem. The essence of real-time is that things happen so quickly that it's easy to accept that the other person acted just milliseconds more quickly than you, and so an arbitrarily sequential order of execution is almost never a problem for the player.

If, for some reason, everybody does tend to use abilities on the same tick, you could just use some system to spread them out so that this is a much rarer occurrence. Make the ticks shorter and more frequent, or have characters act on different ticks based on a speed or initiative value. Or, just randomise the order of logic processing so that nobody gets a persistent advantage.

But if you really want to 'solve' the problem, one way is to split the system up into phases, one for evaluating simultaneous actions, one for applying the results, and one for evaluating AND applying sequential ones. That way the buffs all get resolved fairly and only once that's done are effects like manaburn executed. Generally speaking the only actions that need to be sequential are the ones where the character being changed is the same character that's being examined, because each action needs to perform the whole read-then-write atomically for the system to make sense.

Answer 2

I had a theoretical idea how to combine delaying changes to the world with having the updated values available. I realized the issue mainly boils down to somehow have a defined order of events happening inside a frame, somehow subdividing the frame into smaller, but undefined units in time, both in length and count.

The theory:
Each event is a series of simple actions, which either sample the world, or change them by inserting new entities, changing attributes or applying effects. As Kylotan pointed out, if the changes to the world are delayed, they are not available when an event is processed.

I thought about putting some kind of breakpoints into an event, which mark that we need the updated state of the world to continue. Each segment between breakpoints is processed sequentially.

In the main game loop, the processing of the events is done in a second loop:

1) each event sequentially gets processed up to the next breakpoint.
2) The attributes and status effects of the entities are updated.

This is repeated until there are no unfinished events left.

I am using Java, I don't have any idea how this could be implemented most cleanly. One idea I had is to break the event method into a switch, each segment going into a case.

This would translate the following (pseudo-code)

Event manadrain(){
  player.mana.add(-5); 
  waitWorldUpdate();
  int v = min(target.mana, 10);
  player-mana.add(v);

into:

public void processEvent() {
    switch (segment) {
        case 1:
            player.mana.add(-5);
            return true;
        case 2:
            int v = min(target.mana, 10);
            player - mana.add(v);
            return false;
    }
}

the segment variable can be incremented internally; the return value returns true if there are more segments to be processed. The events can be processed in a list, and removed when they return false.

This way, both of my examples in the question are solved. In the damage debuff example, there are two potential outcomes:

1. If we do the damage and the debuff application in one segment, both of them will deal 100 damage, and receive the debuff.
2. If we apply the debuff first, wait for an update then do the damage, both will do 50 damage with the debuff on.

The manadrain example is simpler, the events are not needed to be broken apart; since they are processed sequentially, the first two will land and burn 2*50 damage, the rest will fail.

Why would such a deterministic solution be important?
For example if two similar entities are created at the same time, and affect eachother in a similar way to the first question example, it may be desired that both of them change in the same way.

On the other hand, the more time I spend working on this problem, the more potential aberrations I find. Not to mention this would likely be a nightmare to debug and work with. I am not even sure this solution is good enough. Please tell me if there are any cases where the above solution fails.