Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Determining effect order


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 Telanor   Members   -  Reputation: 1358

Like
2Likes
Like

Posted 17 August 2013 - 02:54 AM

I'm having a hard time trying to come up with a way to determine the order to apply/process effects on an entity. The ideas I've come up with all have downsides to them, so I'm wondering if anyone can provide some insight on this problem.

First idea is to have a preset list of categories. Every effect/spell is assigned to a category and the categories are all processed in a certain order. There's two downsides to this: If I have an effect that needs to be applied between "category A" and "category B", there's no way to do that without introducing another category. The other issue is, if two effects are both in "category B" and I now have an effect that needs to happen between them, I'm out of luck.

Second idea is to assign a priority to each effect/spell as a float value. Effects/spells with a higher value are applied first. The problem with this one is that if I have "effect B" that needs to be applied after "effect A" and before "effect C", but A has a value of 5, and C has a value of 10, no value assigned to B will create that order.

And the last idea, which is downright awful, is to have each effect (optionally) define every effect that needs to be applied before (or after) it. Aside from the issue of creating circular dependencies, this would really get out of hand if you tried to make an effect that always has to be applied last. Either it would have to specify every single effect must occur before it, or every other effect would have to specify that that effect must come after it.

I feel like the 2nd idea is the most workable, but I want to be as accommodating to modding as possible, so people don't run into issues like "oh well, they set the priority of this spell too high, there's no way to have my effect run in the proper order". Basically all of these work in a closed system when you know every spell/effect that could be applied, but are problematic when mixed with mods. Thoughts?

Sponsor:

#2 haegarr   Crossbones+   -  Reputation: 4580

Like
2Likes
Like

Posted 17 August 2013 - 03:22 AM

A fourth approach would be to ask for a total order statement. I.e. all possible effects are presented in a chain (or perhaps a tree), and a new effect needs to be inserted into this chain to become available in the game. This pushes the responsibility to the designer. 

 


Second idea is to assign a priority to each effect/spell as a float value. Effects/spells with a higher value are applied first. The problem with this one is that if I have "effect B" that needs to be applied after "effect A" and before "effect C", but A has a value of 5, and C has a value of 10, no value assigned to B will create that order.

The example shows a design mistake: If C has a priority of 10, and A has a priority of 5, then this is already a statement about the order of A and C. If now B comes into play and contradicts the already established order, then there is a break in the logic.

 

Now, because you can't have both A before C and A after C, you perhaps wanted to say that the order of A and C is arbitrary until B comes into play. This may be expressed by letting A and C have the same priority first, but requires automatic priority adaption. This solution is a mix of both the category as well as the priority solution, because it allows to shift the category of a particular effect a bit towards another category, so that is is mainly category 1 but a bit also category 2.

 

On the other hand, if the above situation may occur legally, then obviously you need to cancel either the one or the other effect. Either the second effect cannot take place until the former situation has been settled, or else the new situation overrides the older one.



#3 Telanor   Members   -  Reputation: 1358

Like
1Likes
Like

Posted 17 August 2013 - 03:34 AM

A fourth approach would be to ask for a total order statement. I.e. all possible effects are presented in a chain (or perhaps a tree), and a new effect needs to be inserted into this chain to become available in the game. This pushes the responsibility to the designer.


What makes this different from solution 3? And how does it handle the case where Mod A adds 5 effects and then Mod B adds another 10 effects. It seems like each mod would have to know about every other mod.

Now, because you can't have both A before C and A after C, you perhaps wanted to say that the order of A and C is arbitrary until B comes into play. This may be expressed by letting A and C have the same priority first, but requires automatic priority adaption.


That is exactly the situation I wanted to express with that example. How would you code/design such an automatic priority adaption system? It seems to just end up with solution 3.

#4 LorenzoGatti   Crossbones+   -  Reputation: 2761

Like
1Likes
Like

Posted 17 August 2013 - 08:33 AM

If you have impossible ordering constraints (A before B, but B before A), it's a mistake regardless of how they are represented.

 

Of the three representations in the original posts, the third one is by far the most appropriate one because it represents an order relationship correctly; in particular, new "effects" can be added anywhere in the dependency graph, without running into trouble with missing gaps between "layers" or "priorities".

 

It isn't awful; realistically, a few dependencies imply a node's position with respect to all nodes that matter. For example, many different attack types, with various precedences among themselves, can be specified to happen before explosion rendering; then if you say that the two "final" steps of creating debris objects and swapping in damaged sprites and models take place after explosions, they automatically take place after all attacks too.

 

