Mana++: A RPG Spell Creation Language

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).

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).

"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).

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.

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 foul-smelling burp instead of a nuclear dragon breath 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.

I'm brainstorming the concept of using a Visual Scripting Language 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"]Spell - A Function Construct
[/font][font="Arial"]Rune - A Variable or Label Construct in a Spell. [/font]
Chant - Jump Construct
[font="Arial"]Scroll - A List,Queue,Stack,Vector Data Structure for Runes and Spells[/font]
[font="Arial"]Conjure - A Spell Cast (Function Call) within another Spell[/font]
[font="Arial"]Amulet - If...Else...ElseIf..Endif [/font][font="Arial"]Conditional [/font][font="Arial"]Construct In a Spell
[/font][font="Arial"]Talisman - Switch...Case Construct in a Spell[/font]
[font="Arial"]Casting Circle - Do,While,For...Loop Construct in a Spell[/font]

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.

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.

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.

I'm interested in this as me and a friend of mine actually tried - without success - to figure out something similar.

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.

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.

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.

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.

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.

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

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

http://www.youtube.c...h?v=dlJmKqi6EEc

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)

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?

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.

Thanks for the responses! Please forgive the following ramble.

A Written Language. 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.

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

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;
}


A Visual Spell Language (with emphasis on creating the spell, not just the visual effects of the Spell). I've examined the Visual Logic Editing approaches used by Kodu, Kismet, Alice, Scratch. 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 Script Systems and my plan is GUI-tize a stack-based Virtual Machine 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 Visual Logic Machine equally intuitive visually and for some reason I cannot get The Incredible Machine out of my mind.

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:

Element: Fire, earth, water, spirit, air, poison
Trigger type: 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)
Effect Area: scalable between 1-10
Strength: scalable between 1-10
Damage Type: 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.

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.

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

Tossing out super simple ideas here...let's start with some 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.

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)