The following text is somewhat like the long version of a lightning talk I gave at the most excellent Eurucamp. As I used a lot of animated GIFs in Keynote, it’s kinda hard for me to publish a working version of this presentation in any form. So this article must do.
In her keynote at Eurucamp, Joanne talked about awe and how to combine coding with our passions.
For me, one of the ways to get that extra kick is dabble in game programming. I’m bad at it, though. The reason is, I guess that I always lose myself in complexity and then all the fun and awe is lost. This is partly because I tend to over-complect both my thinking and my creations, but also partly because most tools do not keep you from doing that.
A few weeks ago, around the time the amazing SoCoded happened, I stumbled over a thing called Pico-8. It is a so-called fantasy console, a sort of virtual machine or emulator of an imaginary console from the 80’s, designed and built by Joseph “zep” White from lexaloffle games.
Pico-8 is wonderfully quirky, but it also has some very interesting technical limits, artificially but deliberately chosen by its creator.
When you start up the standalone executable (Which is available for Linux, Mac and Windows), it looks like this:
If this looks familiar to you, you’re now officially old. It looks and feels like the majority of home computers that have been released in the early to mid 80’s. It has a prompt that let’s you program. Instead of a BASIC dialect most probably written by Bill Gates, though, Pico-8 uses Lua, the wonderful embeddable language that drives so many game scripting engines. zep chose to only allow a subset of Lua (you don’t have access to the standard library, for example) to keep it within the spirit of the rest of the limitations and the API surface of Pico-8 is also very small.
The magic really starts when you hit ESC (no, this is not vim). You’re landing in a code editor. A very pixelish editor, that is, but with decent support for the most important things you’d want: select, cut, copy, paste, find, it’s all there.
But that’s not enough. if you click one of the icons in the upper right, you can get to a pixel/sprite editor, a map editor, a sound editor and a music editor. There’s no official way to import assets into Pico-8, and while I’m sure people will build tools to do that (more on that later), part of the magic of the Pico-8 experience is that it’s not only necessary to use the internal tools, but it’s also a ton of fun.
Pico-8 has only 16 colors and a resolution of 128x128 pixels. Sprites can be anything from 8x8 to 64x64 pixels, but most games so far seem to embrace a simple 8x8 design.
To design levels for your game, you can use the map editor. you can basically use the same tools as in the pixel editor, with the difference that you’re now painting with sprites instead of pixels. There’s a pretty harsh limit on both the number of sprites you can have and the size of the maps with the additional quirk of the map memory sharing some parts with the sprite memory. This sounds weird, but is a pretty cool play on the memory mapping techniques of 80’s home computers as well as giving you a choice between having lots of sprites or having more or bigger maps.
The sound editor is an interesting thing: Pico-8 uses the same format for musical patterns and sound effects - For the most part the only difference is the speed at which they are played. You can create sound bleeps by drawing with the mouse or you could use a tracker mode.
The tracker itself then allows you to chain patterns together and turn them into one or more pieces of music. You can only create 64 bleeps or patterns and you can have a maximum number of 64 song parts. This doesn’t sound a lot, but you can actually loop different parts of the “song space” differently, so it should be relatively easy to create a multi-song soundtrack.
The theme should be clear by now: It is indeed all about the restrictions. As with any art form, game design and development often benefits from restrictions. For me, the most important ones in Pico-8 are:
I am not too worried about designing graphics. 8x8 pixels and 16 colors don’t give you a terrible abundance of choice if you need to pixel a wall, a monster, or a mage. This means that I can just start creating.
The simple API and the reduced screen space force you to keep things simpler and reduce your game idea to bare minimum. This helps me to overcome the problem of designing too much upfront in my head and then struggling with the actual implementation.
To have something “finished” to demo at Eurucamp, I chose to, instead of coming up with something on my own, implement a real video game classic, Pong. Weirdly, nobody did that before in Pico-8 as far as I can see. It took me somewhere between 4-6 hours to have a decent version with most of the original features implemented.
When saving from Pico-8, it creates a file with a p8 extension. When you open this in a text editor, you’ll see that it’s a text file with several chunks that contain a header, the lua code and serialized binary data. This is great, not only because it allows you to use an external text editor (which, of course, is frowned upon), but also because it allows you to collaborate, as you can easily copy/paste music or assets from another p8 file.
If you’re done with your creation, you can save it as a so called cartridge, which is a png file that not only contains a screenshot of your game and a title you can set by adding two lines of comments to the top of the source, but also the complete game data and code.
You can then upload that cartridge to the lexaloffle website and add it to a forum post, which will then have an embedded web player that will play your cartridge in any modern browser.
My version of pong, called PXLPNG can be found there as well, of course.
Future versions of Pico-8 will probably come with a distributable web player.
Pico-8 unfortunately is not open source and costs ~USD 15 at the moment, but for me, it was worth every penny so far.
It is currently my happy place as a software developer. Web development, like almost every part of software development, got a lot more complex in the last years and to me it seems that this is a trend that will go on for a while until our tools are designed to hide most of that complexity again. Sometimes this complexity can be a bit overwhelming and it helps to be able to dream about simpler times. While this might not be useful for developing sophisticated apps, for games it is a great, fun and productive platform.
