New Zangerland
From Zangshin
Zangerland should aim to be to Second Life what YouTube is to iTunes. A free, open world for user generated content sharing. As part of this I would like to see a development philosophy adopted that is more geared towards a broad based design rather then RPG specific elements. For example in the RPG world, quaffing a potion and casting a heal spell are two distinct action with a similar outcome. But usually these are handled by entirely separate aspects of the code. There is usually a magic system, and an object system, perhaps even a specific potion handling system. I would like to look at this as the same thing. Two different action verbs (i.e. quaff/cast) two different action costs (time+potion vs time+mana) with the same end result (effect of potion/ spell applied to actor). I would like to create a world of emoting, in the mud sense, with appropriate results for "certain" emotes, such as casting, quaffing, looking and so on. The world engine should be able to treat everything the same way though, an action with a cost and a result. This of course puts the burden on the initial design of this system, to make it flexible enough to accommodate all the possibilities of the usually distinct systems it is supposed to replace. For example, can a spell affect multiple others in a complex way (e.g. reveal locations of magical objects to multiple friends), or can a skill be used in a creative fashion (combining a smithy skill, an anvil and raw materials to produce a piece of armor)?
I hope you will take this under consideration, as time and time again I see you wander off in very specific implementations that will limit the scope of this project greatly! For example we should NOT have a specific property management system handling buying and managing property. It should be implied by the actions of the avatars, such as talking to a property salesmen and carrying a key to ones house.
Contents |
ZL v0.0.2 Design Details:
New class hierarchy here: zangerland.com/zl0.0.2/
World
- World
- Object
- Property
- Actor
- Property
- Action
- Effect (Visual, Auditory, Magical, ...)
- Object
Theory on Actions
Actions should be atomic and only need one parameter (the actor being an implied second parameter). So, for example, to use a rock on an enemy, you would first "use rock" and then "apply enemy". This would "load" the rock into the usage "slot" (e.g. a hand) and the subsequent apply would apply whatever is in the usage slot to the target. Of course, macros will enable the user interface to show only one action with two parameters, but in principal every system action should be single parameter only. This is already used in traditional rpgs in the form of wield+attack, or open+get. For example using a gold-key on a wooden-door would look like this: "use gold-key; apply wooden-door).
Theory on Object/Actor duality
This brings me to another pet-idea of mine. The living object. I want to be able to have a magical sword, which is an ordinary object/sword, but can become a living magical being, fighting on it's own accord. Furthermore I want this activation to be in an open-ended way, such that you do not have to "activate sword" for the effect, but may simply "say magic-word" instead. This of course introduces the problem of where does an Object end and an Actor begin? One could, in theory, have Actors that behave like Objects, but this maybe wasteful in the extreme. The point of Objects is that they cannot receive Effects and therefor do not require much processing. So ideally, our magical sword would morph form Object to Actor and back as required. But how will the Object know? For this we need to enable a kind of listening system for Objects. So when picked up, a listening flagged Object will add itself to the Actors listen list. From now on, any Effect the Actor receives will be forwarded to the Objects in its listening list. This way we do not have to forward Effects to all Actors AND all Objects they carry, but only the few that are registered. This can be handled via an event handler for "onPickup" for the Object. Now, if the Actor, or someone else in the room says the magic-word, the Actor possessing the sword will hear it, and so will the sword. It will be able to create the magical sword Actor and remove the sword Object.
Theory on environment influence and Object creation: User Generated Content
I would like to make the UBC system part of the world. In other words, I want to avoid having "editors" and "building commands". Instead, I want to make as much of the building process incidental to actions in the world. For example using a plow while running over grassland, will over several passes turn it into upturned earth, ready for planting and being turned into a field. Likewise, using a pickax in a rocky room, will turn it into a chipped rock room and further into a cracked rock room, and ultimately will let you carve out a cave into the side of a hill! Similarly, for example creating furniture. A simple carpentry skill applied to some raw wood will create a random chair. But a design skill may influence that. For example "designing" a rounded throne, may produce a "majestic throne with bulbous round edges". In other words, a text parser will pick up on certain property words (round, big, throne, majestic) and will turn them into a description with filler and modifiers. the higher the design and carpentry skills, the closer to what is desired for the Object will be produced. For example, "design dragon head detailing" and "carve detail on chair" may turn our previous product into a "majestic throne with bulbous round edges and a dragon head detail carved into its back". In a similar fashion I believe, the system might pick up on room descriptions, for example to detect if there is stone present for the pickax to work on, or wood, or combustibles (like dry grass). We may have to spend considerable time on a grammar system that will enable systematic parsing and discovery of properties. This is of course our "3d" engine. This is necessary even with a 2d world image, since the tile graphics will only be icon-ized representations, and the detail will still be in text. Of course we are free to add ass much detail to tiles as we like, such as transitions from grassland to upturned earth to field. But this may be done after the fact sine it won't be necessary for the detailing of the world.
Theory on Atomic Effects
I have further thought about atomic effects. Effects which are single items of effect between an actor and Actee. I believe, thought testing may show otherwise, that effects need not have any access to the action that caused them. This way an action is simply a list of effects between an Actor and an Actee. Let us investigate some representative examples. Simple actions such as give.
Give
- Give takes a target Actor (Actee) as a parameter.
- It's effects should include depletion of stamina or action points (time).
- It's primary effect will be to remove the item in the source Actors (Actor) use slot and add it to the inventory (or use slot) of the Actee.
- Give needs to be preceded with a Use command to load an Object into the use slot of the Actor.
This example shows us that in many cases two Actions are necessary for what would be commonly understood as a command. Also, that there are lists/stacks of sorts on an Actor that are acted on by the Effects. This includes traditional ones such as worn/wielded but also requires a use/held slot of some type. Also, Effects need some formal type, such as sound, vision, magical and so on. This way certain modifiers can be applied to types. For example vision will be modified for blindness, and there may even be a deafness modifier. furthermore, magical effects may be modified by magical resistance. In AoW magical effects are always attenuated by magical resistance. For example a spell like fly is the same for any level of caster. But trying to cast a spell on a Barbarian of much higher level and magic resistance may cause it to fail repeatedly. Same for heal. So applying attenuating effects of magic resistance makes sense even for positive effects. I hope this system of atomic effects and action lists will prove very flexible and provide realism and practicality in cases unforeseen at the current stage. There maybe a limited list of possible Effects (although a large one) but it may result in near infinite combinations of Actions.
Effects in Practice
I will try to formulate effects in practice for our toy problems. An effect needs several types of basic information. Let's list some of example effects to get a feel for the requirements:
- "say words": Is an action with a simple auditory effect. It targets the current room with the audio "words".
- "yell words": Is an action that targets the immediate area with auditory effect "words".
- "wield object": This has a visual effect ("Actor wields object"), as well as the effect of placing the object in the wielded slot on the Actor.
- "quaff potion": This Action will have several effects. First it will remove the potion from the inventory. Then it will load effects of the potion and execute them.
- "kill snake": This action will initiate a battle. It's effects will include a physical attack with the currently wielded object on the "snake" Actee using properties of the initiating Actor. There may be an atomic "physical attack" effect, or it may be split into several effects, such as:
- A visual (to inform others that they see the attack).
- An auditory effect (even blind actors in the room are aware of the attack, perhaps even sharp hearing actors in the vicinity).
- A health reduction effect on the target actor, which may be specifically a physical damage effect, so all armor and protection modifiers apply.
- An aggression effect to the target actor (and perhaps nearby others) which will cause any auto-defend actions to kick in.
This shows some of the variability of the effects. But also that each single effect is quite limited in scope. In practice effects may be wrapped into higher level constructs and combined, since some actions could cause many simultaneous effects which could be difficult to process in large quantities.
On Object Properties
Generic object handling would enable any object to be wielded or worn. This would necessitate that objects have certain properties, such as weight, shape (blunt, sharp, spiked, soft) and material. This could be taken to complex extremes. The bottom line is that it would be beneficial if any item could be calculated for it's damage potential, and also that a weapons damage potential would be incidental to it's stricture. So instead of a damage value, a sword mi8ght simple be steel, sharp, 10kg in weight and well balanced (a property that makes it well suited as a weapon). Of course not everything could be worn, but a ring should be throwable, and if it's spiked and quite heavy it should be capable of considerable damage. So in a way as Actions have effects, objects have properties. Also this will solve the conundrum of wieldable corpses. For example a Hydra, if small and light enough, might become wieldable. It's stonifying properties may transfer to the corpse. This weapon will have an effect property of turning the attacked creature to stone. This may be a magical or physical effect (modified by different aspects, such as magic resistance or dodging/armor).
