# Mana++: A RPG Spell Creation Language

## Recommended Posts

Hello all,

I'm brainstorming the concept of using a [i]Visual[/i] [i]Scripting Language [/i]to create Spells within a RPG. The premise behind the concept is to use Programming as a Game Mechanic in which players can experiment in creating unlimited types of spells and devise strategies for Spell Creation and use. My current idea for Mana++ is to replace common Programming constructs with Magic Symbols and words associated with Magic:

[font="Arial"][b]Spell [/b]- A [i]Function [/i]Construct
[/font][font="Arial"][b]Rune [/b]- A [i]Variable[/i] or [i]Label[/i] Construct in a Spell. [/font]
[b]Chant [/b]- Jump Construct
[font="Arial"][b]Scroll [/b]- A List,Queue,Stack,Vector Data Structure for Runes and Spells[/font]
[font="Arial"][b]Conjure [/b]- A Spell Cast (Function Call) within another Spell[/font]
[font="Arial"][b]Amulet[/b] - If...Else...ElseIf..Endif [/font][i][font="Arial"]Conditional [/font][/i][font="Arial"]Construct In a Spell
[/font][font="Arial"][b]Talisman[/b] - [i]Switch...Case[/i] Construct in a Spell[/font]
[font="Arial"][b]Casting Circle[/b] - [i]Do,While,For...Loop[/i] Construct in a Spell[/font]

The challenges are figuring out how visually represent spell and balancing their effect. Its not desirable for Mage 1st Class to know how to conjure "Nuclear Dragon Breath" Spell that can vaporizes everything instantly. I would suspect some form of costs to create and use spells would be applied. These costs would be in units of time, materials, mana, etc. For instance you would not be able to write certain constructs until you have obtained certain items or learned certain skills. I'm opened to ideas on this.

##### Share on other sites
Perhaps you collect statements as crafting materials? Could you imagine: "If can find one more amulet, I have an idea to make my fireballs homing!".

I think it would be cool if the number of lines to execute represented the channelling time(actual lines executed, so all the cases you skip in a switch wont count). It would leave room for players to create more efficient fireballs, could add a whole meta game to spell-crafting(which I suppose is the point of Mana++ in the first place). Plus it'll stop people from writing monolith spells that slow the whole game down.

I think it's a cool idea. Have you seen the 'Scratch' programming language, its has a cool way of visualising control statements so that they're easier to comprehend. You should probably do something similar for your crafting table, so that programming isn't a required skill to play(but still very beneficial).

##### Share on other sites
A free-to-play mmo that I tried at one point, Ryzom, used a system like that. I played the game for far too short a time to give a valid assessment of how well the system works.

I do know that from the first time I opened the customization window and began understanding what was going on, I was very excited by the possibilities.

It used something that was akin to credits. At lower levels, you could make a spell with say 4 credits. At higher levels you could use 15 credits. That mechanic limited the low levels like you were talking about (Mage 1st class conjuring Nuclear Dragon Breath). It included having things that "gave credits" to the spell as opposed to only spending them. Reducing your spell's range for example gave a credit and I THINK you could increase the 'mana' cost and be given credits as well.

You can read a bit about their system in the Ryzom user guide, but it is just 2 pages of describing the system. You'd probably have to install and play to get a real feel for the system (unless someone on a blog or YouTube or wiki or something has already made an indepth breakdown).

##### Share on other sites
"Vector Data Structure"? For a player? No offence, but I think you lost your mind...

You are aiming waaay to high. It should be of the complaxity of the 8bit computers's BASIC at most (and it is still for hardcore players).

##### Share on other sites
Colobot did well with implementing a programming language into their game. I quite enjoyed it, and learned some stuff along the way.

But stil, making the game itself would be an absurdly difficult task. Especially with ballancing and predicting what kind of crazy ass combinations the players will think up. The in-game magic compiler will drop dead fast.

##### Share on other sites
If a spell shapes magical energies to affect the world according to the sorcerer's will, you have some good ideas about shaping complexity but you are neglecting both the energies and the world.
Do you have something that can be used as a power source, so that beginner mages can perform only a [b]foul-smelling burp [/b]instead of a [b]nuclear dragon breath[/b] of the same complexity?
What are the "primitives" of your spell "programs"? I'd expect nuclear dragon breath to need something like plutonium, something dragon related (e.g. drinking dragon blood) and maybe a good deal of elemental air, while a modest foul-smelling burp should be fueled by common foods, produced by simple concentration, and propelled (much less far) by mere force of lungs.

