| 4 people marked this as a favorite. |
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?
Words of Power would actually work quite well for this. That text can be daunting, though.
-Ben.
|
| 1 person marked this as a favorite. |
Maybe you should take a look at the Ars Magica RPG? It's got a sophisticated freeform magic system.
In AM, magic is a combination of (Latin) verbs+nouns. There are 5 verbs used:
Creo (I create)
Muto (I change)
Rego (I control)
Perdo (I destroy)
Intellego (I understand/perceive)
And there are 10 nouns:
Animal
Auram (air)
Aquam
Corpus (body)
Herbam (plants)
Ignem
Imaginem (senses)
Mentem (mind)
Terram
Vim (magical energy)
To create a fireball you would use Creo Ignem ("I create fire"). To inflict wounds you would use Perdo Corpus ("I destroy body"). The whole system is fairly refined.
Another vote for the Ars Magica system. The verb-noun system is extremely flexible.
I should add -- magical skill is built on a per-term basis, so you might have a skill of 5 in Creo and a skill of 0 in Perdo, which would make you much better at setting fires than extinguishing them. This provides for variance among equally skilled wizards -- The Green Mage is really good at plant and growth focused magic, while the Black Mage is great at destruction and necromancy (which generally falls under mind and/or body), and the White Mage is good at protection spells (which generally fall under control).
1 question about that, is creo corpus summoning or curing
Both.
There are actually strong limitations in the ArM system itself; permanent spells require rare magical mojo, and that includes permanent healing as well as permanent creation. Something like summon (humanoid) monster would be a [temporary] creo corpus.
I see
I'll have to look at Ars Magica, but obviously I can't apply it directly.
| 1 person marked this as a favorite. |
I think you'd be surprised how much you can transfer. If you simply strip out the pretentious Latin, and instead of callling things "nouns" and "verbs," you can use the object.method() paradigm from object oriented languages like Java and get pretty much the flavor you want.
E.g., instead of having a suggestion spell, you use Mind.control();
I'm not sure that it would be very fun to have the programming metaphor go any deeper. The first observation is simply that even professional programmers aren't very good at writing programs on the fly. There's a famous case report that I can't find quickly that when given a piece of paper and half an hour, some huge percentage (75%) of professional programmers tested couldn't write code to sort an array that would run the first time.
The possibility of "buggy" spells is amusing -- instead of casting a fireball, I cast a firball and fill the hall with pine-smelling branches. I misplace a semicolon and create an infinite loop on my create water spell and end up flooding the world. (See Why the Sea is Salt or the legend of the Sorcerer's Apprentice.) But that kind of humor gets old fairly quickly.
And in particular, that makes your statement that "the order of commands is important" something I would strongly advise against.
The second observation is that programming is hard, especially trying to describe complex effects, and your character is quite possibly much better at it than your player. If I were playing an character that is a professional sailor, you wouldn't expect me personally to know how to reef a sail or run a halyard over a yardarm (whatever the hell a yardarm is). If I were playing a veterinarian, you wouldn't expect me to know the symptoms of hardpad (whatever the hell that is). Ditto for professional mage-programmers.
You could do something with loops?
Like maybe a lot of magic is just doing the task once and then automating the "loop". Like when you prepare your spells, you do something like take a shovel and dig into the ground. Then later, you can use that earlier action to caste a spell that digs a hole.
Similarly, you can burn a candle to prepare to light someone on fire later.
Also: this setting reminds me of Scapped Princess.
| 1 person marked this as a favorite. |
You could do something with loops?
Like maybe a lot of magic is just doing the task once and then automating the "loop". Like when you prepare your spells, you do something like take a shovel and dig into the ground. Then later, you can use that earlier action to caste a spell that digs a hole.
Yeah. See "Apprentice, Sorcerer's." Also see "Fun, Things That Aren't."
Infinite loops are one of the easiest and most common forms of programming mistakes.
You could do something with loops?
Like maybe a lot of magic is just doing the task once and then automating the "loop". Like when you prepare your spells, you do something like take a shovel and dig into the ground. Then later, you can use that earlier action to caste a spell that digs a hole.
Yeah. See "Apprentice, Sorcerer's." Also see "Fun, Things That Aren't."
Infinite loops are one of the easiest and most common forms of programming mistakes.
Sounds like a nat 1 on your check. You gotta set it up to terminate after the right distance or you are gonna have problems.
Sounds like a nat 1 on your check. You gotta set it up to terminate after the right distance or you are gonna have problems.
More like a failure by 5 or more or a natural 1, in terms of real-world frequencies.
|
|
I think the Ars Magica verbs are more like functions that will process multiple different types (different nouns), rather than methods of objects.
Though on the other hand, type does matter; AM is built on the idea of Platonic archetypes. Whether something is Rego (control; orderly transformation) or Muto (strange, unnatural transformation) depends on what you're doing to the object. Rego would be using built-in functionality, while Muto would be coercing objects in ways they don't like.
...
Now I'm starting to visualize different classes using Declarative vs. Imperative magic styles...
[calling] spells without calling diagram considered harmful...
Make your character use only 1's and 0's to cast magic.
Ala Bender
|
|
@Silent: not really. "Creo" is all magic that creates something, or makes it more like its Platonic archetype (healing). That's an entire category of magic. The same goes for the other words.
It's more appropriate to compare Techniques (verbs) and Forms (nouns) to schools or descriptors of spells. Having a good score in Ignem means you're good at casting "[fire]" spells - all of them.
You have a rating in each of them (0+). There's a lot of example spells with levels, and tables to balance your own spells, depending on parameters like duration and area of effect. It's quite flexible.
If you're going to use a level 20 Creo Ignem spell for example (a fireball), you'd check your Creo and Ignem scores, and roll 1d10. If the result is 20+, the spell works well.
A friend of mine tweaked it a bit and made a fireball with a two-minute duration; that ended up at level 35 I think, which his character could do because he was quite specialized in Creo and Ignem.
My character was also good at Creo, but mostly specialized in Terram. I had only a few points in Ignem. I could manage the simple fireball most of the time, but the extended version was beyond my power.
My favorite attack spell was the "Oubliette du Damage" (points if you get the reference), which teleported a cone of earth from beneath the target to just above him, and then let gravity run its course. That was a Rego Terram spell (Rego also includes teleportation). I made it up myself; it wasn't from the book. But the tables in the book made it pretty straightforward to determine what level it should be.
Unlike PF, AM really encourages you to research your own spells.
Another idea I had was that each function has an output that can be the input of another function, but I'm not sure of that.
I think the Ars Magica verbs are more like functions that will process multiple different types (different nouns), rather than methods of objects.
Now I'm starting to visualize different classes using Declarative vs. Imperative magic styles...
This might be the way to go as the VR system does not classify different types of creatures like Pathfinder does. Something is either a creature (called an "agent") or an object -- even then, the system considers a creature as a specialized type of object. For Pathfinder, this might be a refreshing take on supernatural effects where the magic cares little about the trivial differences between creatures.
I think you'd be surprised how much you can transfer. If you simply strip out the pretentious Latin, and instead of callling things "nouns" and "verbs," you can use the object.method() paradigm from object oriented languages like Java and get pretty much the flavor you want.
E.g., instead of having a suggestion spell, you use Mind.control();
Hm, perhaps. I'll need to scrap some cash together to get a copy of Ars Magica for myself. I think the issue I have mostly has to do with the nouns. In other words, there's not really any plants in a virtual simulation, but I should be able to figure something out.
I'm not sure that it would be very fun to have the programming metaphor go any deeper. The first observation is simply that even professional programmers aren't very good at writing programs on the fly. There's a famous case report that I can't find quickly that when given a piece of paper and half an hour, some huge percentage (75%) of professional programmers tested couldn't write code to sort an array that would run the first time.
I don't want the system to be too complicated. I want the players to feel like they're programming, not require actual programming technique. The GM shouldn't have to be a compiler. I'd also require that programs cannot be made on the fly -- they have to be done ahead of time, preferably at the start or in between sessions to prevent analysis paralysis in the middle of combat.
On a tangent, that challenge is actually really unfair. Sorting is a very complex subject. It's even fairly difficult to memorize the asymptotic order of many of the algorithms. Asking a programmer to write a perfectly functioning sorting program on a piece of paper in 30 minutes is like asking a literary expert to recite the first act of Macbeth word for word or a historian to spontaneously give the Gettysburg Address.
The possibility of "buggy" spells is amusing -- instead of casting a fireball, I cast a firball and fill the hall with pine-smelling branches. I misplace a semicolon and create an infinite loop on my create water spell and end up flooding the world. (See Why the Sea is Salt or the legend of the Sorcerer's Apprentice.) But that kind of humor gets old fairly quickly.
That sounds like an interesting idea, actually. Maybe the first time a script is executed, the player has to roll their crafting check to see if the script has a bug. Or the crafting check is done by the GM in secret. On a botch, the script is buggy and does something unexpected.
And in particular, that makes your statement that "the order of commands is important" something I would strongly advise against.
The second observation is that programming is hard, especially trying to describe complex effects, and your character is quite possibly much better at it than your player. If I were playing an character that is a professional sailor, you wouldn't expect me personally to know how to reef a sail or run a halyard over a yardarm (whatever the hell a yardarm is). If I were playing a veterinarian, you wouldn't expect me to know the symptoms of hardpad (whatever the hell that is). Ditto for professional mage-programmers.
Let me elaborate. When I mean "order of commands is important," I mean that the functions should have a logical order. For example, if you want to throw a fireball that involved conjuring a fire and then throwing it, you obviously wouldn't conjure the fire AFTER you command it to move. This differs from Words of Power, which don't really care what order things occur. Words of Power just combines effects together rather than give a list of what happens when a spell occurs.
You could do something with loops?
Like maybe a lot of magic is just doing the task once and then automating the "loop". Like when you prepare your spells, you do something like take a shovel and dig into the ground. Then later, you can use that earlier action to caste a spell that digs a hole.
Similarly, you can burn a candle to prepare to light someone on fire later.
Also: this setting reminds me of Scapped Princess.
I never considered something like a "for each" loop, which might justify multi-target scripts.
Your suggestion does make me think of one odd-ball magic system I thought of before, where when you cast a spell, you're actually doing the action manually while time has stopped. When you resume time, you have amnesia of when you completed the action, making you believe it happened instantly.
But back on topic, I do like the idea of scripts executing pre-recorded actions.
On a tangent, that challenge is actually really unfair. Sorting is a very complex subject. It's even fairly difficult to memorize the asymptotic order of many of the algorithms. Asking a programmer to write a perfectly functioning sorting program on a piece of paper in 30 minutes is like asking a literary expert to recite the first act of Macbeth word for word or a historian to spontaneously give the Gettysburg Address.
Continuing on the tangent.... this is the first time I've had anyone criticize the task as unfairly difficult. Perhaps this is just the cowboy mentality of many programmers, but most programmers are supremely confident of their ability to solve this task.
And, frankly, it's not as difficult a task as you seem to think; it's the sort of thing that any competent programmer knows how to do (in multiple ways) by two months into their first programming course. A "simple" sort like bubble sort takes -- literally -- three lines of code in a typical declarative language, plus whatever overhead the language itself imposes ('public static void armoire vestibule package main()"),
If the Ars Magica system uses five verbs and ten nouns, doesn't that mean there are only 50 spells total that can be cast using that system?
Seems awfully restricted to me.
As Ascalaphus pointed out, it's not 50 spells but fifty kinds of spells.
Spells to create fire are Creo Ignem. This could be a spell to light a candle, a spell to create a burning hands style cone of fire, a spell to create a wall of fire, or a spell to sterilize the entire surface of the planet under a sheet of white-hot flame. Obviously, the last spell would be quite difficult and require an enormous of amount of skill, while any apprentice could light the candle.
Creo also covers other aspects of change such as growth and improvement, so a spell to make a fire hotter could be Creo Ignem. Creo is also used on living things for healing (making humans or animals more like their Platonic ideal). Similarly, Ignem covers other things than fire narrowly defined, so a spell like dancing lights would also be Creo Ignem. So would a spell like heat metal or a spell to warm the room.
Basically, it's up to the player to define the effect that he wants and then the GM decides what the appropriate level and words are. "You want to turn a person into a toad? Well, that would be a Muto (change) spell, with nouns of Corpus (human body) and Animal (animal), and that would be a level 20 spell, level 25 if it lasts until sunset, level 30 if it lasts a month, level 35 if it's supposed to be permanent."
Which in itself can create some interesting exchanges and ideas. If you want to create a ladder out of thin air, that would probably be Creo Herbam (as wood is a plant product), but if your Herbam isn't very good, you could try creating a metal ladder (Creo Terram) or a ladder of bones (which would be Creo Corpus). If you want to put out a campfire, Perdo (destroy) Ignem is the most obvious, but you could also use Creo Terram to smother it under a pile of sand, or Muto Animal to turn your dog into an elephant and stamp it out.
One of the things I like about the ArM system in fact, is that it encourages multiple ways to solve a problem.
Sorting in general isn't that hard. Sorting with a minimal code length, or optimal for some parameter, a bit harder. I can do insertion and bubble sort from memory, I'll probably manage merge sort. But please don't ask me to do heapsort.
That's the more typical attitude.
Having said that, the stats suggest that you can't do it, not on the first try. You'll probably reverse a test, or have an off-by-one error in one of the loops, or forget a semicolon, or some other "stupid" mistake (I note in passing that I don't think I've ever seen an "intelligent" mistake, so I'm not sure what other kind there is).
So I'm willing to say with high confidence that you could probably write something very close to bubble sort from memory and/or first principles, probably within five minutes of the allotted thirty. I'm also willing to say with high confidence that you will be embarrassed by the "obvious" error that you overlooked that would require a small modification before your code worked.
The versatility of Ars Magica intrigues me because this is the general thing I want to accomplish with the system. The scripting system works for "enchantments" as well as for what programming-mages do. The same function that a mage used to set someone on fire is also the function that makes an automated fireplace work and cover an enchanted sword have a blade shrouded in flame. The difference lies with the target and parameters.
Continuing on the tangent.... this is the first time I've had anyone criticize the task as unfairly difficult. Perhaps this is just the cowboy mentality of many programmers, but most programmers are supremely confident of their ability to solve this task.
And, frankly, it's not as difficult a task as you seem to think; it's the sort of thing that any competent programmer knows how to do (in multiple ways) by two months into their first programming course. A "simple" sort like bubble sort takes -- literally -- three lines of code in a typical declarative language, plus whatever overhead the language itself imposes ('public static void armoire vestibule package main()"),
The challenge is unfair for other reasons than the actual implementation of a sorting algorithm. Implementing one that will work on the first run is difficult because programming is an iterative activity. As a software engineer myself, most developers will simply look up a pre-existing sorting algorithm that has already been tested and proven by computer scientists. They do this because re-usability is one of the corner stones of modern software development. Also note that even conceptually simple sorting algorithms can be complex in code. Even an algorithm as naive as Insertion Sort has two nested loops.
Since the challenge graded based on correctiveness rather than efficiency, I'd probably implement "Bin Sort" (sorts by creating a giant array that counts the number of occurences in a given array) if I took the challenge. It's very space inefficient, but insanely easy to implement.
Is shotgun sort allowed?
I believe technically, yes. Although generating a random permutation is not something that every programmer feels they know how to do, or that they've been asked to do a half-dozen times in programming classes, so it would probably be a rather rare solution.
Oh, we're not allowed to just call rand()?
I think that if you're going to use magic-as-programming, that you need to leave a big role for tried-and-tested scripts.
What do you mean? Can you elaborate?
I did have the idea that you can purchase scripts, but you can't customize them or make your own without skill.
| 6 people marked this as a favorite. |
... 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 Magical Vocabulary (aka V,S,M OP Codes.) Each School of Magic has its own predefined magical vocabulary, and, here, we will generically call them OP Codes.
+
----------------------------------------------------------------
EXAMPLE: MAGIC MISSILE (or, Lighting a Chair On Fire with Magic)
----------------------------------------------------------------
-Three System Registers you Learn at 1st Level:
*1*
Register: SENSE (your magical senses)
----------------
Read (PUSH) Mode: Distance to object. If negative, then this distance is to an object you cannot magically target; If positive, then this is the distance to a valid target.
----------------
Write (POP) Mode: Aims your magical-senses to a specified angle and pulses your magical sense. The PUSH SENSE value will not change unless you POP a new value first.
----------------
*2*
Register: CAST (the dolop of magical energy you release)
----------------
Read (PUSH) Mode: Returns damage inflicted as a result of a previous shot.
----------------
Write (POP) Mode: POPing a value to the CAST register causes your magic to "fire" with a range equal to the value written.
----------------
*3*
Register: FOCUS (the thing your energy fires out of, like a wand or hand)
----------------
Read (PUSH) Mode: Returns amount of energy you used (think temperature).
----------------
Write (POP) Mode: Physically swings your focus to specified angle (a circle has 360 degree).
----------------
-The Stack:
Each Wizard has a Stack in his mind. It is on the stack that magical energies are channeled and controled, and it is by the will of the Wizard the stack is powered. When you PUSH a value from a register, it goes to the top of the stack (TOS) and pushes down any magic currently on the stack one spot. When you POP a magical value to a register, it comes off the top of the stack and any magical values left on the stack pop up one spot. Any attempt to POP a value when the stack is empty results in an error (a miscast).
Next, it would be nice to know how to use your senses. Your sense is controlled by the SENSE system register. When you store an angle to SENSE, a magical pulse is sent out along that beam. The distance to the target is returned by reading (PUSHing) the SENSE register. If the target is valid, this value is positive, if it's resistant to magic, it's negative.
-First Spell:
I think we know enough now to begin to code our Magic Missile spell.
Imagine we want to set a chair on fire. But, at first, we don't know where it is, so we have to scan our environment for the target. We begin scanning in a circle with our magical-senses, and once we locate the chair we point our wand at it (or finger) and blast it.
Let's start by deciding that we'll keep track of the current sense angle in user register "S". We'll initialize register S to zero at the beginning of the program:
... PSHI 0 ; Load a zero onto the stack
... POP S ; and store it to the S register.
Next, since the width of your sense-beam is ten degrees, we'll start a loop where we'll increment the angle by ten degrees, see if something's there and, if not, go back and increment again:
... PSHI 0 ; Load a zero onto the stack
... POP S ; and store it to the S register.
LOOP: ; Label of start of loop.
... PUSH S ; Load current S.
... PSHI 10 ; Load the constant 10.
... ADD ; Add 'em together.
... POP S ; Store back to S.
... PUSH S ; Load current S.
... POP SENSE ; Reach out with your magical-senses.
... PUSH SENSE ; Load target distance.
... PSHI 0 ; Now, test if we sensed a valid target.
... JLT LOOP ; Jump if Less Then zero to LOOP (keep scanning).
All of the jump instructions with two operands operate similarly: the top two elements of the stack are compared and popped off the stack. If the condition specified is true, the jump is performed to the label in the instruction. Remember the operands are popped in the execution of the instruction. Also, a good way to remember how to PUSH the operands on the stack is to note that they go onto the stack in the same order in which you would write them down. For example, if you want to code
IF A > B THEN GOTO MYLABEL:
you would first PUSH A then PUSH B and then perform the conditional jump instruction. Well, our spell-program looks pretty vicious ...
What do we have on the top of stack (TOS) if we do not jump back to LOOP: ? If you're with us, you could quickly answer that we've got the target distance on TOS.
Burn it with fire!!
... PSHI 0 ; Load a zero onto the stack
... POP S ; and store it to the S register.
LOOP: ; Label of start of loop.
... PUSH S ; Load current S.
... PSHI 10 ; Load the constant 10.
... ADD ; Add 'em together.
... POP S ; Store back to S.
... PUSH S ; Load current S.
... POP SENSE ; Reach out with your magical-senses.
... PUSH SENSE ; Load target distance.
... PSHI 0 ; Now, test if we sensed a valid target.
... JLT LOOP ; Jump if Less Then zero to LOOP (keep scanning).
SHOOT: ; Shoot the bleeper.
... PUSH S ; Load current angle.
... POP FOCUS ; Move your arm and/or wand (or staff) around.
... PUSH SENSE ; Load the distance again.
... POP CAST ; Cast your magic missile.
Finally, we can bundle up these operations into a Semantic motion: SetTarget(chair), and a Verbal trigger: EmitFire()
+
+
+
Maybe I'll make up more stuffs later. Prolly not. Cheers!
|
|
| 2 people marked this as a favorite. |
Oh, we're not allowed to just call rand()?
I think that if you're going to use magic-as-programming, that you need to leave a big role for tried-and-tested scripts.
What do you mean? Can you elaborate?
I did have the idea that you can purchase scripts, but you can't customize them or make your own without skill.
[At first glance I thought you weren't aware of the concepts of libraries and "batteries included" built-in functionality. On re-reading, you turn out to be asking an interesting question.]
---
I think that most combat-useful spells would be too complex to completely assemble in 6 seconds (1 round). You'd basically want to prepare as much as possible, and then just store them in a cache somewhere and execute the final bit when needed. (Rather like Vancian spell preparation.) However, if you think of spells as being mostly "knowledge" -- code is knowledge too -- then "forgetting" a "memorized" (pre-cached) spell makes little sense.
So should we instead use the Sorcerer as a model, instead of a Wizard? A sorcerer doesn't "forget" his "memorized" spells (his Spells Known) when he casts them. He can't easily load new ones into memory though. Sorcerers are a sort of "read only" casters.
However, the Arcanist is just perfect. You pre-cache the spells you want fast access to, and can cast them as long as you have energy remaining.
---
On to scripting, libraries, compilation and interpreted code and such. I think here we need to veer away from PF spellcasting a little bit and look at magic systems in RPGs in general.
You might have a "systematic" magic system, where you learn basic fire spells before learning advanced fire spells. Where you start out by learning basic principles before you can learn advanced principles. This kind of system is found in Ars Magica as well as in it's sister modern-age game, Mage the Ascension. (And presumably in Mage the Awakening, but I never got through that book. Pages were too glossy to read comfortably.)
On the other hand, you can have "fragments of lore" systems, where each spell stands on itself. Mankind's knowledge of magic is rather haphazard; some ways to do various things have been handed down through the ages, but the connections between them are obscure. There are a lot of gaps. PF is a lot like this; you can learn Summon Monster V without learning 1-4. This style of magic has its own charms; you can have an obscure ritual to do something really specific, without first requiring a lot of broad understanding. Nice if you want to have a Sorcerer's Apprentice scenario :P
Fragmented magic is often associated with having only bits of knowledge from an earlier age of greater understanding (Atlantis etc.), or gaining the knowledge from people who won't tell you everything (bought from devils). Thematically you might expect this magic to be on the unreliable side; spells have weird side effects that are hard to explain or prevent. PF doesn't have that last part; spells are pretty reliable and side-effect-free. (Which I think is slightly disappointing.) This magic system also doesn't have a systematic way to devise (and as a GM, classify) new spells; it really is more an art than a science.
---
In a Magic Programming game, you'd expect the Systematic magic to be the foundation. The minutiae of how to use "machine-level" instructions for spells are known and can be learned through study, and doing so enables significant optimizations. That's a lot of hard work though, and there are also higher-level ways to build spells. Higher-level magic is less prone to coder error because it's much easier to understand.
Compiling spells - you could do all magic as Interpreted, but that'd be slow going. Instead, you might compile your spells in advance. They'll be faster to cast, but harder to change. Also, harder to understand and reverse-engineer for others. So they're good in combat, and any spells you buy from devils are likely to be compiled.
Casting "from the interpreter" is not quite as fast, and hard if you're stressed out due to combat. But it's more flexible and good for making up a custom spell on the spot to get past an unexpected obstacle. (This relates to wizards leaving some spells open for later preparation, but is in fact more flexible.)
Of course, you could (energy permitting) try an interpreted spell again and again until it's perfect, and then compile it for better performance in the field.
Libraries - most programmers use them extensively. So should spellcasters. Why write your own sorting algorithm if you have sort() available, which is probably optimal and bug-free? I haven't looked at Words of Power yet, but I guess a WoP might be a library function, while writing your own is more like wrangling with the GM about the appropriate cost/level of something you want to do.
---
Scrolls - these may need some re-evaluation. Why does the code "disappear" when used once? In this kind of game, such extreme DRM should make scrolls HARDER to make than a Page of Spell Knowledge.
Likewise wands - staves actually make more sense than wands, unless wands implement some sort of pay-per-use mechanic.
Burn it with fire!!
... PSHI 0 ; Load a zero onto the stack
... POP S ; and store it to the S register.LOOP: ; Label of start of loop.
... PUSH S ; Load current S.
... PSHI 10 ; Load the constant 10.
... ADD ; Add 'em together.
... POP S ; Store back to S.
... PUSH S ; Load current S.
... POP SENSE ; Reach out with your magical-senses.
... PUSH SENSE ; Load target distance.
... PSHI 0 ; Now, test if we sensed a valid target.
... JLT LOOP ; Jump if Less Then zero to LOOP (keep scanning).SHOOT: ; Shoot the bleeper.
... PUSH S ; Load current angle.
... POP FOCUS ; Move your arm and/or wand (or staff) around.
... PUSH SENSE ; Load the distance again.
... POP CAST ; Cast your magic missile.Finally, we can bundle up these operations into a Semantic motion: SetTarget(chair), and a Verbal trigger: EmitFire()
You can use a deck of playing cards (or index cards) and program your
spells into decks. Then, when you cast put the deck in front of you,on the table, and begin turning over cards -- if you don't generate a
programming error the spell goes off.
.
|
Do you have a specific programming language in mind to model after? I doubt you want assembly (that ask for a little too much work from your players, no?)
I think your idea of a cyber world where spells are cast via scripts is awesome! I am assuming, however, that most of your group has some background with computer programming? Or is this to be a learning experience?
One of the larger concerns I see is explaining how their scripts that they've been using since level 1 is now 5 times better at level 5. Do you plan to say that the system in which they play gives their scripts more power? They upgraded the machine they are using to connect to your virtual world? Did they gain higher privilege level in the system (upgrading from "player" to "GM" to "Administrator" and various levels in-between)? Of did they decide to peek inside the scripting library that they were using and they keep finding places to improve the efficiency and effect of functions within that library (This is the one that's closest to how I envisioned PF wizards becoming more powerful)?
Some other spells and what they might look like:
Truestrike = new touchEffect();
Truestrike.charges = 1;
Truestrike.range = touch;
Truestrike.effect = modifier.attack.add(20);
Target = concentrationFocus();
Fireball = new areaEffect();
Fireball.range = long;
Fireball.areaEffected = spread(radius, 20ft)
Fireball.effect = modifier.hitPoints.damage(x * d6);
Fireball.graphics.source = "graphics/flyingFireyBall.grs"
if (Target.distance > Fireball.range)
Abort;
else
{
Fireball.effect.execute();
Fireball.graphics.execute();
}
Do you have a specific programming language in mind to model after? I doubt you want assembly (that ask for a little too much work from your players, no?)
It's not assembly it's a Turing Machine. Also, I'm happy for you to use
any higher level language which pleases you. It all eventually becomes1's and 0's on a Magical Turing Machine™.
I'm working on a theory to "explain" Vancian Magic using a Turing
Machine. It's a running idea; essentially, when you prepare a spell what
is created in the mind is a stored-up tape. The tape runs on a Magic
Turing Machine™, and when it's done executing, it is gone from the
caster's mind due to it being out of energy. (This compares to how after
using a Vancian Magic spell, it's gone because it's forgotten.)
I also like the D&D 5e adjustment to Vancian Magic. Casting a
lower-level spell in a higher slot *may* be modeled by PUSHing a higher
value onto a particular System Register. (This thought is completely
experimental and has not been tested yet. Yet.)
.
Ascalaphus and Tensor, you posted some very serious food for thought there. Setting-wise, that might be how it all works, but probably a bit too much for a game mechanic. Regardless, I really enjoy reading your work there.
You can use a deck of playing cards (or index cards) and program your
spells into decks. Then, when you cast put the deck in front of you,
on the table, and begin turning over cards -- if you don't generate a
programming error the spell goes off.
This is a really cool idea. I like tangibles that could make a game more convenient and fun.
Do you have a specific programming language in mind to model after? I doubt you want assembly (that ask for a little too much work from your players, no?)
I envisioned modeling it off of an object-oriented scripting language because the in-setting purpose of the system is to give virtual objects functionality. So, a language designed to manipulate objects makes sense. I also looked at the Linden Scripting System for the metaverse game Second Life. Though event-based, it hosts a large set of functions for manipulating objects and people as well as a permission system to help prevent hostile programming. I'm currently looking at perhaps looking over Ars Magicka and LSL's functions to create a set of functions as the basis for this system.
I'm glad you're intrigued by the setting. I once debated on whether the setting took place in the real world with software programs that invoke magic or be a virtual world. I ultimately decided virtual world because I haven't seen a game setting that took place entirely in a virtual simulation. Even the Matrix was a very minor part of Shadowrun.
In regards to how a scripter gets more powerful, my current vision of system requires that anyone wanting to invoke scripts like a wizard requires a software interface that allows them to do so. If you want to throw a fireball, you need a software application that will allow you to execute the fireball script, either by hand gestures, a verbal command, or a virtual computer that lets you just activate it through a menu. This software also helps control the technical aspects of the scripts, such as resource management. While anyone can purchase such a software, a dedicated scripter creates their own. As they become better, this software becomes more efficient and enables them to have more and more scripts slotted at the same time.
I really like the idea of setting a power level parameter, like setting a caster level. That's a really cool program of fireball and perhaps how I envisioned a script actually looking like in the setting. However, I don't really want to demand my players to know programming. Most of my friends aren't programmers in the slightest -- even a basic script looks like real code wizardry to them.
I am intrigued by your proposal and would like to subscribe to your newsletter.
Newsletter? Like something where I post updates on the system and setting?
Dot for later.
|
I am intrigued by your proposal and would like to subscribe to your newsletter.Newsletter? Like something where I post updates on the system and setting?
It's a snarky way of saying "dotted" for future viewing. This is actually something that one of my players wanted to do something with a year ago, so I'm waiting to send it to him and see what he thinks, considering he does programming for a living.
In true Vancian spellcasting, the spell is not normally forgotten (it can be burned out by overuse or a mistake though).
I find it funny how many people think DnD wizards use the Vancian system, when truth is it was merely inspired by the Vancian system.
--------------------------------
I definitely like the idea of doing this, though it needs to be a bit simpler I think.
Also, power level can be affected not by the scripts themselves, but by the mana available to the caster. So the mana is limited, but also, the cheaper the script is to run, the more easily mana can be recovered. Basically mana could be recovered at a rate proportional to the mana remaining (so having 3 mana remaining would take hours to recover another point of mana, but having 30 mana remaining would take a couple seconds to recover another point of point of mana)
In this way, a caster's power is limited by how mana they can hold as well as how much they are willing to spend. Casters want to run the cheapest scripts they can, but they can run more expensive ones if they need to.
As casters get better they are building their mana capacity which allows them to hold more mana making more powerful scripts viable, and doesn't even need any external excuse for changing their power levels.
------------------------
As for the actual scripts, have objects be used as integral class types of the world. The integral class types that are the objects/creatures of the world all have attributes, but are also two sided, the "server" side and the "client" side. A script can affect the attributes in two ways, the easy way is to add a modifier to these attributes, the hard way is to actually change these attributes. Normally only the "client" side of an object is accessible and is the part of the object that interacts with the world, while the "server" side of the object is normally inaccessible (the objects soul per say). Mana/energy is stored on the "server" side and flows through the "client" side to the world.
For a script to modify an attribute it either adds energy to the attribute (to increase it), or drains energy from the attribute (to reduce it) as it flows to the "client" side of the object. This is easy for casters to do, but is limited by how much energy is available, as once the energy runs out, the script ceases.
To change the attributes themselves requires much higher knowledge of scripts as well as hacking into the object's "server" side to change the attributes at the source. The "server" side is much more "complicated" (from the character's perspective anyway) and thus is very difficult.
When a caster casts a script they are actually creating a new spell object (which is formless, but has it's own attributes and energy/mana reserve) this new object can be attached to specific locations or other objects (the target of the script). The script is constantly expending energy/mana performing it's task, when that energy reserve runs dry, the script ceases to exist. (you could apply this concept to all objects if you wanted, but that adds the risk of perma-death because the "soul" becomes easy to destroy)
For scripts like fireball, and other creation scripts, the scripts can simply emulate the "client" side of a desired object, which then lasts till the script runs out of energy. Permanent objects could be created by creating the "server" side of the object, which then expresses itself through a "client" side like normal.
Fire and other effects are simply objects that have strong effects on nearby objects, so a fireball would be a short-lived script that emulates a fire object that can fill a 20' sphere, and ends when the script runs out of energy.
Illusions are the same, they just emulate sensory attributes but not mass/weight, or other similar attributes.
------------------------------
Sorry for wall of text and the poor writing.
|
|
The thing I wonder about is: how playable would this be? For greater understanding of the difficulties involved, I would suggest playing a few games of Roborally with your gaming group, and seeing how well they do at it.
I like the idea of programmed magic, but actually requiring players to come up with real programs would probably not be very playable; it'd slow down action scenes and you risk frequent arguments about how long a player has to decide what to do on his turn.
There's also the issue of player skill vs. PC skill. For an interesting "solution" to this dilemma, you might want to review the Mansions of Madness board game, specifically the puzzle mechanic.
MM puzzles are some tiles that can be moved according to some rules, until you get them into the right configuration. So a clever player will be able to figure out a more minimal set of required moves. But the PC's intellect determines how many moves you're allowed to make per turn. So a dim player with a bright PC or vice versa will do roughly equally well. (The smart player with smart PC will dominate, obviously. And if you're dim and your character is dim, you shouldn't be doing the puzzles.)
I think you should be focusing on creating a really really really high-level programming language, that still gives players the feel of programming the magic. However, it should be really easy to program "do what I mean" programs in it.
I think there's also a role for what Ars Magica terms "formulaic" magic vs. "spontaneous" spellcasting. Basically, a formula is a spell developed in the lab, and ready for field use. Spontaneous casting means making it up on the spot, and it's harder and more exhausting.
In this context, formulaic magic has been debugged in the lab and is basically a program the player's already written out before the current scene; whereas spontaneous magic means building up a spell right there. You could use the MM approach of only being able to write X lines of code per game turn if you're doing spontaneous magic; not a problem out of combat but in combat time matters, and formulae are faster.
|
|
@Tabletop Prophet: Don't worry, I wasn't saying what you wrote was assembly, I was referencing assembly because I've had to do quite a bit of it recently and... well... Assembly isn't the reason I want to be a Software Engineer for the rest of my life O.o.
If there's some worry about whether this might bog down the game, it might be a good idea to have these software programs that the players buy come with a wide assortment of already written spell scripts, some of the most basic, yet most widely used spells in the game. This would include spells from every level.
From there, players can start adjusting things. They can slightly change spells, or create entirely new ones based on the foundation that you've given, or they can stay comfortable and not change anything.
@Tabletop Prophet: Don't worry, I wasn't saying what you wrote was assembly, I was referencing assembly because I've had to do quite a bit of it recently and... well... Assembly isn't the reason I want to be a Software Engineer for the rest of my life O.o.
Actually, it was much closer to assembly language than to Turing machine code. Tensor seems to be under the misapprehension that Turing machines have stacks (and that operations like push and pop make sense when applied to Turing machines). Turing machines have an infinitely long tape and an attached state machine. While it's possible to simulate a Turing machine in a stack-based architecture, that's no more an actual Turing machine than is a random access machine (RAM), which is actually a lot more useful for writing computer programs on.
And it's still a bad-to-the-point-of-unplayable idea.
The players have no effective way to write code. More importantly, the game master has no effective way to determine if the code actually accomplishes what it's supposed to accomplish, or whether it's got a subtle (or not so subtle) bug.
From there, players can start adjusting things. They can slightly change spells, or create entirely new ones based on the foundation that you've given, or they can stay comfortable and not change anything.
... and as soon as adjustments are made, there's literally no way to determine whether or not their modifications will be effective.
Do you have a specific programming language in mind to model after? I doubt you want assembly (that ask for a little too much work from your players, no?)It's not assembly it's a Turing Machine.
Further to previous:
This is what an actual Turing Machine program looks like
A B C D E F
0 1RB 1RC 1LD 1RE 1LA 1LH
1 1LE 1RF 0RB 0LC 0RD 1RC
This particular program, for example, says that "if the machine is in state A and the tape cell under the read/write head is a 0, then write a 1 in that tape cell, move the head one space to the right (R), and transition to state B." There are six states, named A-F, plus a special H state that indicates the program halts.
Almost no one studies Turing machine programs, for what should be obvious reasons. If for some reason it's not obvious to anyone reading this thread, then I invite them to answer any of the following questions:
1) If I run this program, starting in state A, on a tape full of 0's, will it eventually halt?
2) If I run this program, starting in state A, on a tape full of 1's, will it eventually halt?
3) If I run this program, starting in state A, will it always halt irrespective of input?
and finally,
4) There is at least one input pattern for which this program (starting in state A) is known to halt. What is that pattern, and what is left on the tape after it completes?
Now, imagine that I miswrote the program as follows:
A B C D E F
0 1RB 1RC 1LD 1RE 1LA 1LH
1 1LE 1RF 0RC 0LC 0RD 1RC
I ask the same questions of the modified program. Remember that this represents a spell that you're supposed to be adjudicating in combat, so take up to a minute to answer....
Google had a virtual turing machine for their banner once. It was neat and should be checked out.
I will say that turing machines were not limited to ones and zeros though.
I agree that this project should feel like programming rather then be programming.
A possibility might be to do something with parameters.
A spell needs a target, range, duration, effect, etc.
The script could be about writing these elements together.
Each script is like a function, the player tells the function the expected parameters and how to use them relative to the caster.
For example the target parameter can be T, range R, caster C.
T = C-90 @ R
This would set the target of the spell 90 degrees to the caster's left at a distance of range.
The target could be selected at cast time to be a cone, sphere, nearest creature, etc.
|
|
I don't think I posted anything other than snark, so I'm not sure why people are quoting me as such...?
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.
Another reason I'm interested in this is my Iron God's character is going to be an Android Spellslinger who's magic is "re-skinned" as tech systems, and the flavour of this whole thread coincides nicely with that character's theme.
I agree the system should abstract software engineering to convey the experience of programming without requiring the players to know programming concepts.
I'm currently working on a skeleton of the system right now. I'm debating on whether simply making a list of functions or breaking the system down into Verb/Noun. If I made it Verb/Noun, the verbs might look like this:
Do, which forces an object or creature to do something
Get, which gets information about an object or creature or some characteristic of them
Set, which changes something about an object or creature. This can also include physics properties, like "velocity."
Rez/Derez, which creates or destroys objects or creatures
The nouns would be objects, creatures, and properties of objects and creatures. I could provide a list of properties that objects and creatures have.
I also thought of putting a limitation where, by default, a script can only affect its source (caster or enchanted item). In order to affect another creature or object, the script must either run a detection function or its source must come into physical contact with it. So to set someone on fire, you either have to throw a fireball at them that ignites on contact or scan the area to get the target's UID/truename and then have the fire ignite on them directly.
I don't think I posted anything other than snark, so I'm not sure why people are quoting me as such...?
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.
Another reason I'm interested in this is my Iron God's character is going to be an Android Spellslinger who's magic is "re-skinned" as tech systems, and the flavour of this whole thread coincides nicely with that character's theme.
I intended this to be a new system for my campaign setting that I'm adapting into Pathfinder. You might want to look at Spheres of Power when it comes out this August. It's a highly customizable alternate spell system. It's got some really cool features that make spellslinging more blasty.
|
|
@Cyrad: looks promising... interesting similarity to the AM system, but obviously not a 1:1 mapping. (Probably for the best; why be slave to someone else's theme?)
Have you considered an import/inherit verb?
One interesting in AM was the distinction between Muto and Rego, as well as the broad meanings of Creo/Perdo.
Creo makes something more like it's Platonic ideal; creating it but also repairing or healing (making it closer the the ideal).
Perdo is the reverse; not just destroying outright, but also damaging.
Rego makes an object do stuff that are inherently possible, based on its ideal. Sort of like using a member function. This also included teleportation, since "being somewhere" is normal functionality for objects.
Muto on the other hand made objects do stuff that they were NOT supposed to do. Turning a man into a frog violates the man's Platonic ideal; humans are not frogs. As a consequence, Muto effects couldn't be made permanent (nature always eventually reasserted itself), and caused Warping*, damaging the object. I would relate that to coercing objects to perform operations they're not correctly typed for. There are also so inheritance conflict possibilities here.
*I think it was called that.
So that's basically why I wondered about using inheritance as a mechanic. It's entirely possible that the whole concept of object-orientation was inspired by Platonic archetypes, and in AM the concept of Forms (the nouns) clearly smells of Inheritance. PF, too, resembles object-orientation, with objects (characters) that belong to classes with class features (methods). Races, creature types and subtypes are also examples of inheritance at work. If it were just a bit more consistent, PF would be perfectly suitable for modeling on the computer.
Side note: in Ars Magica there were occasional mentions that the "heretical" house Diedne had developed a sixth Technique: summoning/invocation.
Do, which forces an object or creature to do something
Get, which gets information about an object or creature or some characteristic of them
Set, which changes something about an object or creature. This can also include physics properties, like "velocity."
Rez/Derez, which creates or destroys objects or creatures
If you separate Rez and Derez, you've basically reskinned the five ArM verbs: Rego, Intellego, Muto, Creo, and Perdo. The only real difference is that you've moved motion from Reg/Do to Muto/Set, which may result in Muto/Set being overpowered.
The nouns would be objects, creatures, and properties of objects and creatures. I could provide a list of properties that objects and creatures have.
I doubt it. There are just too many properties. I think this is something better left off-screen.
I also thought of putting a limitation where, by default, a script can only affect its source (caster or enchanted item). In order to affect another creature or object, the script must either run a detection function or its source must come into physical contact with it. So to set someone on fire, you either have to throw a fireball at them that ignites on contact or scan the area to get the target's UID/truename and then have the fire ignite on them directly.
This seems an unneeded restriction. What in-game problem does it solve?
@Ascalaphus
Now that you mention it, I realize that AM's concept of Creo works very well for vScape, the setting I'm designing this system for. In vScape, a creature's body is just an virtual object. A body cannot actually heal because it's not real flesh and blood. In order to heal an injury, you must repair it by creating new flesh and melding it with the body. So creation has a connotation with healing. Though, Rez/Derez involve setting details that definitely do not model AM, which I might have to elaborate on later.
I'm not really sure how an import/inherit would work. Though, I pictured the system would have inheritance in mind. vScape treats a creature's body as a subclass of object, so any function that works on an object will also work on a creature's body. It probably does lend pretty well for Pathfinder's creature types, though some (like undead and outsiders) might not apply to the setting.
I pictured there does not exist functions that directly harm an object. In other words, there's no analog to the inflict spells. Any damage comes as a result of a hostile (or careless) application of a script function. The frog example you gave is a good. Warping a person's body, making it do painful and destructive poses, creating projectiles, etc. A scripter has to be creative with their destruction!
If you separate Rez and Derez, you've basically reskinned the five ArM verbs: Rego, Intellego, Muto, Creo, and Perdo. The only real difference is that you've moved motion from Reg/Do to Muto/Set, which may result in Muto/Set being overpowered.Do, which forces an object or creature to do something
Get, which gets information about an object or creature or some characteristic of them
Set, which changes something about an object or creature. This can also include physics properties, like "velocity."
Rez/Derez, which creates or destroys objects or creatures
You have a point here, though I should have elaborated that Rez and Derez might have very significant differences from Creo and Perdo due to the context of the setting. I honestly can't see scripters specializing based on Verbs. Instead, they would specialize based on Nouns. You'll never hear a software engineer say "I'm experienced in coding mutation methods!" but a software engineer might say they're experienced in writing software for web sites, databases, mobile applications, or games. I don't think verb balance would be an issue other than avoiding clumsy organization.
The nouns would be objects, creatures, and properties of objects and creatures. I could provide a list of properties that objects and creatures have.I doubt it. There are just too many properties. I think this is something better left off-screen.
Hm, that's true, but then there would only be two nouns. Maybe a broad list of properties or a broad list of different types of objects and creatures?
I also thought of putting a limitation where, by default, a script can only affect its source (caster or enchanted item). In order to affect another creature or object, the script must either run a detection function or its source must come into physical contact with it. So to set someone on fire, you either have to throw a fireball at them that ignites on contact or scan the area to get the target's UID/truename and then have the fire ignite on them directly.This seems an unneeded restriction. What in-game problem does it solve?
There's a number of reasons for this.
1) This makes the system not analogous to an existing spell system.
2) Scripts that target objects/creatures directly inherently cost more points to slot because they require more functions to carry out.
3) Non-scripters would be mostly limited to scripts that buff themselves or require attack rolls because their store-bought script interface systems have much fewer power points to allocate than a scripter's custom interface system.
4) Though not an in-game reason, it also mimics how object-oriented runtime environments work and how Second Life's system works.
Maybe I could just simplify it by having targeted scripts require a computer or some kind of device for target selection.
What do you think of this?
Hm, that's true, but then there would only be two nouns. Maybe a broad list of properties or a broad list of different types of objects and creatures?The nouns would be objects, creatures, and properties of objects and creatures. I could provide a list of properties that objects and creatures have.I doubt it. There are just too many properties. I think this is something better left off-screen.
Well, to some extent, Pathfinder has already provided us with this. The difference between Charm Person and Charm Monster is that the former only affects "humanoids."
Again, this is going to get awfully ArM-ish, but that's basically what the nouns do. For example, each element could its own noun, so Fire.set() could make any changes to an existing fire you wanted, including moving it around, making it bigger, smaller, hotter, changing its color, and so forth. That's much more practical than talking to a combustion physicist and trying to figure out how many different things go into a fire.