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
- 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
Darren Hall writes:
[I've snipped out questions that I think will aid in derailing this topic.
Feel free to start new threads]
> --- John Buehler <johnbue@msn.com> wrote:
> > I wonder if players associate 'game' with 'overcoming obstacles to
> > a given goal'.
>
> If we all agree that the point of a game is "entertainment" then the
> receipe for a good game begins with determining what creates an
> entertaining environment. Obviously, if you ask different people
> what makes an entertaining computer game, you would get several
> different responses.
That is certainly true.
> In any case,
> traditionally one of the functions of the game designer is to pick
> and choose which elements are entertaining (and fit with his game
> type or game motif) and include them in his game. By selecting
> certain elements, he is (arguably) already tailoring the game to
> certain types of players.
Sure. How detailed is a designer's understanding of how various game
elements interrelate and affect the interest level of the players that the
marketeers are selling the game to?
> A good example of this is the FPS where the the defining
> characteristic of the game is shooting your opponent many times over
> (whether he be computer generated or a real player). Players of
> these types of games no what to expect when they pick them up and
> play them. They aren't looking for a social game necessarily, but a
> more competative, hand-eye coordination style of game. The only
> social interactions these types of game allow are in multiplayer
> arenas where you can kill your opponent over and over again - and
> possibly some chat either between games or during the game (in case
> you feel like bragging, complaining, or trying to organize your team
> when playing a team game).
And those games usually don't have barriers to entertainment because they
are so focused on one form of entertainment. One experience. Everything in
the game supports that experience. In games that involve multiple
experiences, it's important to recognize that those different experiences
may have different natures. When there is a dependency between experiences,
it is important to make all of the experiences in the dependency chain of
essentially the same form of entertainment.
There was a lengthy discussion a while back about the topic of 'enforced
downtime' and why people don't like it, why it's valuable to game structure,
what people get out of it, etc. Downtime is a dependency that is predicated
in socializing. But if the 'downtime' is a dependency to achievement, it's
likely not going to be enjoyed by the player base as a whole. They may be
able to make the best of the situation, but that's not much of a statement
about providing entertainment to players.
> Both game types above describe very different types of
> entertainment, yet each is (again arguably) equally entertaining for
> different reasons.
It's not a question of whether something is entertaining. It's a question
of whether it is entertaining to a specific player. If it's not
entertaining to them, then they shouldn't be obligated to do it. And to
allay those who take things to extremes, this doesn't mean that if I don't
want my character to take damage, I don't have to. It means that if I don't
want to take damage, I don't have to engage in combat. And that means that
I'm not obligated to go into a combat area for non-combat activities. I
figure that implications are fine, but they should be closely correlated
implications, not implications that the game designer throws together to get
an emotional reaction from the players (also known as "yanking the player's
chain").
> > LOL. So having hated elements of gameplay to bring players
> > together is a good game? I don't think that
> > people are confused. I think that there is a mix of
> > entertainment and barriers to that entertainment. They stay for
> > the entertainment and hate the barriers. But which parts are
> > entertainment and which are barriers varies from player to
> > player. And
>
> > I believe that is a valuable observation.
>
> I think the crux of the discussion is "who defines what is
> entertaining or what makes for an entertaining environment".
While that may be the crux of A discussion, it's not the crux of this one.
That particular discussion will continue to be debated until the end of
time. In the meantime, designers will continue to assemble experiences that
they believe are entertaining. If they examine those experiences for
continuity of type, then the game will gain by it. And by 'type', I mean
something that players find entertaining. Just to throw an example out,
'types' might be as broad as explorer, killer, socializer and achiever. But
it's not important to categorize players so much as it is to ensure that
there is continuity of experiences according to some general 'type' of
entertainment.
> Is it the player or the designer who should be responsible for
> defining what is entertaining?
Consumers always define what the value of a product is. If we assume that
games are about being entertained, then the player decides what is
entertaining. If you're asking about who assembles the game experience,
that is best done as a collaboration. The game designer gives some amount
of rope to the player and the player decides how to hang himself with it
(which is not intended to be an endorsement of player-run worlds).
> Are challenges (or barriers) needed to make a game entertaining?
Don't mix the two words 'challenge' and 'barrier'. That is the source of a
serious misunderstanding in this thread. A challenge is a form of
entertainment. A barrier is an obstruction to reaching entertainment. To
present the same example, enforced downtime. It is a barrier to
entertainment, yet has no challenge aspect to it at all. In fact, it stands
in the way of getting to the achievement experiences that I'm probably
playing the game for.
> And if so, which barriers should you include in a MMORPG style game?
Never include barriers in a game. Ever. They are, by my definition, a bad
thing. They are not synonymous with challenges.
> There is also another element to be considered. Many designers of
> MMORPGs claim to want to promote role-play (yet ironically they seem
> to design games that require leveling or certain class types to gain
> access to different elements of the game. i.e. crafters needing to
> learn to fight to stave off aggressive monsters or player killers or
> needing to change professions, or character skill sets, several
> times to achieve some goal - both of which detract from role playing
> a certain character type) and to that end, they try to create a
> realistic world with a rich backstory, etc. In following along with
> those ideas they will create a weather system, travel system, etc.
>
> There is a fine line here between presenting a 'realistic
> experience' for the player to role play in and presenting barriers
> to entertainment.
Indeed. Realism seems to be a driving design principle in games these days,
and the crafter example is a good one. It illustrates how orthogonal types
of entertainment are dependent upon each other. I'm not particularly
concerned with roleplaying. I'm more concerned that if roleplaying is a
gameplay experience, that the designer support roleplaying by not injecting
experiences which are counter to the enjoyment of roleplaying. As an
example, having to discuss internal game statistics. That is a barrier to
roleplaying. It's not as clearly recognizeable as a boat ride, but it's
still there.
JB - Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- 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