Video

Making Allocation

Allocation was a game I made for a 48 hour game jam. The theme of that jam was Genre without mechanic. Developing and polishing the game within that time limit was difficult, especially as this was my second ever game jam. Below, I'm going to discuss some of the design decisions I made which led me to the final game, as well as some of the challenges I had to overcome to get there.

The theme

The theme for the jam was announced at 8pm on Friday in UK time. For the rest of my evening, I spent my time thinking of different interpretations of the theme that could be interesting to make. Among my list of ideas were an RPG where you can't attack, a card game where you can't see your own cards and a platformer where you move the world, instead of the player.

I didn't particularly like any of these ideas. Each idea would change the way you interacted with the game in the moment-to-moment gameplay, but none of them would cause the player to change the way they think about the genre itself. However, there was one idea I wrote down on Friday evening that I quite liked. I wrote down a Metroidvania game where you don't go anywhere.

I went to bed thinking about this idea. Then, by the following morning, the idea had mutated into the idea I eventually went with. I wanted to make a game in the Metroidvania genre by removing the two things that typically define a Metroidvania game. I wanted to remove the interconnected world and the collectable character upgrades that typically define a Metroidvania.

A Metroidvania?

For those unfamiliar with the genre, I'll give a brief description of what makes a game a Metroidvania. The Metroidvania genre is named as a combination of the Metroid and Castlevania game series. Games in this genre are typically characterised by having a large world for the player to explore, which opens up to the player bit by bit as they explore and obtain new upgrades. The exact nature of the upgrades vary from game to game, but they may, for example, allow you to jump higher to reach new locations higher up, or to shrink down to explore new spaces.

One of the most fundamental aspects of a good Metroidvania game is the world design. The best Metroidvania games give off a sense of exploration, instead of feeling like the player is being guided from upgrade to upgrade without much agency. Some games in the genre even allow the player to break sequence, which means diverting from the path the designers expect a player to take through the game. Developers can include sequence breaks into the world, by allowing players to get to areas they normally wouldn't through thorough exploration or clever use of abilities. Sometimes sequence breaks can occur accidently - through minor glitches or exploits. While this would typically be an issue in most games, games in the Metroidvania genre tend to lean in and embrace these kind of glitches as part of the experience.

The map is a collectable

If I were to remove all the Metroidvania aspects of a game, it wouldn't really be a Metroidvania anymore. So instead of just removing the map and the collectables outright, I merged the two concepts together.

I presented the player with a map of the world that looks similar to the map in other Metroidvania games. This map had several rooms marked on it with no connections between them.

The map of the game that the player starts with.

The player starts locked in a room with some kind of computer terminal in it. By interacting with the terminal, the player is presented with a screen that allows them to place more rooms onto their map.

The player can place rooms on their map.

The player is limited, however. When they start the game, they have access to only two rooms to place. With just these two rooms, there is only one marked point on the map the player can possibly make a path to. The path the player makes is reflected in the game world itself, so they can follow their path to reach the only marked point on the map available to them.

When the player reaches the end of their path, they are presented with a selection of new rooms. Upon returning to their starting room, those new rooms are added to their list of rooms which can be placed on the map.

The first place the player can find additional rooms.

With these new rooms, the game starts to open up. There are multiple points marked on the map that the player can make a path to at this point. Depending on their ingenuity, the player can even make a path that reaches two rooms at once, meaning they can visit two rooms without having to return to the starting point to alter their map. Each new marked point the player visits adds extra rooms to their available pool of rooms, meaning that the player can reach more rooms further out. This is how I made the game continue to feel like a Metroidvania, even when I removed the key mechanics.

Designing progression

Most Metroidvania games have a key path that they guide the player down - a kind of intended route to beat the game. However, they're designed in a way that players can break from that path, and make their own route. Players may be able to skip certain collectables and break the normal progression of the game.

I wanted to create a similar experience in this game. The mechanic of laying out the map actually lent itself very well to this. Players are encouraged to make their own path, and plan the route they want to take themselves.

To help with player choice, I assigned each room a difficulty based on how hard the layout of the room was. Easy rooms would have fewer obstacles and enemies, whereas hard rooms would be full of them. The tradeoff for this was that easier rooms would have fewer connections to the rooms around them. That means that hard rooms are more versatile, and can be used in more situations for a player who is willing to take the challenge. However, to manage difficulty, it's entirely possible to make a route to the end of the game without having to use a single hard room.