##### Share on other sites
[quote name='T e c h l o r d' timestamp='1317979942' post='4870042']
I'm brainstorming the concept of using a [i]Visual[/i] [i]Scripting Language [/i]to create Spells within a RPG. The premise behind the concept is to use Programming as a Game Mechanic in which players can experiment in creating unlimited types of spells and devise strategies for Spell Creation and use. My current idea for Mana++ is to replace common Programming constructs with Magic Symbols and words associated with Magic:

[font="Arial"][b]Spell [/b]- A [i]Function [/i]Construct
[/font][font="Arial"][b]Rune [/b]- A [i]Variable[/i] or [i]Label[/i] Construct in a Spell. [/font]
[b]Chant [/b]- Jump Construct
[font="Arial"][b]Scroll [/b]- A List,Queue,Stack,Vector Data Structure for Runes and Spells[/font]
[font="Arial"][b]Conjure [/b]- A Spell Cast (Function Call) within another Spell[/font]
[font="Arial"][b]Amulet[/b] - If...Else...ElseIf..Endif [/font][i][font="Arial"]Conditional [/font][/i][font="Arial"]Construct In a Spell
[/font][font="Arial"][b]Talisman[/b] - [i]Switch...Case[/i] Construct in a Spell[/font]
[font="Arial"][b]Casting Circle[/b] - [i]Do,While,For...Loop[/i] Construct in a Spell[/font]
[/quote]

I had a similar idea a little while ago, so naturally I think it's a neat idea. However, I think what you have here is *not* a visual scripting language. It's a procedural scripting language that's been obfuscated by replacing various keywords with random magical sounding words. I'm trying to imagine what a spell might look like, and it's just looking weird. Furthermore I don't quite see how any of this actually translates into a magical spell. How do I make a fireball?

The way I'd imagined it working is as a genuine visual scripting language similar to Kismet, but much higher level. Forget variables, loops, functions etc - what you want is fairly well defined functional primitives - categorised according to their basic function - with various inputs and outputs which can be linked together to give a final result.

You might have a set of symbols which represent the different elements, for example; fire, earth, water etc. You might have another symbol which summons stuff. Linking them together with yourself as the target might enable you to summon a stone in your hand, for example. Perhaps you can then create another similar pairing, which summons fire, only this time with the stone as the target, to create a flaming stone. Finally, you might also have a symbol to turn an object into a projectile. Set your flaming rock to be the target of this effect and suddenly you have a spell which enables you to fling burning rocks at people. Additional effects might be able to add an 'on hit' effect, to make the fireball explode on impact.... and so on.

##### Share on other sites
Its the same idea as scribblenauts actually only instead just with magic spells. Unless this game does not have a story, how does the player get the ability to write any spells? does it have limitations or conditions? So like if I saw "Hocus pocus" does the spell create an event or does it create something else?

There's a difference between spells and magic words. If you're using spells, then nobody can come up with them because there are not much of them. However if you use magic words, there are so many things. So if you can program every magic word and make the game in some way that the player can use the magic to solve puzzles or whatever, it will be good.

I leave it to you. I don't know advanced programming so good luck on that.

##### Share on other sites
Your idea is quite bold, I must say. But like they said, a spell would be quite weird. Try to write some spells using the things you described here, but I don't see something THAT complex actually working right. You should probably work mainly with IFs. For example, the more IFs an effect has, the stronger the effect can be. Adding else to that is also cool.

Maybe you could be able to reprogram a spell in the middle of battle. That would also be cool, you could create a perfect spell for that situation( a "perfect" spell would finish random battles at once, which would feel pretty rewarding).

But if you wanna do something like that, then maybe you could use a cost system, different programming commands would have different costs. Or something.

##### Share on other sites
I'm interested in this as me and a friend of mine actually tried - without success - to figure out something similar.
[quote name='Sandman' timestamp='1318065336' post='4870428']The way I'd imagined it working is as a genuine visual scripting language similar to Kismet, but much higher level. Forget variables, loops, functions etc - what you want is fairly well defined functional primitives - categorised according to their basic function - with various inputs and outputs which can be linked together to give a final result.[/quote]We did something different instead. We tried to model mana as "flowing water". Initially, it was essentially a "pipe dream" like minigame. As the player would have progressed in level, he would have got access to more capabilities, valves, pumps, the ability to route pipes one above the other or to get the rid of the grid completely. Ideally, at the end he would have transitioned to scripting.

