[MUD-Dev] Quake II has gone GPL

John Buehler johnbue at msn.com
Thu Mar 14 10:45:49 CET 2002


Daniel Harman writes:
> From: John Buehler [mailto:johnbue at msn.com]

>> One feature of this approach is that the server is the only
>> machine that has the algorithms for movement, and the client only
>> makes a statement about what it wants the character on the server
>> to do.  At no time does the client declare that the world state
>> is a certain way.

> Well you are setting yourself up for a minimum lag of several
> hundred milli-seconds from when you click to when the event is
> acted out. That's actually pretty noticeable, and I've found it to
> be irritating. The alternative approach is to have the same
> pathing/AI algorithms implemented on both client and server, with
> the server obviously being authoritative. Of course that could be
> problematic if the server has access to information the client
> doesn't.

I wouldn't be surprised if Asheron's Call does what I'm talking
about.  There's a noticeable, and very annoying, pause when starting
a character movement.  This is why I don't want players to 'drive'
their characters around, as they do in Asheron's Call.  That
'driving' process involves many interactions with the server, down
to the point of player reaction time.  I want to stay away from that
level of control and slow the pace of player reaction quite a bit.
I want the characters reacting and the players proacting - so to
speak.

And I certainly want to be able to access information in the
movement algorithms that I don't want to communicate to the client.

>> Another feature of such a system that I like quite a bit is that
>> goal declarations are being made less often, permitting voice
>> commands to be used to control the character behaviour.  This
>> leaves more time for socialization in the multiplayer environment
>> - also preferably by using voice.

> In some ways, its similar to the auto-run feature of current
> commerical games. Its not un-common to be frantically trying to
> finish a sentence before you run headlong into a monster you see
> ahead. Whilst less sophisticated than what you propose, I would
> love to see a feature where auto-run followed forest paths etc.,
> so that it wouldn't require quite so much human intervention but
> also wouldn't be a complete autopilot.

Yes, that would be a good step in the right direction (no pun
intended).  Dark Age of Camelot has trails that horses can follow
automatically, but forces players to manually drive their characters
along those same paths.  However, I want characters to be more
active.  I find that when other players just use the in-game emotes
to communicate with me that the experience is far more appealing to
me.  Bows, waves and such.  This is because the interaction is
entirely in-world.  I don't have to look at a chat window, which
really detracts from the entertainment as far as I'm concerned.

> I don't know if you have a windows PC? I experimented with voice
> control using a 'Microsoft Gamevoice' and I didn't notice any
> performance degradation in my games. This device records samples
> of you issuing various commands and associates hot key macros with
> them, it also allows you to do voice over ip with other users. I
> was a bit uncomfortable talking into it though as its irrates
> other people in the room, especially when you had to repeat
> yourself due to failed recognition :)

I haven't played with Gamevoice at all, but I'm pleased to hear that
at least keyphrase recognition doesn't overly load the machine.  I
keep toying with the idea of making a little application that uses
speech-to-text and text-to-speech to let many people talk over a low
bandwidth line without exposing their actual voices.  Seems suitable
for inter-character conversations.

I have played Asheron's Call while talking to a guy in Sweden using
internet telephony.  That completely changed my view of the role of
players and characters in multiplayer games.  I think I'll do a
separate post on the representation of players in multiplayer games.

>> Obviously, this will place significantly greater computational
>> demands on the server, and the developers will have to come up
>> with a good mechanism for somewhat more autonomous activity by
>> characters.

> One has to wonder if the majority wouldn't find the meandoring to
> the bakers amusing at first, and then an irritant later. If I just
> want to go and buy some bread and my character, who has a penchant
> for fine jewellry, stops and looks in the window of every
> jewellers on the way, will I become frustrated?  I suspect I
> might, but I acknowledge I'm a bit of a power-gamer so perhaps
> many others wouldn't.

Well, if your character has a penchant for fine jewelry, it only has
it because you set it up that way.  If you don't find that
entertaining, you eliminate the penchant for jewelry from your
character.  A character is a vehicle for finding entertainment in a
virtual environment.  This is something that I think current game
designers really don't understand.  Irrevocable decision-making is a
dead giveaway to this.

The game that I have in mind is definitely not for powergamers.
Ideally, it's like a running movie where the players prod their
characters to do certain things and the players discuss what they're
doing with each other over voice.  The purpose of having the
characters do things autonomously is to encourage players to have a
sense of separation from their character, but at the same time to
respect their character.  The separation is to attempt to reduce
strong emotional reactions from players (it's only a game, despite
claims to the contrary), while the respect is to attempt to reduce
grief use of characters.

I want players to speak of their characters in the third person, not
the first.  I want retention to be based on an interest in the life
of a character, not in an interest in crafting an alternate life for
the player.  Wish fulfillment is dangerous stuff.

JB

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



More information about the mud-dev-archive mailing list