SWIM – My first PICO-8 Game

Click the play button below to try out the game. (You may want to go fullscreen)

I recently got into designing games for the PICO-8 fantasy console. PICO-8 lets you create and share small games – so small that you can encode the logic, graphics, and music in a single png image! It does this through steganography, storing the game information in the least significant bits of each pixel. You can take a screenshot while playing, and PICO-8 takes care of encoding everything in that one screenshot, which serves as the cover for the game.

Making games in PICO-8 feels different than making games in Godot, my default engine. It has no built-in physics, so you have to write functions to handle collisions, motion, and so forth. And there are no objects – the closest you can get is creating a table with attributes to pass into a function. Drawing things on the screen is also much lower level than I am used to, although PICO-8 at least has a decent suite of useful commands for drawing with pixels.

It is possible to create sprites in PICO-8, but there is no built-in way to rotate them. Because of this, I decided to eschew sprites altogether and draw everything from scratch using just code. Everything in SWIM is made up of circles and individually drawn pixels, which allows for rotatable graphics. Something I like a lot is that PICO-8 measures angles such that a full circle is equal to 1 unit. For example, if you want to rotate 180 degrees you add 0.5 to your angle. I wish more engines did this; reasoning in radians or degrees is ugly, annoying, and unnecessary; now that I have experienced trigonometry in normalized units, I never want to go back!

What I Learned from Slipways

Slipways is an excellent take on the 4x genre, streamlining the formula to create a game that you can play in 1-2 hours. I used to like games like Civilization, Master of Orion, and Alpha Centauri, but I no longer enjoy them because they take too long and require too much micromanagement. After dozens and dozens of playthroughs, these are my biggest takeaways as a game designer.

Debt creates goals

The most innovative mechanic in Slipways for me is the way it handles converters. “Converters” are things that accept resource inputs and produce other resources for the player. The brilliant thing about converters (colonies) in Slipways is that they yield their first outputs as soon as you build them before receiving any inputs. If you urgently need a resource, you can set up a colony to produce it immediately.

While a colony will produce resources without receiving its inputs, it does so at an escalating cost to happiness, an important part of the scoring formula. Furthermore, while satisfying its needs eliminates the unrest, taking too long to fix it results in a penalty that stays forever.

What makes this work so well is that each planet both solves an existing problem and provides the player with a new goal to pursue (and a time limit to complete that goal). Each colony you build is a loan that you will need to pay back, and the neverending quest to pay them all back is the primary driver of the gameplay.

The summary of this game design pattern is: 

  • To provide a goal, give players an immediate reward tied to a penalty. Allow them to eliminate the penalty later by accomplishing some specific (but optional) task.

Upgrade converters when used to encourage interaction

Providing input to a colony does more than just removing the happiness penalty; it also upgrades the planet, creating new needs. Each level results in both more outputs and new challenges, ranging from finding markets for the exports to improving nearby planets. In this way, the player receives a natural-feeling stream of goals.

A big problem that converters often have is that they feel too one-dimensional. In many games, it is common to see converters sitting idle when their outputs are not needed. Upgrading a converter when used is a brilliant side effect that gives the player a sense of progression. Maybe you don’t need any wood right now, but wouldn’t you rather have a logging camp instead of that pitiful little forester?

The summary of this game design pattern is: 

  • To provide player progression and encourage players to use converters, include a side effect in your converter designs. After using a converter a certain number of times, it upgrades.

Discourage completionism by gating off low-level options

Slipways does something interesting with its tech trees that I haven’t seen before. At any given time, you may research technologies from your current tech tier or the previous one. Completing research causes your tech level to advance, providing access to new technologies while also cutting off access to old ones that you never got around to researching. Thematically, the justification is that your scientists have moved on to more exciting projects.

The effect of this design decision is that players must think carefully about which techs they need from each tier because they can’t take them all. This discourages degenerate tendencies towards buying obsolete tech simply because it is cheap relative to the player’s current science production.

For the game designer, this makes balancing technologies a lot easier. Even early game tech can be impactful because you don’t have to worry about the player picking it up at no opportunity cost later. It also improves replayability because the player can’t just always take all of the early technologies.

I think this principle applies to any system where the player chooses from options across several tiers with escalating costs. By locking early options as you unlock later options, each item the player chooses becomes more meaningful.

The summary of this game design pattern is:

  • To enhance replayability in games where the player buys new abilities from a tiered list, lock earlier tiers as the player advances.

Use marginal increases in upkeep rates

