[MUD-Dev] Geometric content generation

[Kwon Ekstrom]

From: <Daniel.Harman at barclayscapital.com>
> From: Kwon Ekstrom [mailto:justice at softhome.net]
>> From: "rayzam" <rayzam at home.com>
>>> From: <Daniel.Harman at barclayscapital.com>

>>>> Perhaps the easiest way to approach balancing is to throw out
>>>> classes, make everything skill based, and allow reallocation of
>>>> skill points. That way players can explore the system, discover
>>>> the lesser skills, drop them and stay happy. It also allows you
>>>> to modify skills without players getting too upset since they
>>>> can always add and remove it. Hmm, isn't that what SWG is doing
>>>> anyway?

>> I don't like the idea of skill points... it would seem to
>> encourage the min/maxing behavior by giving players specific
>> control over what they can and cannot do.

> Well I'm from the Hook school of game design when it comes to
> these systems (at least what I think is his school ;). I believe
> that some players will game a system whatever you do, and that if
> you don't fully understand the system, it will likely be to the
> detriment of those who have a less analytical approach. Following
> on from that I don't see why people who were lucky when they
> picked their character class or whatever, at the beginning, should
> reap the benefits of having a better character for the rest of the
> game.

That's the point, some players always try to find a way to get an
advantage (I'm one of em), the system is designed to work off of a
simple interface (using skills) that any mudder is familiar with.
The complexities of it are all beneath the surface.

As for people who picked better at the start should have a better
character or class for the rest... that's not an issue since you
don't choose a class of any type, sort, whatever... all players are
assigned some basic skills for each of the major knowledge spheres,
and gain in knowledge through use.  What I don't see is why a player
should reap benefits from bad decisions...  they should be able to
recover from them, but not benefit from them other than the
knowledge of it being a bad decision.

>> I've seen similar systems, and it seems to artificially create
>> skill diversity on a character.  I'd prefer to give the character
>> a reason to have those skills and require them to draw from a
>> single pool.  resource management should be an aspect of any
>> skill based system.

> I'm not sure I understand how the system I mention 'artificially
> create(s) skill diversity' anymore than your opposing sphere

By distributing points into different areas to be filled forces them
to use points in those area, which may or may not be a form of
progression that the player wanted to from the start.  IMHO players
dislike being forced.  The opposing spheres, the player chooses what
skills they want to use and in turn gain similar skills.  It
encourages diversity since some spheres compliment each other, but
discourages too much diversity with spheres that directly oppose
each other.

> concept. Whilst perhaps logical in some limited instances,I see no
> reason why learning first aid should negatively affect another
> skill I may have already aquired. Of course it is a game, so I
> don't think realism is an overriding priority - as opposed to
> internal consistency which most certainly is.

Well in reality, skills upon themselves don't negate other skills,
although people do forget things over time... and the time necessary
to develop and hone skills is limited.  I think that too many game
development teams put too much stock in reality, it's a game.  There
should be enough reality to make things recognisable, but most
importantly it should be entertaining.  I agree consistency is the
key to any system or suite of systems.

> A seperate pool for trade skills is again something conceived to
> prevent people from gaming in such a way that it will be
> detremental to both their own and others enjoyment. If its from a
> single pool, people end up creating trade mules which is not only
> boring for them, but encourages players to be self sufficient
> compounded by the fact that the mules (and thus the best
> tradesmen) will only be on briefly to fashion things rather than
> properly played.

I've encountered similar problems, I haven't talked much about my
plans for fashioned eq, but it will require a wide amount of
diversity to be able to fashion the best equipment in the game.
Since the opposing spheres discourages too much diversity by
requiring the players to improve their skills evenly, that would
take a long time to reach the oppropriate knowledge levels to
accomplish such a thing.  Any player willing to put that much time
and effort should be able to use it imho.

> Having said that, encouraging people to work together is key and
> careful thought needs to be put into a system such as mine to make
> sure there was interdependency between players.

*nod* Agreed, encouraging players to work together towards a common
goal is high on my priority list.  The skill system is designed to
encourage it in some ways, although I have other systems more suited
to the task.

> The real problem with my system, is that people will often want to
> make a generalist and then be miffed that they can't be the best
> at anything. Thats where the reallocation aspect is again a
> helpful factor. In the end, the main objective is to create a
> system which acknowledges the difficulty of designing balance, yet
> doesn't penalise the player for our inevitable design mistakes.

That's the beauty of my system, you can always change what your
character is by simply using different types of skills, you can
always build upon what you know... I'm a believer that the longer a
person players the more benefits they should have.  There will be
some powergamers out there who may find a few loopholes to a quick
position of power, but the ability to do that will be harder than on
a flatter class based system.  The problem as
always will be to keep up with player progression.

-- Kwon Ekstrom

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