The actual game engine should probably process a list of "pass" objects in sequence, but turning a direct acyclic graph of precedences into a processing order is a computer's job; avoid unneeded bookkeeping for game content authors.


Edited by LorenzoGatti, 17 August 2013 - 08:34 AM.

Produci, consuma, crepa

#5 Telanor   Members   -  Reputation: 1358

Like
1Likes
Like

Posted 17 August 2013 - 03:55 PM

If you have impossible ordering constraints (A before B, but B before A), it's a mistake regardless of how they are represented.


Of course. I didn't state this but in that example, effects A and C don't actually care what order they're in, but since the system would require a priority be assigned for all effects, they were arbitrarily assigned those orders. When just A and C are used, it made no difference, but when B came into the equation, it caused a problem.

Of the three representations in the original posts, the third one is by far the most appropriate one because it represents an order relationship correctly; in particular, new "effects" can be added anywhere in the dependency graph, without running into trouble with missing gaps between "layers" or "priorities".

It isn't awful; realistically, a few dependencies imply a node's position with respect to all nodes that matter. For example, many different attack types, with various precedences among themselves, can be specified to happen before explosion rendering; then if you say that the two "final" steps of creating debris objects and swapping in damaged sprites and models take place after explosions, they automatically take place after all attacks too.


Correct me if I'm wrong, but I think we're thinking about where the order is assigned in two different ways. You seem to be thinking of it in terms of the spell specifying the order of each of its effects. I was thinking about it in more global terms, as in "effect C" always occurs before "effect B" regardless of whether its applied by a "spell A", "spell B" or "spell C". I'm not sure there would be a case where you'd want to have the order be one way for one spell and then entirely different for another spell given the same effects.

Also, I think the order is far more important when considering the effects currently on an entity. Entities can have effects like "damage reduction" or "fire resistance" applied to them from separate spells. Now when the entity is attacked, these effects will inspect the incoming damage and modify it. This is where I feel the order is important.

Consider a zombie that has the following two effects applied to it: "Converts healing spells to 'harm' spells, and 'harm' spells to healing spells" and "All damage is reduced by 50%". If you cast a 'harm' spell on the zombie, one of two things can happen, depending on the order those effects are applied. If the damage reduct is applied first, the zombie will be healed by 50%. If the conversion is applied first, then the damage reduct won't apply (since it's now a heal instead of a damage spell), and the zombie will be healed for 100%.

How would you specify the order in this case?

#6 DrEvil   Members   -  Reputation: 1105

Like
1Likes
Like

Posted 18 August 2013 - 11:24 AM

I would create dependency categories that you can associate with effects that require ordering dependencies. This allows your effect to define one or more types of effects it depends on being processed first so that when effects are added or removed you can order them by their dependencies. Dependencies could vary by specificity. Maybe there is a damage dependency that must process after all damage and more specific ones that only apply to fire damage. Depending on the complexity of the effects system you might need to essentially build an effect dependency graph with the prerequisite conditions and then when taking damage that may have multiple effects, propagate the list of damage effects through the tree, where its effects might split and follow different paths down the graph and get modified in various ways until it comes out the other side of the graph potentially heavily modified or transformed into a wholly different effect set.

On top of that you might also want to create processing groups to batch process different effect types before others. Effects that convert effects to other effects should probably come first so that before other effects are applied, conversions are made so that later effects can be applied to the conversions.

#7 Telanor   Members   -  Reputation: 1358

Like
1Likes
Like

Posted 18 August 2013 - 10:55 PM

So kind of like a more flexible version of solution A? The dependencies would be applied to the categories themselves and anyone could add new categories? Seems pretty good, but it might make it easier to end up creating circular dependencies. Also it would still have the problem of not being able to stick an effect in between two effects with the same category(s).

#8 haegarr   Crossbones+   -  Reputation: 4580

Like
1Likes
Like

Posted 19 August 2013 - 04:14 AM

IMHO a reliable non-compromise solution doesn't exist as soon as you want to mix the input from 2 independent sources and the criteria isn't already defined for both sources. 

 

Could you please give an example of how an effect should work, and how 2 effects from unaware sources have to be integrated? 



#9 Telanor   Members   -  Reputation: 1358

Like
1Likes
Like

Posted 19 August 2013 - 05:22 PM

If I could come up with an example of how it should work, the problem would be solved. All I know is that there are some effects where the order will matter, and in such cases, there needs to be a way to specify the order. I think it would be a nightmare if I tried to just specify that manually for each effect, so I want some more general way of doing it.

