Scripting Question

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

I've been toying around with Lua for a while now, and I currently have a
bit of a problem. The thing is, I'm not 100% sure what the best way to
use the scripting system is.

I considered using an event-based model, where scripts attached to
objects are run on specific events, such as onCollide, onUse, onDamaged,
etc. Then the script is run, and the corresponding event code is run.
However, this feels a bit limiting, and could require a lot of work if a
new event type needs to be added.

Then I considered running the entire game through scripting, with
speed-critical bits coded in C. I toyed around with this idea before,
and liked it, but I'm more than a little worried about speed issues,
especially if my game is realtime.

Lastly, I considered hardcoding game events, and just using scripts as
datafiles, which is, needless to say, handy, but a bit of a waste of
potential.

I feel like I'm missing something rather obvious, here. Any advice
would be appreciated. I'm very comfortable with Lua, and have no
problems using Lua's C API, but understanding the language isn't enough,
when I don't know what to *do* with it...

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> I've been toying around with Lua for a while now, and I currently have a
> bit of a problem. The thing is, I'm not 100% sure what the best way to
> use the scripting system is.

I think it is important to remember the problems that most scripting
languages can have with scalability.

> I considered using an event-based model, where scripts attached to
> objects are run on specific events, such as onCollide, onUse, onDamaged,
> etc. Then the script is run, and the corresponding event code is run.
> However, this feels a bit limiting, and could require a lot of work if a
> new event type needs to be added.
>
> Then I considered running the entire game through scripting, with
> speed-critical bits coded in C. I toyed around with this idea before,
> and liked it, but I'm more than a little worried about speed issues,
> especially if my game is realtime.

I wouldn't be worried about speed issues. I'd be worried about
maintaince issues.

People tend to like scripting languages as they make it so easy to code
things. It feels like such a relief to be able to just write code
without having to think about all this seemingly meaningless syntactic
sugar.

The bottleneck, however, is never in *writing* code. The bottleneck is
in maintaining code. Your goal at the end of the day is to have as
much done with as little code as possible. Systems which make it
harder to write code thus help enforce this.

> Lastly, I considered hardcoding game events, and just using scripts as
> datafiles, which is, needless to say, handy, but a bit of a waste of
> potential.

I find it ironic that you are worried about wasting the potential of
Lua when you are quite willing to waste the potential of C by moving
entirely into a scripting language.

> I feel like I'm missing something rather obvious, here. Any advice
> would be appreciated. I'm very comfortable with Lua, and have no
> problems using Lua's C API, but understanding the language isn't enough,
> when I don't know what to *do* with it...

"The obvious thing to do" is "to decide what to do with it" :>

I'd recommend taking a look at TOME to see how other's have dealt with
the Lua/C divide.

If I were you, I'd use LUA as a pure data-definition language. It
makes a nice, powerful, data definition language. This way you can
also ensure all your LUA scripts are run at start up so you the
limitation of run-time error checking isn't a big one - you'll get any
run-time errors at start up.

If it weren't for my need to keep all my data structures in read-only
memory, I'd be tempted to use LUA in POWDER. I'd use it in much the
same role as enummaker is currently used.

I'd consider moving stuff like "dialogue" and "quests" into Lua.
That's like step 14 in writing a roguelike, however, so that bridge can
be crossed much later :>
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "Timothy Pruett" <drakalor.tourist@gmail.com> napisal w
wiadomosci news:UfRLe.7787$0E5.3842@fe05.lga...
> Then I considered running the entire game through scripting, with
> speed-critical bits coded in C. I toyed around with this idea
> before, and liked it, but I'm more than a little worried about speed
> issues, especially if my game is realtime.
Go for it and don't worry about the speed; the speed-critical things
in scripting languages (like hashes) are usually very well written and
better than anything a single coder could come up with.
My RL is half-C and half Python, and it works for me. It might be hard
to decide which parts should be scripted and which should remain in
C - the approach that worked for me is "all the parts that iterate
over anything should be in C, the rest is in Python".

regards,
Filip

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Jeff Lait wrote:
> Timothy Pruett wrote:
>
>>I've been toying around with Lua for a while now, and I currently have a
>>bit of a problem. The thing is, I'm not 100% sure what the best way to
>>use the scripting system is.
>
>
> I think it is important to remember the problems that most scripting
> languages can have with scalability.

