Making a Scriptable Engine

Sage
Posts: 1,066
Joined: 2004.07
Post: #1
After searching around the web with no results, I'm back for more knowledge.

I am curious how people create scriptable engines. My goal is to make a simple 2d engine (for now Smile) that allows for scripting to handle level set up and other things. I suppose my first question is more of a design question: what things in games are left to scripting vs. hard coding? Secondly, how would I implement this? I know that I will either make the game using BlitzMax, Cocoa, or C++ (using SDL). I want the scripts to be based off BASIC (or actual BASIC if possible).

Any suggestions? If I missed good threads about this, I apologize. I searched for scriptable and found nothing good.
Quote this message in a reply
Member
Posts: 338
Joined: 2004.07
Post: #2
There's a lot of information on gamedev:

http://www.gamedev.net/reference/list.asp?categoryid=76

Go down the page a ways and you'll find tons of articles on it.

As for your design question: During coding and testing two distinct games I found myself wasting a lot of time balancing the game. That is, I'd have some hard-coded constants, compile/run the game, find it doesn't quite work, quit, change the constants, and compile/run again. Rinse, repeat. It's a real pain in the ass- especially during KDC when "testing" ended up being "test for 5 seconds, then play for half an hour."

Instead, I can have those parameters outside of the code in a file, or even pull up a console-type thing in game and change them during runtime. In the first case, I save a recompile. In the second, I can see the results immediately.

Justin Ficarrotta
http://www.justinfic.com
"It is better to be The Man than to work for The Man." - Alexander Seropian
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
The usual way is to embed an existing scripting language (eg. Lua, Python or Ruby). Writing your own language massively increases the effort involved.

Then you have to decide where the compiled/scripting boundary goes. That's entirely up to you -- you could go the whole hog and write almost the whole program in the scripting language (cf. Smiley Tag), or to the other extreme where only one specific part of your program is in the scripting language. Probably you'll want a line somewhere in the middle.

Then you have to expose functionality from the rest of your game to the scripting language so that the scripts can do what they need, and you have to organize for the scripts to be called at appropriate times. The details of those will depend on which language you've chosen.
Quote this message in a reply
Member
Posts: 28
Joined: 2003.10
Post: #4
OneSadCookie Wrote:The usual way is to embed an existing scripting language (eg. Lua, Python or Ruby). Writing your own language massively increases the effort involved.

I dunno, even Lua may occasionally be too heavyweight compared with a lightweight language of your own.

Scripting in Oolite (which is built in Cocoa/Obj-C) works by reading in property lists, and using NSSelectorFromString() to call object methods. Since scripts are checked regularly there was no need to implement any looping structure and conditional structures are limited to a simple test of an array of conditions. The same basic principles made an property-list-based AI state-machine easy to implement as well.

I'm probably biased though - I wrote Turing-style state machine simulators when I was a kid...

-- Giles Williams
Oolite - retro space-sim agogo
Quote this message in a reply
Moderator
Posts: 3,573
Joined: 2003.06
Post: #5
I learned my scripting skills mostly from Game Scripting Mastery, which is a really great book IMHO. I did very simple stuff based on text files, and also designed my own high-level compiled language. I haven't finished the compiler for it because I dropped the project in favor of Lua long ago, but the assembler is first version complete. It's a serious effort to make your own full-featured compiled scripting language, no doubt. But I agree, you can write simpler types of non-compiled command-based spripting languages which can be very powerful and should not be dismissed.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #6
I'll focus a bit on exposing functionality here, then:
You need to decide on what you need to control from the outside. If you just want to configure stuff, that should be an easy thing to do, but if you want to script behaviour, then we need a bit more structure. My rule of thumb is to expose as little as humanely possible in the start, and then expose more as you find that you can't live without that. Personally, I tend to do this process as late in development as possible, since the interfaces inside the game have been set in stone. Try to stay high-level: the purpose of scripting is to expose functionality, not the bowels of the game. So, expose the functionality to Hurt enemies, rather than exposing their health, animation state, sound state and AI state.

When you do your exposing, think like an end-user. SInce you have access to the engine, you can expose whatever you like, but a user is more likely to bend your scripting to the very limit, or just think "Nah, this can't be done". Is it really necessary to tweak the playback rate of the noise powerups make when they are picked up?

That said, let's talk about examples:
- Access to the player
- Access to the enemies
- Access to the bullet controller (stop all bullets, remove all bullets, make all bullets fall towards the ground)
- For each body; position, velocity, acceleration, collision states, drawing
- For each enemy; Remove, re-spawn, hurt, canSeePlayer, isDead, isDying, isFalling, moveTo, followWaypoints()
- The level: number of enemies left [of a certain type, perhaps], weather control, background music, dialogue...

Bottom line? You need far less functionality than you think, and for once, you seldom have to plan it out very carefully.
Quote this message in a reply
Member
Posts: 257
Joined: 2004.06
Post: #7
AnotherJake Wrote:It's a serious effort to make your own full-featured compiled scripting language, no doubt. But I agree, you can write simpler types of non-compiled command-based spripting languages which can be very powerful and should not be dismissed.

While I agree with the statement, I just want to amend to it that it all depends on how much time you want to spend writing your own scripting language vs. integrating an existing language like Python or Ruby.

The brains and fingers behind Malarkey Software (plus caretaker of the world's two brattiest felines).
Quote this message in a reply
Moderator
Posts: 529
Joined: 2003.03
Post: #8
If you're using BlitzMax, it supports Lua already.

Here's a tutorial:

http://www.blitzwiki.org/index.php/Introduction_to_Lua

"Yes, well, that's the sort of blinkered, Philistine pig-ignorance I've come to expect from you non-creative garbage."
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #9
You might also want to look into Io. It's a very clean language. (too clean perhaps as it's lacks fancy control structures.) It looks *very* promising as an easy to use, easy to set up scripting language, but I'm sticking to Ruby for my general purpose needs.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #10
I have embedded Lua in a C++ game engine, and while it's not such a joyride as one might think, it's alright. Lua seems to give the most bang for the buck when one looks at power/speed vs. easy embedding.

Coding up your own scripting language is only worth it if you are doing it for the exercise, or need something really special. Otherwise, you are better off with an "off the shelf" language.

Getting your scripting language and compiled code to interact properly is the most difficult bit, as you have to find the right balance between complexity, ease of use, speed, and scope. I primarily used Lua for parameter driven stuff, and high-level logic.
Quote this message in a reply
Post Reply