middleMaking things real in the virtual world do It’s much more difficult than drawing something. and as we saw Drawing them is already complicated with challenges.
Items as pure data
Once upon a time, in the days of DikuMUD, every object in the game was type – ITEM_WEAPON, ITEM_CONTAINER, etc. These were similar to what I said. template in the last article. But they are hard-coded into the game server.
When we added new content to the game, we were limited by the data fields provided. You cannot add any new behavior to vanilla DikuMUD. That item type defined everything an item can do. do, And worldbuilders couldn’t change the code to add new item types.
To expand the behavior a bit, there was a small set of “special procedures” hardcoded into the game like “magic_missile” or “energy_drain”. Their slang term was “procs,” and to this day Players talk about weapons that “actuate” monsters.. By default, you can specify that there is a “specification procedure” by filling in a field for a weapon and selecting from a limited menu.
if we look back previous article, and what this means for portability of object ownership, one thing stands out. function of a given object in DikuMUD context Where it lives: DikuMUD game servers. It had no code attached to the items it could come with when moving between worlds. Instead, it was just a database entry. that much meaning The field of was entirely dependent on the game server.
attachment action
The modern world is more flexible. thank you. concept of Attach Blocks of script code for individual items ensured that both the functionality for the item and its intended behavior become “data” in the database. This allowed non-operators in the world to add features.
Each object in the database maintained a list of associated scripts. When this technology first appeared, scripts were literally placed directly in the field of the object itself.
Later they became distinct datatypes and instead connected to object templates and object instances. This allows scripts to attach and detach from objects on the fly.
this was architecture revolution: You can become obsessed with any sudden action. You can share behavior between objects. Mix and match actions from different sources and use them as building blocks to create more sophisticated gameplay.
There are still limits. Actions do not entail the entire game system. Each script still has dependency in another script. For example, let’s say you have an apple. You want it to be food, so you can attach the following action to it:
When this object is eaten
{
Figure out how much food value the object has
Increment my stomach’s fullness by that much
Make sure I don’t go over the max stomach fullness!
Delete the eaten object
}
It seems simple, but it makes the following assumptions:
- Where does “eaten” come from? That means the whole UI, the concept of food in the first place, etc.
- If an object has a food value, but it was not a food until this action was attached, where is the food value stored? Does the object have the usual empty fields (“Does the food script attached, check storage box #1?”) How to pre-populate it? Should the script be able to add fields on the fly?
- Wait, does the player have a stomach? Is it defined in the player template? If you add “food” as a concept via script, you probably won’t. In other words, you need to add a “food eater” to the player with a script and have that script add the required fields.
- Is your stomach max? Where is it defined?
To make matters worse… if you want to poison your food? (By the way, the answer is to overload the event handler for the “eaten” message, so you should be able to define the script priority…)
To make matters worse… what if the world you bring this to is RTS, and where there are no avatars in the first place?
Trying to take only a food script from one world to another would be a total failure. Because all these assumptions are dependencies.
Object portability is not entirely hopeless.
People often think that you can set up a mapping between field values in one game and field values in another game. And indeed, there has been such a thing as “compatible player files” since the early home computer RPGs of the late 1970s and early 1980s. However, we should not underestimate the scale of the task of figuring out the value of a cooked pie. Breath of the Wild is in Halo — Or map every game to every other game.
There is currently no standard for “what you can do” in the virtual world, and we you shouldn’t want them. The act of setting standards is also setting limits, which will stifle creativity enormously. There are still too many possibilities to explore. Scripts are just data, so they’re just text! — Can be loaded. at a remote site. If you have a popular set of scripts that many people load from a common location on the web, standards can begin to emerge based on real-world usage. As long as the script can actually add data fields on-the-fly, as long as the script can be packaged with all the dependencies inside, and something like “eat” can be a message to the object – actually sharing the behavior across the world You can.
I know this works because I’ve built it before, including the old startup Metaplace.
Paradoxically, for decentralized fans, the result is literally decentralizing script locations. centralization failure point. If there is a bug in that script, everyone’s meal will stop working. So make a copy instead… Keep a history of versions… Worried about the fork… You need to build consensus on how to extend or change the behavior…
We return to “technology is for people”.
What used to be a technical problem becomes a human problem. It becomes a political challenge to manage open source software projects. There is an added complexity that a poisoned apple is not the same as application software. There is no right answer on how it works!
- Sci-fi games may want to use this very differently than fantasy games where witches can enchant apples.
- For games that can do anything from insects to mammoths, the measure of “feeling full” may need to vary significantly.
- A survival game may want real nutritional value rather than a single “food” value.
- The gameplay experience of casual titles can be severely compromised by that level of complexity.
- If you can take food to a new world and eating restores health, it can really upset the game balance where you shouldn’t be able to heal at all.
This is why transporting object functions between worlds is more difficult than anything else. social The problem and item portability in the way most people dream of is much more likely to be limited to looks for a long time. The exception is when you have centralized control over your game design, or at least strong consensus, across multiple worlds.
It left us with the biggest social problems. Something I touched lightly a few articles ago: Ownership.
— Cross-posted on the Playable Worlds website