The biggest concern was actually guiding the player. I didn't want players to feel overwhelmed, or that they didn't know how to start laying out maps. The marked rooms on the map make it fairly obvious where they need to get to, but easing the player into to the concept of laying out the map was very important.

I planned out the routes the player could take after obtaining the first set of new rooms. There are three main options.

The player can reach this room.

The first, and most simple option is to place the rooms as in the picture above. This path doesn't require the use of any of the medium-difficulty rooms the player has access too. When the player reaches the end of this path, they'll be given a selection of useful rooms that will help them more easily reach other marked points on their map.

Alternatively, they can reach this room.

The player could also place the rooms like in the above picture, in order to reach a different room. This route uses a medium difficulty room, but is still a viable option.

The final route the player can make.

The picture above shows the final route the player can make. This route differs from the others in that it visits two rooms at once. This is more efficient than visiting them one at a time, but more difficult for the player.

So when the player starts out, they have access to just a small pool of rooms and a small number of places to go. This helps a player get used to constructing the map and making their own routes.

As the player continues to discover new rooms, the number of routes the player can make increases exponentially. This gives the player more and more freedom in the way they design their map as they continue through the game. As such, it wasn't possible for me to route out all of the maps the player could make. Instead, to design the position of each individual room, I used a more iterative approach to design.

Which is a fancy way of saying I used grid paper and an eraser.

My sketches during the design process.

I spent a fair bit of time moving the shapes of the rooms around, and choosing point on the map room they could be obtained from. Once I was happy with my map, I started implementing the rooms into the game.

Adding Difficulty to Progression

I already mentioned that I had 3 difficulties of room. I also said that the player wouldn't need to use the hardest difficulty if they were careful with the way they placed their rooms. However, to properly design difficulty, I needed to decide what would happen when the player dies.

When the player runs out of health, they are returned to their starting point. However, as an additional penalty for dying, any new rooms that the player had collected and not returned to the start would be lost, and would need to be collected again. While I'm usually against harsher penalties which cause players to lose progress, I felt this one was necessary. It forces a player to think carefully about the route they make, needing to design a route that they are capable of traversing both forwards and backwards. I also felt this was necessary so that players could be challenged by designing more efficient, yet more difficult routes through the game.

A staple of the Metroidvania genre is health upgrades, which make the game easier for players who go out of their way to find them. I wanted a similar kind of upgrade, but in this game, the player never gains any character upgrades. To make a similar system, I added in two healing rooms, which were given out in the same way as other new rooms. Healing rooms can be placed along a route to provide rest stops for a player, where they can refill their health. To be able to make efficient use of these rooms, the player would have to add them in sensible places along their route. The healing rooms only have one entrance/exit, and so the player can't place them directly on their route. Instead, they have to design a diversion to be able to reach a healing room. I thought this was quite a graceful solution which merged health upgrades with the game's core mechanic.

A healing room acts like extra health in other Metroidvania games.

Implementation

I made this game for a 48-hour game jam, so I didn't have much time to implement the game. I also made the game in PICO-8, which presents its own challenges, but also has a few useful features I made use of.

One feature I used was the PICO-8's map editor. Each PICO-8 cartridge has some space set aside for map data, which can then be rendered to the screen. I used this space to store all of the rooms in the game, next to each other. When the player moves between rooms on their map, the player's position is jumped around this map space to put them in the room they moved into.

The map editor with rooms stored in it.

Along with the tiles which make up the rooms, I stored the positions of enemies as tiles in the map. At runtime, these tiles were removed and replaced with game objects for the enemies they were representing. Doing it this way made it very easy to design maps quickly during the game jam, although this method doesn't scale up well to larger games, especially those with more complex backgrounds.

Lua is the language used by PICO-8. I find it lends itself quite well to game jam programming, since it's very easy to start writing code quickly in. Each game object, like an enemy, or the player, is represented in code by an object in Lua. Even in a short game jam, it is very helpful to keep code organised, so I made heavy use of object-oriented practices and explanatory variable names. During the game jam, I wrote about 30,000 characters of code. One key disadvantage of PICO-8 is that it provides very little in the way of existing code bases, so basically everything needs to be written from scratch.

Limitations