Unfortunately, the idea was way too complicated and we couldn't quite finalize it beyond the initial stage. While the "flowing water" concept simplified quite a lot the notions involved in measuring "spell power", as well as providing some interesting constructs such as flow/pressure, mapping those notions to the interactive environment proven to be fairly difficult. As he needed to find a full-time job, we had to drop the project. I still think this could work somehow, my biggest fear is the complexity involved would just drive away most.

##### Share on other sites
[quote name='Sandman' timestamp='1318065336' post='4870428']
You might have a set of symbols which represent the different elements, for example; fire, earth, water etc. You might have another symbol which summons stuff. Linking them together with yourself as the target might enable you to summon a stone in your hand, for example. Perhaps you can then create another similar pairing, which summons fire, only this time with the stone as the target, to create a flaming stone. Finally, you might also have a symbol to turn an object into a projectile. Set your flaming rock to be the target of this effect and suddenly you have a spell which enables you to fling burning rocks at people. Additional effects might be able to add an 'on hit' effect, to make the fireball explode on impact.... and so on.[/quote]
I thought of something very similar to this recently. My idea used runes and recipes. A rune represents a certain magical element, like fire, wind or life. A recipe represents a certain effect: summon, projectile, enchant, explode, etc. Put a fire rune in a projectile recipe and you have a fire bolt. But, if you put that fire rune in an explosion recipe and then put the explosion in a projectile, now it's a fireball that explodes on impact. All spells you can create are simply different ways of nesting recipes together.

##### Share on other sites
[quote name='Suspense' timestamp='1318348817' post='4871482']

I thought of something very similar to this recently. My idea used runes and recipes. A rune represents a certain magical element, like fire, wind or life. A recipe represents a certain effect: summon, projectile, enchant, explode, etc. Put a fire rune in a projectile recipe and you have a fire bolt. But, if you put that fire rune in an explosion recipe and then put the explosion in a projectile, now it's a fireball that explodes on impact. All spells you can create are simply different ways of nesting recipes together.
[/quote]

Sounds a lot similar to this alchemy game which I saw from ipod.

##### Share on other sites
Look at space chem for how to beautifully use programming concepts to have a game. Then keep looking at the more complex examples..

##### Share on other sites
I think it's a cool idea and most of you are forgetting it's visual, so it makes sense.

I see a way it could work, but it would take a lot of effort.

In my opinion you would need to have three sections for a spell (Also calling functions spells is a bad idea, maybe call them constructs) Cast, Continuation, Death for Initialise, Update and Destroy (Destroy would only be able to be done by the spell itself).

The truly hard part will be making sure that someone is limited based on level they are at. There will be people that could come up with something that would break your algorithm and allow them to make a super powerful spell. OR your algorithm will be really bad and no-one below like level 50 would be able to make anything. (That kind of makes sense, keep it to people who have achieved ancient-hood or something)

##### Share on other sites
You have some concepts, but you're missing a system...

Runes could be types of spells, for example elements, represented by symbols.. A circle makes a protective field, a line is an attack, so you draw a circle and put a rune on it, say for fire, and you have a fire shield. Whether this shields from fire or ice is up to you. You draw a line with a rune at your end, and it shoots fire. You use a conjure function with the fire rune(/variable/input) and it summons an efreet. Wind would call a djinn, maybe.

You would only have a limited number of variables, with specific functions represented by things like lines and circles. For example, the rune set is the allowable variables for inputs, and the circle shield or line attack are functions which produce the desired output.

Programming on the fly during a game is something I would find cool, but it's quite a bit to learn just for casting a fireball spell. Why would I want to write a whole function when I could just hit the fireball spell icon and go?

##### Share on other sites
Two Worlds has a similar system. Each spell consists of a "Carrier" and "Effect". The Carrier may be, for example, a combination of the runes Fire and Arrow, and the effect may be "Fire" and "Area" which means that you will shoot a fire arrow that will explode upon hitting target. Basically, you put an element (Fire, Ice, Poison) and a type (Arrow, Area, Enchantment, Summoning) to both carrier and effect and that's how you create the spell.

