[MUD-Dev] Quake II has gone GPL

[John Buehler]

shren writes:
> On 6 Mar 2002, T o F wrote:
>> On Tue, 2002-03-05 at 18:16, Joshua Judson Rosen wrote:

>> But for example if the user asks to go on his right, then:

>>   - the client suppose he can do it, so go on the right

>>   - alert the server of its action

>>   - if it's ok, the server retains the new position, else it sets
>>   the correct one and sends it to the client.

>> I suppose I would do it this way...

> By and large, with modifications, I think everybody does it this
> way.  Blizzard's Diablo II does, from all observations.  I once
> wrote a guide to lag when playing Diablo II on battle.net, which
> you can read to find out some of the flaws to this system:

>   http://www.io.com/~shren/.lag.html

> Most notably, the ever-famous snap-lag, where the client decides
> you walked from X to Y, then shows the player walking from X to Y.
> The server decides, for whatever reason, that you can't walk from
> X to Y, so sends you an override message telling you that you're
> still at X.  From the player's view, they walk from X to Y then
> snap back to X, which can be very confusing untill you realize
> that the server thinks that there's something in the way.

> If the server and the client can both handle pathfinding equally
> well, then the system works very well.  But to do this, you have
> to let the player avatar walk through any dynamic object - other
> players and monsters, for instance.  Note that most FPS games let
> you do this.  Subspace, one of the best multiplayer internet games
> I've played, makes everything dynamic transparent except for
> bullets, and by default has a pretty low rate of fire.  (The game
> itself encourages you to fire conservatively, as firing lowers
> your shields a little bit per shot.)

An approach that I'd like to see is to have the client only indicate
the destination and to have the server work out the path and notify
all clients where the character is as it works through that path.
The assumption behind such a system is that the player isn't driving
the character around as with current games.  Instead, the player
makes statements about goals for the character.  While 'move here'
<click> is a statement of a goal, it's a very low level one.  I'm
thinking instead of goals such as 'go to the bakery', where the
bakery is on the other side of town.  While on the way to the bakery
(walking), the character steps over mud puddles, runs from cover to
cover during rainstorms, waves to characters that it knows well and
hasn't seen in a while, steps aside for ladies, etc.  All of those
behaviors would be part of the player-declared behavior of the
character, so the player controls the behavior generally, but
doesn't have to act out every little movement.

Even in combat, the idea would be to have the client only send goals
to the server.  'Give ground', 'push forward', 'support Bob', etc.
This is a style of play where the player's skill is involved at a
higher level, leaving the nitty-gritties - the realtime behavior -
to the server, which is partially driven from the player's declared
preferences.  So when somebody swings a sword at my character's
head, my character can duck, dodge, parry or block as is appropriate
to the situation and according to my preferences.  Similarly, if my
character sees an opening and I've stated that I want my character
to push forward, the character will attempt to exploit that opening.

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.

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 behavior.  This leaves
more time for socialization in the multiplayer environment - also
preferably by using voice.

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

JB

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