The most jarring and unpleasant part of Slipways for me relates to administrative upkeep costs. As you add more planets to your network, there are thresholds at which your empire “size” increases. Each time this happens, the number of credits you pay per planet in upkeep increases by 1. I am often shocked when this happens because building a single new colony causes a massive drop in income.

I found that such abrupt changes in income felt artificial because it didn’t make sense that adding one planet would suddenly make the rest of them cost more. This led to situations where I didn’t want to build a colony because it would drastically change my costs. I prefer marginal upkeep systems like the one in Eclipse where each colony costs progressively more to maintain than the last one.

My main takeaway from this aspect of Slipways is to avoid springing massive upkeep changes on players just because they crossed some threshold. There’s no design pattern here, just a cautionary tale.

4X games don’t need combat

Slipways has no combat, a departure from the genre (the fourth X stands for “exhale” instead of “exterminate”). While it is a single-player game, its focus on trade would work very well in a multiplayer board game, trade providing healthier player interaction than war. The emphasis on commerce over combat is one of the things I like a lot about Sidereal Confluence, and Slipways demonstrates that you don’t need to abstract everything else away to get it.

What Loop Hero Does Well

I beat Loop Hero recently. It is an excellent game with a core gameplay loop that is addictive and engaging. You play as – or perhaps, manage – a hero in a world that has been forgotten (literally) and walk around a circular path placing tiles. Each tile provides both opportunity and danger, often in the form of enemies to fight. The hero automatically battles monsters (with no input from the player) and receives equippable loot that modifies their stats. Once you die or retreat, you return to your camp and use resources acquired during the expedition to improve your base. Then you embark on another journey.

The best part of the game for me was tile placement. What makes tile placement engaging is the interactions between tiles. Some tiles transform others; if you put a meadow next to something else, it will become a blooming meadow, increasing its healing by 50%. Other tiles complement each other very well; swamps make healing lethal, and vampires heal their allies, so it makes sense to place vampires by the swamp. With over fifty different tiles, exploring the rich heuristic tree of tile placement and synergies was what kept me returning to the game.

Tile design in Loop Hero follows the principle that every choice should provide both risk and reward. There are very few tiles that are pure upside; nearly all of them pose some threat to the hero, and the challenge is finding ways to mitigate the danger so you can enjoy the reward. This is a tried and true principle of game design, and it is executed very well here. I think my favorite example is the smithy, a building that consumes unused items to give you a defensive buff, spawning a golem after the sixth. The cleverest part is that killing the golem gives you six items that are often more valuable than the ones you lost, so you are punished for your greed but rewarded for facing the punishment.

The game also features three types of heroes to choose from, each with radically different mechanics. When I realized that the third hero was the final one, I was disappointed that there weren’t more. But as I kept playing, I came to appreciate the stark differences between them. Each hero has a central, unique mechanic, and the same tile might have very different implications for different heroes. For example, the first hero gets stronger the longer the battle takes, so a tile that reduces everybody’s attack speed is better for him than for the other heroes. The different hero-tile interactions added another dimension to the tile placement subgame, which kept things fresh even when I used the same tiles in each game.

Four Quarters made an excellent decision in using idle-style combat with no player inputs. Players will often fight dozens of monsters in a given loop, and having to make combat decisions would slow the game down to unbearable levels. Removing choices from battles leaves more time for tile placement. This is a useful general principle- whenever you have two subgames, and the first is much less engaging than the second, paring down the former gives players more time to focus on the latter.

I wish that inventory management had received the same treatment as combat, though. The hero has several item slots and the loot that you equip buffs different stats. You have to ask yourself questions like, “is 20% evasion better than 5% vampirism and 8 defense?” Each item has a numerical level as a rough guide to its strength, but sometimes your strategy may require a lower-level item with the buffs you want over a higher-level one irrelevant to your build. One benefit of the system is that it helps the player identify with the hero. Eventually, however, the constant need to compare item stats begins to feel math-y and tedious. I found inventory management to be the least compelling part of the game.

The other main subgame involves building your camp between runs. Much like expeditions, building your camp involves placing tiles on a square grid with placement mattering for certain tiles. For example, the Farm produces one food resource for each of its surrounding tiles that is empty. Constructing buildings is the primary way you spend resources gained during an expedition. Base-building is fun, but only in the same way that incremental improvements between games are satisfying in any roguelite. Players like progression and like seeing numbers go up. Letting them build a base to increase their numbers is difficult to get wrong.

