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
From: "Chanur Silvarian" <chanur@guildsite.com>
> From: "John Buehler" <johnbue@msn.com>
>> Say, the developers create an encounter that takes 10 high level
>> characters with average gear. The powergamers will take down this
>> encounter within a month or two,. the casual gamers will come so
>> much later that the encounter have been given "farm status" by
>> the high level crowd and thus the encounter may never be
>> available to the casual gamer crowd, which will forever be locked
>> out of the Great Cave of Phat Lewts unless they join high level
>> crowd, which becomes harder and harder because the high level
>> crowd only wants people with the good stuffs from the Great Cave
>> of Phat Lewts.
>> So - If the developer do not make it challenging, the power
>> gamers will get bored and leave. If they make it too hard for the
>> casual gamers, they may create a rift between the two crowds of
>> players and eventualy the casual gamers might leave.
> This is precisely why I don't think that anything in an MMORPG
> should be static. Once the Great Cave of Phat Lewts has been
> conquered all of the Phat Lewts should be randomly instantiated
> elsewhere, creating the Wonderous Cave of Phat Lewts. If you need
> to kill a dragon to enter said cave then once the dragon dies it
> should be instantiated (spawn) in a random location rather than
> right back on the same X, Y, Z coordinate where it can be camped.
And loose the story behind WHY the dragon was defending it's cave
AND leaving it's cave wide open ? Remove the challenge of entereing
said Great Cave of Phat Lewts for the next playergroup ?
> Random spawning not only makes it impossible, but also dangerous
> to attempt camping.
It also makes the area less interesting in some ways, since the
Commander of the castle no longer sits in his commando room, the
Gate Guard is in the basement and the King decided he should swap
place with the Cook !
Mind you, random spawns is all nice and dandy for minions, but for
named MOBs and the likes, it would spoil their background story and
challenge to have them randomed all over the place. And if you only
randomize the loot tables, you'd have the kitchen boy drop the
Flaming Sword of Godslaying +1 and the King to drop a Dull Rusty
Spoon.
How fun is that ?
Also a large part of building an interesting area is to stage the
fight of the Boss, so randomization would be limited on such.
> Random quest locations make the quests fresh and new for every
> player that gets them rather than just an activity that is
> necessary to get item A. If item A from that quest is random then
> it reduces camping because you don't know what you are going to
> get and increases the "wow!" factor if you get something really
> good.
While randoming on Quests can be done nicely, I think it's an area
you have to be very careful because :
1. Level of frustration (Gahhhh .... he's not even in THIS TOWN ?)
2. Game Testing (the horror, the horror ... I've tried 18 different
ways and it still doesn't work.)
Some personalized Quests would be cool to have though.
> Within all of this randomness, of course, there should be
> weighting. The random spawn should be weighted so the dragon has
> an extremely low chance of ending up in a newbie zone (though
> myself I wouldn't make it impossible). The random item should be
> weighted to skills the character has and further to skills they
> have actually built up.
I'm all for having some interesting spawns even in the "lesser"
areas, but all within reason of how powerful they should be so you
don't end up with a newbie massacre for no good reason.
If you HAVE to make a newbie massacre, at least have a background
story. Newbie massacres can be fun though, if done proberly.
> In looking at this from the player types and how they would
> respond (this is all subjective opinion of course), the socializer
> sees little difference but there is actually an increase in
> socialization through trading/selling the randomized rewards.
True, unless the dragon spawns on top of their wedding ceremony.
Kills all the quests AND trample's the wedding cake.
Murphy's Law: Anything that can go wrong, will go wrong.
> The explorer now has MUCH more exploration to do because things
> always need to be found again, the explorer could also try to
> figure out the weighting system so they know the best places to
> look for things.
I'm uncertain on this one, because the reason to exlpore something
is often that you want to know where things are - The base idea of
randoming defies this reason entirely. I think some explorer types
would be very miffed about pure randomization.
Though if the changes in spawns would be something that changes
gradually over a period of time like, a month, then it could be
great fun for them to figure out the new systems as they evolve. But
if it's totally volatile, I think they would resent that. Besides,
having Uber_dragon_01 spawn ontop of you while you're out exploring
would not be everyones cup of tea .. or coffee.
> The killer won't see much difference, they'll still hunt and trade
> for the best equipment just as they did before.
The killer would probably not care one bit, except now he have to
interact with people in order to find out where the stuffs he wants
to kill is at today. He might not like being forced to soacialize
with people, but would probably not mind it .... much.
> The achiever will find it slightly more challenging to stay ahead
> of the pack but not greatly so, but I believe that achievers like
> a challenge (I may be wrong).
> The biggest change is that achievers cannot thwart others who are
> trying to achieve and must therefore move themselves forward
> instead of holding others back to maintain their superior status.
Which would probably be their biggest complaint about this, that it
targets them specifically and makes it harder for them to stay
ahead. They are after all Achievers and anything that can keep them
from that is evil.
And what about the fifth type of people ?
---
Jens L. Nielsen
(aka. Sheela Caur'Lir)
- 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
- 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