Wed, 14 Oct 2020

I'd seen PICO-8 mentioned a bit on Twitter in the past couple of years without really getting it. I couldn't quite see the point of developing for a fantasy console when real 8-bit and 16-bit consoles (and computers) exist from back in the day. I'd been considering the difficulties of distributing Pac-Bun and how hard it is to get games running on multiple platforms (or even multiple machines with the same OS, but that's another story). For PICO8 there's a web player for making embeddable versions of your games inside a page. And it's easy to use. And you can make standalone "native" versions as easily for Windows, Linux and Mac.

And I thought about the tooling for developing on old platforms - luxurious compared to actually developing when these machines were state-of-the-art (DevPac 3 and it's free!?! When I were lad we had nowt but DevPac 1 and only after several years off a cover disk with no manual...), but still a bit awkward.

Then I realised I'd actually purchased PICO-8 in a bundle a few months ago and so the remaining excuses not to have a go had been eliminated.

I thought I'd take an afternoon's shot at it. I spent half that afternoon trying to get the installation to be portable and I still don't like the compromise I came to (see below). I was worried.

But then within a couple of hours I'd implemented a huge chunk of Pac-Bun. By the end of the day there was more:

Link (seems better for mobile)

And by the end of 48 hours:

Link (seems better for mobile)

Of course the first 90% is the easy bit. It's the last 99% that's hard. So it's been most of a month since then:

Link (seems better for mobile)

PICO-8 is a very well realised idea. The restrictions stop "rabbit-holing" too much without getting in the way of actually implementing features. Pac-Bun happened to be a pretty good fit, which doesn't hurt and I consciously decided to not fight the PICO-8 (well, at least not until near the end) and to not worry too much about how to do things. The resulting code is not a work of art. But at the same time, it could be so much worse.

The Lua implementation is fine. I'd messed with Love2D a bit at one point, but on the whole I'm new to Lua. There's a few things I don't like, the major one being indexing from 1 instead of 0 - but that's Lua's fault not PICO-8. And there's plenty who would disagree with me (and be wrong).

The built-in dev tools seem horrible at 128x128 until you start using them - and quickly you realise they're effective and refreshingly lean. I've since found BBedit more handy for code editing and begun using external editors for some sprites, but for the most part what comes in PICO-8 suffices and is highly convenient.

Music was... interesting - I get the impression this is the trickiest aspect of PICO-8, but my rather eclectic music experience seems to have helped me a lot here. And the excellent tutorials from Gruber.

Some observations:

• PICO-8 has way more processing power than real older systems, especially when you consider that it's running a high level language like Lua. It runs rings around most 16bit systems, never mind 8bit ones.
• PICO-8 has way more RAM to play with than older systems: the 2MB for Lua alone was reserved for exotic business machines like the Atari TT back in the day.
• The screen resolution is much smaller than most real 8bit or 16bit machines which underlines the comparatively huge processing power and RAM available.
• The cartridge size is tiny (esp when compared to the 2MB of RAM). I haven't played around with using multiple carts much yet, but the (artificial) lag from loading off another cart is noticeable and may be more of a problem than I'd like. I'm contemplating filling up memory at start-up for a new project - will have to see how that goes.
• 16 colours on screen (with some caveats) is fine. Only having 32 colours to choose those 16 from is a bit irksome, especially when the "hidden" colours aren't all particularly useful. It does stop a lot of wasting time selecting a palette, I guess. A less arbitrary available palette would be welcome for me at least, though.
• It does mean that the pal() command and associated tricks are so much fun to play about with, though.

In general, I've really enjoyed PICO-8 so far and I'd encourage others to have a go - if you've coded in the past it's fun to chuck away pretensions and hack. If you've never coded before it's a lovely little sandbox to get your hands dirty in and build some rather nice sand castles. It's very forgiving and that's always a good thing.

Minor moan - Portable PICO-8 for Mac - or not so much

Warning: please don't be put off PICO-8 just by this

I blame Apple as much as anyone - ~/Library/Application Support is a stupid place to hide data for applications at the best of times, but when it's where the documents, in this case source code, are supposed to live it's ridiculous. It's literally inside a hidden folder. How is this helpful to beginner coders? I kinda thought these were at least part of the target demographics.

The solution is to edit the config file in this location to point PICO-8 to look somewhere else for its file system (and hence your source code), but then you need to make the same edit on every machine you use it on.

Give me a config file in the application directory or in the app bundle itself or a setting within the application itself. And choose a better default.