Postmortem

It has been a week since the Linux Game Jam 2023 development period concluded. I’m looking back at how the jam went and what I learned. My decision to use PICO-8 for this jam is where most of my reflections lay, so I’ll cover that last.

Build and publish

I prepared upfront to automate the build and publishing pipeline. It did indeed avoid a last-minute panic to publish on a deadline. When the jam was extended by a day, that automation meant I could work on one last feature right until the last hour with the confidence I could publish a new build of the game in just a few seconds.

Changes for the future:

• Create a project template including standard boilerplate code for a stub game (common helper functions, menu, controller handling, etc) with build and publish automation ready-to-go.
• Create a GitHub Workflow for exporting/publishing games.
• Don’t bother with Snap or Flatpak. This was a Linux Game Jam, so I prioritised Linux packaging, including a .deb, AppImage, Snap (in the snap store) Nix Flake and simple tarballs. The workflow for building/publishing snaps is quite different from my typical approach of using GitHub actions, and the review period for Flatpak is a blocker for jam time pressures.

Feedback from Friends

Without a doubt, the single best decision I made during this jam was asking my friends, Roger, Alan, Mark, McPhail, Stuart and Simon, to test and provide feedback; this happened daily (thanks to the automation above) and had a huge impact on how the game evolved, including:

• Getting it to work on FAKE-08 (more on that later)
• Making the game more intuitive/accessible
• Coming up with new game mechanics
• Setting the game pacing and difficulty
• Dropping features that were not fun

And that last point is important ☝️ Don’t get attached to ideas if they are not working. Fail fast; cut out the cruft that is not adding value.

Changes for the future:

• Share plans for games/jams early so friends can comment and share their ideas.

Game Design

I could (and should) have done more upfront planning. Most of Day 2 was spent making tables for player weapons progression, alien behaviour, and difficulty progression. I needed these before I could figure out how best to implement them, and this is something I should have done well ahead of the jam starting.

Changes for the future:

• Create difficulty/behaviour tables ahead of the jam. These will likely be subject to change during the implementation, but having them ready will enable earlier playtesting feedback so they can be refined.
• Write the descriptive text in bullet points for game mechanics so they are easy to interpret when you come to implement them. I spent a bit of time trying to remember what my notes meant. Make sure your past self is a good assistant for your future self.
• Smaller game scope. I’ve only participated in 2 game jams so far, and I’ve made this mistake in both. I’ve been too ambitious with the features I wanted to implement, and this approach will certainly not scale to shorter jams.
• Write down how the game will communicate with the player. I got great feedback about how the game could better “teach” new players how to play.
• Dedicated “Training” missions were not fun. Teaching the player should be fully integrated into the game as fun, not grindy, levels.

Game Juice

I wanted to use this jam to put into practice some of what I learned about juicing game feel. I loved working on particle effects, screen shakes, and animations and ensuring every pixel was impactful and not lifeless or uninteresting.

Changes for the future:

• Continue to study the art of game juice and game feel to refine visual feedback to players.

PICO-8

The Good 👍️

I will start by saying that I loved working with PICO-8 and the PICO-8 community. Here’s the good stuff:

• Lua: My first introduction to Lua. It suits me; I’ll be doing more with it.
• Fast iteration: I’ve seen that PICO-8 is popular for jams because you can go fast, and you really can.
• Community & Documentation: The PICO-8 documentation is very good, and the PICO-8 community provide excellent learning resources and targetted discussion. Sharing carts means lots of code examples are readily available to learn from.
• Sharing .gifs: Quickly creating gifs of new game ideas/features and sharing them with friends helped the feedback loop and also for writing up Dev Logs and social posts.
• Genuine 8-bit vibes: Writing for PICO-8 took me back to a mindset I had working on the C64 in the ‘80s. I love the feeling of accomplishment when I’ve implemented something efficiently, from elegant input handling, sprite objects, collision detection and particle animations. However, striving for efficiency also became a drag on momentum…

The OK 👌

While my overall impression of PICO-8 is and will remain positive, here’s where my choice to use it was not ideal:

• Not native: This is not PICO-8s fault. PICO-8 is a fantasy console and therefore operates as such. But early feedback was my game didn’t feel “native”. To some extent, I masked this on the game’s binary exports by disabling the built-in PICO-8 menus.
• PICO-8 emulation: Many handhelds can play PICO-8 games by way of the FAKE-08 emulator. However, FAKE-08 is not 100% accurate, so a good chunk of the first day of the jam was spent making my code compatible with FAKE-08. This was mostly because I didn’t feel I could create a game using PICO-8 and not cater to the PICO-8 community.
• Sound & Music: While there are a few collections of reusable music and SFX assets for PICO-8, it is slim pickings. These assets were more than sufficient for this game, but for future projects, I’d struggle unless I could find a collaborator to work on sound design and music composition.

