You''ve probably heard this a few times too many all ready but... Wow!! Great Idea!

I was recently thinking of making a game based on the wheel of time novels and wanted to do someting similar for the casting system (btw, there''s already a group of peope working on that IP)

It seems you already have a spefic method of implementation in mind (and I didn''t get the chance to put too much thought into my idea) so I''m not sure how good my ideas will be.

Anyway, I also was thinking of having a system of word''s, which wouldn''t be immediately obvious to the player (e.g. if you''re using runes they won''t be labelled ''fire'',''explode'', etc. but will just have generic magical names)

The spells would be made of a base word which would accept arguement''s (very similar to your C function thing) but the whole spell would be ONE function (not a chain of functions) however a spell could accept the result of another spell as an arguement.

This would mean you would have to have spell types (very similar to variable types) which would determine what arguement types it accepts and what type it returns.

e.g.
A mangify spell which doubles the effect of any energy

definition

energy SP_Magnify (energy X)

This for instance could be used to double the effect of a small fire (or a big one)
However if you have another spell

energy SP_fireball (int size, int speed, int direction)

You could combine them to give

energy SP_Magnify ( SP_fireball (int size, int speed, int direction))


So the spell caster has a choice of making a size 10 fireball for X mp or double a size 5 fireball for X/2+Y mp.

Then you could add a spell that automattically gives a target direction (sort of like a detector),one that maintains a spell while you''re gone and one that allows the holds a spell until it is triggered to give something like.

void SP_Hold (spell X, trigger Y)
direction SP_Detect (area X, detectType Y)
trigger SP_Detect (area X, detectType Y)
type_x SP_Maintain ((type_x) spell X, int Time)

which can combine to-

