Scripting Question

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...
4 answers Last reply
More about scripting question
  1. 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)
  2. 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
  3. 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

    --
  4. 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.
Ask a new question

Read More

Development Games Video Games