Developing a scripting system

[BirdofPrey]

Hi all! I'm glad I found this place! I'm a month or 2 into development of a roguelike. Programming it with C++ using SDL and SDL_TTF. My overall vision is a game that combines what I consider the best parts of my favorite roguelikes (mostly ADOM and nethack), with many unique additions of my own. I've already scoured the articles on Roguebasin but real dialogue is always nice.

I'm still in very early development - I have a decent dungeon generator, good and fast FoV code (though I haven't rounded it off for aesthetics yet), and generally all the structures I need in place to begin adding content.

Here's where the topic comes in: I have my heart set on a highly flexible scripting system to be used in the external data files in the game. If things work out properly, I would want to have almost everything except for the most basic game engine details to be defined in external files rather than hard-coded. Everything from random map parameters, specific maps, quests, items, monsters and monster AI, skills, effects, etc. There are several reasons I want to do things this way, but to enumerate just a few, such a system would
1. Let me define limitless possibilities of complex behavior without having to resort to hugely cluttered code and a constant need to recompile with every tweak
2. Be flexible in a way that could govern anything from the way a certain item acts every time you use it, to the fine details of some puzzle in a unique map
3. Maybe the most important one of all, making such a system would let anyone who learned it be able to create their own content for the game. Sharing the creation process with my internet friends would be a lot of fun as well as take a big load off of my shoulders in terms of having to make 100's of items myself.

I haven't completely settled on anything yet, but the way I imagine it right now, on game startup the parser will run through all of the text files, parse each line into appropriate components, and then store those components as vectors in the item/monster/whatever data under different 'hooks'. When an action is done, say the player drops an item, it sets of a DROP trigger for that item, and the item is checked for any special behavior when dropping. If the action succeeds, it'll then set off a 'DROPPED_ON' trigger for any tiles/objects that the item was dropped on. This'll be the case for pretty much any action - it'll set off an active trigger for the subject of the action, and a passive trigger (if it applies) to the object of the action.

So I guess my question to you all is, what do you think of the feasability of this plan? Have any of you tried your hand at this kind of system, and how successful were you? What are the biggest pitfalls and things to be aware of when making such a system? Any comments and suggestions would be appreciated. I'm going to start making the text parser as soon as I get a new charger for my damned macbook.

[zzo38]

If you want a scripting system, I recomend implementing FLISL. When I implement a scripting, I would do FLISL as well. I think FLISL is better way, anyways. It is powerful and simple to implement without worrying about parentheses or syntax or anything like that, just words (like in Forth).

[BirdofPrey]

If you want a scripting system, I recomend implementing FLISL. When I implement a scripting, I would do FLISL as well. I think FLISL is better way, anyways. It is powerful and simple to implement without worrying about parentheses or syntax or anything like that, just words (like in Forth).

Thanks, sounds interesting! Unfortunately the site isn't responding to me at all right now, but I'll keep trying.

[Nahjor]

I'm pretty sure every RL developer has the massive-scripting-language-based-RL idea at some point. My plan for that particular white whale, when I had the bug for it, was very much the same as you describe there. I'm also pretty sure that just about everyone does what I did...starts a project that way, and comes to a realization a short way in that this really isn't the way to go.

If your project uses this approach and works, massive kudos. But I suspect that you'll end up in the same trap as most people who try it; you end up having sunk tons and tons of work into some portion of an engine, and you still have no game. The scripting engine is a black hole... it keeps growing and growing in scope and required power, until it has consumed all of your will to code.

But like I said...if you can make it happen, big kudos, and I'll definitely try it out.

[zzo38]

If you want a scripting system, I recomend implementing FLISL. When I implement a scripting, I would do FLISL as well. I think FLISL is better way, anyways. It is powerful and simple to implement without worrying about parentheses or syntax or anything like that, just words (like in Forth).

Thanks, sounds interesting! Unfortunately the site isn't responding to me at all right now, but I'll keep trying.

Sorry, my router was damaged. It works perfectly OK now. You can view it now. FLISL

[BirdofPrey]

I'm pretty sure every RL developer has the massive-scripting-language-based-RL idea at some point. My plan for that particular white whale, when I had the bug for it, was very much the same as you describe there. I'm also pretty sure that just about everyone does what I did...starts a project that way, and comes to a realization a short way in that this really isn't the way to go.

