Task List for Multi-Game Development

[+Gemintronic]

This is not a new concept: just new to me.

 

I was thinking of dividing individual games into static arrays of 8-bit values. Each element would represent one of 256 routines to jump to. Obviously some routines would have to be unique per game. I'm hoping most (like polling joysticks or collision) would be common enough to afford some space savings.

 

Am I barking up the wrong tree? Does this actually save space?

 

I'm thinking also that you could use this technique for running two simulanteous games on-screen. The top half of the screen could be allocated to a unique game for player one whilst the lower half runs a seperate task list for their own (perhaps different) game.

[yllawwally]

Isn't this similar to what was wanted for one of the swordquest games? 1 bit determines, chase or run for player. Another bit to decide if you avoid or attack the monsters. A couple of bytes that would determine how a room would act.

[Wickeycolumbus]

Not sure I understand what you're saying completely. Are you talking about for a cartridge that has multiple games on it?

 

If so, done correctly it could save space. I do this in "Mini Game Collection". There are several routines shared across the 3 games on the cartridge, including the score kernel, "blank" kernel, joystick/switch reading, random number generation, and probably more that I'm forgetting.

 

Making the entire game a table of subroutine addresses probably won't compress it too much. There are many cases where the code would take less space if it weren't a subroutine. Different games would also require very specific routines as you mention. Adding in bankswitching would further complicate the matter.

 

The big issue with running two different games on the same screen is the processor time the game logic requires off screen. Of course you could designate every other frame for a particular game, or something similar.

[roland p]

There are many cases where the code would take less space if it weren't a subroutine.

True, I have the habbit of creating just one stream of code. Even the bankswitching is fixed (no jsr'ing). jsr feels bulky.

 

As for multiple subroutines. The question should be, what kind of games could you create by sharing lots of subroutines?

 

 

If you use an array of pointers (aka jump table), you need to store 2 bytes for each subroutine (high and low byte). The call could be:

LDX #subroutine_id
JSR gotosubroutine

 

But that doesn't take less space than:

JSR mysharedsubroutine

 

But maybe a variant of the BRK trick can be used? : http://www.qotile.ne..._prog_guide.txt

[Wickeycolumbus]

True, I have the habbit of creating just one stream of code. Even the bankswitching is fixed (no jsr'ing). jsr feels bulky.

 

That's pretty brave I've also heard of switching mid scanline to get more graphics accessible to the kernel. Seems like it'd be hard to debug.

 

As for multiple subroutines. The question should be, what kind of games could you create by sharing lots of subroutines?

 

 

If you use an array of pointers (aka jump table), you need to store 2 bytes for each subroutine (high and low byte). The call could be:

LDX #subroutine_id
JSR gotosubroutine

 

But that doesn't take less space than:

JSR mysharedsubroutine

 

But maybe a variant of the BRK trick can be used? : http://www.qotile.ne..._prog_guide.txt

 

It's interesting to think about. That'd make the game logic look pretty weird. I imagine something like this:

 

brk
.byte #ReadControllers
brk
.byte #MoveSprites
brk
.byte #UpdateScore

[roland p]

That's pretty brave I've also heard of switching mid scanline to get more graphics accessible to the kernel. Seems like it'd be hard to debug.

I just use includes to keep things readable. In ballblazer, I have 1 subroutine (the (pseudo) 3d>2d calculations), and some indirect jumping. The kernel occupies 6 banks, insert one nop and it's ruined . It's not that hard to debug, it's just a lot

 

I think it depends on the type of game. In sokoban, I used a some subroutines, to check if there is a space, a block or a wall at certain coordinates. When the player moves, the game has to know if the player moves towards a blank tile. if it's not blank, but a block, it has to know if the next tile is blank, so the block can be moved into that blank tile. So that routine is used 2 times there. But maybe it could be programmed without subroutines.

 

I think a lot can be programmed without subroutines. When do you really need subroutines?

[+Gemintronic]

Thanks for all the replies. Now I'm a bit more clear (to myself) what I wanna do. I'm pretty sure I can make a runtime language that starts at one 8-bit instruction long and allows however many subsequent arguments and parameters. My goal in designing a cross platform 8-bit scripting system is to use as little storage space per instruction with the most impact on game functionality. For instance, I could assign, say 16 to the function JOYEVENT. When I read an instruction from ROM and it happens to be JOYEVENT I have it refresh all input statuses and then jump to the event for the highest priority button/joystick press. Plenty of functionality for a single 8-bit value

 

I also plan on leaning heavily on default values. Say, if I assign a sprite to an object I'll assume the developer wants it to start at the center of the screen.