November 2003
- Fwd: Web vs. Java client Eric Merritt
- Fwd: Web vs. Java client Mike Shaver
- MUD-Dev Digest, Vol 6, Issue 3 Alex Chacha
- MUD-Dev Digest, Vol 6, Issue 3 Zach Collins {Siege}
- java clients (was: MUD-Dev Digest, Vol 6, Issue 3) ceo
- MUD-Dev conference 2003/2004 Brian 'Psychochild' Green
- Biz: Game support Peter Tyson
- Biz: Game support Damion Schubert
- Biz: Game support Daniel.Harman@barclayscapital.com
- Biz: Game support Michael Sellers
- Biz: Game support John Erskine
- Advantage for outside skills T. Alexander Popiel
- Advantage for outside skills Jeff Fuller
- Advantage for outside skills Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment szii@sziisoft.com
- Removing access to entertainment Patrick Dughi
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment Hans-Henrik Staerfeldt
- Removing access to entertainment apollyon .
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Peter Keeler
- Removing access to entertainment Matt Mihaly
- Removing access to entertainment Amanda Walker
- Removing access to entertainment John Buehler
- Removing access to entertainment Daniel.Harman@barclayscapital.com
- Removing access to entertainment John Buehler
- Removing access to entertainment Michael "Flury" Chui
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Daniel.Harman@barclayscapital.com
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Jeff Crane
- Removing access to entertainment John Buehler
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment Chanur Silvarian
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Michael Sellers
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Matt Mihaly
- Removing access to entertainment Kwon J. Ekstrom
- Removing access to entertainment Brian Lindahl
- Removing access to entertainment John Buehler
- Removing access to entertainment Damion Schubert
- Removing access to entertainment John Buehler
- Removing access to entertainment Marian Griffith
In <URL:/archives/meow?group+local.muddev> on Wed 03 Dec, Brian Lindahl wrote:
> On Fri 14 Nov, John Buehler wrote:
>> This is an observation about some graphical games that I've
>> played through the years, and a pet peeve that has been building
>> all that while. I don't know if text games have this manifested
>> in any way, but the graphical games sure do: they remove my
>> access to entertainment as part of the normal operation of the
>> game.
>> Example 1: Nighttime and rainstorms.
>> Example 2: Mesmerization.
>> Example 3: Blindness.
>> Example 4: Slow travel in large worlds.
I can not fully agree with any of the following. Certainly not as
long as it is phrased in terms of (all) players ... or simi- lar
terms that amount to that. Nor do I agree with the original post.
> 1. I think night time and rainstorms become challenges to overcome
> - granted it does depend on the implementation. But at night,
> wouldn't it be best to have a light? Ok, so you get a light, where
> do you get this light from? This provides an avenue for
> entertainment and a means of overcoming the challenge. Rainstorms,
> I'm not sure why this removes access to entertainment. If you're
> talking about losing footing on dangerous terrain, why not get
> some boots/shoes with better tread? Again, a method of overcoming
> a challenge.
There are a great many reasons both for playing a game and for
incorporating certain features within a game, and then there are
many motivations to do and like things. Overcoming the game
challenge is only one of those, and its importance likely varies
from one player to the next. There will, undoubtedly, be players who
appreciate the additional challenge as there are players who dislike
the disadvantage darkness or other reduced visibility gives them.
There will also no doubt be players who enjoy the added uncertainty
over precise control over what happens within the game. Broadly
stating that darkness and rain is 'no fun because you can not see
everything there is to see' is far too simplistic.
> 2. I can see why people dislike mesmerization. No one likes not
> being able to do anything at all.
I am sorry, but I disagree here. Personally I may not 'like' to be
paralysed within a game, but I very much enjoy the sense of thrill
it gives. The sudden lack of control and uncertainty can be, in a
sense, quite appealing. If it is overdone then, like any other
thing overdone, it gets to be annoying, but as a tool of a game
designer it is one of the most powerful ways to invoke strong
emotions in the player.
> 3. Blindness. Most games have a method of blindness. I think that
> an implementation of activity while being blind (albeit not at the
> skill level of full vision) is key to overcoming this challenge,
> if not curing the blindness altogether.
See above. Blindness is essentially the same as being paralysed and
has many of the same benefits. In addition it encourages a social
dimension in a game, since players must either wait out the loss of
sight, or find some other way to overcome it, and this usually will
mean enlisting another player to help. This is a game design issue,
not a player enjoyment issue. Just like 'enforced downtime' is, and
disjunct class capabilities so that no single player can stand on
her own entirely.
> 4. Slow travel in large worlds. Again, I think this is a serious
> implementation flaw. Horses, carriages, etc. are a must need, as
> is automated transportation so you can carry about something else
> while you travel.
Quick travel, as pointed out before, is a potential danger to
coherency of the game. If too easily accessible it carries with it
the significant risk of bleeding dry the game experience as
originally intended. As Raph Koster pointed out players are
motivated towards convenience not experience. In mud terms it is
most likely to lead to dead zones which are no longer the most
optimal. For a game designer that is a waste of resources. For the
player it threatens the social fabric of the game, since everything
is ony a few mouseclicks away, and the game can all too easily
deteriorate into a 'city of thousands of strangers' instead of a
'village of hundred familiar faces'. The social experience is much
stronger in the second case.
Also, if the game world is big, it should *feel* big. The key is to
make it also feel *alive*. If traveling through the world is
intrinsicly entertaining, or at least interesting, then it will not
matter that it takes a long time. What if traveling to another town
takes three of four real days, as long as plenty of things happen
along the way, and the group making the journey can decide to leave
the common path to explore a forest, or a set of caves, and when
encounters with hazards scaled to the group can happen at any given
moment? Currently games are set up with encounters in static places
and players forced to travel to them. This is not the only way that
games can be set up. Encounters can trail players as they move
around. Minor threats can grow into major ones if they are not
dealt with soon enough (e.g. an orc tribe setting up camp near a
player city will eventually grow into a real threat to all players
until a large force of players removes it, or the orcs level the
player city of course). This kind of organisation can make
traveling through the game decidedly 'fun' as well as challenging,
and not that many players would, I think, complain even if it takes
a lot longer than currently considered acceptable to travel from one
spot to another.
It is never good to define a problem in terms of current
implementation . That is one of the first things you learn when you
study architecture, but it really applies to every form of design.
Marian
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...
Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey - Removing access to entertainment John Buehler
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Corpheous Andrakin
- Removing access to entertainment Darren Hall
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Chanur Silvarian
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Jeremy Neal Kelly
- Removing access to entertainment Corpheous Andrakin
- Removing access to entertainment John Buehler
- Second Life's customers own the IP of their creations Mike Shaver
- Second Life's customers own the IP of their creatio ns Christer Enfors XW {TN/PAC}
- Second Life's customers own the IP of their creatio ns Lee Sheldon
- Second Life's customers own the IP of their creatio ns Christer Enfors XW {TN/PAC}
- Second Life's customers own the IP of their creatio ns Jeff Thompson
- Second Life's customers own the IP of their creations Corey Crawford
- Second Life's customers own the IP of their creatio ns Corpheous Andrakin
- Second Life's customers own the IP of their creatio ns Ren Reynolds
- Second Life's customers own the IP of their creatio ns Daniel.Harman@barclayscapital.com
- Second Life's customers own the IP of their creatio ns Crosbie Fitch
- Second Life's customers own the IP of their creatio ns Amanda Walker
- Second Life's customers own the IP of their creatio ns Ren Reynolds
- Second Life's customers own the IP of their creatio ns Ola Fosheim Grøstad
- Effects of skill-imbalances? Joshua Judson Rosen
- download-barriers Joshua Judson Rosen
- download-barriers Matt Mihaly
- Language and platform for Text MUD server =?koi8-r?Q?=22?=Andrew Batyuck=?koi8-r?Q?=22=20?=< javaman@mail.ru>
- Language and platform for Text MUD server Miroslav Silovic
- Language and platform for Text MUD server Kwon J. Ekstrom
- Language and platform for Text MUD server Patrick Dughi
- Language and platform for Text MUD server Alex Chacha
- Ragnarok Wisdom Michael Tresca
- Java on Linux gbtmud
- Java on Linux Artur Biesiadowski
- AS TECHNOLOGY SCATTERS VIEWERS, NETWORKS GO LOOKING FOR THEM Michael Tresca
- Breakdown of Java users Christopher Kohnert
- Second Life's customers get [copyright?] of their creations Joshua Judson Rosen
- Rubies of Eventide shutting down Mantees de Tara
- Rubies of Eventide shutting down Zach Collins {Siege}
- Rubies of Eventide shutting down Sheela Caur'Lir
- Rubies of Eventide shutting down Michael Sellers
- Rubies of Eventide shutting down Koster, Raph
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction David Love
- Dopamine and addiction a t y mcguire
- Dopamine and addiction Lars Duening
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction Rayzam
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction Rayzam
- Dopamine and addiction Marian Griffith
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Eli Stevens
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Jessica Mulligan
- Trusting the client, encrypting data ceo
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Peter Harkins
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Crosbie Fitch
- Trusting the client, encrypting data Richard A. Bartle
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data ceo
- Trusting the client, encrypting data J C Lawrence
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data Paul Schwanz
- Trusting the client, encrypting data Vincent Archer
- Trusting the client, encrypting data Felix A. Croes
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Alain Hamel
- Trusting the client, encrypting data Richard A. Bartle
- Trusting the client, encrypting data Alex Chacha
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Crosbie Fitch
- Payment Transaction Processing altug
- Payment Transaction Processing Sean Middleditch
- Payment Transaction Processing Jason Smith
- Payment Transaction Processing stanza
- Payment Transaction Processing Matt Mihaly
- Payment Transaction Processing Gary Cooper
- Payment Transaction Processing J C Lawrence
- Payment Transaction Processing Gary Whitten