Hello all,

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]

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.

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.