Within the base-building subgame is another subgame where you can craft and equip special non-inventory “camp items” between expeditions. Initially, these confused me because the effects of each item were so weak. For example, the Loaf of Bread only gives you +10 HP (for reference, the total HP for the hero rises from the low hundreds to over a thousand by the end of an expedition). However, as you upgrade your camp you gain more and more camp item slots, so you might eventually equip 30 Loaves of Bread for a respectable boost of 300 HP. This is fun in the late game where it provides highly granular customizability to your hero but is less relevant early on when you can’t equip enough camp items to make a difference. Overall, I would prefer stronger items and fewer slots. I didn’t feel that I needed the level of control that the game gave me, and redoing my build was tedious.

Foreshadowing is important in single-player games, and Loop Hero does a great job of foreshadowing everything. Since players create the obstacles, they are very aware of what they will be facing. Progress bars provide clear reminders of how close the player is to facing the boss or reaching the next day, and the loop-based structure of the environment allows them to predict that the next loop will be similar in many ways to the last.

There is something powerful about loops in games. There is a great article about the roguelike game Unexplored that sums up why they work so well:

Interconnecting spaces are a good thing because they naturally bring you back to where you started, helping you to feel your character developing. When you return to familiar surroundings with a new item or weapon you tend to realize the difference between how you were before and how you are now, and get a handle on your hero’s journey.

Alex Wiltshire, How Unexplored generates great roguelike dungeons

In Loop Hero, each new turn around the map sees you facing the same challenges as before, but with new gear and new tiles to shake things up, providing a strong feeling of progression.

Overall, I found Loop Hero to be both rewarding and educational as an example of good game design. After beating the game and seeing almost all of the content, I don’t feel much of an urge to keep playing, but I am sure I will want to return if Four Corners releases any more content.

The difference between cards and dice

Dice have been a looming problem in Dungeon Rancher for a while. Every monster uses dice to track its level by the number of dice on the card. On top of that, players must roll enough dice to feel secure in feeding their monsters. Given four colors of dice, even the most conservative estimate puts the total dice required at 120. This is prohibitive on cost alone, but dice are also inconvenient for tracking states because it is easy to knock them over, losing information.

For these reasons, we’ve decided to try switching to using cards to track monster levels instead of dice. Each monster has a stack of cards, and to tend to it you must play a card equal to or greater than the top card. Instead of four bags of dice, there are now four decks of cards. This has major implications for the game.

When we used dice to represent levels, the highest die determined the difficulty of tending to the monster. It is inconvenient for players to search a pile of cards, so now only the top card matters. Since it would be too powerful to train a monster by changing just one card, we decided to remove the training mechanic altogether. Rerolls became the ability to discard a card and redraw from that deck.

Fortunately, we have space for the card piles above or below each monster because we limit rooms to two monsters. This is good because the new resource cards need to be the same size as the draftable cards since some are in the draft. The change also makes it much easier to theme the resources because we can use thematic icons rather than pictures of colored dice.

Players naturally hold all the cards they gain from different sources in their hands – both the drafted cards and the produced ones. Therefore we had to modify the rules about discarding your hand at the end of your turn. Now players must only discard down to their hand size, whether they keep drafted or non-drafted cards. Their hand size is equal to the number of rooms they control, making room building a little more interesting.

Finally, we decided that all monsters should start at level 1. To level them up faster, players may spend a new type of token to tend to them again.

Using a different type of component to represent information always has consequences. I find it is best to go with whatever changes are suggested by the new medium rather than forcing it to work the same way as the old one. The same is true when working under component restrictions. For example, if you are involved in an 18-card contest, don’t try to cram a bunch of state information into the cards. Just use them the way cards are typically used and make a good game within those bounds.

Evolution of Dungeon Rancher Monsters

Early on, we knew that the monsters in Dungeon Rancher would have abilities if only to differentiate them from each other. There are four resources players use to feed monsters. Since each monster uses two resources, this implies a total of 4 choose 2 = 6 monsters. We gave the Dragon and the Golem simple resource production abilities to start with while testing other aspects of the game.

It wasn’t too long before we added abilities for the rest of the monsters as well. One useful principle we discovered is that abilities that don’t require keeping the monster around are unthematic because they make the monster feel more like a resource card than like something to raise. For instance, one version of the Golem’s ability allowed players to discard it to build a room for free, so players treated it like a “free room” card and always used it immediately.

We settled eventually on the concept that each monster would have a different scoring ability. After some experimentation, we further determined that such scoring abilities should always force the player to take on risk for more points. For example, the Dragon scoring ability increases its value for every ‘6’ on it, making it much more difficult to tend. Under this system, creatures represent different ways for the players to challenge themselves to increase their score.