If your project uses this approach and works, massive kudos. But I suspect that you'll end up in the same trap as most people who try it; you end up having sunk tons and tons of work into some portion of an engine, and you still have no game. The scripting engine is a black hole... it keeps growing and growing in scope and required power, until it has consumed all of your will to code.

But like I said...if you can make it happen, big kudos, and I'll definitely try it out.

Haha, well said! I knew from the moment I started even considering this approach that this is what the biggest danger would be. And I'd say I agree that the chances are fairly decent that it'll happen to me in the end. Still though, I feel like I at least have to try my hand at it. I'll make an honest attempt, and what happens will happen. One of my side-aims in this project is to become proficient in c++, so even if the idea doesn't pan out at least i'll get some valuable experience out of it.

[stu]

I think you'd be stupid to implement anything other than Lua for scripting / driving the game.

Whatever you do, dont roll your own.

[BirdofPrey]

I think you'd be stupid to implement anything other than Lua for scripting / driving the game.

Whatever you do, dont roll your own.

Noted.

edit  - Out of curiousity, why do you say that? Is it just that it would be too much work, or is it memory/performance issues?

[zzo38]

I think you'd be stupid to implement anything other than Lua for scripting / driving the game.

Whatever you do, dont roll your own.

I think you are wrong. Just implement FLISL it shouldn't be too hard and it shouldn't take up too much memory if you implement it good. I guess if you really wanted to, someone could implement FLISL in Lua, but that would just make it slow.

[stu]

I think you are wrong. Just implement FLISL it shouldn't be too hard and it shouldn't take up too much memory if you implement it good. I guess if you really wanted to, someone could implement FLISL in Lua, but that would just make it slow.

1 - you dont have to _implement_ lua, you just drop it in.
2 - lua is well know, works and is awesome.
3 - lua has been proven, bug tested and used far and wide
4 - lua has a small footprint
5 - lua has a well known C/C++ binding API for integration
6 - flisl syntax looks like garbage
7 - flisl is unknown
8 - flisl has no public implementation
9 - flisl has no public documention beyond a weak specification
10 - flisl has no documented C/C++ bindings API
11 - if you want forth, use forth, why create some slightly different dialect of forth?
12 - why would you want to implement flisl on top of lua? flisl doesnt offer you anything at all.
13 - flisl is way too low level for a scripting lanauge, requiring a boatload more work on the base level to get anything like lua's functionality

I just realised you wrote flisl. I looked over your spec, it doesnt seem to offer anything at all over basic forth.

There is nothing about flisl that looking over the spec or examples that says "win" over lua.

Maybe you should implement flisl first, then try and do some REAL example code in it. nested tables/arrays/hashes, anonymous functions, global vs local scope binding, fully functional / function passing, etc

(If you want modern forth, I suggest you look at factor).

[zzo38]

I have found a implementation of Forth written in Lua, but it isn't very good, I made a lot of improvements to it, and I might make some more improvement later. See http://zzo38computer.cjb.net/luaforth/forth.lua for the improved one (it does have a link to the original, in case you want to see the original one, which isn't very good). I have tested the improved one and it works OK.

If you want to embed Lua, then just make sure to put Lua version 5.1 or newer so that this Forth will work on it OK. Hopefully ToME accepts this, because ToME uses Lua and if I want to write it in Forth instead, then I will use this to make it work.

[stu]

the biggest problem is that forth is too low level for a scripting language.

Youve seen/written forth inside of Lua. Can you now write lua in flisl? that would be a good test for you to prove the effectiveness of flisl

[BirdofPrey]

Anyway, despite most of the responses here, I've decided to go through and try to get my own thing going. I hope to keep my motivation going by continuing to work on other parts of the code at the same time, and by beginning to add content as the script gets more fleshed out. I guess I'll post updates on how things are going occasionally. Thanks for the advice though 

[stu]

If you want to finish your game, I'd think twice about it. A roguelike is a full on big project. A scripting system is also a full on big project and you want to do both at the same time. Good luck and have fun. Keep us aprised

[Slash]

Seconding that advise; reuse as much as generic components you can, be careful with the way you use your willpower, it is a scarse resource.