##### Share on other sites
Thanks for the responses! Please forgive the following ramble.

[b]A Written Language. [/b]My example of Mana++ was an analogy. However, using a typed language for Mana++ could be a good place to start, or at least offered as an optional command line interface. I would prefer to use a syntax closer to spoken language than that of popular computer languages(ie C++). The notion here is to provide a sense of realism such as invoking a spell verbally as you read it aloud from a Grimoire. But, who knows, L33tspeak could be popular for casting spells in a Computer RPG.

For starters, Mana++ would be syntactically reversed in construct declaration and would compile constructs based on context of usage. Thus a construct may serve many different purposed based on context. I by default would use English (although i think latin would be more fun and challenging).

In Mana++, you name the construct followed by the Construct Type or Data type. The interpreter would parse the statement ignoring optional inert fill words like (the, a, of) and only acting on active keywords like is (=, ==). You could place inert filler words anywhere in the statement and the parser will ignore them.
[i]
The fireball Spell
Create the greatballoffire Rune from a Projectile
The greatballoffire's life is created from a timer that decrements by 30 Ticks per cycle
Cast Circle of throwgreatballoffire until it's collision occurs
move the greatballoffire's in the forward dirction of 1 meter until greatballoffire's collision occurs
if greatballoffire's collision occurs with a Enemy then Enemy's penalty recieves the degrade Spell
End throwgreatballoffire
The End of the fireball[/i]

[code]void fireball(void)
{
Projectile* greatballoffire Rune = new Projectile;
greatballoffire.life = new timer(30 * 1);
Meter* movement = new Meter;

throwgreatballoffire:
greatballoffire.direction.forward = 1;
impact Target = greatballoffire.collision;
if (Target == Enemy)
{
}
if(collision == true) goto throwgreatballoffire;
}[/code]

[b]A Visual Spell Language [/b](with emphasis on creating the spell, not just the visual effects of the Spell). I've examined the Visual Logic Editing approaches used by [url="http://research.microsoft.com/en-us/projects/kodu/"]Kodu[/url], [url="http://www.udk.com/features-scripting.html"]Kismet[/url], [url="http://www.alice.org/index.php?page=what_is_alice/what_is_alice"]Alice[/url], [url="http://scratch.mit.edu/"]Scratch[/url]. But what has really captivated me is the Little Big Planet's approach to Logic Circuits. What I admire about LBP's Visual Logic Circuit implementation is that complexity level is scalable. Simple circuits can be combined to create more complex ones. Additionally, LBP's visual representation is unlike any of the others described above. It makes a beautiful game out of creating mundane logic. That philosophy is on par with what I desire to deliver.

I've pondered over approaches to Visual Logic Editing. My current idea based on my experience in writing [url="http://forum.thegamecreators.com/?m=forum_view&t=116663&b=1"]Script Systems[/url] and my plan is [i]GUI-tize[/i] a stack-based [url="http://en.wikipedia.org/wiki/Virtual_machine"]Virtual Machine[/url] with a relatively small Visual Logic Instruction Set. The Logic Circuitry (Input/Output Connection) System that Kismet and LBP uses does appear to be very intuitive. The trick for me, will be to find a way to make [i]Visual Logic Machine[/i] equally intuitive visually and for some reason I cannot get [url="http://en.wikipedia.org/wiki/The_Incredible_Machine_%28series%29"]The Incredible Machine[/url] out of my mind.

##### Share on other sites
I would have some kind of system where you can combine attributes of a spell into one spell as mentioned before like a recipe. As an example, you could have the following attributes:

[b]Element[/b]: Fire, earth, water, spirit, air, poison
[b]Trigger type[/b]: impact, timer, trap (enemy enters into the effect area), threshold (triggers when a certain threshold is met such as HP of target drops below a certain value)
[b]Effect Area[/b]: scalable between 1-10
[b]Strength[/b]: scalable between 1-10
[b]Damage Type[/b]: slow bleed, instant damage

Each attribute has a certain cost of mana and posssibly cast time associated with it. So maybe impact costs hardly anything but threshold costs a lot. You could also not have certain attributes available until they reach a certain level.

One of the harder parts to me is how to visually represent the spell on the screen for every combination so that it accurately represents the spell.