The newest addition to the monster mechanics rewards players for placing monsters with matching “personalities” in adjacent rooms. For example, placing a creature with a food symbol on its right in a room to the left of one with a matching food symbol on its left produces a single food resource, which is automatically useful since you have two monsters that require it. The objective was to make monster placement more interesting. Adding this mechanic costs very little because it echoes the existing mechanic that adjacent matching rooms produce magic resources.

When game procedures inspire new mechanics

Game procedures are what I call the various maintenance tasks required in any board game to keep the game going, such as reshuffling decks, sorting the supply, or counting up victory points. They are the sorts of things that would be automated in the computer version of a game. An important part of board game design is streamlining procedures so they are not noticed by the players, since they do not contribute anything positive to the experience of the game.

Sometimes, in the course of improving game procedures, you find a new twist on your mechanics. This happened to me recently in Dungeon Rancher. I had been using six-sided dice to indicate monster levels, and one of my playtesters remarked that in the real world it is inconvenient to have to find a value on a die – in TTS, of course, you can just press the corresponding number.

I had not been intending to use dice in the actual game (the level die was a placeholder), but this got me thinking – how could dice be used to represent levels in a way that didn’t require the onerous procedure of locating a face? As it happens, when players are tending to monsters in Dungeon Rancher (a task that requires assigning a die that equals or exceeds the monster’s level), they tend to place the die on the monster to remind themselves that they have tended that monster. This inspired me to use the number of dice as the level, rather than the maximum die.

Each time your monster levels up you have to assign it a die matching or exceeding its highest die. The die you assign remains on the monster, increasing its level and potentially increasing the required value for the next time you need to tend to it. The required procedures are very smooth because they already match what the players needed to do; no additional steps are required.

This in turn led to some new mechanics revolving around rerolling dice – both dice used to tend monsters and dice already on the monsters from previous rounds. Thematically, this works very well – if you give the monster high-quality food, it becomes spoiled and will want high-quality food in the future, but you can attempt to tame it and reduce its pickiness. The mechanical process ends up feeling very rewarding, as players must balance caring for their monsters now with keeping their monsters as docile as possible for future rounds.

The lesson I take away from this is that sometimes the best source of mechanical inspiration can be coming up with ways to remove mundane chores from the game.

Cutting mining mechanics from Dungeon Rancher

Recently I oversaw a playtest of Dungeon Rancher in which rounds took 20 minutes (the target is 6). This was an increase of 4 minutes per round from the previous week, so I focused on determining why it was taking so long. It turned out the main culprits were the new dice-selling mechanic (which has since been removed) and the Mining Phase.

The Mining Phase was the mechanic I was most excited about going into the project initially. In games like Dungeon Keeper 2, there is a mechanic in which digging into a gold vein is likely to reveal further gold veins because they tend to be grouped. I wanted to replicate this feeling without any spatial elements by having decks of cards where certain cards allowed players to change the deck from which they drew.

We removed the mechanic of needing specific cards to switch decks after a previous playtest but left the four decks with different resources, each coded to one of the four needs of the game. The red deck had the least challenging monsters, allowing players to save minions for use generating red dice. The green and yellow decks provided green and yellow dice directly. And the blue deck provided tunnels and blueprints for building the rooms that passively generate magic each round.

Unfortunately, the mining phase takes too long. Players have also said that it feels very swingy; this is probably due to the threat system where resource cards have threat symbols that increase the strength of the next monster encountered if its color matches. Running into a lot of monsters means you won’t have time to gather resources, and finding many resources means the first monster you encounter will probably wipe you out.

The other cost of the mining phase is in explanation time. Between the threat system, the differences between the different decks, and capturing monsters, it adds a lot to the explanation time and some aspects are difficult for players to remember, such as the nuances of each mining deck.

As much as I wanted the mining mechanics to work, playtesting indicates that the cost is too high for what they add to the game. Therefore we are removing mining from the game. The core fantasy of the game is raising monsters, which does not require the mining minigame. To replace it, we are adding a Drafting phase in which players draft monsters, resources, and rooms into their dungeon. Drafting solves the problems that led to the removal of Mining because it takes very little time to explain and can be done quickly and simultaneously.

Drafting will hopefully also address feedback that the game lacks player interaction. The difficulty with player interaction is that it can lead to longer playtimes and is often not compatible with simultaneous gameplay. Drafting interactions are one of those rare exceptions.

Could fixed prices solve lengthy trade negotiations?

