#175208 - Ruben - Sun Oct 03, 2010 4:17 am
Hi, again.
I'm working on my DS port of an RPG... and I've gotten to the part where maps require scripting (events and whatnot).
When I used to code on the GBA this wasn't a problem as ROM was executable so all map functions could be written in C and just linked as normal. However, since the 'ROM' area of the DS (filesystem) isn't exactly executable (at least, not by linking all the code at once), I've run into the necessity of scripting instead of functions.
DekuTree and I were discussing this just yesterday and brainstormed a few ideas but couldn't really arrive at a proper conclusion. So I was wondering what your take on this would be (the pros + cons and why you chose that design (ie. makes sense, space efficient, whatever)).
#175209 - Dwedit - Sun Oct 03, 2010 4:30 am
You could do scripting, you could use a virtual machine, you could even use overlays.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#175210 - Ruben - Sun Oct 03, 2010 4:45 am
Well, the scripting idea seems the most obvious and logical choice... overlays are a pain to work with... and can you expand on what you mean by virtual machine?
#175211 - Dwedit - Sun Oct 03, 2010 5:23 am
It's basically just scripting, but with bytecode instead of text commands. I only mention virtual machines because I've worked on emulators.
If I was doing it, I'd use overlays, because I'm more comfortable with swapping in and loading ASM code than embedding Lua or something.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
Last edited by Dwedit on Sun Oct 03, 2010 5:28 am; edited 1 time in total
#175212 - Ruben - Sun Oct 03, 2010 5:24 am
Ah. Well, that's what I had thoguht about when I mentioned 'scripting' =P
Except, of course, I meant using #defines so I can actually use text.
So apart from the virtual machine idea, are there any other ideas? Perhaps position-independent code?
#175213 - Dwedit - Sun Oct 03, 2010 5:36 am
When I was doing the Pocketnes GBAMP firmware, I had to split things up into two projects. I had function stubs located at well-defined fixed addresses that jumped to the real address of a function, and well-defined equates from the other project.
So my idea here is to have a block of code to load dynamic code into. You have the master project, and a bunch of slave projects. Slave projects use a special linkscript so they have their code and data located within specific boundaries.
Whenever the slave needs to call something from the master, you put in a stub at a fixed address within the master project, and define the address of that function for the slave project. So you need to manually export a bunch of functions.
Or just use real overlays so the compiler gets all the linking correct without making slave projects.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#175214 - sgeos - Sun Oct 03, 2010 6:28 am
I highly recommend scripting, as I don't see how you could reasonably complete an unscripted non-tech demo RPG. Having 1+ full time programmers and 1+ full time scripters is not abnormal for full scale commercial RPG development. Lua is the canned scripting language of choice, although a lot of pro shops roll their own scripting languages. The original FF4, like most SNES games, would have been scripted in an ASM-like scripting language. (Writable, but not really readable by others.) Custom scripting languages these days tend to be C-like... or they were last time I checked.
If I were going to do this, I'd embed Lua (relatively easy) and write some code to interface with a table of flags. I'd have three types of flags- temporary (cleared when you leave the map), permanent local (saved, local to each area / map), and permanent global (saved, accessible to all maps). You could have temporary global flags if you really want them (cleared on reset). Recurring things like chests could have a special set of flags, or be part of the local or global pool.
I'd also create some sort of a definitions module for each local area / map. Then I could write something like:
| Code: |
if (tempFlag(def.SWITCH_A)) then
message(mes.NOTHING_HAPPENS)
else
message(mes.CLICK)
patchMap(def.SWITCH_A_X, def.SWITCH_A_Y, def.SWITCH_A_PATCH)
setFlag(def.SWITCH_A)
end
|
This would be a script to open a secret passage.
Note that I'm treating the map (and greater game state) as a state machine with live preloaded data. The scripting engine is called by the game engine and has read / write access to the parts of the state machine you choose to expose.
Obviously changing party members, restoring HP/MP, adding/removing items and all that stuff should be scriptable. You'll need extra glue code for all of this, if you go the scripting route. See the RPG Maker scripting documentation for an slightly incomplete list of scripting features that will probably not be tailored to your situation.
None of this is hard stuff, but after you finish the scripting engine you need to fill it with content. That is the hard part due to the sheer volume of scripts that need to be written.
(If there are any strange misplaced words in my post, I curse auto spell correct to the underworld. Again.)