##### Share on other sites
I think the difference between what you're proposing and what you seem to be aiming for (i.e., fun!) is the difference between writing a compiler and writing a game. You want a spell creation system that is fun to use, but you seem to be intent on implementing that system by forcing the players to learn a non-trivial programming language.

Why not start from the fun side and work BACKWARDS? Someone else already touched on this. Enumerate the possible effects you want in your spell system. Then list some different methods/vehicles of producing those effects.

****************************************

Heal - adding health to a target

Harm - removing health from a target

****************************************

'K. Now we need some METHODS:

Create - causes to come into being

Remove - removes from existence

****************************************

And a VEHICLE (conveyance, pathway, etc.):

Project

****************************************

And so...

Create Heal - heals the caster
Create Harm - hurts the caster (derp!)

Remove Heal - cancels a heal on the caster (more below)
Remove Harm - cancels a harmful effect on the caster (more below)

Project (Create Heal) - heals the target
Project (Create Harm) - hurts the target (there we go!)

****************************************

Some basic assumptions: all spells are targeted on caster without the Project vehicle, and all spells while not necessarily instant cast are instant EFFECT (i.e., once casting is complete the effect takes place immediately).

With that said we could add a TIME MODIFIER:

Repeat - repeatedly casts the heal without further caster involvement

Said modifier would require increased initial investment of mana/power and could have diminishing effect.

****************************************

And so...

Create Heal Repeat - heals the caster over time
Project (Create Harm) Repeat - hurts the target over time

Now Remove Harm makes more sense, as well as Project (Remove Harm) and even Project (Remove Heal) to strip an enemy of a heal over time effect. And what about Project (Remove Heal) Repeat? Heh. Keep the target from getting any further heals for a bit. But how could you remove the (Remove Heal) Repeat? Lol! Perhaps we need another EFFECT, or maybe we could be loose and say Harm applies to any harmful spell.