Trading mechanics are a powerful way to introduce player interaction into a game. However, freeform trading can massively slow down the game depending on how much players negotiate. If players are allowed to trade anything, they might argue over the proper exchange rate. Even in Sidereal Confluence, where exchange rates are explicitly defined, it is unclear how much the loan of a converter card is worth.

I’ve been thinking about this lately after the first playtest of Dungeon Rancher. Trade in Dungeon Rancher serves the vital role of smoothing over randomness by allowing players to buy from other players the things they could not mine themselves. However, we aim for the game to last 30-45 minutes with six rounds, which means there is little space for lengthy negotiations. We previously let players trade monsters, dice, and rooms, but now we restrict it to dice, the most comparable resource. I don’t know whether this is enough, though.

Most games with trading mechanics don’t restrict what players can trade. In Dune, you can even exchange binding promises about future actions (modern games don’t allow this anymore). In a game like Sidereal Confluence where everybody is trading simultaneously, this isn’t too bad – as long as everybody is engaged, the only effect is to increase the game length. But in a game like Catan where a player can only trade on their turn, this can lead to significant downtime in the wrong playgroup. For this reason, I think freeform trade should seldom be turn-restricted.

But some games have an elegant alternative – fixed prices. In Imperial Settlers, players can build “Open Production” buildings that produce a resource and allow other players to gain that same resource (from the bank) by giving the owner a worker. Setting aside the question of whether this counts as trade, this is quick because there is no negotiation – the owner cannot even refuse the offer, and the rate is always one-for-one.

Root: The Riverfolk Expansion does something similar with its otter faction, which has three different types of goods and services on offer; in this case, however, they may set the price at the end of their turn. The player has more control over their sales but still cannot refuse the trade.

In both Imperial Settlers and Root, trade is indirect; the seller puts out an item at a price on their turn, and the buyer chooses whether to buy it on theirs. This can feel less personal than direct trading between players. A mechanic that I think could strike a middle ground is at-will trading with fixed prices. Say I want to exchange wood for stone; I look up the trade ratio for the two (1:1 for simple games) and offer another player the trade. There is no room for negotiation here – they must accept or reject my offer, avoiding a bartering session. Since the rules endorse the exchange rate, it is less likely that a player will feel ripped off.

I don’t recall seeing this mechanic in any published games. Fixed trade ratios are often used for trading with the supply, not directly with other players. But even when you set the terms of exchange, trades between players are interesting. Trading mechanics are good at compensating for bad luck and make specialization viable while also promoting player interaction. If that is possible without exploding the game length, I think it is worth trying.

Pushing your luck in Dungeon Rancher

I’ve started work on a new board game, this time with a collaborator. The game, Dungeon Rancher, is a push-your-luck game about raising monsters in a dungeon. It involves mining for resources and monsters, building your dungeon, and providing for your monsters. Monsters can be kept or sold after each round – if you keep them, they double in value, but it becomes harder to satisfy their needs.

I used to be indifferent to push-your-luck as a genre, but my mind changed after playing The Quacks of Quedlinburg. I think the great thing about push-your-luck is it provides decisions without an obvious solution; sure, you could compute the probabilities if you tried, but the optimal move is often fuzzy.

Currently, Dungeon Rancher pushes players’ luck in three ways:

  1. During the mining phase, the player chooses how deep to mine. As they mine they reveal monsters. If they reveal too many, the monsters attack their dungeon.
  2. When deciding where to house monsters, there is no limit to how many monsters may be housed in the same room. However, if any monster in the room rampages, the player loses all the monsters in that room, so cramming monsters into 1 room is risky.
  3. Monsters double in value every round, but the risk of them rampaging, damaging their room, and escaping also increases.

One possible issue with this is that both dice and cards are sources of luck in the game, whereas it is generally recommended to use only one or the other. Dice provide a straightforward way to represent an escalating risk. The player needs to roll above a threshold for each monster each round, and that threshold increases along with the monster’s level. Cards are a convenient way to have random encounters with monsters that can then be captured.

Right now, after one playtest, housing monsters has proven to be not that risky since players have little trouble caring for them and are able to build large dungeons. Monsters also do not rampage as much as predicted. The mining phase push-your-luck mechanics are working well, however.

One dynamic of Quacks that we borrowed is that pushing your luck too far is not completely punishing – it offers the player a choice of consequences. In this case, if monsters attack the dungeon the player can either defend the dungeon – abandoning any loot they collected – or keep the loot and allow the monsters to destroy a few rooms. I think this choice is important to lessen the sting of getting unlucky.