On international Talk Like A Pirate Day 2019, I released a Pico 8 game that's seen more attention than any of my previous projects, Pico Pirates.
In this post, I’ll be going through the development process from start to finish and touch on a few specific points, namely;
So, let's start at the beginning.
I first started experimenting with Pico 8 in November of 2017. The first cartridge I put any significant time into was a dynamic fluid system adapted from a project I completed as part of my degree. This was partly to test the technical capabilities of the engine and partly to accustom myself to LUA, a language I'd not previously had any experience with.
Once I had a functional interactive fluid system up and running I began adding additional features. I already had a boat that I could move around to create waves and so the next logical step was to add a cannon to make even more waves. But what's the point of a cannon if there's nothing to shoot? A sea monster sprite was created and wriggling tentacles added to create even more interaction with the fluid system. Now we needed to make shooting a sea monster feel nice and juicy and before I knew it the cycle of feature creep had taken over this little tech demo.
This iterative process was rather addicting and I soon fell in love with Pico 8. It felt like no other engine I'd ever used before. With Unity, Unreal or even Game Maker it's easy to become lost in seemingly endless UI windows for features that would certain be useful at some point in a larger project but to begin with can feel rather daunting. Pico 8 was much more akin to building a model railway, full of possibilities with development that felt more like play than work. Everything from the boot jingle to the stripped down code editor was meant to feel different from other engines, to feel much less stressful and as lexolaffle’s zep put it, cute [link here to zeps talk on cute dev tools].
It was this feeling of playfulness that made me comfortable enough not to continue work on this cartridge. The joy of development was a far bigger allure than the idea of releasing a polished product and having to go through the more difficult stages of development such as balancing and optimisation (we’ll come back to that last point a lot more later on).
Over the next couple of months I developed a simple arcade game (Super Funky Ball) and prototyped a series of other ideas. One of these ideas grew out of an art test with isometric sprites; a set of small buildings, trees and patches of land which I envisioned would one day form part of a farming simulator. I posted these onto my Twitter feed and was bowled over by the positive reception, it only seemed sensible to continue working and turn this art test into a full fledged game.
After a few weeks of iteration I began to realise a few unfortunate things;
To counter this, I began to break down what I would need to make this project a success and how I could move forward. One aspect of note was world generation. How do you generate an isometric world?
To answer this, I booted up a fresh cartridge and began what would become the over-world section of Pico Pirates.
Went to go make a new #pico8 file for doing iso worldgen, but got distracted and ended up with this island gen + boat thing, woops pic.twitter.com/pUWGW17TDy— Craig Tinney (@ctinney94) January 23, 2018
This early prototype had no relation to an isometric layout and served a nice breath of fresh air from all the nasty maths I managed to get myself tangled up in. On top of this, my placeholder art for this new cartridge proved to be very pleasing to myself and folks on Twitter. I began refining what I had and started adding more features. A boat with more realistic waves, beaches with waves the lapped calmly over the surface, a generic text box and string rendering system. Doodles became sprites with numerous palettes and soon enough it became apparent this simple cartridge was developing a life of it's own.
Ah, feature creep. Hello old friend!
During this period of development I'd been going through a spell of unemployment which thankfully came to an end in February of 2018. The downside of this being my free time becoming more restricted and as a result, my Pico 8 output dropped significantly.
Skip forward a few months and I managed to get my work-life balance into a place where I could dedicate more time to things like game development. I was getting better at self management and successfully released a number of smaller cartridges in the interim to scratch my programming itch. Instead of starting with art assets for these smaller cartridges, I instead focused on more finite, well defined technical challenges such as implementing the mechanics of a double pendulum simulation ( https://ctinney94.itch.io/double-pendulm) .
My appetite for a larger project was ever growing. One day I remembered two of my previous projects, the top down island generation and the reactive water demo. They're both games about boats, what if you could explore islands and get into random encounters with sea monsters? I started to sketch designs of what the final look of the game might look like, fantasised about what the experience might feel like if I managed to get everything in my mind implemented. I started to get excited. This would be my best Pico 8 game to date!
Despite this excitement I still had a number of core design questions to be answered. What would the overall objective be? What else could they player do other than move between islands and get into scraps with sea monsters?
But I didn’t care, the appeal of this project was too great and I soon set to work without giving these questions much though, perhaps to be own detriment further down the line...
In October of 2018, I managed to secure a new job with a more programming focused role which involved making a significantly longer commute. Despite this consuming more of my time, this resulted in a huge improvement to my Pico 8 output. Now I had a pair of 1 hour blocks of time on the train which would be perfect for casual chunks of game development!
Before I could start making use of this time however, I would need a new development machine...
Until this point I'd exclusively been using my desktop computer for all my game development, but that clearly wouldn't be suitable on the train. I decided to spare no expense and took a trip down the local cash converters. I quickly bought the lowest spec netbook on display. Pico 8 runs quite comfortably on a Raspberry Pi so I assumed any modern windows machine would do me just fine. For the most part, I was right, this machine proved to be adequate for the task at hand but it undoubtedly had an influence of the development process of Pico Pirates.
Something I hadn't anticipated was the lack of a high speed internet browsing capabilities. Granted I had access to a connection for the majority of my 1 hour train dev sessions, but it often unreliable and trying to load more than a single browser tab resulted in progress grinding to a halt as my netbook struggled to switch between tasks. This resulted in a substantially lower reliance on online resources for finding technical solutions to problems and made posting content to social media much more difficult. Before this project, I would've said this first factor could only decrease my efficiency but this turned out to not be entirely true.
Without access to the usual quick google-copy-paste solutions I was used to, I was instead forced to take my time, seriously consider what I was doing and actually think through solutions to my problems. As someone who grew up in the online age and started programming in my late teens, this was maybe one of the most important shifts in my own, personal development during this project.
The inability to post small updates to social media also kept me focused on the task as hand and encouraged me not to concentrate too much on work that might be more flashy or visually pleasing than technically sound.
The smaller slots of development time also allowed me to experiment in well defined periods of time without getting too carried away. In this time I created dozens of tweet carts and started to grow an appreciation for optimising sections of code to fit inside a strict character limit (something that would prove to be invaluable later on in development).
Features of Pico Pirates were developed in a more modular fashion. I would invest train journeys on creating a map that would be slowly filled in as the player explored the world, pseudo 3D trees for islands and alternative views for digging up treasure. This method of development was brilliant for rapid iteration and measuring the limits of what was possible with the modest memory and computing power allocated by Pico 8. The downside of this however was when I would inevitably have to merge this work into the larger project, often a time consuming process and one that would blind me to viewing my token budget as a whole.
Which brings me quite nicely onto my next topic.
For those unaware, Pico 8 has a fixed limit on the number of chunks of code that can be used in a given cartridge.
In the example below I’ve highlighted the sections of syntax that count as 1 token each (there’s some interesting rules surrounding this, such as opening and closing brackets counting as 1 token collectively, but generally it’s one token per piece of syntax), totally
print ( "Hello world!" )
9 tokens for a simple for loop. You may notice that values such as numbers or strings are one token regardless of size or content. Just file that thought away in your mind for the time being.
As progress continued on Pico Pirates, the token limit became an ever encroaching challenge always on the horizon and something I would eventually need to address. A number of features I had yet to fully flesh out were removed for fear of over running this limit.
The most significant of these ideas that were removed was whirlpools which would be spread out over the game world. The plan was for these whirlpools to teleport the player to another whirlpool somewhere else as a sort of chaotic fast travel system. This mechanic would be accompanied by a number of unique visual effects to really sell the effect. Since I decided to cull this feature, these visual effects also ended up on the cutting room floor, saving a huge number of tokens.
Pretty chuffed with the (near) final zoom effect put together for use in pico pirates— Craig Tinney (@ctinney94) July 23, 2018
Plan is to combine this with the whirlpool effect made last night and teleport the player around the world because that's how whirlpools work, like sea wormholes #pico8 pic.twitter.com/nLV5081TQY
Other features had to be drastically optimized. I was forced my to examine every existing function to find what could be trimmed down in any way. This proved to be invaluable in keeping myself familiar with the many parts of the project but certainly did prove to be quite the time investment. Whole train journeys were spent examining single functions and wittiling them down to the most bare components whilst keeping everything functional.
This process also resulted in code become significantly more dirty. Some of you might be familiar with the principles of Clean Code and how useful it is as a general programming practice for both yourself and whoever might also end up reading your code.
To keep it brief, Clean Code dictates a number of techniques to help keep your code readable and easily maintainable through descriptive naming, single use functions and detailed exception handling to name just a few. Basically every single one of these techniques had to be ignored to meet the technical limitations of Pico 8. Fully descriptive variable names? Takes up too many characters. Simple, single use functions? Functions take tokens to create, if only used once, the logic would need to be where this original call is made. Separate exceptions and classes for individual cases? I wish!
Stringifying many variables become a prevalent part of the code base. Remember when I mentioned variables such as strings would only ever count as one token? Turns out, if you want to store more unique variables but don't want to spend any extra tokens, building arrays from strings is a great way of accomplishing this.
Take the following as an example;
// Draw part of the HuD on screen
// Draw another part of the HuD
A fully fleshed out HuD could feature dozens of sprites all requiring specific placement and sprite values which would all require additional token consumption.
By including a stringToArray function, we can take all these unique values which would normally each take up a token each (plus the comma used to separate them!) and pop them all into a single string.
Here’s what the result of this using this new function would look like;
for i=0,[number of things to draw],5 do
Not the most readable of snippets I’m sure you’ll agree, but ultimately worth it from a token quota perspective. I still can't help but look at sections like this and feel a certain level of disgust. My once beautifully simple instructions reduced to a set of obtuse array entries.
Without this mess littering my cartridge, Pico Pirates wouldn't have half the number of features eventually made their way into the final release.
At this point, Pico Pirates had been in active development for about a year (not counting the original fluid demo cartridge and subsequent hiatus) and I was starting to feel like this cartridge was about as optimised as I was ever going to make it. I was growing ever more desperate to just get the game finished and released to the world. There was a somewhat rudimentary gameplay structure but still no concrete ending or any real incentives for exploring different islands.
In reality, the most significant parts of Pico Pirate’s gameplay such as the final boss and distribution of varied rewards from treasure chests had yet to be implemented and would only materialise in the last ~10% of development time. At this point what I had was a very polished, repeatable, vertical slice. A procedurally generated world, combat encounters with a couple of different enemy types, but not much beyond that.
As a result, the subsequent bonus items added for finding treasure chests were viewed through the lense of combat. The rewards eventually decided upon included the following;
There wasn’t (and still isn’t) anything that helps players explore the world any more efficiently, which seems daft considering this is what most of the game is spent doing.
When I did decide on an ending for the game, it only made sense that there should be one last final encounter. One final big blowout to provide a proper challenge and test the players’ skill. The same enemy they’d have to fight dozens of times to get to this point, just much bigger and scarier (one benefit of this being large portions of existing logic could be re-used, saving the amount of tokens required). I toyed with the idea of this final enemy being ever present in the world, travelling about independent of the player. In practice this would prove too costly and was eventually downgraded to simply appearing once the player finds 4 pieces of a compass (the final item to be added to the possible pool of treasure chest items).
Whilst this felt like a cheap solution at the time, I’ve grown to appreciate this design decision and come to peace with it. It makes sense in a narrative context and gives the game a sense of scale, a pecking order which the player falls into.
The time is now mid-august 2019 and the end development appearing on the horizon, Pico Pirates could be called feature complete with the final addition of the final Pirate King encounter and the culling of ever more tokens. I decided to choose a deadline. Talk Like A Pirate Day seemed like the perfect time, it gave me 4 or so weeks to prepare for release and had a very suitable thematic connection.
As I started to view the project through a different lense, that of a final product, there was just one main omission that became obvious. Music.
I would not describe myself as a musician of any sort (except perhaps a bad one) and my previous attempts at creating melodies failed to live up to the standards I had imposed on the rest of development (i.e. not being complete rubbish). It became apparent that I would need to bring in some outside help. A few months ago I sent out a tweet vaguely asking for opportunities to collaborate with chiptune musicians which never caught traction so a more direct approach would be required.
In the Pico 8 community, there are a number of key developers that anyone involved in the scene will probably know of and of these only a small number of them are musicians or composers.
Chris Donelly (known to most as gruber_music) was the first name that sprung to mind when thinking of standout Pico 8 musicians. Some of my favourite Pico 8 games prominently featured his work and for good reason, Chris is an absolute wizard when it comes to harnessing the limited spectrum of Pico 8 audio effects.
I’m sure it won’t come as a shock to many that I’m not exactly a big name celebrity in this niche development community and was certain an accomplished figure such as Chris would like nothing to do with the likes of little old me. Nevertheless, I reached to him out on Twitter and told him a little my game.To my amazement, not only did I get a reply, but Chris actually seemed to like my game and offered to help develop a soundtrack!
If this chance encounter had not gone according to plan, I may not have ended up with such wonderful music in the final version. I didn’t have a second pick for people to blindly to ask for help so I’m incredibly lucky the first person I asked agreed to help me out. To do this a mear month from my self imposed deadline was a silly thing to do and could have very easily backfired.
With music being an afterthought, I had neglected to leave the audio portion of the cartridge in an orderly state. Sound effects had to shifted around, references all over the code base refactored and evaluation had to be undertaken to establish how much space could be given to create a complete soundtrack to the game. Whilst this didn’t impact the release timescale, it certainly wasn’t the most productive process and could’ve been avoided with a bit more forethought.
I have to say, when Chris’ music was added to the nearly finished product I felt a huge burst of joy! It was like Pico Pirates went from some collection of code and sprites on my awful netbook suddenly turned into a video game that people might actually want to play!
At this point, I had two weeks left until my deadline and everything was seemingly complete. The list of bugs reported by friends I roped in to help test the game grew ever smaller and my list of things to complete all but dried up. The last fortnight before release was spent playing the game over and over again trying to find any technical flaws that I might have previously skimmed over. Having such a large amount of free time was a great relief and certainly more preferable to my previous game jam releases which inevitably became mad dashes to the finish line which ended up producing silly bugs which normally wouldn’t be produced in a more relaxed environment.
In the days approaching release I wrote the descriptions that would be posted on itch.io as well the lexoffle forums and made a fancy picture for the finished cartridge.
At this point I can only view Pico Pirates by it’s failures, by what could be done better, by all the imperfections I had to make peace with in order to get it out the door. This postmortem is really just me attempting to justify what I view as the games shortcomings and making peace with what I will always view as an unfinished project. Still I can’t ignore what strangers who don’t know me on the internet say about Pico Pirates. It stayed atop of the most popular Pico 8 games on itch.io for about a week after release and currently sits at a solid 5 star rating (thanks to all 6 people for your ratings).
The lack of enemy variety and variance in tasks available to the player I would say is the biggest downfall of the experience as a whole. I believe this is a natural consequence of being unaware of the resources available in a single Pico 8 cartridge and a failure to plan for the design for the game as a whole in its inception.
The octopus/kraken/sea monster enemy is certainly the strongest enemy in the game in terms of variety and challenge. The telegraphing of certain attacks with the subtle movement of the water surface is a great use of an aesthetic feature that also fulfills a use in gameplay without being overly distracting. The periods of idleness make hitting the monster significantly easier than the smaller enemy ships that quickly shift from left to right, something I noticed new players struggle particularly with early on.
Alternating attack patterns would certainly have improved the other combat experiences but I do still struggle to imagine how many different actions an enemy boat might be able to make.
The rewards from island treasure is another example of how greater variety could've improved the experience as a whole. For the player to reach the natural end of the game they would have to visit dozens of islands and would inevitably encounter the same reward potentially 3-4 times. Perhaps singular, one-off mechanical upgrades could've improved things here. I'm a particular fan of games that manage to stack upgrades on top of each other (such as The Binding Of Isaac or Nuclear Throne) and potentially something that could’ve worked quite nicely in Pico Pirates.
The reception from players has been nothing short of wonderful. I have yet to show the game to a friend of acquaintance without having them smile and tell me something they like about the experience within the first few minutes of play. Now I’m under no delusions that someone playing this game with me standing right by them will probably be inclined to say lovely things to me out of politeness, but still, a very warm reception which I’m very grateful for.
So back to my original question when I started writing this, was it all worth the time and energy? Purely from my own experience making this game, absolutely. For me game development is its own joy and having any play what I make is just the icing on the cake. If I knew nobody was going to any of my games ever again, I’d still make them.
The lack of financial backing or requirement for commercial success were reasons why a) I could take as long as I did to make a fairly short game and b) removed any potential stress by not designing with a market in mind or needing to get the game into as many hands. However this did play into why it took 2 years to develop from initial inception to final release. Would I change things in retrospect to shorten development time? Probably not. Taking it slow is an underrated privilege that helps to minimise stress and prioritise artist integrity.