A lot of games use "magic" of some type. Magic can actually be used to mean anything that is an arbitrary manipulation of the game world outside of the physical limitations of that world (i.e. it must be metaphysical). For a game we could essentially call gravity "magic", but that's not important to this discussion (or maybe it will be, once I'm done). My idea is to create a scripting language for a generic magic system in any arbitrary game willing to implement the scripting system. This could be turn based or real time games, FPS's or RPG's, etc. I think this would be a valuable tool for any game that wishes to implement magic in some way (that is, if properly designed). Since for the purposes of a game the actually, mathematical workings of the physical world are not as important as the observerd results of those workings, it would even be useful for non-magical type elements (essentially returning to times when people thought the world ran on magic). The scripts of "MageScript" would have a number of purposes. First, they must define all of the attributes of the world that they are capable of affecting. Traditionally we will think that a spell will affect a person's mana reserves and an enemy's health (if it is a destructive spell). These are attributes of characters in the game and have no physicallity to them, they are nebulous. But such a spell could also effect the items on your person, i.e. deplete the ingredients needed to cast the spell. So, spells positively and negatively effect various resources in a world, be they physical or metaphyical attributes of a person or object, or the quantity/quality of a specific item a person holds. Second, the scripts must define which creatures are capable of possessing which resources. Obviously, a non-magical creature will not have mana to deplete, so a spell to drain a target's mana will have no effect on this creature. A rock can be thought of as having "health" in that if we hit it enough times it will break, but it can't hold spell reagents. Third, it defines the methods in which a spell can affect the resources of the world. We may want to create a game where there are no such things as regenerative spells, so there is no need to define a method in which a spell INCREASES the value of a resource. Fourth, scripts define different ways in which one can target a spell. A spell can be targetted on the caster's person, or across the room at a group of people, etc. The spell can be thrown from a distance, or the person has to get up and touch the target, etc. Essentially, we are defining the scope of the spell (how many people it can affect at one time) and the range of the spell (how close the caster must be for the spell to be effective). So, to be able to define an exploding fireball spell, you would need to be able to have spells that affect an area of people as well as spells that fly through the air. Fifth, the system must define what type of objects are targetable. This probably would not be done in the script, it would be done in the code. If I want to be able to enchant a cloak with a spell of invisibility, I will have to define inanimate objects as targetable. Finally, the system would include a set of assemblies for performing all these actions. With a generous use of some OOP Interfacing, it should be possible to make it generic enough to drop into any game. At this point, a framework of magic has been created. Basically, we've defined our own arbitrary "chemistry set". From here, creating spells is just a matter of linking all of these previous attributes together and then assigning the result to a caster of spells. These spell definitions could be done as a script, or they could be done by the player in the game, as a sort of magic caster sim. This latter purpose is actually the ultimate goal, a more sim oriented magic system. I recall playing Ultima 4: Quest of the Avatar, in which you learned of the existance of spells in your travels, read books to find the ingredients for the spells, went to a magic shop and had the spell entered into your spell book (if you could remember what ingredients went into the spell) and then collected reagents like ash, pearl, fungus, etc (oh, the ellusive manroot!), in order to cast your spells. The really interesting thing was that you didn't necessarily have to find the list of ingredients for a spell, just hearing about it was enough to make it an option at the spell book shop. So, if you new a few of the ingredients (or remembered from a previous playing of the game), you could experiment with the spell maker until you got it right. While this may seem cheap, I found the ability of the player to be more proactive in their magic learning process than "Oh, I walked in a shop and now I know this spell" to be quite interesting; spells required actual knowledge. At this point, I'm looking for thoughts. Design, architecture, etc.

Why an entire scripting language? Why not a meta-system that can support any language? Why not a set of parallel scripts that do not need to be integrated with the game proper, but rather generate either data or code? Or, if none of that is appealing, why not just an extensino/library in a given language such as C++?

The dependency of a whole new language is what concerns me most.

