15 Mar, 2010, Deimos wrote in the 122nd comment:
donky said:
If your effects are defined as data, rather than code, then all these problems go away. You can have input parameters to the effects, like spell.falloffAmount so that the "strength reducing" effect works for whatever rate you wish it to. You can simply redefine effects and have the input system reuse existing ones, based off a simple search it would do automatically. You can easily detect orphaned effects simply by doing searches on the data.
If I'm understanding you correctly, you're saying that you would define a generic behavior (say, a DivAttrByModEffect as effect.attribute /= effect.modifier) as the effect, and pass it input parameters for any desired effect that uses that behavior? If so, that doesn't solve the problems…
15 Mar, 2010, donky wrote in the 123rd comment:
Deimos said:
If I'm understanding you correctly, you're saying that you would define a generic behavior (say, a DivAttrByModEffect as effect.attribute /= effect.modifier) as the effect, and pass it input parameters for any desired effect that uses that behavior? If so, that doesn't solve the problems…
donky said:
If your effects are defined as data, rather than code, then all these problems go away. You can have input parameters to the effects, like spell.falloffAmount so that the "strength reducing" effect works for whatever rate you wish it to. You can simply redefine effects and have the input system reuse existing ones, based off a simple search it would do automatically. You can easily detect orphaned effects simply by doing searches on the data.
If I'm understanding you correctly, you're saying that you would define a generic behavior (say, a DivAttrByModEffect as effect.attribute /= effect.modifier) as the effect, and pass it input parameters for any desired effect that uses that behavior? If so, that doesn't solve the problems…
Maybe that's not what I am saying then. Everything you suggested were problems in the post I replied to, were things I have in practice in development of an actual live game, found to not actually be problems.
15 Mar, 2010, Deimos wrote in the 124th comment:
donky said:
Maybe that's not what I am saying then.
Is it or isn't it?
donky said:
Everything you suggested were problems in the post I replied to, were things I have in practice in development of an actual live game, found to not actually be problems.
If you aren't going to expound on how you solved the problems, I'm not sure what value you feel that you're adding to the discussion by letting us know this?
15 Mar, 2010, donky wrote in the 125th comment:
Deimos said:
Is it or isn't it?
donky said:
Maybe that's not what I am saying then.
Is it or isn't it?
I don't understand what you wrote enough to know.
Deimos said:
If you aren't going to expound on how you solved the problems, I'm not sure what value you feel that you're adding to the discussion by letting us know this?
donky said:
Everything you suggested were problems in the post I replied to, were things I have in practice in development of an actual live game, found to not actually be problems.
If you aren't going to expound on how you solved the problems, I'm not sure what value you feel that you're adding to the discussion by letting us know this?
In my last post I gave you as clear an answer as I felt your response allowed. Reread what you quoted immediately above, and then ask whatever you want based on what I communicated there. The ball is in your court. If you do not ask me anything that I can answer without wondering what you mean, then I cannot elaborate.
15 Mar, 2010, Deimos wrote in the 126th comment:
donky said:
In my last post I gave you as clear an answer as I felt your response allowed. Reread what you quoted immediately above, and then ask whatever you want based on what I communicated there. The ball is in your court. If you do not ask me anything that I can answer without wondering what you mean, then I cannot elaborate.
How does allowing more than one input parameter solve the problem of only being able to model a finite set of behaviors?
For example, explain how your system would model this effect:
strength = ( strength / 2 ) * sqrt( sword_skill )
15 Mar, 2010, David Haley wrote in the 127th comment:
I think that you're talking about somewhat different problems, yes.
15 Mar, 2010, donky wrote in the 128th comment:
Deimos said:
How does allowing more than one input parameter solve the problem of only being able to model a finite set of behaviors?
I am unclear on how this is related to what I said.
Deimos said:
For example, explain how your system would model this effect:
strength = ( strength / 2 ) * sqrt( sword_skill )
strength = ( strength / 2 ) * sqrt( sword_skill )
I am assuming that 'strength' is the involved character's strength attribute, and that 'sword_skill' is the character's sword skill level. It may be implicit that these are their meanings, but unless it is stated, the possibility for miscommunication is present.
This effect can be categorised as a multiplier for an attribute. So the effective result is that a multiplier of '0.5 * sqrt(sword_skill)' would be placed on the character strength attribute. It gets more complicated than that, but that is the gist of it.
15 Mar, 2010, donky wrote in the 129th comment:
David Haley said:
I think that you're talking about somewhat different problems, yes.
Every single thing that Deimos listed in the text I quoted are not actually problems in the effect system I have alluded to. These are clearly described problems. What problems are we talking about that are different, if not those ones?
15 Mar, 2010, Deimos wrote in the 130th comment:
donky said:
It gets more complicated than that, but that is the gist of it.
As DH would say, this is hand-wavey. Please describe exactly how you would pass "0.5 * sqrt(sword_skill)" as a parameter into your effect.
15 Mar, 2010, David Haley wrote in the 131st comment:
donky said:
Every single thing that Deimos listed in the text I quoted are not actually problems in the effect system I have alluded to. These are clearly described problems. What problems are we talking about that are different, if not those ones?
Most of the discussion thus far has been about being able to modify arbitrary things in arbitrary ways and how this would work out. The issues that you replied to are a sub-conversation, and I think that Deimos is saying that your comments don't address the larger conversation. (Of course, that's just my understanding of what he's saying, and I don't want to put words in his mouth…)
For instance, you said: "I am unclear on how this is related to what I said." Well, it's related because you showed up in the middle of a much larger discussion. :wink:
15 Mar, 2010, Deimos wrote in the 132nd comment:
Well, mostly I was pointing out that his system can only handle very simple expressions. Any attempt at handling a complex expression would require him to do calculations outside of the effect, in order to pass the results in as parameters, which is a Bad Thing. An effect should encapsulate its own behavior. You shouldn't be doing half the work for it and passing it the other half to figure out. Not to mention that passing it in by value means that your system breaks if any of the variables (i.e. sword_skill in my example) happen to change while the effect is active.
15 Mar, 2010, donky wrote in the 133rd comment:
Deimos said:
As DH would say, this is hand-wavey. Please describe exactly how you would pass "0.5 * sqrt(sword_skill)" as a parameter into your effect.
donky said:
It gets more complicated than that, but that is the gist of it.
As DH would say, this is hand-wavey. Please describe exactly how you would pass "0.5 * sqrt(sword_skill)" as a parameter into your effect.
It needs to be, I would prefer to have you lead me towards the detail you want, rather than going into a giant elaboration that was pointless.
As I said, everything is data. So this breaks down to a tree of expressions.
One possible breakdown:
Now the effect would say (let's assume it is a ring that is worn and unworn):
def OnWorn(self):
character.AddModifier(D)
def OnUnworn(self):
character.RemoveModifier(D)
But of course this code does not actually have to exist. Generic systems can infer when effects attached to items should be applied. And inherently, because this ring applies its effects to the wearer, wearing it has those effects for as long as it is worn.
15 Mar, 2010, donky wrote in the 134th comment:
Deimos said:
Well, mostly I was pointing out that his system can only handle very simple expressions.
Hence my lack of understanding, because this to me was an unjustified assumption.
Deimos said:
Any attempt at handling a complex expression would require him to do calculations outside of the effect, in order to pass the results in as parameters, which is a Bad Thing.
This is assuming what I meant by data, I believe. But my other response should show that the data I am talking about is executable, which allows all sorts of valuable possibilities to come into play.
15 Mar, 2010, donky wrote in the 135th comment:
David Haley said:
For instance, you said: "I am unclear on how this is related to what I said." Well, it's related because you showed up in the middle of a much larger discussion. :wink:
No, that was not it. It was because Deimos was making assumptions, and it was not entirely clear what assumption he was making.
15 Mar, 2010, David Haley wrote in the 136th comment:
If you say so, I suppose. Just tryin' to be helpful and explain why you were told you weren't addressing the bigger problem we were talking about when you stepped in.
15 Mar, 2010, Deimos wrote in the 137th comment:
donky said:
Now the effect would say (let's assume it is a ring that is worn and unworn):
Immediate application and removal of effects is not at all what we've been discussing for the past 3 pages. In particular, we're discussing the difficulties that come about from cumulative effects with intermediate dependent states. Or, in layman's terms, effects that depend on other effects to derive their values over time.
This presents a whole slew of problems that don't exist otherwise (i.e. in what you've described thus far).
15 Mar, 2010, donky wrote in the 138th comment:
Deimos said:
Immediate application and removal of effects is not at all what we've been discussing for the past 3 pages.
donky said:
Now the effect would say (let's assume it is a ring that is worn and unworn):
Immediate application and removal of effects is not at all what we've been discussing for the past 3 pages.
That was merely a footnote on the answer to the question you asked. It is irrelevant except as one of the possible ways these modifier expressions are put in place.
Deimos said:
In particular, we're discussing the difficulties that come about from cumulative effects with intermediate dependent states. Or, in layman's terms, effects that depend on other effects to contrive their values over time.
This presents a whole slew of problems that don't exist otherwise (i.e. in what you've described thus far).
This presents a whole slew of problems that don't exist otherwise (i.e. in what you've described thus far).
And I consider it completely on topic to say, look I don't have these problems in this system, here's an alternate way of doing it.
15 Mar, 2010, donky wrote in the 139th comment:
David Haley said:
If you say so, I suppose. Just tryin' to be helpful and explain why you were told you weren't addressing the bigger problem we were talking about when you stepped in.
I wasn't aware I was being told this by anyone other than yourself, until Deimos' most recent post. And yes, I read every page of this thread before I posted. I may have skimmed some of the pointless seeming ones that I found disinteresting, but I certainly paged through it.
15 Mar, 2010, David Haley wrote in the 140th comment:
Do you need a simple majority, two-thirds majority or merely two people before you believe something? :rolleyes: Well anyhow, I'm glad this particular confusion is behind us. Let's go back to discussing how arbitrarily we want to modify things without any limits whatsoever and without knowing ahead of time what we want to do. :wink:
Less facetiously, your suggestion might not sit will with Shasarak, because to implement your proposal one needs to know an awful lot again about what one can modify, which is exactly what he has been trying to avoid. So your suggestion would sit well in my camp, but really doesn't address Shasarak's goals here. I'm still curious to know how he'd handle all this in practice.
Less facetiously, your suggestion might not sit will with Shasarak, because to implement your proposal one needs to know an awful lot again about what one can modify, which is exactly what he has been trying to avoid. So your suggestion would sit well in my camp, but really doesn't address Shasarak's goals here. I'm still curious to know how he'd handle all this in practice.
Random Picks
Well, I'll grant you that, with the caveat that such a system would be horrible to maintain. For instance, suppose I create a new spell and I want it to reduce strength by 3 every tick. Do I have a "-3 str per tick" effect that already does this? I can't just create one without finding out, or I risk redundancy. So, I have to sift through all of my effects to find out. Maybe I have one, maybe I don't. What if I change my mind later and want it to reduce strength by only 2, instead? I can't just change the effect, because other spells might rely on it. So again, I may have one or I may not, and I have to sift through all my effects and find out. And if no other spells relied on the effect that I stopped using, I now have an orphaned effect that nothing uses, but I can't possibly know that unless I sift through all possible spells, potions, etc. to find out.
If your effects are defined as data, rather than code, then all these problems go away. You can have input parameters to the effects, like spell.falloffAmount so that the "strength reducing" effect works for whatever rate you wish it to. You can simply redefine effects and have the input system reuse existing ones, based off a simple search it would do automatically. You can easily detect orphaned effects simply by doing searches on the data.
Yes, I have worked on a system like this. It is in use in a live game.