Game Boy development

To try and stay true to the theme for this game jam, I chose to develop a ROM for the Game Boy.

It would have been somewhat easier to mimic the look-and-feel of a Game Boy game using another language/engine, but some of the charm of developing for older platforms is the limitations imposed by the consoles itself.

C Programming

This game was developed in C, using the GBDK-2020. I mostly work in JavaScript or other managed languages like C#. I have not used C in a long time (probably more than 10 years at this stage). It was definitely a challenge to get used to C's quirks. 

To speed up & simplify development, no dynamic memory is used, everything is stored in either global variables or lives on the stack. 

This worked, and although the code is a mess, the short duration of the game jam meant this was manageable. I did run in to problems at the 11th hour trying to link & compile music libraries, so that was one challenge I could not overcome before the deadline.

The alternative to C for Game Boy development appears to be either Game Boy Studio, or assembly code. I decided not to use assembly as the learning curve is too much for a short Game Jam. Additionally, I didn't use Game Boy Studio as I wasn't sure if it would provide useful abstractions for a custom turn-based game that I was making.

Sprites

The Game Boy is a very limited platform, it can only store 40 sprites and 10 per row. Since my game can have more than 10 units on-screen at a time, this meant I could not use hardware sprites to render these images.  (additionally, each unit is made of multiple sprites)

Instead, the units on-screen are actually rendered into the "background" tile map. The unit tiles are periodically swapped out to give an animation effect. 

The limitation here is that background tiles must be aligned to the background grid. When moving a unit, they need to move between grid cells. This means when you move a unit or trigger an attack animation, the game blanks out the background tile, and puts a sprite in place of that unit. At most this requires rendering 2x units (an attacker and a defender) which fits happily inside the sprite limitation for the game boy.

Scrolling

The game stutters when scrolling. This is because the "render" loop updates the entire background tile map with new images each time the viewport is scrolled.

Theoretically, this is not the most performant way of scrolling. The Game Boy can have a background tile map that can be larger than the screen, it would have been possible to render  the entire large tile map, and use hardware scrolling.

But this itself causes problems. When displaying a movement grid, the  current implementation can restrict this to updating just the tiles on-screen. So using a larger background would mean setting and resetting a larger area, potentially limiting performance while showing that area.

In the end, due to the short game jam turnaround, I did not peruse any of these optimisations. 

Known Bugs

I don't think the damage preview and level-up mechanic work quite right. I think at some stage they became broken when I implemented changes to the missions levels. It takes a fair amount of time to re-test these mechanics (playing through maps after each change) so these may be left un-fixed for the final submission.