What worries me about this design is that MageScript is no different from any other scripting language. Personally, I think that we need to stem away from the usual notion of magic in games, and get inspiration from the magic in literature and "real world" magic (at least for the ones who believe it; has anyone here seen "the skeleton key"?). But that's a bit off-topic. Unless your magic system offers a different kind of magic (one where you don't just specify the targetting type, type of particles and an effect such as heal), the only way I can see it any better than other scripting languagues would be with a point-and-click editor that eases the process, like the trigger editors in Starcraft and Warcraft III.

Whenever I come to a point in which I want to make a scripting language to make something easier, I always come to the conclusion that the scripting language should just be another step in the process that doesn't need to be seen by the user. The way I'd have this working would be to have a GUI that allows the user to create "spells" and in turn this GUI stores the data in an Intermediate Language, our scripting language, then the user's target language would import the script file appropriately. Using the script would allow not only multiple languages with the same scripting system, but it would also allow the user to debug (as far as what's scriptable) their program without having to recompile hundreds of files.

Quote:

Original post by Oluseyi Why an entire scripting language? Why not a meta-system that can support any language? Why not a set of parallel scripts that do not need to be integrated with the game proper, but rather generate either data or code? Or, if none of that is appealing, why not just an extensino/library in a given language such as C++?

I guess this is what I really mean. Basically, it should just be any system to abstract the definition of magic as data, not code, and this abstraction would ideally be as portable as possible, allowing for mass reuse of the data. I suppose I could say it's defining a "magic spell" file format.

And I'm certainly not advocating a full featured, turing complete language. I guess processing capability would not be necessary at all. Though I had initially thought it necessary for defining the methods in which spells effect resources, really these can be stored as mathematical equations, the equations being saved as data and parsed in the native code.

Though now I'm starting to wonder if integrating such a system into a game wouldn't be any less work than adding a new magic system into the game from scratch. Is supporting the "spell format" (regardless of the effort to actually invent the format) just as much work as implementing any ol' magic-in-code?

Quote:

Original post by Jotaf What worries me about this design is that MageScript is no different from any other scripting language. Personally, I think that we need to stem away from the usual notion of magic in games, and get inspiration from the magic in literature and "real world" magic (at least for the ones who believe it; has anyone here seen "the skeleton key"?). But that's a bit off-topic. Unless your magic system offers a different kind of magic (one where you don't just specify the targetting type, type of particles and an effect such as heal), the only way I can see it any better than other scripting languagues would be with a point-and-click editor that eases the process, like the trigger editors in Starcraft and Warcraft III.

Oh, definitely. It's not meant for the player to write the raw scripting language. In the game, the user might pile together ingredients in a bowl, "speak" an incantation, and that all translates into some kind of back-end code that is savable. For the developer, such a UI isn't necessary, they know the effects they want and they can write the code to do it. If the developer doesn't want the user to make up their own spells, then they just don't ever include the spell UI.

Quote:

Original post by ferr Whenever I come to a point in which I want to make a scripting language to make something easier, I always come to the conclusion that the scripting language should just be another step in the process that doesn't need to be seen by the user. The way I'd have this working would be to have a GUI that allows the user to create "spells" and in turn this GUI stores the data in an Intermediate Language, our scripting language, then the user's target language would import the script file appropriately. Using the script would allow not only multiple languages with the same scripting system, but it would also allow the user to debug (as far as what's scriptable) their program without having to recompile hundreds of files.

That's certainly the hope here, to create a flexible magic system that A) allows for players to experiment, and B) allows for developers to tweak gameplay without recompiling everything, which to me are basically the same tasks with different UI's.

Quote:

Original post by capn_midnight That's certainly the hope here, to create a flexible magic system that A) allows for players to experiment, and B) allows for developers to tweak gameplay without recompiling everything, which to me are basically the same tasks with different UI's.

I think you should think of it less as a "Magic System" and more of a "Battle/Etc Interaction System." You have to keep in mind that while things like Fireball Level 2 (Magic) are states that require calculations amongst stats between various entities, things like Attack (Physical) and Potion (Item Use) also require calculations amongst stats between various entities.. that said they could all be created in the same fashion.

I don't mean to put your idea down, it's great, but I can't imagine how typing "target.health += 50" in this script would be different from doing it in any other script. I'd love you to prove me wrong, of course.