#169822 - hacker013 - Wed Aug 05, 2009 9:54 am
Heey everybody,
I'm still working on Ura Zelda Project and the project is already getting big. So I've to makte the choice now, a Internal scripting language or not? Can you guys explain me the do's and don'ts about it. Where to use it and where just use c. And which Interal scripting language is the most suited for the nds? I heard and know about Lua but are there also others? Can you please help me with these questions?
I also added a poll, just so that I know your personal opinion :)
- Hacker013
_________________
Website / Blog
Let the nds be with you.
#169826 - elhobbs - Wed Aug 05, 2009 1:33 pm
a scripting engine allows you to create content and game flow without having to rebuild the entire engine. it allows the game to be extensible.
I think for the ds you have lua or build your own. the are open source games with scripting languages - quake come to mind. but, that may not be the best example.
#169828 - sgeos - Wed Aug 05, 2009 3:48 pm
The real answer is, "it depends".
| hacker013 wrote: |
| Where to use it and where just use c. |
First, only use C for events when everyone who will be writing events knows C and knows it well enough not to crash your game. Also make use that you can't afford the overhead of a scripting layer (basically never) or you can't justify taking the time to add a scripting layer (small projects). When you use C, program everything with an application specific API.
Use scripting if not all of your scripters know C, or they don't know it very well. (Usually whenever you have anyone else help you with your scripts.) Scripting often provides a sandboxed semi-fail-safe environment. You will want to use an application specific scripting language. Under the hood, you can bind the C side application specific API to the scripting engine, so if done correctly moving to scripted events should be relatively painless from a featureset standpoint.
| hacker013 wrote: |
| And which Interal scripting language is the most suited for the nds? |
If you have the time, rolling your own will work the best. If you don't have the time, I'd go with Lua.
#169831 - elhobbs - Wed Aug 05, 2009 7:15 pm
one benefit of using C is that you can use a debugger. finding errors or logic flaws in scripts can be tedious without a debugger.
#169838 - Kyoufu Kawa - Thu Aug 06, 2009 8:07 pm
I'd say use an internal scripting engine.
I do it in OpenPok?, and debugging really isn't that much of a problem when you flood the system with realtime debug output on what commands are found, what bytecodes they have and what parameters they fetch.
#169840 - sgeos - Thu Aug 06, 2009 8:41 pm
You could always port an implementation of your VM to the PC and debug it there. As an alternative, you could set up a log file on your target platform.
#169845 - Miked0801 - Fri Aug 07, 2009 12:59 am
Don't borrow the trouble of a scripting system unless you need to. Just one more extra thing that can break.
#169870 - Karatorian - Sat Aug 08, 2009 1:55 am
It all depends on the game. If the game needs support for complex events, scripting can be helpful. If it doesn't, scripting can be overkill.
It also depends on the skillset of the development team. If the people who're going to be building events aren't neccessarily conversant in whatever low level language the game is written in, it can be easier for them to pick up a scripting language . It also reduces the chances that they break the whole game. Even if the event programmers know C (or whatever), it can be easier and faster if they don't need to bust out the compiler everytime they tweak one little thing.
As I assume you're making a Zelda clone, I'd imagine that the support for complex events is a project requirement. They can be handled with hardcoding or an advanced dialog system that isn't quite a full fledged scripting language, but often those dialog systems grow and grow until you end up with a poorly designed scripting language. It's often better to just implement scripting from the get go.
As for what to script and what to hardcode, that is a matter of personal preference. One method some people use is to script as much as possible. Basically, they write everything they can in the scripting language. Then, if something's too slow or whatever, they replace it with C code. Of course, somethings are just to low level to script effectively and it pays to know that, so you don't bother wasting time.
I assume you've got your basic game engine up and running. Here's what I'd suggest. Integrate your scripting language and then expose as much of the engine interface to it as you think you'll need. Then, whenever you want to add something, try to implement it as a script. If you can't, decide wether you should expose more of the engine (so you can) or implement it in C. This should allow for rapid prototyping of features, even if those features end up hard coded in the end.
#169876 - hacker013 - Sat Aug 08, 2009 12:18 pm
Thank you guys for yor reactions, they helped me a lot but they raised me some more questions. Like if I design my own scripting language, which way is the best to let it work. Like java with bytecode or like that the text is directly interpertated (batch way like).
Example second way:
cmd: drawPixel 16 16 green -> parse to an array -> search for command and execute with parameters in array.
Can you explain the differents between the 2 and way the 1 of the 2 is better ?
And if it would the best way to do it the way like java how do I program that ?
- Hacker013
_________________
Website / Blog
Let the nds be with you.
#169878 - vuurrobin - Sat Aug 08, 2009 1:04 pm
bytecode is easier to parse since you're comparing bytes instead of words. because the script has already been compiled to bytecode, most mistakes of the script (like typos) will be cought by the compiler, so you dont have to check for them on execution. bytecode script will also be smaller than text scripts.
textscripts avoids the need for a compiler, making it easier to execute them. but it means more work for the interpreter to compare words and check for errors. you can create and execute them on your ds, or even changing scripts during execution. its also easier to debug, because you can just print the command your executing to screen or a file.
I think the best way to start is to look at what the scripting language should do, and how you're planning the syntax.
#169880 - DekuTree64 - Sat Aug 08, 2009 1:13 pm
I would say, write all your command functions in C, then decide whether a specialized language would make it easier to call them. Or if you have a lot done already, post the list here.
Do you have a custom map editor for the game? If so, you might want to integrate scripting into that rather than using bytecode/text. RPG Maker has a nice intuitive scripting interface that's quick to work with since you can click on locations in the map to place sprites and stuff. At least RPGM95 that I used way back in the day had some annoying limitations though, particularly involving multiple conditions and simultaneous movement of sprites. But they'd be pretty easy to fix, and otherwise it's a pretty powerful system for its simplicity.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#169881 - Kyoufu Kawa - Sat Aug 08, 2009 3:31 pm
The process ala OpenPok?:
There's a list of function pointers for each possible command byte. These functions can call others to collect parameters.
For debugging, the interpreter loop has a list of all command names, which can be printed on a debug console. Each command also prints the parameters it collects.
Scripts are precompiled into bytecode as .s files: becomes | Code: |
.byte SAY
.word str0001 |
or something like that.
All this lets you compare the running transcript against the original script or bytecode. Say for example you mess up on the compiler and it emits a short where a byte was expected as a parameter, that would cause an extra command byte to appear, and you can tell because that command is not in the script.