void SP_Hold (SP_Magnify (SP_Fireball (5,10, SP_Detect( {5,5,0,10}, HUMAN)), SP_Maintain ( SP_Detect({5,5,0,10}, HUMAN), _1DAY)

i.e. If any human crosses the area in the next one day greet them with a really nice fireball.

Obviously with every single spell added the possibilities increase exponentially.

Issues I''d thought of:
One: this spell systems lends itself to being represented internally as once the spell has been parsed you simply have to call the relevant c functions which will automatically generate the appropriate result. That way the designer does not have to come up with each possible spell just with each unit of the spell.
Two: the complexity of the spells have to be hidden somehow unless the user specifically wants it. eg the fireball spell above can take the direction being faced by the caster as it''s defualt direction so the user does not have to indicate it unless it''s different from the one he''s facing. This has to be done as often as possible but always with the possibility of being overwritten by the player. The goal is hassle free complexity. with an interesting by-product being that a player may be using a spell for ages only to find out that he could do a miillion other things with it.
Three: In the interest of hassle freeness you simply CANNOT use a text interface. Depending on how easy/difficult you want the spells to be for the user to understand/improvise you could use buttons/menus or something more abstract (runes,hands motions, button combinations etc.)

Umm, what else...? Oh and have fun!


---------------------------------------------------
There are two things he who seeks wisdom must understand...
Love... and Wudan!

youd woulda never guess man but i am in the process of designing a game virtually exactly the same as what you are thinking off. I was going to allow the player totype in three keywords, each with a different characteristic that would in turn do something different...

I figured someone was gonna mention Rudora no Hihou in this thread...

BTW, DuranStrife, if you''re into emulation, the ROM has been translated...

It''s a pretty good game with a really engrossing spell system. All the spells in this game are one-word spells using one of a large number of base spells combined with prefixes and suffixes that modify power and targetting. Unfortunately, that was the shallow point... you couldn''t really change the effect of a spell beyond whether it was single- or multi-targetting.

There was your standard set of elements and to each element there corresponded around 20 bases, all of varying strength and some with multi-targetting built in. Plus there were various bases for status, healing and powerup spells. And a very few special spells which have a specific word used to cast them and couldn''t really be modified.

Then through the game, people would occasionally tell you spells or you see the enemy cast a spell and you would have to dissect the components in order to learn the new base and some prefixes/suffixes.

To make spells, you would go to an option in the main menu and then you have a spellbook with 32 slots in it for you to enscribe the spells of your choice. Once enscribed, the game would assign the cost of the spell in MP based on its construction. You could then use it in battle as you wished. This set up was good because the MP cost prevented you from being god-like too early on and it kept the pace of battle up by not "typing" out spells in battle.

For an example of some spells, the spell IG was a base for fire costing 1 MP and caused a weak fire attack. You could however pump it up to IGLUS where LUS was a suffix that increases power but increased cost to 2 MP. Or you could say IGNA which would use a weak fire attack on all enemies; this also increased cost to 2 MP. Then again you could say IGLUSNA and use a more powerful fire attack on all enemies, but it would cost 3 MP.

Following me here? It''s a really nice system, but it''s definitely difficult to implement. Apparently Rudora no Hihou has a dictionary of over 2000 "words" for prefixes, suffixes and bases and likely a rather complex grammatical parser that it uses to determine what your spell is.

Hope you found this interesting if nothing else...

-Auron

quote: BTW, DuranStrife, if you''re into emulation, the ROM has been translated...

Where can I get the full translation? Mine is only about 10% done, and none of the spell characters are translated.

i seriously seriously suggest you check out eternal darkness for the gamecube. they used a kind of magic grammer, as other people have suggested, to implement all their different spells. the player has to find all the different runes to put them together and either guess how to put structure them to cast them.

the only disappointing thing, to me, was that there were only a limited number of spells possible, and all were predefined. when i had read about the game i thought the system youre suggesting is how they implemented it and i was very excited. the result was a little disappointing from that perspective, but its still a really good game with an excellent spell system.

I was also thinking of creating such a system.
But I got a bit *stuck* with the following:

1. What is the basis construction words (e.g Elements - Fire, Earth etc) or even more - Light, Darkness, Life, Death etc.
My solution to that would be a set amount (e.g the ones I define)

2.How do you convert words into 2D/3D effects? (E.g fireball)
My solution is you use description words for that - e.g you describe the form that your spell takes - square, amorph, ellipse etc.

3. What will happen if you go to advanced spells - e.g you want to cast mass fear spell?
My solution is to default it to something, although it will decrease the flexibility of *magic engine*.


And I got some other problems that I can''t remember right now.

Good luck and try something more grounded, easier.


" Do we need us? "

Ionware Productions - Games and Game Tools Development

You know, this particular topic comes up every now and then on this board.
I''ve participated in a few of the threads...

Be aware of some things:
Are you going to make it for most people? Then you will need GRAPHICS.
Are you going to make it for geeks? Then you will want a programming language.

That said...


Setup some kind of grammar with certain buidling blocks that can construct bigger building blocks with each other, like regexps.

Make a real programming language thats Turing-complete.
Like so

fireball(dmg, rad){    fire(getobjcenter(),rad);    dodmg(dmg);    }dragonslave;    //naturally has obj passed as param{    color(RED);    lightning;    fireball(DAMAGEMAX, 1000);    //damage, radius.} 

Parser/lexers are not insanly hard, just a terrific headache to build in C++. I''ve got a limited one working right now, I can send you the source code if you like, it might save alot of wheel-reinvention.



~V''lion

Bugle4d

quote: Original post by DuranStrife

quote: BTW, DuranStrife, if you''re into emulation, the ROM has been translated...

Where can I get the full translation? Mine is only about 10% done, and none of the spell characters are translated.

I tried e-mailing you with the link, but the e-mail in your profile doesn''t work.

I really have no idea if it would be against board rules to give you the link, but here goes anyway: Aeon Genesis Translations (Note that the ROM is NOT available on that site).

Returning to the topic at hand, the idea of making the spell system a programming language would be extremely cool if you were in an RPG that takes place inside a computer. You program your attacks using code and then compile them into your character. As the game progresses, you''ll find new, better libraries to use to code up your attacks or you''ll be e-mailed the new version of the libraries. However, that would have the possibility of getting unruly to say the least.

Outside of that type of situation, it would just be plain weird to have a spell system like that in any other RPG. I think you''re better off going with either a rune type system or a word-based system. The runes would be easiest because there''s a much smaller number of possible combinations (eg: 10 runes to choose from, combos of 3 runes, that''s 720 combinations assuming runes cannot be used more than once in a spell). Words would be very difficult since you''d HAVE to parse the modifiers and be able to come up with something regardless of what gibberish they enter.

-Auron, almost wanting to make a game using the "code-your-attacks-ingame" system...

I think you could probably get away with a Turing Complete spell-casting language, provided you don''t require the player to understand it: In other words, have a reasonably large supply of pre-generated spells available to find (scrolls, NPC teachers, wahtever) but also allow players to construct their own spells if they want to.

As to controlling recursion and preventing infinite loops, as has been suggested above, simply having each command consume some resource should do it - sure you could write a spell that cast a minimal fire dart at specified target then called itself on the same target, but the first time you cast it, at best it''d cast the spell repeatedly at the target until you ran out of mana. At worst, it''d crash your wizard (or the game) when it hit stack overflow and, for example, cost your wizard some levels.

Some examples of games like the one you''re suggesting:

<a href="http://games.ravenblack.net/rules/1/example.html">Warlocks</a>

<a href="http://rsazure.swan.ac.uk/~rsjames/spellcast/">Spellcast</a>

<a href="http://www.gamerz.net/~fm/Main/">Firetop Mountain</a>