Pirate's Folly

January 11, 2022
3 minutes

The Raspberry Pi Pico inspired the release of the Picosystem. I love working with limited hardware as a challenge to improve my programming. I’ve had my fair share of 6502 assembly for the NES but recently enjoyed the new RP2040. The Picosystem uses the RP2040 to run games, so I just had to try it out!

I began development of Pirate’s Folly, a procedurally generated game. I’ve laid the groundwork for terrain and item generation; however, enemy placement is still needed. In the GitHub repo, I have a list of completed and planned features. The idea is a blend between One Piece, Minecraft, and No Man’s Sky. Pirates competing for treasure is such an entertaining concept since pirates are the most unpredictable and greedy people! To lean on my CS (and not artistic) background, I used Hugo Elias’ procedural generation webpage for algorithm details. His site is down, so you can view a locally-served PDF. That enabled me to generate over a thousand square kilometers of terrain to explore. So, like Minecraft there is a vast world to explore, but I have a global seed (57) that will show the same world to everyone. In that way, players can share good locations for items or pirates.

PicoSystem

I’ll keep this page updated as I proceed. Currently, I’m wondering if I want to develop the game for Game Boy with the upcoming release of the Analogue Pocket and GB Studio 3.0.

Transition to Game Boy

Sadly, the Picosystem SDK stopped getting updates after the system release, so I decided to move the game to a more reliable console. Restraining the requirements further, I began using GBDK-2020 to make a GB game!

I chose to use GBDK-2020 instead of GB Studio because I know how to program C and something like procedural-generation isn’t nearly as common as side-scrolling games. When GB Studio abstracts away a lot of the programming aspects, they lower the barrier of entry while compromising expressability.

A lot of the code from the Picosystem could be reused for Game Boy; however, every 16-bit variable needed to be converted to 8-bit. In addition, float arithmetic isn’t supported in GBDK (or on the GB’s Z80 processor for that matter). These restrictions ultimately reduced the quality of map generation, but it should still be good enough for exploration.

Game Boy

Procedural Generation

After loads of trial and error, I found that the following formula works very well to provide fast and seeded noise.

uint8_t noise(uint8_t x, uint8_t y) {
  // return random number [49, 201]
  // derived from perlin noise and 8-bit xorshift
  x ^= (y << 7);
  x ^= (x >> 5);
  y ^= (x << 3);
  y ^= (y >> 1);
  return x ^ y * SEED;
}

The formula took inspiration from Hugo Elias’ tutorial, but is closer to Michael Martin’s xorshift post. The xorshifts I use differ from common xorshift algorithms in that the function doesn’t use its previous output as the next input. Here, noise is a function of x, y, and SEED.

Profiling

Procedure% Self CyclesSelf CyclesInvocationsProcedure Cycles
_interpolate_noise40.7%100035660127866036/8112/8111.8
_set_bkg_tiles.set_xy_btt21.6%5306900867324520/8328/7883.1
_shift_array_left16.8%412876806718122880/122880/122880.0
_shift_array_up9.3%2278617633667816/67816/67816.0
_generate_side3.8%9259312673167776/189308/180029.8
_terrain2.0%4909548127866188/8540/8539.8
_noise1.5%37845844730738/8/8.0
_generate_item1.1%260834412786212/212/212.0
LABEL_1C61.0%23946843501684/684/684.0
_display_map0.6%15954326732155176/158632/157505.6
LABEL_400.4%110082035011100/1112/1100.0
_set_bkg_tiles0.4%107708867324680/8488/8043.1
_closest0.2%5625841278644/44/44.0
_update_position0.1%2986042212735
LABEL_A40.1%2100603501744/744/744.0
_generate_map_sides0.1%1828726719167864/551336/550198.1
LABEL_0.call_hl0.1%1262043501780/792/780.0
_get_terrain0.0%117068100968/140/116.0
00106$0.0%1102322206353
_check_interactions0.0%75264336264/264/264.0
_joypad0.0%67200336200/200/200.0
_adjust_position0.0%36396337
LABEL_48.int0.0%19500751040/1052/1040.2
_clock0.0%1344033640/40/40.0
_main0.0%012778
_check_input0.0%012778