Being rushed for time in a game jam means that some content will not be as polished in a game with a longer development time. I wanted to address some of the things that I couldn't get done in the game jam's time limit, and how I'd go about implementing those, if I'd had more time to work on the game.

First, let's talk about the graphics. The graphics in this game look fairly placeholder and unpolished. I'm not an artist, so it takes me a fair amount of time for me to create graphics I'm happy with. As such, I decided that I wanted the graphics to be functional, but nothing special. I put a little more effort into certain GUI elements, such as the map system, because it was very important that the player could easily use these, but for most part, the graphics are very basic.

The second thing that's most obviously missing is music. Music can be very useful when trying to set the atmosphere for a game, but in a game jam, it's a low priority for me. If I were using a different game engine, it would have been possible to use some public-domain music, but due to the way PICO-8 handles sound, all music needs to be composed in the editor itself. I ultimately decided that having no music at all would be a better decision than using hurriedly composed music, especially as PICO-8 has no in-built way to mute sound effects and music independently.

Character movement is something that's very hard to get right. It's fairly easy to make a character that can move and jump, but making it feel good to control needs a lot more time to get right. This meant that the character in Allocation feels a bit stiff to control. Their hitbox is not very forgiving, and they lack much acceleration - going pretty much straight to maximum speed from a stop. These are all things that are expected from game jam games, but something I'd definitely spend more time tweaking in a full game.

Another thing I was lacking in this game was user testing. User testing is very important for checking players actually understand the game. I did spend some time making sure that players could use the map system, given that it's such a core part of the game, but there were aspects of design I didn't pay as much attention to.

After posting the game for the jam, I saw a number of comments talking about a specific enemy.

A "sawblade" enemy.

The comments made it very clear that most players did not realise that they could attack and destroy the sawblade enemy. This makes a lot of sense - this kind of hazard is usually indestructable in similar games. Additionally, the fact that a lot of sawblades stay stationary, while other enemies move could easily give of the idea of being similar to spikes or other indestructable hazards. If I had realised this before releasing the game, it would have been easy to fix - I'd just need to alter the graphics a bit.

The sawblades weren't the only misconception that players ended up having. I had a few people say that they didn't realise they could shoot upwards, and at least one person tell me they didn't initially realise they could erase rooms from the map. All of these are things that I would have made a more concious effort to make clear to players, if I had more time to work on it.

Scalability

I've seen a few comments saying that they'd be interested in seeing this game's main mechanic implemented in a larger game. Since I released this game in 2018, I've given this a bit of thought.

I think that this game concept worked so well because of the game jam setting. It worked beacuase the game world was so small and scaled down. To implement it over a full-scale game world, I would struggle to make each room the player found feel useful.

Because there are some rooms the player has that are very useful, they re-use those rooms constantly. In a larger game, this would become annoying, as the player would have to travel through the same rooms again and again. It would also make obtaining new rooms feel less useful, as they would often not be as useful as what the player had before. If I kept the pool of rooms sparse, it would make the world feel empty, as there would be less to obtain in a larger world, even if I were to add back in some traditional upgrades.

I've had a couple of ideas for ways to counter these issues, but none of them feels as graceful or easy to understand as Allocation was. I could make longer or taller rooms, or rooms with awkward shapes, meaning that harder-to-obtain, yet smaller rooms would become more versatile in comparison. Alternatively, I could change the way that the player places rooms in some way, for example, making them permanant on the map, or having the player shift them around like a sliding puzzle, but these would introduce their own kinds of complications.

The biggest obstacle to design, however, would be progression. I mentioned earlier that, even in this small game, the routes that the player could make quickly became exponential and impossible to map out. While sequence breaking is usually appreciated in a Metroidvania game, it's important to design the game in such a way that half of the content doesn't become suddenly trivial due to an oversight.

All that being said though, it's not as though this idea is entirely written off for me. Even as I'm writing this, I'm getting ideas for tools to automatically check the game world, and ways the world could be designed to counter some of these issues. If I can get all of this sorted out, maybe I'll revisit this idea someday.

My final thoughts

Despite some of the issues the game has, I'm overall very happy with this game. I think it was an excellent implementation of a new concept, and was very competent and complete for a game jam game. The game has received many comments, and it's clear that people who played it really enjoyed themselves, which I'm really glad to see.