[MUD-Dev] Continuous versus Discrete Functions
rayzam at home.com
Sat Dec 22 14:24:41 New Zealand Daylight Time 2001
----- Original Message -----
From: "John Buehler" <johnbue at email.msn.com>
> Dave Rickey writes:
>> From: John Buehler <johnbue at email.msn.com>
>>> Dave Rickey writes:
>>>> From: John Buehler <johnbue at msn.com>
>>>>> This pattern is fairly common and I'm stumped as to why the
>>>>> discrete function (apparently implemented as tables or
>>>>> cascading conditionals) is the function of choice for system
>>>>> designers. My time on flight simulators showed me the power
>>>>> of continuous functions - especially when multiple continuous
>>>>> functions are contributing to the outcome of any activity.
>>>> Two reasons:
>>>> 1) Players seem to hate discontinuous feedback from the
>>>> system. To them, something either works, or it does not.
>>>> This tends to reflect itself as extreme criticism of any
>>>> portion of the game system that provides a spectrum of
>>> So you're stating that, in your experience, my expectations are
>>> in the distinct minority? That players prefer on/off and
>>> success/fail behaviors?
>> Not quite, I'm saying that most of them interpret almost
>> everything as a success/fail, and given a broad spectrum of
>> partial successes treat only the top fraction as "success"
> What I'm hearing is that current games, which are predicated on
> advancement, assign no real value to less-than-optimal outcomes,
> so producing a non-optimal result is a failure. This suggests to
> me that there is even more value in reducing the prevalence of the
> 'work to achieve' style of entertainment - if we can assume that
> players only think this way because of the environment that they
> are placed into. The value is in providing a spectrum of viable
> entertainment from not just optimal results, but from non-optimal
> results as well. Perhaps eliminating the possibility of attaining
> the optimal condition is a good first step. Another good step
> would be the elimination of value by being optimal in the first
We use a hybrid. That is, success/failure is a digital signal. Then
when you succeed, there is a range of effect. The effects are
continuous functions, based on what I've termed
'effectiveness'. This includes factors such as training in the skill
or spell, attributes of the doer and possibly of the
recipient/victim, quality of materials, and many other factors, in
fact whatever is deemed appropriate.
Now, not every skill/spell/race power uses this system, but most do,
in some shape or form. Example: a flight spell won't have a
continuous, analog success for flying or not. However, the duration
it lasts does, and is based on the caster's effectiveness.
If you cast that magic missile that does 100 hit points of damage,
you either hit with it or you don't [digital]. The actual amount of
damage done goes from a minimum to the maximum of 100, and is
affected by your percentage in it, if you've specialized as a mage,
the effect that world has on that type of magic, the overall
elemental balance in the Retroverse, the caster's stats in it.
On the victim's end, the damage determined by the above formula gets
taken, and is affected by continuous functions for armor worn,
resistance/vulneratibility to the appropriate elements: be it from
race, spells, armor, etc.
The feedback provided to the caster is scaled to the amount of
damage done after everything. Cast a strong spell against a
resistant opponent, and you get told you plink! him [well in more
appropriate terms]. So the caster is doing a binary action:
success/failure of casting the spell, but the visible end result is
based on continuous functions.
I'd expect that this sort of system is being used at many
places. This may just be a semantic issue about what is a
less-than-optimal outcome. Or of course, that I based my examples on
Flight and a combat spell. However, the same is true for alchemists
making golems to protect their castles, which is a very involved
crafting system requiring planning of component armors, and
spells. It's just harder to explain. :)
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev