[MUD-Dev] Geometric content generation

[Eric Rhea]

On Thu, 27 Sep 2001, Matt Mihaly wrote:
> On Wed, 26 Sep 2001, Eric Rhea wrote:

>> There does appear some interesting properties emerging wherein
>> user driven content is concerned. e.g., It is not adviseable to
>> have players build houses on their own choosing unless the world
>> state can accomodate for it in some way. This leads me to believe
>> there are at least some core principles that might be shared and
>> an attempt to enumerate them might be in order (as I haven't seen
>> an attempt anywhere else).

>>   - Players should not have free roaming placement of buildings.

> Depends on what you mean by free-roaming. Should they be able to
> build a castle on the highway? No. Do I see a problem with letting
> them build their buildings in the middle of a 100 mile-wide
> savannah? Nope. Currently in Achaea, we only have custom housing
> you pay for, but when we put in an automated housing system, there
> will be few restrictions on where you can build (well, aside from
> obvious ones, like no building stone castles in the middle of the
> ocean).

>>     - They should be able to rent or purchase buildings.

> Boring. Players want to choose their own location for housing.

They want to choose a location for their housing, but given the
choice between no housing, or selective housing, I'm sure they would
opt for selective housing. Many states cannot handle it and I'm
saying those that could handle selective housing should make use of
it.

Some systems provide a calculated region wherein a player can locate
their house, which encourages town like growth, but it also wrestles
with the same kind of attitude that you see where one may only rent
or buy already existing housing. "I can only build around here?! 
Lame!"

If there were a gradient sketched out, and some data collected from
players, I seem to think that we would see the rent/purchase of
existing housing infrastructure be pretty darn close to
rent/purchase/build of housing within a given area.

>>   - Players should not be able to remove object collections of
>>   another user.

> That's an awfully broad statement and one that I disagree with if
> presented as any kind of general design rule. Lots of PvP fun to
> be had there.

Good point here. I was considering only those objects within a given
region, to restrict players from doing certain types of activities.
This has the potential provide ample opportunity for rogue-like
activities.

>>     - If the larger consensus is that an object is troublesome,
>>     it should be returned to the player's inventory.

> How would you establish that?

This ties into the moderation idea that posited up earlier in the
discussion, which appears to have not been tried quite yet. On one
end, you'll have certain aesthetic police watchers who maintain the
quality of the community and on the other end you have griefer
police you ensure that you'll never have any visually pleasing or
logically flowing works within your housing area. I'm just not aware
of any moderation type system that are capable of working - inside
the game.

That said, I'd like another stab at refining these items of user
driven content generation in the effort of nailing down a
generalized set of principles for this and to refine the items
themselves.

Generalized design rules when implementing content systems driven by
players:

1. Object Placement
===================

Players should have the capacity to place objects within qualified
areas. Flipping this around, there should be areas wherein objects
can not be placed by the players. One would not want a player to
place a castle in the ocean without some good logistical sense as to
why that castle is there.

Caution:

  Do not permit the players to build upon any area that might grant
  them the capacity to turn the region into a mob factory farm ( an
  industrial unit wherein the player consecutively farms a certain
  type of item through the tactical advantage of having structures
  to interfere with the ecology of the area)*.

2. Variance in Region
=====================

The regions in which an object may be placed should be aware of what
type of object is being placed and be sensitive to allow or disallow
placement of that object. E.g., Not all regions should support the
construction of houses, but there should exist some regions that
support the construction of minor elements, such as scarecrows.

Caution:

  Regions should be carefully calculated so as not to offbalance the
  environment of the game. If region A is designated as a cornfield
  and region B is designated as an advanced city zone, it might be
  curious to your players as to why in the middle of a city a
  cornfield blossums.

3. Object Interaction and Players
=================================

There should exist modes of interaction between the player placed
objects and that of other players. E.g., tolerating theft of certain
objects between players, object enhancement for defensive or
offensive capability against other players, or the enrichment of
narrative by allowing objects to contain notes, stories, or other
collection of words from the words smiths.

Caution:

  In general, you would not want player placed objects to adversely
  affect NPCs.

----

Potential reasons for using player driven content contribution:

  1. Potentially lower overhead than using in house content addition
  (anyone able to verify this with some data?)

  2. Larger population of players who do play these type of games
  would find the ability very attractive, potentially leading to
  higher player retention or to a higher percentage of new players
  looking for this type of atmosphere.

  3. Adds a more varied culture to the gamestate, whereas system
  driven content addition does not.

And if

  http://www.enkanica.com/MUD-DEV/Research/EQ/Data/EverQuest_Good_andthe_Bad.htm

is any indication as to what *might* make a game successful, varied
content is one item on the list of good things to have.

Factory problem notified by Ola Grstad here:

  https://www.kanga.nu/archives/MUD-Dev-L/2001Q3/msg01053.php

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