snip
Also, is this looking to become an actual playable mechanic, or a .layer of delicious flavour on top of the existing systems? Because this is pretty complex for a brand-new system, but I'm always down for re-skinning the existing system as something else.
Snip.
Not sure if you were talking about my suggestion or not, but suggestion was a reskin of D20 WoD. It doesnt seem too complex there, in fact is quite versatile without having the free form feel to it (which is why I dont like AM, I might as well go find a free form game if Im going to use that magic)
I'll take a look at them! After I've processed some of the suggestions everyone has given, I'll write up a simple skeleton draft of the system.
What are your thoughts on this? Any suggestions?
Just saw this thread, so I'm skipping over a lot of it, but you might want to take a look at what I did to sorcerers over here.
Quickly:
Sorcerers have a stack of cards and play a game called "combine the effects."
Start with a target ("sphere AOE") add a modifier ("lingering") add a status effect ("damage over time") and finally an element ("cold damage").
Voila. Now you have an AOE burst that inflicts lingering frost damage. Want something different? Swap out the pieces.
Target ("line AOE") add a modifier ("multi-target") and an effect ("fatigues") and an element ("acid").
Bam, two short lines of acid that you spray in two directions that sapps people's strength.
If you can dig up Wizard's Bane by Rick Cook, that might have some suitable ideas as well. The big thing there was that the bigger, more powerful spells were mostly just combinations of lesser spells.
Don't try to throw a bigger fireball, just throw bunches of them. Delayed blast fireball is just a wrapper around wait () and fireball ().
This would probably tend to a system where a higher level spell becomes more of a grouping of lower level effects, and a lot more use of observation spells and conditionals within the spell function, which perhaps consume more energy. The caster can very cheaply look at where his target is and decide where the fireball should detonate. A spell that takes a designated target and aims the fireball at the target's current location requires more energy, to feed the observation spells, tracking spell, and so on. The advantage is that the caster can fire & forget the spell (either feeding it energy continually until he terminates it by stopping the energy flow, or by giving it a chunk of energy at cast time and really ignoring it), leaving him free to spend his brainpower on other spells.
Really fancy spells would observe the target, determine the most likely mode of attack, and execute that attack; basically these become limited AIs, expert systems.
yeah, I'd say do something liek two worlds 2's system, in which you have type, transmission, and effect.
like
fire, ray, dmg is a fire ray spell.
fire, self, buff is a spell that buffs you strength
fire, ray, debuff is a spell that debuffs your enemies strength
frost, ray, debuff is a spell that debuffs your enemies Dexterity
you get the idea.
> Rebooting thread. . .
I created a very rough draft of how I'm starting to envision the system. Definitely not mechanically polished, but this might give an idea how the finished system may look like. Pathfinder does spells by using a curated list of effects that only work on specific types of targets (if any at all), organized by level of power. Ars Magicka does the same except the effects are organized by target type and action type. Words of Power has a spellcaster combine spell effects and a targeting method. My prototype system has a list of object types and what effects can be operated on them. The "caster" then combines these effects and has them performed on a target. I can then introduce new types of objects that can be scripted, like a "Fire" module that creates and manipulates a fire source. However, looking this over, I'm worried I may have made it a bit too complicated. What do you think? Any thoughts or suggestions? A sample script is below:
Cube Strike
Mem cost 3; Target on rez; Effect Rezzes a Tiny cube to a location in Close range and moves it 5 feet.
Functions
Object::Rez(2)
Object::Move()
... The order of commands is important. For example, if you want a script that sets a chair on fire, you would have it look like this:
SetTarget(chair)
EmitFire()What are your thoughts on this? Any suggestions?
Not surprisingly, the magical theory used to accomplish this rather mechanical (or ritualized) casting system was originally discovered by Arch-Mage Turing. He learned and carried the system back to us from the Hidden Vaults, which he found while wandering the pathways between our world(s) and the outer-gates. The method he found is immensely powerful.
Since that time, after Arch-Mage Turing brought us this knowledge, other great Wizards have studied "the great theory of control"; trying to weave the system more tighter and more flexible -- the last great conjunction of ideas was discovered by Wizard Van Neumamm. Lo he now rests in the earth too.
Any yet, even now, after all this time, we still don't know if this system of casting is alone powerful enough to explain and harness, for our command, all the forces of reality. Alas, I pass on the system as we know it.
.
You need three things:
First, what you need is a "Stack" (magical of course - triggered by the command words POP and PUSH).
Second, you need several "Registers" (small magical storage areas for energy -- think of registers as little boxes you can write or read bits of magic into or out of). Registers come in two flavors- 1. General Purpose Registers, 2. System Registers. They are all predefined and dependent upon the level of the Magic-User. You can gain more at higher levels. General purpose registers are for use in storing values for later use. System registers generally have two meanings depending upon whether you are Reading from them or Writing to them.
(Usually, System Registers are what you want to Gain as you level up (spell slots), because this type of register "brings forth" your magical ability into reality.)Third, a...
Really, assembly coding? That would be a bit involved for an rpg...there's no memory maps to keep track of, right? (supposed to be funny, not insulting). That's really spelled out, though....
[EDIT] I just realized that it might appear that I was insulting someone...that's not my intention [/EDIT]
It's still good to throw ideas around, even though I agree an assembly system is way too low level, especially for my vScape setting.
Er, any opinions? Sorry to bump.
I haven't gone through everything yet, but I suspect anyone with actual programming knowledge will be bothered by your terminology, which is far removed from reality, though it does sound neat.
Additionally, you should probably come from the point of view of the limits imposed by the vspace program. Since if the program allowed it, all effects would manifest at maximum power.
Alternatively, use the limits of the characters knowledge, since the character's knowledge affects the efficiency and ability of any scripts they write.
I haven't gone through everything yet, but I suspect anyone with actual programming knowledge will be bothered by your terminology, which is far removed from reality, though it does sound neat.
Additionally, you should probably come from the point of view of the limits imposed by the vspace program. Since if the program allowed it, all effects would manifest at maximum power.
Alternatively, use the limits of the characters knowledge, since the character's knowledge affects the efficiency and ability of any scripts they write.
I'm a software engineer myself. It did feel funny to use some terminology, but I wanted to make it sound unique. For example "cache" used to be called "inventory." I did not really like the latter name because it created too many ambiguous connotations when the concept is fairly unique (metaphysical storage space inside every object). Some of the terms, like agent, actually do originate from a proper source. Even Rez and Derez are terms used by a Second Life, an actual metaverse, to mean the materialization/dematerialization of a virtual reality object. I'm glad you find it interesting.
You have a good point. I'm considering having some effects scale off of ability scores while the maximum mem a AESI granted by a class feature has scales off of a character's scripting skill ranks. Or some combination of it. I'm trying to figure that out.
Your example of target (target: on rez) makes no sense.
If an object is being rezzed, the target should indicate where that object is going to be rezzed (the following commands are then assumed to be targeting the rezzed object. Makes more sense this way.
Besides, how else are we going to indicate where the object is to be rezzed? Objects can be rezzed with a location that is targeted with aim or selected, in which case the object rezzes between the source and that target, as close to the target as the object can fit. You could then have an advanced targeting function that could place the object relative to the target (I.E. above, behind, etc).
---
Why is the Virtual Interface modeled as an object? Or is it only for interacting with the game when not in the game (if you even include playing characters when not in the game)
---
why is the Mem cost, referring to memory or overhead? Particularly in that you imply that greater memory cost means greater power, or that greater power can be gained by increasing mem cost, which makes no sense from a programming perspective. This seems like something that would be limited by what the game program allows, thus I think it would sound better being named and referred to from that perspective.
---
You can call the "cosmetic parameters", "custom skins", or "custom models", representing the player creating custom textures or models for the game to use with their scripts. Sounds a bit like terminology that game modders use today, thus would be recognizable and informs quite closely of what they do.
Also Scripts that can have these cosmetics changed at runtime, should probably require having the custom skins and models already created and merely selects from available models and skins at runtime, though having a quick color selector at runtime wouldn't be to difficult.
Would be neat to be able to change the default texture for newly created objects.
---
Might be interesting if some special scripts can function when the source is derezzed (cursed or blessed objects for example). Usually the target would be the first rezzed object containing the derezzed object, or centered on the location of such.
---
Don't forget object scaling! (would be a fun thing to include, and useful if it can be used on derezzed objects, I.E. so if you have a script that creates a dragon, but don't have enough space, then create it in your cache, then run a script to shrink the dragon, then rezz the dragon.)
Very good questions going on here. Do tell me if you disagree with any of my answers or have suggestion. I encourage it!
Your example of target (target: on rez) makes no sense.
If an object is being rezzed, the target should indicate where that object is going to be rezzed (the following commands are then assumed to be targeting the rezzed object. Makes more sense this way.
Besides, how else are we going to indicate where the object is to be rezzed? Objects can be rezzed with a location that is targeted with aim or selected, in which case the object rezzes between the source and that target, as close to the target as the object can fit. You could then have an advanced targeting function that could place the object relative to the target (I.E. above, behind, etc).
Good point. I originally intended to limit rezzing to adjacent locations to avoid abuse cases, but that might not be necessary. Targeting is definitely the part of this system that needs more work. It raises the question of what happens if multiple objects are rezzed. I'm brainstorming fiercely on numerous possibilities.
Why is the Virtual Interface modeled as an object? Or is it only for interacting with the game when not in the game (if you even include playing characters when not in the game)
Short Answer: Everything that an agent can interact with in vScape is an object (VRO). It makes sense that the Virtual Interface is also an object.
Long Answer: The concept of interacting with the virtual world on a computer-based level struck me as an intriguing aspect of the setting worth exploring. It's a rather cool visual to scan a virtual object and see information about it, and perhaps even change it. However, it raises the question: how does someone access this meta side of vScape?
- Maybe only off-line users can do it? Well, I have mixed feelings about the idea of letting users access vScape without actually jacking in. Like, why would anyone go anywhere risky if they could simply remotely control a cheap avatar from the comfort of their RL home? I think even Shadowrun had this issue where riggers used to be able to sit miles away while controlling their drones remotely. To me, this doesn't sound very exciting. A game about jacking into a virtual world should encourage actually jacking into the virtual world.
- Maybe someone can focus on an object and know its information psychically? No, that does not feel very appropriate for a cyber setting. And it raises the question exactly how that person "knows" the information.
- Maybe a person sees a HUD in their vision in a sort of augmented reality kind of way? Well, that would be kind of odd to have people wave their hands around to interact with something only they can see. Another issue is that it inhibits character interaction since no one can stop, hinder, or respond to someone using the HUD.
- What if every user inherently has a holographic computer that they can materialize at will? That sounds cool, but does that mean everyone can see the screens? What IS this computer? It also suffers the same issues as the previous idea: 1) it inhibits interaction because other characters can't stop them from using the device, and 2) it's difficult to describe in text. It's difficult to explain the workings of an abstract item of great importance. This led me to my next idea.
- What if the user has a handheld computer that's an actual object? I liked this idea because:
1) It's a concept players can relate to. Many people have smartphones and tablets they carry everywhere. A player who knows how a smartphone works knows what they can and can't do physically with a Virtual Interface. For example, I don't need to explain that a PC needs two hands free to use a tablet VI. That's common sense.
2) It follows the basic rule of vScape's structure: every interactive thing is a virtual reality object.
3) It allows character interaction. A person too busy looking at their interface makes a vulnerable target. An enemy could disarm the device or destroy it. It's something "real" for characters to respond to.
4) It gives dedicated scripters an Achilles heel and creates different play styles. A dedicated scripter that alters the battlefield to their will would prefer to stay at a distance -- rather difficult to use your tablet while someone is shooting at you. However, a person that just uses scripts to buff themselves or throw fireballs probably does not need a computer to do it.
5) It allows customization and flavor. A Virtual Interface could take many forms that users buy from vScape marketplaces. A character could have a holographic projection as mentioned before. Maybe a wristwatch. Perhaps a savvy character made their own that's grafted to their arm. The form could greatly influence how the device operates.
6) It fits thematically, a cyberdeck that exists in the virtual world.
why is the Mem cost, referring to memory or overhead? Particularly in that you imply that greater memory cost means greater power, or that greater power can be gained by increasing mem cost, which makes no sense from a programming perspective. This seems like something that would be limited by what the game program allows, thus I think it would sound better being named and referred to from that perspective.
I modeled this after Second Life and other process management systems. In Second Life, every script has a memory limit because each virtual locale is hosted on a server. vScape locations are also hosted by computers. I needed some way to gate the power of a script, so this seemed logical. The general idea is that vScape has a limit on script memory. Being a good programmer allows you to circumvent those limits by making your code more efficient.
You have a point, though. Perhaps a different model would be best.
You can call the "cosmetic parameters", "custom skins", or "custom models", representing the player creating custom textures or models for the game to use with their scripts. Sounds a bit like terminology that game modders use today, thus would be recognizable and informs quite closely of what they do.
Also Scripts that can have these cosmetics changed at runtime, should probably require having the custom skins and models already created and merely selects from available models and skins at runtime, though having a quick color selector at runtime wouldn't be to difficult.
Would be neat to be able to change the default texture for newly created objects.
"Custom skins and models" is probably a better way to describe it. I do indeed for the Object module to have a SetTexture function as well as a SetMaterial function.
Might be interesting if some special scripts can function when the source is derezzed (cursed or blessed objects for example). Usually the target would be the first rezzed object containing the derezzed object, or centered on the location of such.
I like that. I'm considering ideas like hostile script insertion and hostile attachment objects. Hostile script insertion would allow a hacker to circumvent standard limitations insert a script into an object he doesn't own or even a person's avatar. A hostile attachment is an object that attaches to an avatar and therefore cause bad things to happen to that person.
Don't forget object scaling! (would be a fun thing to include, and useful if it can be used on derezzed objects, I.E. so if you have a script that creates a dragon, but don't have enough space, then create it in your cache, then run a script to shrink the dragon, then rezz the dragon.)
That's a good idea!
why is the Mem cost, referring to memory or overhead? Particularly in that you imply that greater memory cost means greater power, or that greater power can be gained by increasing mem cost, which makes no sense from a programming perspective. This seems like something that would be limited by what the game program allows, thus I think it would sound better being named and referred to from that perspective.I modeled this after Second Life and other process management systems. In Second Life, every script has a memory limit because each virtual locale is hosted on a server. vScape locations are also hosted by computers. I needed some way to gate the power of a script, so this seemed logical. The general idea is that vScape has a limit on script memory. Being a good programmer allows you to circumvent those limits by making your code more efficient.
You have a point, though. Perhaps a different model would be best.
Well, I never heard of Second Life, s it doesn't work as a reference for me.
As for the scripts, I can see having a mem cost on script length, which might limit how long of a script can be written and saved, as that is not only something that should be limited, but also could actually consume more memory.
It was just the idea that 500 damage takes more memory then 5 damage, that seemed really messed up. Numbers don't exactly consume more memory, so I figure, the VScape main program should fill in those types of numbers automatically based on agent access/allowance parameters. In this way, if a scripter tried to make a cone of fire, they wouldn't get to decide on how much damage, but rather they would simply state in their script to cause damage, and the program when it processes the script would insert an appropriate damage value.
This also gives players an incentive to go "questing" to gain upgrades to their virtual stats so the program will give their scripts greater values, instead of simply having the best scripter be the all powerful god on first day in the game.
I haven't gone through everything yet, but I suspect anyone with actual programming knowledge will be bothered by your terminology, which is far removed from reality, though it does sound neat.
I literally almost made a rant post about rezzing not being a word...
It's in reference to Tron and derez(the original movie, which coined the term, rez I believe was not used), which is short for de-resolution, already bad prefix for creating assumptions, de makes a noun or state into a verb, removing the prefix makes it a state or noun again. resolution of course being what ever is actually running on the CPU as having resolution, everything else is not in resolution.
also, later post on cache and inventory, a more correct term would have been members.
also, on how people interact with items in Vspace, look up how the latest shadowrun version does the matrix. It behaves like a virtual machine where everything knows what everything IS, like it knows how many members it has, that it is an object, and what all the data is set to. Everything has levels of access, so if you have no tags on an object you have no ability to interact with an object. many objects give out a single tag for free when you attempt to interact with it for the first time.
2 tags I think is admin access and 3 tags is ownership.
you can interact with anything on the matrix so long as you know where it is from any distance, but things can be hidden in hubs, which are basically like a virtual building, it might just look like a floating key but when you interact with it you teleport "inside".
everything in a hub that isn't owned by a visitor and was brought in is owned by the hub and by extension the hubs owner, so you can't hack specific objects in a hub easily.
i don't think i said everything absolutely correctly, as it's been a while, but it's all food for thought.
stuffWell, I never heard of Second Life, s it doesn't work as a reference for me.
As for the scripts, I can see having a mem cost on script length, which might limit how long of a script can be written and saved, as that is not only something that should be limited, but also could actually consume more memory.
It was just the idea that 500 damage takes more memory then 5 damage, that seemed really messed up. Numbers don't exactly consume more memory, so I figure, the VScape main program should fill in those types of numbers automatically based on agent access/allowance parameters. In this way, if a scripter tried to make a cone of fire, they wouldn't get to decide on how much damage, but rather they would simply state in their script to cause damage, and the program when it processes the script would insert an appropriate damage value.
This also gives players an incentive to go "questing" to gain upgrades to their virtual stats so the program will give their scripts greater values, instead of simply having the best scripter be the all powerful god on first day in the game.
I would have to agree, usually you have to trade off between size and speed. So it could technically be to make the damage in such a burst requires a more complex program, and that damage is not a number being adjusted, but actual system stability.
This thread has me very interested.
I think system stability damage would be interesting when entering non-game virtual spaces, but since the characters and their scripts are in a game, then the game will have it's own damage that functions like normal game damage.
Thus system stability damage should be something completely different, and that would be disallowed by the moderators of the game.
Having mechanics for it would be interesting though.
I think system stability damage would be interesting when entering non-game virtual spaces, but since the characters and their scripts are in a game, then the game will have it's own damage that functions like normal game damage.
Thus system stability damage should be something completely different, and that would be disallowed by the moderators of the game.
Having mechanics for it would be interesting though.
I mean it as more of as not "a number that lowers" and more of something that actually has to be chipped away at, like a actual 3D hitbox that takes damage like real world stuff. damage wouldn't be about adding a bigger number but something that can process the damage faster/better.
A hit box or character model is made up of a whole lot of numbers. Having a single damage number vs a health bar or the like IS the faster/better (computer speaking wise) way.
A square cube has 3 numbers for a minimum of 8 vertices (24 numbers), and I'm quite sure most of those get overlapped due to how things work, so it would likely be more than that. Adding any kind of damage effect or deformation would only increase the amount of memory needed, but for the target of the effect, not the effect itself nor the caster of said effect. It would also take a lot more computer power to do that.
So yeah, single number dmg vs hp is the quick easy to do it, and nothing about a virtual environment would change that.
Thus if it uses any kind of other sort of damage mechanic, it would still be simulated based on the rules of the game, would be slower (though may not be noticed by the players), and would still be at the whim of the main program.
Any kind of mechanic for disrupting system stability would be disrupting either the computer the game is running on, or the connection between the computer and other computers . Either case would be something that officials would want to stop.
I'm using Snow Crash and Second Life as inspiration. Second Life is basically an MMO completely centered around user-created content. You can build and program objects. It also has a massive economy where users can sell their creations for currency exchangeable with real money -- in fact, I'm actually a weapon merchant. When I played around in Second Life years ago, I realized that I could use it to help fill the gaps in my concept of vScape. It was here that I realized vScape might make for a rather interesting setting for science fiction RPG. This is a world where buying/selling body parts is a major industry. Quality clothing comes with software that allows you to change its material and color at will.
@GM DarklightHitomi
You have a point that there exists some dissonance if a script effect's damage is determined by some number a scripter sets. Perhaps a better solution is have the damage scale passively based on the scripter's skill. Mechanically speaking, that might mean a scripted flame designed to deal damage would do 1d6 per scripting skill rank up to a certain maximum allowed by the system.
I also had another idea bouncing in my head that instead of there existing a hard limit on mem cost, high mem cost affects the execution time of the script. In other words, it may take more than one standard action for the script to take effect. It may take rounds or even minutes. However, there still needs to be some limit on how many scripts a character can have primed at once since they can do these at will. So this may not work entirely.
@Bandw2
I use the terms "rez/derez" because Second Life uses this terminology to make something appear or disappear in virtual space. It's fairly commonplace for terms to originate from science fiction, such as ICE and even the word cyberspace. But your concerns are valid. "Desolution" was pretty lame terminology from Tron, and one of the things that made it evident the writers only had cursory knowledge of how computers work. I did consider "virt/devirt" or "mat/demat" to mean virtualization or materialization respectfully.
I've read about the Matrix from Shadowrun, which is based on the Neuromancer books. It's great inspiration, but also useful in that I can see potential pitfalls. Much of the Matrix is abstract and difficult to visualize. As mentioned before, this was one of the reasons I choose to model Virtual Interfaces as tablet computers that users carry around.
Any kind of mechanic for disrupting system stability would be disrupting either the computer the game is running on, or the connection between the computer and other computers . Either case would be something that officials would want to stop.
Anomalies will be one of the more fun aspects of this game to design. For example, some very exceptional users have learned to hack their computer hardware and software to trick vScape servers into augmenting their mental abilities and hard-lining their thoughts into virtual space. In other words, they enabled servers to host their cognitive processes, granting them superior intelligence and inhuman reflexes. However, the strain of their mind affects the servers. Whenever such an individual arrives in a region, everyone else in the region suddenly experiences everything in slow motion for a few seconds as the servers struggle to load balance to adapt the heavy burden the person's mind has.
with stability I was talking more in the physical sense. as in if you cut someone' leg off, they actually lose their leg, not lose 25 hp points.
also, the latest form of the Matrix forces everything to take on icons that match what they do.
with stability I was talking more in the physical sense. as in if you cut someone' leg off, they actually lose their leg, not lose 25 hp points.
I totally agree. One of my friends remarked this is one of his favorite aspects of my setting: combat can have lots of flashy wounds and dismemberment since no gore exists. Avatars have no true internal organs. A person feels like they do, but they actually don't. The aesthetics allow more prominent dismemberment, adding a new dimension to the game. Maintaining your avatar is a major aspect of the game. If your hand got cut off in a fight, you need to get a skilled crafter to reattach it or make you a new one.
While it makes more sense damage for the numerical measurement of damage in a virtual setting, hitpoints don't really model this kind of interesting dynamic. In fact, a Constitution score no longer really applies in vScape because a user agent is more like an intelligent construct. This is actually a really huge point of discussion and one of the major reasons I have leaned towards making my own RPG system rather than use PF/3.5e OGL. I'm also not a big fan of Pathfinder's damaging object system. This is a system I'd seriously consider revising. At the very least, I'd want to create a uniform system of hitpoints per size category of objects.
On that subject, I should probably bring up what happens when someone dies in vScape. An avatar is kind of like a digital robot a user controls remotely. When an agent's avatar takes enough damage, the agent dies. For a user, this causes them to disconnect from vScape. However, such a process proves traumatizing for the user, causing Wisdom drain. Lower Wisdom causes the person to slowly lose their sanity as the difference between RL and VR blurs with each death. If low enough, the character goes mad and becomes unplayable. An avatar is also usually the highest investment a character has, so a destroyed avatar is like a martial losing their best weapon.
Have you looked at an actual game scripting interface? The one I'm most familiar with at the moment is Transcendence/
I'm not sure what you mean by "game scripting interface." Do you mean a scripting language as part of a user content creation system? Or a game that models programming as part of the gameplay? Transcendence looks like the former.
I'm a software engineer and have a business in Second Life selling products I personally scripted. I love looking at ideas flourishing here, but I could really go into extremes when designing this. However, I want a system that makes a player feel like they're scripting. It's also important that a GM can easily read a script and figure out what it does. Deciding where to draw the line is a major issue. Some aspects of programming may come natural to me but alien to someone without programming experience. This is a large reason why I made this thread.
I do agree with you that there should be definitions for different things. Generally, I broke it down to this:
- An object is anything that has a physical representation in virtual space.
- An item is an object you can carry either in your hands, on your avatar's person, or in your avatar's cache.
- An agent is a controlled entity capable of experiencing and interacting with virtual space using an avatar as a body. A user agent is controlled by a human jacked into the virtual simulation. A non-user agent is controlled by a scripted artificial intelligence. In Pathfinder terms, agents are creatures.
- An avatar is a specialized object that an agent uses as their "body" in virtual space.
Any thoughts about this?
I'm working on an RPG/Campaign Setting that I have interests in adapting to Pathfinder in the future. The game takes place in a virtual reality simulation with a scripting system that enables supernatural effects. A tech-savvy character can code their own scripts and execute them. I envisioned that a character would install a system that grants them X number of "slots" that they can allocate to scripts that function as at-will abilities. However, reallocation takes at least an hour to do so.
However, I want to create an elegant system for players to create their own scripts, but I'm torn on how to do that. I've looked at Words of Power and wasn't happy with how they did it. I'm considering having scripts consisting of a list of "functions" that do very simple things. The order of commands is important. For example, if you want a script that sets a chair on fire, you would have it look like this:
SetTarget(chair)
EmitFire()What are your thoughts on this? Any suggestions?
This is a beautiful thought.
Anyhow, someone suggested Ars Magica. I too, second the suggestion. Check it out. :)
I should have a clearer idea how a script interacts with objects inside its cache. Some scripts could require an object as a "material component", but I'm not sure how explicit or implicit to make this. An explicit representation of this could gate particularly powerful effects.
For example, a function that can change an agent's avatar for the purpose of a transformation effect might require a copy of that avatar in the user's cache.