Recently I have been busy porting my PICO-8 Bumble Bots game to the Gamebuino game console. Gamebuino resembles PICO-8 in that it is also a console for making and playing retro-games with the emphasis on making them. Unlike PICO-8, the Gamebuino is a physical console based on an Arduino board. Here is a picture of a Gamebuino featuring my Bumble Bots game. (Btw, I "shopped" the picture to increase the brightness of the screen, but it's not a mock-up. This is a picture of the game actually running).
Porting my game has been a fun project. So far, I have ported all the game-play elements, and re-created nine of the sixteen levels. The coding is effectively done. The main work pending is porting the last seven levels. I am sharing my experiences here, as I hope that some of you find them interesting.
Gamebuino's resource limitations follow from its physical implementation and are mostly more tight than PICO-8's artificial limitations. The screen resolution of the Gamebuino is 80x64. Although it also supports 160x128, this resolution is not recommended. The details would be too small and drawing to the screen would require more CPU. CPU speed is anyhow a limiting factor. Just drawing an empty screen of 80x64 pixels at 25 FPS loads the CPU for 50%. On the PICO-8 I had no problem achieving 30 FPS, but realizing 25 FPS on the Gamebuino (with a more limited resolution) required a few optimizations. Also, unlike PICO-8, RAM-memory is scarce and you cannot really dynamically allocate memory. You are effectively restricted to global variables and the stack. This requires you to be more conscious of memory usage while you develop. Similar to the PICO-8, there are also limits to the size of the program, but Gamebuino games can be a bit larger. My game is near PICO-8's token limit, but will be less than 50% of the maximum size on the Gamebuino.
I found it very useful to first have created the game on the PICO-8 and then port it to the Gamebuino. For prototyping the PICO-8 is a much more friendly environment. PICO-8's code-run-debug cycle is faster. Lua is also a friendlier language than C/C++ which you need for the Gamebuino. A silly mistake in the C/C++ code can easily lead to a crash or (undetected) memory corruption. Also PICO-8's built-in sprite, sound and music editors make it easy and quick to create and adapt graphics and sounds. Creating images and sounds on the Gamebuino is more cumbersome. Fortunately, it was quite easy to port PICO-8 images to the Gamebuino. I was also able to port the sound effects I created, although this required a bit more work as Gamebuino's sound effect support is a bit more primitive.
In short, I found PICO-8 and Gamebuino to nicely complement each other. PICO-8 is an excellent environment to quickly prototype and evolve a game idea, and to get it out on the web. However, after that, it's great to port it to a physical device that you can hold in your hands and hand-over to friends to let them try it out.
See my post on the Gamebuino site for more details about the porting process.
Cheers,
Erwin
Heh, yes, zep spoils us rotten with PICO-8's cycle counts. A lot of the more impressive stuff on PICO-8 wouldn't be possible on the sort of hardware it pretends to be.
This is not a criticism of PICO-8, though. I might do a couple of things slightly differently, but overall it's a pretty fantastic fit for someone who wants to make a small game from scratch without too much pain and too many finicky details. Great for learning too.
Gamebuino is interesting but a little too limited for my tastes, honestly. Been there, done that, prefer this. ;)
@eriban After the trouble of porting Bumble Bots to a now defunct console, check out this handheld that sorta looks like a Gamebuino but runs real PICO-8.
[Please log in to post a comment]