We've now got 2 EFFECTS, 2 METHODS, 2 VEHICLES (self+project), and 1 TIME MODIFIER giving us a grand total of 16 possible spells. Yeah, some of the combo's are...weird, but I can envision situations where there could be a use (e.g., you're walking through a field of magical sleeping poppies, so you cast a Create Harm Repeat on yourself to keep from falling asleep).

Some of the removes are kinda' useless so we probably need another TIME MODIFIER:

Wait [Until/For] - until meaning not triggered until needed, meaning opposite effect; for meaning not triggered until same effect (examples below)

****************************************

There we go!

Now we can do...

Create Heal Wait [Until] - heals caster on next harmful effect received
Create Heal Wait [For] - heals caster on next heal effect received

Project Create Harm Wait [Until] - harms target when target receives next heal effect
Project Create Harm Wait [For] - harms target when target receives next harm effect

Remove Harm Wait [For] - removes next harmful effect on caster before it is applied!
Remove Harm Wait [Until] - would read Remove Harm Waiting Until [next harm is needed], which would mean confusingly enough when the next heal effect is received - cast this and the next heal effect you receive also triggers a remove harm on yourself which would be useful if you see you've been afflicted by any kind of Create Harm Wait

****************************************

Which brings me to some particulars. To make Waits worth casting I would think they would make the cast spell require LESS mana/power, since there is no immediate effect required. Conversely to balance this I would think the effect of a Wait spell should be less than a non-Wait spell when appropriate (e.g., a Project Create Harm may do 100 damage whereas when a Project Create Harm Wait [Until] fires off on a just healed target it only inflicts 75).

Anyway, those are just some random thoughts. And I didn't even add in ELEMENTAL modifiers.... (!)

Project Create [Fire] Harm
Project Create [Water] Heal Repeat Wait [Until]

Or FOCUS modifiers... (!!)

Area Project Create [Fire] Harm
Area Create Heal Wait [Until]

Every single one of the above items (modifiers, effects, vehicles, etc.) lends itself very well to any kind of graphical UI for spell creation. Each one could be assigned a different power cost and level of effect, and you could very easily allow the spell creator to "enhance" the effect by dumping more power into the spell. That way your generic level 1 Mage would only have say 10 mana to dump into a spell but your level 10 Mage might have 100. Ramp up the Harm effect, extend the Wait duration, or lengthen the Repeat. Increase the Area. Etc., etc.

Take care, and cool idea! Love to see it in a game some day.

##### Share on other sites
To be honest I'm holding the view that if the user needs to type anything, you probably failed at making a game. and made something close to a simulation or programmer challenge.

Typing just isn't "magical", it's something everyone does everyday just about. Typing also doesn't follow basic rules of "learning(from the ground up)", the basic one being "something must be able to happen by accident, and be repeatable". Meaning you lose a lot of "general community" target base.

_____________

The best example that comes to mind is The Elderscrolls alchemy system

Then spacechem. I actually use this game as a warmup for programming, when I don't actually want to program.

_____________

If I were to design something from the ground up I would choose something like connect the dots.

Players are given a random field of spell effects(in halves and thirds). They then draw a circle, and two strokes(straight/curved line/squiggle). Any effect that is crossed is added the the final spell. You then save the spell for later use.

Expansions would include ways to clone the spells(enchanting), ways to add more circles and strokes(rituals, recoil, and similar)

##### Share on other sites
Interesting idea. Can't say I'm a big fan though.

If I were going to do it and I was concerned about balance I'd borrow from the constraints programs face.

Let the caster have mana, focus, and power.

Mana is analogous to electricity. Just like a computer expends electricity to run programs, a caster expends mana to cast spells.
A computer has an inexhaustible (for the purposes of this discussion) supply of electricity, whereas a caster has a finite supply of mana.
When the caster expends all of his or her mana, he or she must restore that supply before he or she can cast anymore spells.
Just like severing the supply of electricity to a computer terminates running programs, exhausting the supply of mana can have effects on spells.
A spell effect could not be as effective, or it might not apply to as many targets as it was intended to.

Focus is analogous to RAM. Just like program data occupies memory, aspects of spells occupy varying amounts of a caster's focus.
A video player might store the chunk of video and audio it is playing in RAM. A spell's targets could occupy a caster's focus.
A spell targeting a large number of specific targets would occupy more focus than an area of effect spell.
A spell with a large number of effects would occupy more focus than a spell with a single effect
Since many spells will be instantaneous, let them occupy focus for a certain time after they are finished. (This might be analogous to garbage collection.)
Spells that remain active for a certain amount of time will occupy focus for that amount of time.
Attempting to cast a spell that would occupy more focus than available could have effects.
A spell that overflows might not apply to as many targets as it was intended to, apply to targets it wasn't intended to, or change the targets of other active spells.
Or it might not apply as many effects as it was intended to, apply effects it wasn't intended to, or change the effects of other active spells.

Power is analogous to CPU. CPU executes program instructions sequentially.
As long as the CPU can execute instructions fast enough, it can switch between each program and run each so it seems like they run at the same time.
But if the number of programs gets too high, the CPU either focuses on certain ones (meaning others slow down significantly) or spreads out its execution too thin (meaning all slow down less significantly).
Faster CPUs execute program instructions faster than slower CPUs.
Let aspects of the spell involve power. A spell with ten targets could require the caster to have ten power available to cast in a second, but if a caster had fifty power available maybe it could be cast instantly.
But if the caster had five power available, maybe it would take three seconds to cast.

Source or code consumes disk space.
Let spells occupy space in spell books.
A spell book can be wrote to once or many times.
If a spell book can be wrote to once, a caster may not add new spells to it if it is full.
If a spell book can be wrote to many times, a caster must select which spell to overwrite.
Let writing to a spell book consume a small amount of mana, occupy a small amount of focus for a fair amount of time, and require a small amount of power for a fair amount of time.
This will prevent casters from swapping spells in and out of a spell book as needed in the heat of the moment.

These three constraints can play a big part in the game, like class/character attributes and feats.
A high focus caster can cast tons of weaker spells.
A high power caster can cast a few powerful spells.
A high mana caster can cast any spell over time.

I'm tired, so I'm sorry if this kind of got jumbled at the end. Hope it helps.

##### Share on other sites
What about function pointers, lambda expressions and closures?

##### Share on other sites
I had an idea slightly similar to this, but without an actual language.

Players could have an interface where they can set the range, damage, 'mana' cost, etc. of their spells, and they only had a certain amount of 'points' to raise/lower certain things. For example, more range costs points, less mana costs points, more damage costs points, etc. and the other way around for lowering range and such.

This is generally how designers would go about balancing spells, though they wouldn't keep such vigorous track over the specific amount of points you'd have to pay to do so and so.

You could also have the player specify the type of spell (area damage per second, projectile, area nuke, direct 'targeted' nuke, and so on) from an enum and have the option of adding special effects (stun, poison, 'mana' drain, and so on) from a drop-down list. Adding these effects costs points, and the amount of points effects cost raises if the type is area of effect and how large the radius/area of effect actually is. For example, the stun time costs 5 points for each .05 seconds, an additional 10 points per 25 radius, and so on. It could also add to the mana cost of the spell.

I can imagine this would also be difficult to program, but probably easier than what you originally had in mind. It would probably be hard to balance, but with a good deal of thought it might actually turn out interesting and maybe even...[b]fun[/b].

##### Share on other sites
[quote name='GHMP' timestamp='1320833191' post='4882057']
I had an idea slightly similar to this, but without an actual language.

Players could have an interface where they can set the range, damage, 'mana' cost, etc. of their spells, and they only had a certain amount of 'points' to raise/lower certain things. For example, more range costs points, less mana costs points, more damage costs points, etc. and the other way around for lowering range and such.

This is generally how designers would go about balancing spells, though they wouldn't keep such vigorous track over the specific amount of points you'd have to pay to do so and so.

You could also have the player specify the type of spell (area damage per second, projectile, area nuke, direct 'targeted' nuke, and so on) from an enum and have the option of adding special effects (stun, poison, 'mana' drain, and so on) from a drop-down list. Adding these effects costs points, and the amount of points effects cost raises if the type is area of effect and how large the radius/area of effect actually is. For example, the stun time costs 5 points for each .05 seconds, an additional 10 points per 25 radius, and so on. It could also add to the mana cost of the spell.

I can imagine this would also be difficult to program, but probably easier than what you originally had in mind. It would probably be hard to balance, but with a good deal of thought it might actually turn out interesting and maybe even...[b]fun[/b].
[/quote]

It's more along the lines of the interface. And since it's geared towards programming: that means they're looking for something that based on problem solving, something that can solve "undefined" problems, and something that takes mastery/understanding.

so in otherwords a really hard design problem if you want to keep it "clean", simple, understandable, and have a low barrier to entry(with high curve).

##### Share on other sites
[quote name='lithos' timestamp='1321232935' post='4883598']
[quote name='GHMP' timestamp='1320833191' post='4882057']
I had an idea slightly similar to this, but without an actual language.

Players could have an interface where they can set the range, damage, 'mana' cost, etc. of their spells, and they only had a certain amount of 'points' to raise/lower certain things. For example, more range costs points, less mana costs points, more damage costs points, etc. and the other way around for lowering range and such.

This is generally how designers would go about balancing spells, though they wouldn't keep such vigorous track over the specific amount of points you'd have to pay to do so and so.

You could also have the player specify the type of spell (area damage per second, projectile, area nuke, direct 'targeted' nuke, and so on) from an enum and have the option of adding special effects (stun, poison, 'mana' drain, and so on) from a drop-down list. Adding these effects costs points, and the amount of points effects cost raises if the type is area of effect and how large the radius/area of effect actually is. For example, the stun time costs 5 points for each .05 seconds, an additional 10 points per 25 radius, and so on. It could also add to the mana cost of the spell.

I can imagine this would also be difficult to program, but probably easier than what you originally had in mind. It would probably be hard to balance, but with a good deal of thought it might actually turn out interesting and maybe even...[b]fun[/b].
[/quote]

It's more along the lines of the interface. And since it's geared towards programming: that means they're looking for something that based on problem solving, something that can solve "undefined" problems, and something that takes mastery/understanding.

so in otherwords a really hard design problem if you want to keep it "clean", simple, understandable, and have a low barrier to entry(with high curve).

[/quote]

I am actually making a sort of spell creation language for my game although there is no programming involved.
Players find words of power all over the world. These words affect spell stats:
Type(elemental, healing, telekinesis, freezing, item buffs, etc)
Result(single target multi target aoe)
Range
Power
Mana
Duration

Players gather words from exploring ruins. They can make spells and sell grimoires that have the spells, but other players can't see the words. They can only use the pre-made spells.
They can sell or trade words to expand their repetoire. This allows wizards guilds who hoard their magic for members and such. It will be interesting to see how people utilize the system.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628402
• Total Posts
2982473

• 9
• 10
• 9
• 20
• 24