Lua seems to scale pretty well, from what I've seen. Obviously not as
well C/C++, but better than some of the alternatives.

>>I considered using an event-based model, where scripts attached to
>>objects are run on specific events, such as onCollide, onUse, onDamaged,
>>etc. Then the script is run, and the corresponding event code is run.
>>However, this feels a bit limiting, and could require a lot of work if a
>>new event type needs to be added.
>>
>>Then I considered running the entire game through scripting, with
>>speed-critical bits coded in C. I toyed around with this idea before,
>>and liked it, but I'm more than a little worried about speed issues,
>>especially if my game is realtime.
>
>
> I wouldn't be worried about speed issues. I'd be worried about
> maintaince issues.
>
> People tend to like scripting languages as they make it so easy to code
> things. It feels like such a relief to be able to just write code
> without having to think about all this seemingly meaningless syntactic
> sugar.
>
> The bottleneck, however, is never in *writing* code. The bottleneck is
> in maintaining code. Your goal at the end of the day is to have as
> much done with as little code as possible. Systems which make it
> harder to write code thus help enforce this.

I've found, so far, that I can get a lot more done in Lua than C, in
way fewer lines of code. Lua's main data structure, tables, certainly
help with this.

>>Lastly, I considered hardcoding game events, and just using scripts as
>>datafiles, which is, needless to say, handy, but a bit of a waste of
>>potential.
>
>
> I find it ironic that you are worried about wasting the potential of
> Lua when you are quite willing to waste the potential of C by moving
> entirely into a scripting language.

Don't get me wrong, I love C, but it really doesn't have much
potential to waste. The only benefit of using C is speed, and a
wealth of libraries available.

>>I feel like I'm missing something rather obvious, here. Any advice
>>would be appreciated. I'm very comfortable with Lua, and have no
>>problems using Lua's C API, but understanding the language isn't enough,
>>when I don't know what to *do* with it...
>
>
> "The obvious thing to do" is "to decide what to do with it" :>
>
> I'd recommend taking a look at TOME to see how other's have dealt with
> the Lua/C divide.

I never looked deep into it (although I guess I'll have to now), but
to my knowledge it's just used for datafiles.

> If I were you, I'd use LUA as a pure data-definition language. It
> makes a nice, powerful, data definition language. This way you can
> also ensure all your LUA scripts are run at start up so you the
> limitation of run-time error checking isn't a big one - you'll get any
> run-time errors at start up.

In a released product, there shouldn't be too many run-time errors to
worry about. But, anways, it seems I may have to go with the datafile
approach, even though that removes the possibilities of, well,
scripted events.

> If it weren't for my need to keep all my data structures in read-only
> memory, I'd be tempted to use LUA in POWDER. I'd use it in much the
> same role as enummaker is currently used.
>
> I'd consider moving stuff like "dialogue" and "quests" into Lua.
> That's like step 14 in writing a roguelike, however, so that bridge can
> be crossed much later :>

Yeah, that step can wait a bit, although Lua seems an obvious choice
for dialogue and quest storage. Who wants to have to recompile, just
because they fixed a spelling error in a piece of dialogue?


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> Yeah, that step can wait a bit, although Lua seems an obvious choice
> for dialogue and quest storage. Who wants to have to recompile, just
> because they fixed a spelling error in a piece of dialogue?

This is the case for some games (I think ADoM has everything contained
within the EXE for the windows version), but most good designs
recommend that scripting be done in a separate file.

Quote from "Programming Role Playing Games With Direct X" (p. 580):

"When creating projects as large as role-playing games, you will
find
it difficult (and foolhardy) to program game-related information
in
your source code. Your best course is to use ... scripts for
gaming
data such as dialogue. In this way, you can ... save time because
you don't have to recompile the project every time you make a
change..."

Obviously, this is precisely what a scripting language is for, but it's
certainly a good idea to do this using WHATEVER language you decide to
write your dialog for - including C/C++, which this book uses.

It's actually a handy book for anyone making an RL, although obviously,
not everything in the book will pertain to RL games. The flip-side is
that not every detail about RL games will be covered either - like
dungeon level generators - but it gives a good introduction to the sort
of concerns you'll have implementing an RPG, even if you don't use
Direct X, or don't use 3D/2D graphics.