[MUD-Dev] Better Combat

[John Buehler]

David Kennerly writes:
> John Buehler wrote:

>> My metric is every 3 seconds during an 'intense' activity.
>> Certainly less frequent control during other times.

> I like what you've described.  As far as pure timing goes, 3
> seconds is similar to or even faster than many roles of combat in
> MMPs.  For instance, when I play a midlevel priest in Dark Ages, I
> heal and buff/debuff significantly less often, on average, than
> once each 3 seconds.

The three second metric is a lower bound.  I wouldn't want to see
people doing things any faster than that.  Thus the 'intense'
activity comment.

> Yet I can see how you would like someone to design a game that
> delegates low-level decision making.  For instance, maybe a player
> does not command heal or buff/debuff explicitly, but only
> selecting a preference, such as ordering the options "buff the
> team", "protect myself", "debuff the enemy".

The control system is intended to automate the span of activities
from realtime/twitch action in combat to a point where the player
can comfortably issue commands to a character while paying attention
to the overall action.  If the role of magic in your game is such
that spells can be cast at twitch speeds, in reaction to changing
events, then it would be a natural part of the automated control
system.

"Protect myself" is implicit in your control strategy.  It's a
question of whether you want to duck, dodge, run away, block, etc as
your preferred means of self-protection.  If you have twitch-speed
magical means of protection, those could be included in your control
strategy.

If buffing and debuffing are twitch-speed actions, then it would
again go into your control strategy.  I'm assuming that it is not.
That those actions take a few seconds to complete, and so can be
left to the player to manage.  Having a sequence of actions
precanned by the player is just a macro-level function that could
easily be added to the control system - including interruption and
resumption when mandatory twitch-speed actions are needed.

For example, if your character is casting the second of eight spells
and some monster that the fighters haven't kept at bay takes a swing
at your character.  Your character ducks and dodges, interrupting
its spellcast.  The fighters get back to keeping the monster
occupied and your character can then resume what it was doing.  The
character works on a task list, after a fashion.

For the record, I don't see mages fitting into the usual class
structure of damage dealing and character enhancers.  I want them
involved orthogonally to everything that other classes do.  I've
mentioned that elsewhere.

> Final Fantasy Tactics had something like this, but not as
> high-level, or infinitely diverse, as you hope for.  Although even
> that is higher-level than Final Fantasy XI.  Yet it was a team
> management game.  Shattered Galaxies manages many units so is
> also, necessarily, higher level management, but its higher-level
> management of multiple units does not encourage socialization
> more.  As far as I can tell.  Maybe it would with only one unit to
> control.  Or would it just be dull?

A management interface doesn't create an opportunity for
socialization, especially if the player feels like he's herding
kittens.  I know that Age of Empires always gave me this feeling -
some unit somewhere was doing something that I didn't want it to do.
It is a critical part of the design that characters must be able to
operate completely autonomously without fear of something extremely
stupid happening.  Perhaps undesireable, but nothing catastrophic.

Autonomous operation is critical because the control system is
intended for both PCs and NPCs.  Further, if a game wants to permit
unattended PC activity, including travel, then the control system
ensures that the player's character will continue to react to the
environment in a reasonable way.

>> And this is also an example of designers not knowing what's going
>> to happen.  They just give the players some tools to find
>> entertainment.  They don't say how the tools fit into the game.

> *scratches his head* Are you talking about a dynamical system?
> Since it is a computer game, there must be something somewhere
> that ensures that these "improvisation" cases do happen, instead
> of a software crash happening.  And that something somewhere
> requires specification.

I don't mean that the software is going to be self-modifying or any
such exotic thing.  I only mean that when an encounter begins, the
designers won't know if an NPC will pick up a rock and throw it or
if the NPC will charge or run away.  The software is constantly
factoring in the environment and the changing circumstances, so the
designers can't know how an NPC will behave.  They could do an
investigation by looking at the code and data after the fact and
figure it all out, but they can't predict it.

This is said in acknowledgement of the fact that players reverse
engineer everything.  If the designers can predict what will happen,
then eventually the collected body of players will figure it out.
Similarly, if the designers can't know what's going to happen,
perhaps the players never will either.

> For it to be a wise design choice, it also has to be more
> efficient than a non-"improvised" solution.  Sorry to quote,
> "improvisation" but used, I can't make heads or tails of it.  Is
> the computer improvising?  Are the players?  If the computer is
> "improvising", what system defines its method?  Does the computer
> use short-form or long-form improvisation, Whose Line is it Anyway
> or Second City style?  :)

Improvisation is a way of identifying the utility of an item that is
not normally used in that capacity.  A chair as a shield, etc.  A
chair's ability to be used as a shield is something that the
software will already know.  Whether or not the control system
causes an NPC to choose to use it in that capacity or not is subject
to the algorithms of the control system.

Put a faction check into the decision process and perhaps the
character doesn't want to annoy the owner of the chair.  Put a
weight check into the decision process and perhaps the character
doesn't want to carry around that 30 pound metal chair.  It CAN be
used as a shield, but it is a poor fit for the character's needs.

Perhaps the character will do the mountain moving to Mohammed and
stand behind the chair instead of picking it up.

>> Conceivably, those presets could be specific to a number of
>> opponent types - or even specific to an opponent: NEVER run from
>> a bear.

> With well-chosen preset management system, I speculate this would
> be fun.  While it is yet more overhead, I think it augments the
> rest of what you wrote.

Sure.  And blue-sky stuff permits that.  The volume of data and
processing that I'm throwing around here is massive.  This system is
not viable for a massively multiplayer game today.  Well, unless
each player is charged considerably more money to support the
massive infrastructure costs.

>> It was meant to imply it.  It doesn't guarantee it, but I believe
>> that when players are not obligated to do something by the game,
>> they'll look at their remaining entertainment choices and
>> voluntarily engage in one or more.

> So it doesn't impede socialization, which is shade different from
> a design that encourages socialization.  But anyway, I'm splitting
> hairs.  I agree that I would socialize more and I suspect many
> others players would, too.

I think the important point is that players would socialize purely
out of a desire to.  Not a need to.  I don't really want to
encourage socialization so much as avoid opposing it.  I don't want
to encourage combat, encourage magic, encourage crafting or anything
like that.  I just want the game to permit players to do the things
that they enjoy, within reasonable limits.

When players are micromanaging a character every moment of the game,
then the only time left to do socialization is when they aren't
doing anything in the game - downtime.  I'd rather that the game
permitted my character to do something autonomously or
semi-autonomously so that I can consider doing other tasks that
don't even involve my character's hands, feet, equipment and
location.

>> When the players expect to create bead necklaces, sure.  The
>> marketing has to avoid walking into the trap of promising hero
>> status,

> Sure.  Yet, how large would you guess the market is for players
> who want to pay a monthly fee to not accumulate status?  Even most
> standalone games have a save game feature.  Even fighting games,
> when ported to console, implement methods to accumulate status,
> such as missions in SoulCalibur on the DreamCast.

The monthly fee isn't to NOT accumulate status.  The monthly fee is
to experience something enjoyable and engaging.  The appeal is not
to status, but to experience.  I just don't believe that the purpose
of having a multiplayer social space is so that people can compare
their achievements.

JB
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev