[MUD-Dev] Combat messages

[Adam Wiggins]

[Marian:]
> On Sat 12 Jul, Adam Wiggins wrote:
> > > Everything between { and } is what you eventually get on your screen?
> > > everything between [ and ] is a command somebody has to give,though I
> > > left the actual text of messages out, for clarity. Things between the
> > > < and > are difficult as here the game must reformat the messages ge-
> > > nerated by the commands  to string them together.  And in the case of
> 
> > Yup.  A few years ago this was a problem just because of processing time;
> > now there's no reason you can't implement it.
> 
> You can tell better than I can. What I was trying to ask was. Will it
> be possible to look reasonably like english,  and will it be pleasant
> to read? To string together phrases you usually have to reformate one
> or both phrases to make the resulting sentence flow.  I don't believe
> you should be aiming at anything resembling literature,  but to get a
> good flowing sentence might be difficult?

Sure.  I think your confusion is between a system which has some sort of
fundamental understanding of english (or whatever language you happen to
be using), and something which allows for a lot of varied phrases to be
stuck together.
This kind of message processing already exists in mosts muds today, and has
for a long time.  The person who creates the message makes something
like this:

$n smile$% as $e cocks $s $p.

This, with very simple substitutions, can end up being any of
the follow messages:

You smile as you cock your 9mm pistol.
Marian the dark-eyed minotaur smiles as she cocks a strange looking weapon.
A dark-eyed minotaur smiles as she cocks something invisible.

And so forth.  The system doesn't understand or make intelligent use of
pronouns or any other language devices; it just substitutes in strings at
certain positions.  Ie, it reaches the '$e' in the message and checks the
gender of the person doing the action.  If it's male, it substitutes 'he';
if it's female, 'she'; if it's neither, than 'it'.
Now, we can get more complex with things like 'X grins and does Y' or even
'X grins as he does Y'; this requires a less line-oriented message system,
but still not too bad.
When you get into the realm of what Nathan is describing, you have to drop
back to some slightly more descriptive messages (descriptive in terms of
the system, not in terms of the wording) which can be interpreted a potentialy
infinite number of ways.  Thus, instead of just sending a straight text message
which says '<object name> collides with <object name> and <verb>s' it actually
sends a message to the *system* describing the nature of the event.  Each
interpreter object (ie, player's bodies) can then decide to display the
message any number of ways.  Thus you have the charred meat example shown
below, or the grenade exploding against the bulkhead becoming a dull thump
and vibration from the other side of the wall.  There's certainly more than
one way to handle this at the implementation level; you could have the wall
actually act as a filter for the event, so that the message which reaches
the player-interpreter object is just 'dull thump and boom' which is then
processed through the player's senses; or you could just ignore the message
on every object without an interpreter and then have the interpreter of
each player try to figure out how the message will actually reach the player.
Also, since you're not sending the messages 'immediately' (meaning you might
wait as long as .1 seconds before sending the message) you can concat stuff
together.  Thus, player recieves an event about Bob grinning; .005 seconds
later the player (object) receives an event about Bob cocking his gun.
At this point no output has been sent to the screen.  Another .005 seconds
elapses, the system decides to queue up the messages and send them out.
Finding that both 'Bob grins' and 'Bob cocks his gun' have the same actor,
it gets stuck together and sent to the user as 'Bob grins and cocks his gun'.

> > > Krr*ganfth being hurt makes him scream as well.  Also it introduces a
> 
> > Uh, well of course.  Maybe I've been out of the mudding community for
> > too long, but shouldn't someone getting hurt cause them to react as
> > they actually would? *boggle*
> 
> I'm not saying that they shouldn't. Just that the system must do it, and
> in the example did.  I have not yet seen any game that actually takes it
> to that level of reality.

*nod*, well, that's what we're here to fix. :)
Actually, I have seen several attempts at attempted pain-modeling, but
all were very crude.  Ie you take 20% or more of your (ick) hit points,
and your character drops to the ground, screaming in pain and basically
unable to do anything for X number of combat rounds.  Of course, trying to
tack pain-modeling onto a completely non-health based combat abstraction
like hitpoints is pretty pointless to my mind.

> again, not the fact that it can't be done, but that, to improve the im-
> mersive quality of the combat descriptions it must be done. What nathan
> wrote included this, and it's not something I've ever seen done.  I can
> not tell if it is simple or difficult, that's what you guys are good at
> but I wanted to point out that the example implied this type of message

Yes, it's difficult, but not as difficult as it looks.  Mainly it involves
starting your mudbase from scratch and re-thinking basic message-handling
and so forth in such a way as to make it possible.  Trying to do Nathan's
message system on an existing codebase would probably be about as much
fun as a dental appointment.  In the end you'd probably end up having
to rip out all the basic stuff and re-doing it for anything more complex
than simple concatination.

> I snipped the comments because this was an example of how things work
> nowadays.  Not how I think they should.  The above is what you get if
> each action produces its own message and sends it to each player yes?
> To get from that to something like Nathan wrote is the real challenge

Yes, there's two sides to this.  I think you could probably implement
'You grin and cock your rifle' on a standard mud by simply delaying the
messages and allowing some filter to shove them together before output.
Doing the sensory stuff is a whole other ball of wax.