The Pain 😱

I chose to use PICO-8, knowing it has several constraints to create a sense of working on a retro platform, and those constraints have been very thoughtfully implemented, IMO. Indeed, working with a 128x128 resolution made me think about how to display player progress/score/health compactly, which I was very pleased with. And while I am no artist, I can make passable 8x8 sprites in a pinch. But the 8192 token limit and compressed space did become a burden, here’s why:

• The last four days of the jam, I spent more time optimising code than working on game features because I needed to free up tokens to implement features. I did enjoy this process, but with a jam deadline approaching, it is not how you want to spend your valuable time.
• Token optimisations sometimes introduced regressions into previously well-tested/working code and required time to play through levels to ensure everything worked as intended.
• I had to remove comments and delete commented-out “features”, such as debug hooks, to free up compressed space.
• Some features never got implemented due to a lack of tokens or compressed space.
• Features implemented towards the end of the jam (the boss fight in particular) are not as complete as I would have liked.

Even now, I am still finding new techniques to optimise PICO-8 token utilisation which could free up space to make new game features.

Changes for the future:

• Add PICO-8 optimisation tools to the build pipeline so I can retain debug capabilities and verbose comments.
• Use PICO-8 built-in menus to create a more cohesive feel, native or not.
• Integrate better in-game guidance for controls/keybindings
• Set up a FAKE-08 test environment on the development workstation so I don’t have to rely exclusively on friends testing with their devices.
• Use a more mainstream game engine to enable access to lots of ready-made assets for sounds and visuals.

PICO-8 final thoughts

My main takeaways about PICO-8 are these:

• I love it.
• I love that PICO-8 introduced me to Lua, which I’ll invest more time learning.
• You can iterate very fast.
• Without a jam deadline, more complete games are viable and fun to work on with PICO-8 despite the token limitations.
• I would use PICO-8 for shorter jams where the available time will be exhausted well before token limits.
• The PICO-8 community is inviting and helpful.
• It is worth doing at least one jam with PICO-8.
• While I enjoy token hunting (genuinely, this is a fun game in itself), I think my time would be better spent learning the art and craft of creating games rather than becoming an expert in PICO-8 token optimisation.
• I will continue using PICO-8 as a prototyping tool and a learning platform to teach my daughter more code skills.

The Game 🕹️

Overall, I’m very happy with how the game turned out. It is a small but complete game, taking about 18 minutes to play through from start to finish, with enough mini-games to keep the gameplay fresh and with a good sense of progression. The feedback, post-jam, is the game pacing is good and the gameplay fun.

I wanted to put into practice some game juicing techniques, and I’m rather proud of the results; palette flashes, palette swaps, screen shake, screen flash, multiple particle effects; psycho-visual transparencies, knock back and classic demo scene text effects.

There are about a dozen mini-games, and those were created quite by accident 🤯

• While testing the game before the alien could move, I smashed into objects as fast as possible to test the collision detection. This was the inspiration for the Power Spree mini-game.
• Similarly, avoiding the un-firing aliens falling down the screen before the player ship could fire rockets was the catalyst to create the asteroid games.
• While testing the two-player mode, I instinctively moved to protect the uncontrolled 2-UP ship and laid down covering fire. This became the Cargo Run mini-game.

My friends came up with other mini-game ideas, which I sadly didn’t have the time or tokens to implement. Anyone of these mini-games could have been a jam entry in itself, and I’m thinking about developing some of these ideas into smaller casual games. And that right there is the value of participating in game jams.

Antsy Alien Attack Pico is the implementation that the original Antsy Alien Attack deserved. I now have the confidence that I could make a better shmup, and perhaps I will 😃

What’s Next?

Participating in Linux Game Jam 2023 has been quite profound:

• The most significant discovery was using Lua. I immediately felt at home with Lua, and I am currently researching other game engines that use Lua as the principal scripting language.
• I want to make more games. In fact, I’m going to make more games.
• I like making (what are now considered) retro-styled or pixel art games. I am going to focus on this style exclusively.
• New bucket list item is to publish at least one game for PC, mobile, web and console. I mean, how hard can it be? 😉