Simple scripting language for RPG spells?
Isaac Kuo
I'm developing ideas for a multiplayer game mastered Roguelike
game system, and one thing I'd like is for the GM to be able to
customize magic spells.
I want PC/NPC stats to be kept to a minimum, as well as any
magic spell script code, to try and keep things simple--kind
of on the level of Wiz War.
Does anyone have any pointers on how best to do this, or even
just ideas for what sort of spells they'd like to see?
I imagine this would be basically like MUD scripting, which
I'm not familiar with, but it would be slightly different
in that areas of effect are significant. For instance, a
"Wall of Fire" spell could create a line of fire which lasts
a while.
--
_____ Isaac Kuo k...@bit.csc.lsu.edu http://www.csc.lsu.edu/~kuo
__|_)o(_|__ ICQ 29055726
/___________\ "Ha! I've spelled your doom!!! I've spelled it D-U-U-M!!!
\=\)-----(/=/ Just like in VACUUM!"
Martin Alnæs
>game system, and one thing I'd like is for the GM to be able to
>customize magic spells.
>
>I want PC/NPC stats to be kept to a minimum, as well as any
>magic spell script code, to try and keep things simple--kind
>of on the level of Wiz War.
>
>Does anyone have any pointers on how best to do this, or even
>just ideas for what sort of spells they'd like to see?
>
>I imagine this would be basically like MUD scripting, which
>I'm not familiar with, but it would be slightly different
>in that areas of effect are significant. For instance, a
>"Wall of Fire" spell could create a line of fire which lasts
>a while.
I've been wondering if it's possible to create a system where
all the spells isn't made in advance. Let me explain more:
* There could be a list of premade spells
* and a list of effects the game engine can handle
This list should contain very small "parts" of spells,
like the standard fire, ice, lightning, etc. plus some
psychological effects like paralyze, terrify etc.
and preferably much other, non-standard stuff.
* There could be a wordlist containing a lot of "powerwords"
which might trigger certain actions in combinations,
and words which will increase or decrease the power of the spell.
* A "spell" will actually be a phrase of words, which might trigger
the forces of magic, depending on the circumstances.
* The user might learn premade spells, or the user might experiment
to create his own. This should be a dangerous task, though.
The user could also find papers with unfinished spells etc.
* Although perhaps difficult to implement, some sort of
"poetry detector" should be present. The scripting engine
should be able to detect if the word is written in a mess or
clearly ordered, or whatever...
Was this all clear and understandable?
Is it a good idea? Is it way too difficult to make it work?
The word lists must be pretty large to make it interesting.
This makes some of the magic experience actually reside
in the players head, not just as a number on the screen.
The player might learn how to improve his spells, and how
to create new ones.
Martin Alnaes - malnaes at c2i.net
Michael Duffy
a system as flexible as possible so that both our users and ourselves could
create a wide range of spells. Here are some general things to keep in mind
when developing such a system.
* Make a list of all the spells you want to support. Break the list down
into as many major classes of spells as you can. By spell class here I mean
how the spell works. For example, a fire bolt, ice projectile, and a magic
missile are all missiles that simply have different types and amounts of
damage. All your wall spells will be in the same class. Your healing and
mana recovery effects are the same class (add permenant points to a stat up
to the maximum). Spells that add points temporarily to a stat are in the
same class, whether that stat be Strength, Dexterity, Health Max, Perception,
Speed, or whatever. Each class will take its own special case programming,
but once you have that support in then you should be able to create endless
variants within that class. You want to eliminate per-spell special case
programming and scripting as much as possible.
* Design spells such that they can have multiple effects. If you have spell
A which causes damage and then stuns the creature, and spell B that just
stuns a creature, then both spells should use the same code/script for
stunning. This seems obvious, but you do have to keep it in mind when you
design the system. If you already have the script written for stunning, then
you should be able to add it to a damage projectile to get spell A, rather
than having to write a new script specifically for spell A. You shouldn't
have two or more scripts that do essentially the same thing.
* Create a common way to access game variables. You don't want your users to
have to memorize a different way to access each variable. You should be able
to access the strength, intelligence, hit points, magic points, weight, etc
of an object all through the same interface. Make it as easy as possible for
the user to access the game state.
* Keep it simple. Well, as simple as possible while still meeting your
design goals. I've spent the past week doing nothing but simplifying my
code, combining structures, lowering the number of variables the user has to
mess with in the AI, etc,. etc. Icky, icky programming and debugging. Very
tedious work. Plan the simplicity from the start so you can avoid what I've
had to deal with for the past week. :)
* Along the same lines as above, look for unifying elements among your
spells. For example, it wasn't until I got deeper into implementing spells
that I realized that pretty much all of them could be based around the
projectile code. I use the same code to handle speed, targeting, direction,
damage/effect application, collision detection, area of effect,
casting/throwing/shooting with all the spells and missile weapons. Spells
that instantly target another creature (rather than having the spell move
from caster to target) have a speed of -1 which means to move directly from
caster to target, so they can still use all the other projectile code. This
unification seriously reduces the amount of code and script you have to write
and debug.
* Make your spells data driven. This means you define the characteristics of
the spell in the data, not the script. Reduce the number of scripts your
users will have to write as much as possible. So if you have a spell that
freezes an opponent for 5 turns and another that freezes for 10 turns, they
should both use the exact same script with one spell storing "5" in it's data
and the other spell storing "10". Then the script will use the spell data to
determine how long to freeze the opponent. Again, this seems obvious but you
need to keep it consciously in mind while designing.
Hope this helps,
Michael Duffy
mdu...@ionet.net or mduffy at studioblue dot com
Isaac Kuo wrote:
> I'm developing ideas for a multiplayer game mastered Roguelike
> game system, and one thing I'd like is for the GM to be able to
> customize magic spells.
>
> I want PC/NPC stats to be kept to a minimum, as well as any
> magic spell script code, to try and keep things simple--kind
> of on the level of Wiz War.
>
> Does anyone have any pointers on how best to do this, or even
> just ideas for what sort of spells they'd like to see?
>
> I imagine this would be basically like MUD scripting, which
> I'm not familiar with, but it would be slightly different
> in that areas of effect are significant. For instance, a
> "Wall of Fire" spell could create a line of fire which lasts
> a while.
lew_m...@my-deja.com
k...@oldbit.csc.lsu.edu (Isaac Kuo) wrote:
>
> I'm developing ideas for a multiplayer game mastered Roguelike
> game system, and one thing I'd like is for the GM to be able to
> customize magic spells.
>
> I want PC/NPC stats to be kept to a minimum, as well as any
> magic spell script code, to try and keep things simple--kind
> of on the level of Wiz War.
>
> Does anyone have any pointers on how best to do this, or even
> just ideas for what sort of spells they'd like to see?
>
> I imagine this would be basically like MUD scripting, which
> I'm not familiar with, but it would be slightly different
> in that areas of effect are significant. For instance, a
> "Wall of Fire" spell could create a line of fire which lasts
> a while.
I am currently in the process of creating a game that uses scripts to
handle more than just spells. There are currently two schools of
thought I have come across. First is create a parser and a byte-code
machine that translates the scripts to activate precoded routines in the
engine. Most commercial games use this technique.
I was too lazy to bother with that process. I would much rather spend a
few hours of research instead of coding a bunch of extra code. Instead
I went with a Dynamic Language. If you choose the right language, you
can get scripting for free. It has made things so much easier.
You can e-mail me directly if you would like specific information on
what I uncovered.
Lew
Sent via Deja.com http://www.deja.com/
Before you buy.
Chris Testa
Mareia and depending on your weapon and armor you can combine diferent
materia. There are then materia that add to the spells effect such as 'all'
which casts the spell on all enemies, and 'counter-attack' which
automatically casts that spell when attacked. The great thing is that the
more powerful the armor the more materia you can combine. You could
probably implement something like that only letting the PC have so many
slots (combined or otherwise) and maybe some artifacts that can effect how
many. then they can create spells that they want with the effects that they
want.
-Chris
Brian Robinson
> I'm developing ideas for a multiplayer game mastered Roguelike
> game system, and one thing I'd like is for the GM to be able to
> customize magic spells.
>
One thing you could do would be to subdivide your spells into
classes, like bolt spells, healing spell, etc, and then provide each
function with a power parameter or object. Add a color and then you
could code spells like this:
{BOLT 6 GREEN}
A bolt spell that does six damage and appears in green.
{BALL 10 YELLOW}
A ball spell that does ten damage and appears in yellow.
{HEAL 50 NONE}
A heal spell that heals fifty damage. There is no color because there
is no on screen display.
You might want to add other parameters like range or specials.
--
Brian Robinson
brob...@ist.ucf.edu
Institute for Simulation and Training
Isaac Kuo
>I am currently in the process of creating a game that uses scripts to
>handle more than just spells. There are currently two schools of
>thought I have come across. First is create a parser and a byte-code
>machine that translates the scripts to activate precoded routines in the
>engine. Most commercial games use this technique.
>I was too lazy to bother with that process. I would much rather spend a
>few hours of research instead of coding a bunch of extra code. Instead
>I went with a Dynamic Language. If you choose the right language, you
>can get scripting for free. It has made things so much easier.
Well, I know one possibility is to use VBA as a scripting language.
It's powerful, and standard, but perhaps too powerful.
Actually, it is definitely too powerful. It's too easy to make
"macro viruses" with them, and since I want spell code to be
automatically downloaded and run by game players...well it's too
great a risk.
Another possibility is to use Java, but I'm not really familiar
with it. My main experience of it is, of course, Javascript on
the WWW, which doesn't inspire confidense.
No, I think writing a specific scripting language is the way I'll go.
William Tanksley
>In article <7vd0j9$aqu$1...@nnrp1.deja.com>, <lew_m...@my-deja.com> wrote:
>>I am currently in the process of creating a game that uses scripts to
>>handle more than just spells. There are currently two schools of
>>thought I have come across. First is create a parser and a byte-code
>>machine that translates the scripts to activate precoded routines in the
>>engine. Most commercial games use this technique.
>>I was too lazy to bother with that process. I would much rather spend a
>>few hours of research instead of coding a bunch of extra code. Instead
>>I went with a Dynamic Language. If you choose the right language, you
>>can get scripting for free. It has made things so much easier.
>Well, I know one possibility is to use VBA as a scripting language.
>It's powerful, and standard, but perhaps too powerful.
Visual Basic is _standard_?
>Actually, it is definitely too powerful. It's too easy to make
>"macro viruses" with them, and since I want spell code to be
>automatically downloaded and run by game players...well it's too
>great a risk.
True.
>Another possibility is to use Java, but I'm not really familiar
>with it. My main experience of it is, of course, Javascript on
>the WWW, which doesn't inspire confidense.
Java would be worth considering, actually -- except for the "minor"
problem that VMs are so huge.
>No, I think writing a specific scripting language is the way I'll go.
May I suggest that you instead use one of the many prewritten scripting
languages? Your choices include:
- 4th (secure, limited library, no standard bytecodes)
- slang (insecure by default, but it's possible to write a secure library)
- Python (secure, standard bytecodes)
- Perl (cryptic, no standard bytecodes, secure, good library)
I highly recommend Python.
> _____ Isaac Kuo k...@bit.csc.lsu.edu http://www.csc.lsu.edu/~kuo
--
-William "Billy" Tanksley
Isaac Kuo
First off, I thank all those who have responded. I had at
first been thinking along the lines of Michael Duffy's
response, which was essentially similar advice as one of the
Roguelike FAQ articles I've read.
In article <MPG.1283de4fc...@news.mindspring.com>,
eric <REMOVE_...@mindspring.com> wrote:
>In article <7vcb9q$h5a$1...@its1.ocs.lsu.edu>, k...@oldbit.csc.lsu.edu
>says...
>> I'm developing ideas for a multiplayer game mastered Roguelike
>> game system, and one thing I'd like is for the GM to be able to
>> customize magic spells.
>> I want PC/NPC stats to be kept to a minimum, as well as any
>> magic spell script code, to try and keep things simple--kind
>> of on the level of Wiz War.
>> Does anyone have any pointers on how best to do this, or even
>> just ideas for what sort of spells they'd like to see?
>I've done some things along those lines. As others have said if you have
>specific spell effects in mind, such as fireball, firewall, icebolt etc.
>YOu can easily generalize the simple aspects of each spell and then
>define some basic scripting elements to produce each desired effect, that
>is a sort of top-down method. The other way (and the way I've been doing
>stuff with) would be a bottom-up method, where you start with the simple
>constructs and then work them together to create the effects you want.
I guess the "top-down" method is what I'm looking for. The
"bottom-up" method, which basically hands the "scripting language"
over to the players, seems harder to develop and manage.
I'll model the spells as reentrant procedures/functions written
in a simple procedural scripting language. I'll try to avoid full
OOP, but objects and NPCs are somewhat like objects in that they
each have a list of stats. Error handling is simplified to
cleaning up the heapspace and returning "The spell misfired!" to
the player (the spell may have incomplete effects).
An important function would be a "draining" function which attempts
to take an amount from a stat (typically MP) and if it's not available,
terminating the spell execution. The function definition would look
like:
DRAIN Vstat BY amount OR message
if Vstat<amount
error message
else
Vstat = Vstat-amount
endif
Function definitions are distinguished by using all caps for
the function name and syntax. Call by name parameters start
with "V" with lowercase following; call by value parameters
are all lowercase. Thus, typing could be minimized.
The main use for this DRAIN function would be a MP drain, so
a function specific for that could be defined:
MPDRAIN amount
drain my.mp by amount or "Not enough MP!"
"my" is the player character calling the spell. Special
functions for prompting the player for targets would be
needed.
Well...anyway, this is how my thinking is going right now...
--
_____ Isaac Kuo k...@bit.csc.lsu.edu http://www.csc.lsu.edu/~kuo
lew_m...@my-deja.com
k...@oldbit.csc.lsu.edu (Isaac Kuo) wrote:
<<...snip...>>
> I guess the "top-down" method is what I'm looking for. The
> "bottom-up" method, which basically hands the "scripting language"
> over to the players, seems harder to develop and manage.
>
> I'll model the spells as reentrant procedures/functions written
> in a simple procedural scripting language. I'll try to avoid full
> OOP, but objects and NPCs are somewhat like objects in that they
> each have a list of stats. Error handling is simplified to
> cleaning up the heapspace and returning "The spell misfired!" to
> the player (the spell may have incomplete effects).
>
> An important function would be a "draining" function which attempts
> to take an amount from a stat (typically MP) and if it's not
available,
> terminating the spell execution. The function definition would look
> like:
<< ...pseudo-code snip...>>
>
> Function definitions are distinguished by using all caps for
> the function name and syntax. Call by name parameters start
> with "V" with lowercase following; call by value parameters
> are all lowercase. Thus, typing could be minimized.
>
> The main use for this DRAIN function would be a MP drain, so
> a function specific for that could be defined:
>
> MPDRAIN amount
> drain my.mp by amount or "Not enough MP!"
>
> "my" is the player character calling the spell. Special
> functions for prompting the player for targets would be
> needed.
>
> Well...anyway, this is how my thinking is going right now...
You might want to have a "my.stat.current", and "my.stat.base" variable
set up so that spells can have a 'temporary' effect which wears off --
such as a "slow spell" or similar. It also allows for those "extra
health" spells which boosts the HP over the 'base' value for a short
duration.
---
Isaac Kuo
>In article <7vfu5c$d6m$1...@its1.ocs.lsu.edu>,
> k...@oldbit.csc.lsu.edu (Isaac Kuo) wrote:
>> I guess the "top-down" method is what I'm looking for. The
>> "bottom-up" method, which basically hands the "scripting language"
>> over to the players, seems harder to develop and manage.
>> I'll model the spells as reentrant procedures/functions written
>> in a simple procedural scripting language. I'll try to avoid full
>> OOP, but objects and NPCs are somewhat like objects in that they
>> each have a list of stats. Error handling is simplified to
>> cleaning up the heapspace and returning "The spell misfired!" to
>> the player (the spell may have incomplete effects).
[...]
>> "my" is the player character calling the spell. Special
>> functions for prompting the player for targets would be
>> needed.
>You might want to have a "my.stat.current", and "my.stat.base" variable
>set up so that spells can have a 'temporary' effect which wears off --
>such as a "slow spell" or similar. It also allows for those "extra
>health" spells which boosts the HP over the 'base' value for a short
>duration.
Yes, some sort of distinction between permanent and temporary
effects is necessary.
One thing that I initially thought might be sufficient would be
to have a "PAUSE n" command. This would pause the execution for
n turns, which would implicitely multitask execution of the spell
with everything else going on in the game world. A temporary
effect could thus be implemented by affecting a stat or creating
an object, and then reversing the effect after a PAUSE command.
However, I quickly realized that this was the wrong thing to do.
It made permanent changes the default, and made temporary effects
more difficult to implement. It would be all too easy to make
a mistake, or for unanticipated reactions with other spells to
occur.
I need somehow to make temporary effects default. A
"my.stat.current" distinction isn't quite enough--if a
change is temporary, for how long will it be in effect?
Also, what about temporary constructs, like a fire wall,
or a summonned elemental?
I'm still thinking about what the best way to go about
these things is.
One thing I'm sure of, though, is that I want the power that
multithreading can allow. I want spells to be able to
have complex timed delayed reactions. These could be used
to create traps and puzzles, used by "Game Masters" to make
obstacles for the "players".
Hmm...I'm realizing that this scripting language might be
appropriate for defining NPC combat behaviour as well.
Robert Seeger
SafeTcl (part of the core language), you can assure that untested code
is safe to run. Using Itcl (a downloadable extension), you can add
objects. It's best point, however, is that it's probably the easiest
language to learn in a very short period of time. To the guru, languages
like Perl will always be faster. However, to the casual programmer, Tcl
runs at a comparable speed to Perl.
You can find information on Tcl at http://www.scriptics.com
Hope this helps,
Robert Seeger
> > _____ Isaac Kuo k...@bit.csc.lsu.edu http://www.csc.lsu.edu/~kuo
>
> --
> -William "Billy" Tanksley
--
Whenever you're having a bad day, and it seems like everyone's
trying to piss you off, remember this - it takes 43 muscles to
frown, but only 4 to pull the trigger of a decent sniper rifle.
- Sorry, I stole this .sig, but I love it. . .
Pierre Bru
wtan...@hawking.armored.net (William Tanksley) wrote:
[...]
> May I suggest that you instead use one of the many prewritten
scripting
> languages? Your choices include:
>
> - 4th (secure, limited library, no standard bytecodes)
> - slang (insecure by default, but it's possible to write a secure
library)
> - Python (secure, standard bytecodes)
> - Perl (cryptic, no standard bytecodes, secure, good library)
I once read in some newsgroup (can't remember where) that Baldur's Gate
use Lua as a script language. I do not now if that is true, but the
language seems to be interresting (I do not use it, I've just read the
documentation).
http://www.tecgraf.puc-rio.br/lua/
Pierre.
Brian Robinson
> "my.stat.current" distinction isn't quite enough--if a
> change is temporary, for how long will it be in effect?
> Also, what about temporary constructs, like a fire wall,
> or a summonned elemental?
>
mentioned this earlier in either this group or the misc group.
Basically, all spells would be "effects" on a given object,
be it a player, a sword, or terrain. They could have certain
properties, like a poison effect draining some hps each turn.
And the way you would implement the effect would be by
"ticking" it. This means that each turn, you would allow it
to perform some action. This action might be to take away
some hps, or to destruct itself.
The examples above are easy to do in this system.
If you want a fire wall, create a fire terrian with a
duration effect on it. The effect only reduces its turn
counter each turn until the spell expires, at which point
it destructs the fire terrain and replaces it with the
original terrain underneath, the destructs itself. A
summoned elemental would work much the same way, with
the effect removing the elemental after a certain
amount of time.
With the effects, you could actually get away
with not having a max and current variable for each
stat. Any effect could just know, "I started by
subtracting one from the stat, so when I finish, I
will add one." The only snag is the possibility of
negative stats, but in this case you could make the
effect not take place if the stat was already at one,
etc.
William Tanksley
>To add to William's list, Tk/Tcl is a fine scripting language. Using
>SafeTcl (part of the core language), you can assure that untested code
>is safe to run. Using Itcl (a downloadable extension), you can add
>objects. It's best point, however, is that it's probably the easiest
>language to learn in a very short period of time. To the guru, languages
>like Perl will always be faster. However, to the casual programmer, Tcl
>runs at a comparable speed to Perl.
I would dispute the claim of speed of learning, although the rest is
certainly true. Tcl has a very baroque syntax, even though it's a very
consistent one.
>You can find information on Tcl at http://www.scriptics.com
Do so. It was my mistake to not list it.
I consider it the second worst of the available choices, though. Perl is
worse due to its monolithic nature; you can't strip out things you don't
need. All the rest, including Tcl, can be stripped down as needed.
>Robert Seeger
--
-William "Billy" Tanksley
Olwynn
RPG that I played a little of about 5 years ago too. All I can remember was
that there was some sort of somatic wordset, whereby you used a hand signal
for a specific magical sylabul. After you learned enough 'sylables' you
could string together a 'word' for greater effect. So with a few deft
selctions, you waved your hand around and cast a spell more powerfull than
it's component parts.
Its a good idea though, I think it has merit above systems where the magical
spells available are preset only by virtue of keeping the player interested
in the magic system implimented in game. You could even have each sylable
have it's own parameters for a visual effect as well.
ie
fire + power + range + area = fireball
red + area*2 + glowstreak_in_default_color +
expanding_sphere = fireball
or
heal + all + demi + remove_abnormal_status = heal
the whole party half hitpoints and cure poison, blind, etc.
green + every_party_member + medium_glow +
silver_highlingt = result
The resulting spells could be created dynamically by effect depending on how
they were assembled with a parsing engine reading the spell, determining
targets and effects, and sending attributes to an animation creator which
would take them and apply them according to a set of rules involving color,
distance to target, strength, etc.
Cheers
Richard
Chris Testa wrote in message <7vctpc$lm2$1...@bgtnsc03.worldnet.att.net>...
David Bollinger
an embedded language - much "cleaner" in my opinion than some other
options, such as Tcl or Perl. It's also very small/lightweight, one of
the fastest around, well documented, and easily bound with C functions.
I do know that Baldur's Gate used Lua for "test" scripting - cheats
and such - though the game itself was not scripted with Lua. However,
BioWare's upcoming game MDK2 is to be scripted with Lua. Also, Lucas
Arts' Grim Fandango was fully scripted with Lua.
A good way to get a feel for Lua might be to search the mailing list
archives, found here:
http://www.egroups.com/group/lua-l/
Cheers,
Dave
In article <7vmtkr$vv1$1...@nnrp1.deja.com>,
DrkDrgn5
flexibility.
Pierre Bru
drkd...@aol.com (DrkDrgn5) wrote:
> I wouldn't learn a little scripting launguage. Id go for C++,
> so much flexibility.
you can get the best of the two worlds with CINT, a C/C++ interpreter.
have a look at http://root.cern.ch/root/Cint.html
William Tanksley
> drkd...@aol.com (DrkDrgn5) wrote:
>> I wouldn't learn a little scripting launguage. Id go for C++,
>> so much flexibility.
>you can get the best of the two worlds with CINT, a C/C++ interpreter.
>have a look at http://root.cern.ch/root/Cint.html
Very few modern scripting languages have *less* flexibility than C++; most
have far more, and all are easier to work with.
>Pierre.
--
-William "Billy" Tanksley, in hoc signo hack