#13858 - animension - Wed Dec 24, 2003 12:06 am
This isn't really to ask questions, but more so to hopefully start an intelligent dialogue amongst fellow developers on the topic of the use of scripting languages within GBA games.
Some specific aspects of this topic I'd like to raise are:
* Language choice and their pros and cons
* Efficiency of using scripts
* Scope and extent with which scripts are used (code the entire game in script <-> code only dialogue in scripts)
* Ease of tying in particular scripting languages into a 3rd party language such as ANSI C or C++
* Example uses of scripting in a game engine
Any developers who wish to chime in would be most welcome. In particular, I'm curious about the extent and scope with which scripts are used.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin
#13889 - sajiimori - Wed Dec 24, 2003 5:53 pm
Extent wise, one common approach is to design the non-scripted portion of your program as a toolbox for the scripts to draw from. The scripts can describe what you want to happen, and the low-level compiled code (aka the engine) can describe how to make it happen. In other words, the scripting interface is simply an abstraction of the underlying engine.
With this approach, it's appropriate to consider the scripts to be "in charge", while the engine exists in service of the scripts. Contrast with calling utility scripts to handle conversations.
#13902 - Miked0801 - Wed Dec 24, 2003 6:48 pm
OK, here's how the script works in our RPG engine.
Pretty much, our script engine is a BASIC style interpreted language where programmer add functionality as requested by the scripters (yes we wrote it ourselvers.) Our language has basic loop control (while/for) and conditionals (if/switch.) We also have persistant and temp vars for use. It has served the purpose for 3 games now and has managed to speed up development times nicely - also the token commands in the languages can be compressed per level and uncompressed as needed to save ROM space.
To specifics:
"BASIC" languge pros - just about anyone with any programming knowledge or for that matter logic abilities can script out levels for us as that's what BASIC is all about. Cons, it's hard to write large units in BASIC without achieving spaghetti - but that's not what scripts are for. There for small consise actions that control a small contained areas.
Efficiency:
Two reasons to use scripts: To free up developers to work on other portions of the engine. Scripts are the perfect thing for level designers, producers with al little extra time (ha), jr. level programmers, and even the occasional artist. As scripting an RPG style game can take as much time as the code side of things, scripting is necessary. The other being that scripts can be isolated per level, and the data for the scripts tends to be more compact than code as the tokens tend to be smaller than code.
Scope:
We use it for moving actors around, triggering dialogs, causing screen fades and such in events, or whatever is needed. We don't use them for menus or UI - we leave that to code as they are so quick to do anyways. It could be argued that menus and UI are also good canidates for scripts as well, but we haven't gone that route.
Ease:
It took a couple of months to get the basic engine up and functioning with 2 full time developers - 1 working on the the windows tool, one working on the GBA side interface. Then another couple of months to get the kinks worked out. Now that it's in place though, adding new commands and such are a matter of changing INI files and such so the time was very well spent. Still, it wasn't "Easy" to get it up and running :)
Uses:
Engine takes control of hero character, walks over to window, triggers dialog about whatever, then triggers another character to walk over next to him, spawn special case pat on back animation, then spawn dialog. Spawn monster appearing, Dialog and enter fight.
This would be a very typical event for scripting. Another would be talking to the king of the realm, scanning the vars to see if you've completed your quest, and spawning the congradulations dialog/event, or the keep trying event.
Hope this helps:)
Mike
#13905 - maximAL - Wed Dec 24, 2003 7:47 pm
@mike
wheres the point of using an interpreted(=slower) language when the code has to be recompiled all the time anyway?
#13909 - Xax - Wed Dec 24, 2003 8:52 pm
Mike: As a newb, all of that info was very useful. Question. In what way(s) could you use scripts for menus and UI?
#13912 - sajiimori - Wed Dec 24, 2003 9:56 pm
I can't speak for Mike, but a couple obvious benefits of scripting languages are safety (can't mess with hardware or pointers) and simplicity (for artists and designers who shouldn't have to learn a lower-level language, or even for programmers who don't want to deal with irrelevant details).
Besides, nobody said the whole project has to be recompiled or relinked when a script changes. In a test environment, the scripts could easily be seperate from the binary executable.
For instance, my GBA projects generally have a 2-stage build, where C/asm/whatever code is compiled and linked first, then the data is concatenated into a filesystem and appended to the binary. After altering a script, only the second stage needs to be performed. Programmers could provide tools to artists and designers for automating this process and getting instant feedback on their work.
#13913 - Miked0801 - Wed Dec 24, 2003 10:02 pm
maximAL:
Recompile time isn't the issue - allowing non-developers (read cheaper labor) to code on a project is. Besides, once a sript is created and compiled once, it dosn't need to be recompiled. Also, we're using scripts for things where speed isn't a concern. Who cares if a menu is running at 60Hz or 30Hz. You won't noticed and neither will I. Optimize where it matters. Besides, for in-game tasks such as these, all the BASIC interpretor is doing is calling C code that we've already written - so there is no real large overhead.
Xax:
You'd add markup language to the interpretor such that it would read as a command: Place Button with graphic Z at X,Y on screen. Run code buttonHandlePress() if system detects it's pressed (kinda like VB). You get the idea (hopefully.) The thing with UI is that it takes nearly as long to do the BASIC code as it does to do the C code. The advantage being that if you did it right, you could create your UIs in a windows APP then export the data to GBA and have it work - again freeing developers to do other things. A properly coded menu system though would mostly nullify his advantage though. In our menu engine, I can create a basic button hop, text display type UI in an hour - including debug time. If it only takes that long, the benefit of offloading that task to other people in minimal.
#13915 - animension - Wed Dec 24, 2003 10:14 pm
Mike:
Thanks for that insight! That's exactly the kind of dialogue I was hoping to prompt from developers that are "in the know", and I hope others will also pitch in their 2 cents on how they see fit to use scripting languages. Since I don't have the time or patience to develop an entire language and interpreter from scratch, as for now I'm a one man dev team and want to get cracking on the engine, I'll probably use a pre-existing language.
As I see it, it would be a good idea to let the native code engine handle such things as blitting, sprite managing, sound processing, memory copies, interrupts, timing, and keypad input, and then to have scripts simply tell what to draw, what sound and music to play, what animations to start, and generally everything else that is "gameplay" oriented like event sequences, etc.
Am I on the right path if I were to implement something like the following:
Player presses keypad to move avatar into the doorway of a store
Engine handles the keypress, checks the map data if the next tile over can be moved onto. Engine scrolls the map to where avatar sprite moves onto tile. An array is then checked to see if a script needs to load based on this movement. A script to handle loading the store scene is called, and the script tells the engine to fade to black, load the store tile maps, start playing music for the store, and then proceeds to load other scripts that initialize actors in the store. A script for the store clerk actor is called, and the script tells the engine what sprite sequence to use for the clerk, where it's position is, and what script to run in the event the player interacts with the actor. After other actors load in like manner, the program flow returns to the script that initialized the scene, and since all actors are in place, fade-in and exit the script. Flow returns to the engine. Player then presses keypad to move toward counter where the clerk is waiting, each step of the way a check occurs to see if a script needs to load for movement onto a tile. Finally the player reaches the counter, and presses "A" to talk to the clerk. Keypad is received by the engine, and since the engine was told to load a script or function within the clerk's actor script for action events, flow then proceeds to the script interpreter. The interpreter loads the action event function of the clerk, and checks if a game state variable (has the player talked to the king yet?) is true or not, and tells the engine to display specific dialogue depending on the state variable. Flow then returns to the engine for the player to do as he sees fit.
A simple scenario, but nonetheless commonplace and pretty much covering all the specifics. If this kind of scenario is ideal from an efficiency and ease-of-use standpoint, I'll stick to it.
As far as choosing an implementation language, I'm hoping to use a somewhat high-level language that can handle complex data structures as I can cut down on the scripting if I can capture concepts such as scenes and actors in a easy to work with and reusable form, like objects or structs. I understand Python is a language that can handle such high level data structures, but I have also heard of Ruby and have also visited their homepage to do some research on it. Has anyone been able to successfully use either of these 2 languages on the GBA?
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin
#13916 - sajiimori - Wed Dec 24, 2003 10:26 pm
Python, Ruby, and Lua (another popular scripting language) are all garbage-collected languages. Has anybody used a GC language on GBA? I'm wondering if the mark-and-sweep process could disrupt a realtime environment.
#13919 - Miked0801 - Wed Dec 24, 2003 11:24 pm
animension
That's the exact type of thing that we handle with our script handler. Once the script interpreter is written, it's trivial to handle that event.
Other comments welcome :)
Mike
#13920 - tepples - Wed Dec 24, 2003 11:32 pm
Google claims that there exist real-time garbage collection algorithms.
However, will a script interpreter, scripts, and assets fit into 256 KB for the slave ends of a Single-Pak Multiplayer setup?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#13923 - sajiimori - Thu Dec 25, 2003 12:20 am
As Mike was mentioning (I think), scripts that are compiled to bytecodes can actually be shorter than equivalent CPU opcodes, and the accumulated savings should eventually make up for the size of the interpreter.
If my compiled scripts were not smaller than equivalent compiled C, I would be inclined to optimize my bytecode representations. Given the narrow domain of a simple scripting language, the bytecodes should logically contain less information.
#13925 - animension - Thu Dec 25, 2003 12:41 am
I'm not intending on building a single-pak multiboot-able game, so byte-code representation and the size consumed isn't that big of a concern for me, although conserving ROM space is an important issue nonetheless.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin
#13928 - sajiimori - Thu Dec 25, 2003 1:30 am
Well if you only wanted us to talk about things that are relevant for your project, you should have said that instead of merely "starting a dialogue". ;-)
#13936 - Miked0801 - Thu Dec 25, 2003 7:33 am
Yes, our scripts are much smaller than the equivilent C code would be - plus we can compress them giving us further savings. The code for reading the tokens really isn't that complex either. So yes, this is a good way to go. Garbage Collection isn't needed with our system as it's just a basic/token interpretor. Of course, going with a system that needed Python or such might be nice, it defeats the ability of Joe Random User from creating scripts - a real minus.
Mike