[MUD-Dev] Re: MUD-Dev digest, Vol 1 #142 - 4 msgs

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

"Koster, Raph" wrote:

> Big difference between innovating and doing brute force analysis. Reverse
> engineering the rules of a game is mostly a matter of doing repetitive
> actions and tabulating the results in order to arrive at a formula. Lots of
> people helps tremendously for that, and it takes a fairly complex system to
> get past the brute effort they'll direct at it. Especially given how
> effectively the Web lets them share their data.

If you are talking about the RPG advancement/skill systems then how easy the
mapping process will be, necessarily depends upon the nature of the function
you use. Most developers probably choose a simple one in order to make
balancing easier? It is clearly possible to make a game system that is
sufficiently complex (or which hides the mechanisms under a layer of
"indirections" and delays) to make even suboptimal mapping practically
impossible. Another possibility is to seed each new character with a hidden
gene that will determine what kind of path will be optimal for that
particular character. To make this fun for dabblers is, of course... a
challenge.

However, I think the real issue is that most designers think about size in
terms of breadth mostly, but clearly the size of the physical world is just
as much a matter of depth. The real breadth of any given system may also be
questioned as it typically builds upon inheritance of mechanics from a small
set of classes (thing, creature, plant...). Thus, have you figured out the
mechanics of one creature then you probably can guesstimate a lot about
other creatures. It is my opinion that notions about size should include
diversity and/or range at a more "functional" level than number of different
animals, number of rooms, etc.

I would argue that in order to raise the "real size" while maintaining
control you will have to break away from the OOP paradigm where everything
is constructed on one (class/object) level. Isn't it true that almost all
MUDs are, more or less, built on top of the same conceptual framework and
that design/implementation costs/abilities result in conceptually fairly
similar systems? If so, how can existing systems tell us anything about what
is achievable under another framework and paradigm?

--
Ola
(note: it is possible to increase depth and breadth without increasing the
mathematical complexity)




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev