gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Callback systems vs... ?

#17472 - poslundc - Tue Mar 09, 2004 1:11 am

I'm starting to assemble bits and pieces of the scripting system for my game. Since I'm probably the only one who'll ever be using it I'm keeping it pretty low-level. Eventually I'll make something higher level for the more fundamental RPG features (eg. what happens when you talk to someone, etc.) but right now I'm just looking at very basic stuff that happens when the game first loads, like displaying a splash screen, fading the screen up and down, setting up the start-game menu, etc. Stuff that I already have modules to do the actual work for, but now I need something that tells the game what pictures to load, what music to play, how long to wait, in what order, etc.

Right now I'm just looking at creating a C module with a bunch of functions to do these tasks, and each one sets up a callback for the next function that needs to be called. So for example the first function sets the initial game state, sets the palette fader to black, calls the module to load the opening splash screen and then calls the fading module to fade up. When the fade is complete, it activates a callback function which is the next link in the chain, etc.

I'm fairly confident I have a workable system here but I thought I'd see if anyone had any input or insight into this process. Maybe head me off before I code myself into a corner, or something. (And no, Mike, I don't envision myself writing a BASIC interpreter to handle this stuff. :)

Thanks,

Dan.

#17474 - Miked0801 - Tue Mar 09, 2004 2:25 am

:)

What has worked well for us (for years and years on many platforms) is to have what you are calling a script system (we call it the menu system) actually run our whole game. Each module (State) has 3 functions associated with it, an Entrance, Tic, and Exit function. The entrance state is run when a state is begun. It setups up the screen and such (fade in, place sutff, etc.) use the tic to handle input and state changes, and have the exit run to free vars and fade out. Easy to code, easy to maintain, easy to use. Yes, it's a finite state machine and it works beautifully. Sound like your going that route anyways :)

This is a seperate system from a RPG hi-end script handler. The low level is designed to move you in code from state to state. The high end handles only code within the in-game state.

#17755 - bats - Sun Mar 14, 2004 6:12 am

That low-end scripting sounds like a pretty good idea.
I actually just finished my high-end scripting system, and I have to admit, it wasn't nearly as difficult as I thought it was going to be when I started...

Basically, I made designed a virtual machine, assembly language, and scripting language bottom-up. And wrote some execs in perl (way simpler than it would have been in C/C++) to compile and assemble. Time: about a week and a half.

I don't have much experience making games, but it seems to me if you're working on an RPG, you can afford to spend the time to make a nice scripter.

Ben