I agree that there probably isn't a perfect solution to this. But just because I can't think of one doesn't mean one doesn't exist tongue.png. I wanted to see if anyone could come up with "better" solutions. DrEvil's idea is pretty good and I may end up going with that.

#10 Zipster   Crossbones+   -  Reputation: 874

Like
1Likes
Like

Posted 20 August 2013 - 04:57 PM

It's difficult to give an exact answer without knowing exactly what effects can... well... affect in your game, but ideally, you don't want effect order to matter. There are ways to design such a system so that effects can be applied in an arbitrary order, and an intermediary layer can sort out the side-effects and make sure objects are actually affected in a sane manner.

 

The analog is a graphics engine which renders in two phases: the first phase collecting all the objects that need to render (or in your case, all the effects that need to be applied), and then breaking down the objects into their component pieces and rendering them in the correct order to minimize state changes, handle transparency properly, etc. (which in your case is breaking down a high-level effect into its low-level state changes and sorting them appropriately).



#11 DrEvil   Members   -  Reputation: 1105

Like
1Likes
Like

Posted 21 August 2013 - 06:13 PM

I would probably simplify the effects so that you can put together discreet stages of effect modifications where the order doesn't matter, ie so the math is communative and easy to understand, sort of a series of accumulations and applications in stages. The key I think is a sensible ordering of the calculations with an ordering that makes sense to the player.

 

For example.

  1. Take input list of effects, such as list of damage types
  2. Transform effect types to other effects so they will be treated as though they are the transformed effect
  3. Accumulate all damage together, keeping them separated by type still(fire, arcane, magic, physical, etc), you can also accumulate healing effects as well during this loop.
  4. Apply healing modification effects to healing values.
  5. Apply total healing to the character so that the healing comes before the damage to offset the damage if you so desire. Alternately you could split healing effects into pre-heal and post-heal to modify this order for certain cases, or treat post heals as tiny delay/duration regeneration.
  6. With the accumulated damage per type, apply damage modifiers that apply to each type, (fire resistance will reduce the fire damage only, etc)
  7. Accumulate damage modifiers together and apply them to the characters health.

 

If I were building an effect heavy system I would probably treat everything as an effect that goes through this pipeline. It wouldn't be just the spell effects that go through this, but also the protection levels of armor would be represented as an effect on the list.

 

Start with something simple and easy to follow and worry about the complex order issues when you actually run into a problem creating an effect that maybe you can't with this. At that point it will be easier to understand what and where you have to plug in some new 'features' to get what you need.


Edited by DrEvil, 21 August 2013 - 06:14 PM.


#12 Telanor   Members   -  Reputation: 1358

Like
0Likes
Like

Posted 22 August 2013 - 02:02 AM

I would probably simplify the effects so that you can put together discreet stages of effect modifications where the order doesn't matter, ie so the math is communative and easy to understand, sort of a series of accumulations and applications in stages. The key I think is a sensible ordering of the calculations with an ordering that makes sense to the player.


I definitely plan on breaking the effects down to simple parts. We had even planned to apply all the simple number calculations as (base+flat)*multiplier so it wouldn't matter what order those simpler effects were applied in.
 

Start with something simple and easy to follow and worry about the complex order issues when you actually run into a problem creating an effect that maybe you can't with this.


I think I might just do that. We don't have a concrete list of things we actually want to do for now, and the ones we have thought of won't have much issue with the order. I just worry about ending up with a bunch of hacky fixes later to get some effects to work. I'm also trying to keep mods in mind and not design something that's too restrictive.

#13 DrEvil   Members   -  Reputation: 1105

Like
0Likes
Like

Posted 23 August 2013 - 05:13 PM

That's cool.

 

You're kind of thinking like I do quite often. I often have a vague idea that something is going to be a problem in the future but have a difficult time thinking of a real world example of just how it would manifiest. I usually try to get another set of eyes or two and talk it through them, and maybe blueprint out the near term use cases and see if those would be covered and if I still haven't come up with a concrete problem case I have to force myself into just moving ahead and worrying about the problem when I actually run into it. Often I never do so it's fine. At the base level it seems like a simple matter of a hierarchy of effect applications that may do you fine. At worst if you do run into an order of operations issue hopefully it would be easy to alter its effect a bit or split it into multiple effects in order to get the desired outcome but within the framework of the simplified calculation pipeline.

 

Good luck!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS