[MUD-Dev] Re: DIS: Client-Server vs Peer-to-Peer

Ling K.L.Lo-94 at student.lboro.ac.uk
Fri Dec 11 13:53:43 CET 1998


On Wed, 9 Dec 1998, Nathan F Yospe wrote:
> On Tue, 8 Dec 1998, Ling wrote:
> :On Thu, 3 Dec 1998, Niklas Elmqvist wrote:
> 
> :I can't claim to be a budding game designer if I haven't at least thought
> :about all the different types of games possible! :)  I think JCL is
> :referring to my thoughts about teamwork and how games orientate around
> :"Only You Can Save Mankind".  I'm all in favour of wingmen running around
> :getting in your way when you're about to do something that's quite vital
> :and would probably save their butts too (which happened to me whilst
> :playing some game last week).
> 
> Pratchett is genious. I couldn't help thinking about Nintendo "Starfox",
> and the "teammates" you have to save when I read that. I've had a little
> bit of thought in the same direction, especially with the teams for GURU
> and the battalions for Singularity 2. Sing 2 shouldn't have that many of
> the NPC teammate types...

Okay, actually I'd rather have teammates that helped me. :)  The problem
with coding this is providing decent interface for the human player to
examine and order the teammates and a conjugate interface for the teamates
to gauge the human player.  It's usually the latter that's ignored
resulting in a one way flow of information.  That's why all-human teams
work better, they tell each other how they are and what each of them are
going to try and do to achieve the goal. Unfortunately this is trudging in
AI waters and the word blackboard.

> Unless you weren't refering to the Pratchett book by that name? There is
> some need for thought in the area of goals and division of glory when in
> a massively multiplayer setting. I used to approach it with split story,
> multi-continuity approach (see my old posts on story fragments), but now
> am looking at regenerating clones of the same story in a new world, with
> new characters and settings. The variables for this sort of thing are at
> least dynamic enough for some "freshness" with a cloned story. The least
> recognizable aspects are all that remain... the old plot/quest elements.

I was referring to both the genre of one vs. the world and the book; 
trying to be clever. :)  I admit that the big attraction of a lone saviour
is that of ego boosting.  How ironic given that employers look for team
spirit.  Is it coz these 'team players' actually wanna kick their
colleagues' butts with a tac-nuke?

Looking back at some of my doodles for game designs and evaluating them 8
yrs on, they probably wouldn't give as much satisfaction as the lone wolf
type games coz they share out too much of the glory.  Games like
Battlezone lets you keep the kudos coz the player *built* the AI units in
the first place.  You own those units and they owe their existance to you. 
The same effect wouldn't be there if some 'higher command' allocated a
squad for you to play with.

> :> Not sure what you're getting at with "orientation" here, but I tend to
> :> agree on the cyborg bit (if I understand you correctly). Dying as a GI in
> :> an Omaha beach scenario would probably transfer your control to another
> :> soldier in the same unit (or at least someone of the same rank and class) 
> :> -- if the cyborg did not take care of diving into cover automatically, the
> :> player might find himself walking through a line of characters in a few
> :> seconds' time if that MG-42 opens up at an unfortunate time. 
> 
> :Ever played X-Wing vs. Tie Fighter?  In that, you pilot a craft in a
> :squad.  Dying means you are shunted to another craft in the same squad. 
> :When this does happen, I usually take at least a second to check where I
> :am, my status, who's on my tail and ohmigosh I'm about to fly into a Star
> :Destroyer!  (that's actually happened)  In any case, it's worth looking
> :into the game to see what commands for wingmen has evolved over the years. 
> :Stuff like attack my target, scram and target the unit that's targetting
> :my target. :) 
> 
> That could be fun... I've never really considered doing something like a
> body-switch on death. If a character has a clone waiting, the mind moves
> into the clone in whatever clone-bank is being used. If not, the player,
> bereft of one character, is prompted to animate another character from a
> list of currently owned characters, or create a new one. It might be fun
> to allow the player to select a comparable NPC at the time of death, but
> not randomly.

The body-switch on death used in the above game had a defined limit, you
could only switch so long as there were squad members surviving.  The was
a sufficient disadvantage in switching anyway, the size of your squad
drops down a notch, the craft you drop into is probably in multiple pieces
and it didn't reflect well on your combat record.

I wouldn't recommend body-switching for 99.99% of muds.  It just "doesn't
feel right" as well as having dire consequences on the gameplay.  JCL's
rather extreme mud being in that 0.01%. 

> :For muds, it's different, I've planted people in other parties to see what
> :they're doing whilst I go around setting things up for an ambush.  We did
> :shortcut coz the plant is usually a friend who's playing in the same room
> :as me.
> 
> And this is the reason for the player accounts and the fact that I have
> in the client a bit of code to prevent multiple running versions. There
> would have to be a second computer on a second provider acting as the
> plant, for someone to pull this off. That, or two people with a
> telephone... 

I don't see how this stops a friend with a genuine account spying for me,
which is what I meant above.  We were in labs, each computer had a
separate internet address.  I'm in labs atm, still haven't bought a PC. :)

Random thought spurred from your passage:  Imagine grouping the starting
point of players according to their geography.  Kinda like what UO does
(implicitly due to lag) but imagine if each server was just an area in one
large world.

  |    Ling Lo (aka Lethargic Lad)
_O_O_  kllo at iee.org






More information about the mud-dev-archive mailing list