Hello all!

Today, I just wanted to write about my experience making this game for the Blackthornprod third game jam. As I was writing this devlog, I realised it would be a long post on game design and "how to handle game jams" with the through line being the development of minimalist mastery.

Some topics covered in this post are:

• Coming up with games based on game jam themes
• Viewing your games as "responses" to previous games made
• Choosing a game engine
• A short post mortem of Minimalist Mastery at the end

Below the post-mortem will be a list of all links to videos/articles that I mention in the post.

I do plan on updating this game (at some point) currently my mind is occupied on another project but once that's done, polishing this will be my top priority!

Quick note: in the Blackthornprod video "17 games where less is more" you can see this one at (0:17). Even if it were a small cameo, this is the first time my game has made an appearance in a video of this style and I couldn't be happier :)

The BTP (Blackthornprod) game jam wasn't my first rodeo. All of my published games (excluding one) have been made during a game jam but that doesn't mean there were no hiccups. One of the first ones came from interpreting the theme of the jam: "less is more".

Game jams occasionally have a prompt, which can either be a description of a design/mechanic to use ("dual purpose design") or it is based on  a "theme". Usually for game jams there are 2 types of themes:

• an abstract idea or a tangible object (i.e. "rejuvenation", "chocolate")
• an aphorism which is liked to multiple ideas ("less is more")

You rarely see themes of the latter and by their nature, these themes invite you to take your time as to how you will approach them. There are plenty of developers who use an example by the host (i.e. "the more loot you have the slower you walk"). Personally, I prefer to come up with my own interpretation on the theme, but it requires more work.

I can see why developers just take the examples given, usually it's time efficient and avoids the work of having to come up with an interpretation of the theme and game design mechanics. For the BTP game jam, I saw a lot of developers on forums asking for advice on "what to do for the theme" and how they "can't think of any good ideas".

As my game was ranked well in theme, I did some thinking as to what makes for good incorporation of game jam themes, into games and how to come up with them. Here is the first thing I wanted to tackle...

Coming up with games based on themes

The key thing to recognise is that the number of ways a theme can be used within your game. You can incorporate any theme for your game in 4-5 different ways...

1. Use the theme as the core of one mechanic

2. Use the theme as a problem/challenge

3. Use the theme within the game's ludonarrative

4. Use the theme within the game's story/plot

5. Use the theme within the game's art-style/music (doesn't always apply)

Let's first address points 1 and 2. 

Any game comprises two things: a problem and a solution. More often than not, the core "mechanic" of your game is the solution, and the challenges the game presents to a player are the problems. 

We can use a few genres as examples of this concept...

Platformer

Core mechanic: Jumping

Problem: Traversal of a terrain/obstacles

Solution: Using the core mechanic: jumping

FPS

Core mechanic: Shooting

Problem: Enemies are lowering your limited health

Solution: Using the core mechanic: shooting

Keep in mind these are gross oversimplifications, maybe even facile observations about games because one can say "What about games that have multiple mechanics?" or "What if there are multiple forms of gameplay thereby presenting multiple different problems?" or "What if our core mechanic isn't the solution because we have multiple mechanics?".

For the first and third question, if you look at point 1 it says the core of "one" mechanic, so in theory you can have multiple mechanics. The core mechanic should be the one that solves the majority of the problems set forth by your game. Also, a core mechanic can be highly abstracted, jumping on top of enemies versus jumping on top of spring platforms are not 2 different mechanics. They are merely extensions of the one mechanic; which can be extrapolated to the core mechanic: jumping.

For the second question, I say, remember the context we're working with: game jams and limited time. Pragmatically speaking, you won't have the time to develop a game with multiple forms of gameplay or large expansive worlds that allow for multiple extensions. 

You can have multiple mechanics in your game OR have one mechanic and multiple extensions of that mechanic, but you can't have both and more. For game jams, short, unified, polished experiences are ones to aim for; making your game larger than it needs to be can only be a detriment.

Back to the theme, we can make it either our problem or our solution (core mechanic). Let's take the theme: "rejuvenation". If we made the theme our solution/mechanic, it could be...

• a player who's a necromancer reviving corpses from the dead
• a player who gathers energy from the planets to rejuvenate the sun to prevent it from exploding
• a player who's a gardener, trying to water plants to make them stay alive

A necromancer needs an undead army. The sun is about to explode. Plants will die without water. For each example, the player is using the mechanic of "rejuvenation" to solve a problem. Imbuing something with life can take many forms, but it is always the crux of what the player is doing during gameplay, it is the monad of the game.

But what if "rejuvenation" was our problem? It could be...

• a tower defence game; where plants are overgrowing your towers, rendering them useless
• a horror game; where the player's paintings come to life and are attempting to murder you
• a puzzle game; where an overflow in electricity across a neighbourhood is causing damage 

Notice how what the player does is not linked to the theme. The player isn't trying to imbue things with life or "rejuvenate" them. Of course, one could observe that the player is trying to do the opposite: they want things to "die". For the first example, the player using weed-killers to activate the towers can be seen as the opposite of the theme. Keep in mind the solution doesn't have to be the opposite (thematically) to the problem. Likewise, the core mechanic doesn't have to be the opposite to the theme. 

Take the second example, maybe the core mechanic would be hiding inside/behind furniture to avoid being seen by the paintings. And the third example could be about changing wires/adjusting the circuit using a budget. "Hiding" and "buying new equipment" aren't the antithesis to "rejuvenation" yet they prove to be solutions to the problem of "rejuvenation" and can be core mechanics of a game.

So these are three examples of how to implement point 1 and three examples of how to implement point 2 of the theme.

Now let's move on to points 3 and 4.

The difference between design and story is quite simple: the former is about how the player interacts with the world, and the latter is what the world is. Ultimately the design of the world and the plot are two different flavours on how a game presents its narrative.

The ludonarrative is about the player's story/experience whilst the plot is about the character's story/experience. Take any RPG for instance. An example of a ludonarrative may be when the player (after multiple trial and tribulations) managed to grind their characters to a high level to finally beat this one boss that had taken them weeks to overcome. Most likely, the player will have a strong emotional connection to this particular boss that kept them grinding for hours.

Does the RPG characters address that this one boss in particular had been difficult for the player? Most often, no. Whether it took you 4 or 400 tries, the game's story will continue the same. But this experience of fighting the boss 400 times versus doing it 4 times will affect the player's experience. It's when an emotional effect of the player leads to their experience being their own story. Meanwhile, the story of the game is the plot, and could go something along the lines of "Ancient crystal has been shattered across the kingdom. Find the shards to defeat the evil king and save the princess".

I'll admit that this example is extremely over-simplified. If you're interested in a more elaborate discussion of ludonarrative, then I'd recommend clicking this link to see a video regarding Darkest Dungeon and its use of ludonarrative for interesting gameplay.

Whilst we're here, the reason why I didn't include "theme impact on game design" on the list of how to incorporate the theme is because I like to think game design encompasses:

• the core mechanic/solution
• the problem/challenge
• and the use of ludonarrative

There's more to game design than that, but discussing "what is game design" is a rather broad, large and abstract topic that is beyond the scope of what we're talking about. Here is one article about what a game designer does. 

So how can you use your game jam theme for ludonarrative or story? For the former, think about the atmosphere or the emotions you want to evoke in the player. Let's take the theme "rejuvenation" again. "Rejuvenation" can be broken down into 2 phases (before: when it's dead, and after: when it's brought back to life). Perhaps in the game, the player starts out with 1 HP, but slowly, as they traverse the world, they become rejuvenated and gain more HP, being able to withstand the harsh world more. Gaining more HP and fighting monsters can empower the player and make them feel rejuvenated.

Not all "themes" can link in so well with ludonarrative. "Chocolate" would be particularly hard to do, but perhaps it could be linked to a "sugar rush" that the player feels. Maybe the player character controls are quick with high speed and energy, but as the game progresses, the player loses the initial "sugar rush" as their character slows down. 

Notice how this "player experience" can be different from the core mechanic. Perhaps in this "sugar rush" game the player is a grocery store clerk, and the core mechanic is using the mouse to run around the store and arrange items in the store correctly. But as a secondary mechanic (something outside of the player's control) could be losing speed/energy over time as a consequence of the "sugar rush". Mechanics, challenges to overcome and ludonarratives compose game design and can layer on top of each other to form interesting gameplay.

Addressing point 4, the use of story relating to a "theme" is similar to any writing competition. Despite all the advice for writing stories, there's a scarcity of writing good stories relating to a given prompt. The best one is this link that I found here. 

An important concept is that your story (or the story of the game) should be able to work independently from the prompt: in essence, it should be a good story regardless of the prompt. Moreover, it should be able to communicate the prompt within the story, so that if a reader were to be told the prompt that inspired your story, they can clearly see the inspiration and explain the connection between the theme given, and what you've made of it.

If you're struggling to think up of how to think of a compelling story based on  a prompt, perhaps avoid point 4? But if you want to try regardless, in order to improve your story-telling skills (game jams are perfect for learning new things) then you need to "learn creativity". A lot of people have the misconception that you're either "born creative" or not, but, like everything else, it's a skill that can be taught.

A discussion of how to cultivate creativity and using prompts effectively for good storytelling is beyond the scope of this devlog. (And as I'm writing this I realised that this "small" section dedicated to advice on making up games based on game jam themes have exceeded the intended scope as well). Read about "creativity seeding", "overcoming cognitive biases" and essentially about "how to become more creative".

Finally for point number 5

This will be fairly succinct because if you're implementing point number 5, there's the presumption that you're proficient enough within art, music composition or sound design that you can incorporate a theme within that process. 

For the theme "less is more" (used in the jam), a lot of artists brought out minimalist styles that are inherently about emphasizing "less" within artwork. I also composed some "minimalist" music for my game. For those who may not be familiar with what "minimalism" is in art and music,  this is a link to a video about minimalism in art and this link is a video about minimalism in music.

Most game jams have themes that will make it difficult to incorporate the theme in this way. But if you can find a way to do so, it can only enhance the use of your theme within the game.

What to do with the 5 points?

Now that you have a theme and these 5 points in mind, think as to from what angle do you want to approach this theme from? Would you make it a game mechanic? Or would you rather implement the theme from a story perspective? 

You could also write down some interesting game ideas, and (using the 5 points) see if they connect in any meaningful way to the theme.

The former method can be seen as front-to-back and the latter can be seen as back-to-front. (with the "front" being the theme and the "back" being the game idea).

What if I can't think up of anything?

 It will take practice and time but improving your creativity should be the place to start. Your creativity allows you to form interesting interpretations of game jam themes. In my personal experience,  studying English Literature, Poetry and analysing texts have helped me creatively. Because I was made to come up with multiple interpretations of scenes, use of words and characters, I allowed myself to come up with multiple interpretations of a prompt or theme.

The best place to start out is this: look at the prompt and think of the first word(s) that comes to mind. It can be anything. Then, using this word(s) you conceived, think of another word based on your word. You can continue this chain of "seeding", restart the chain and think of  a new word from the root, or form a web of words and ideas.

In essence, you need to break down the word(s) down to their meaning and find other words by association. Try reframing the question not as "how do I make a game based on the theme rejuvenation?" but instead as "what does rejuvenation mean?"

But this isn't the only way (or most effective way) of thinking of new ideas.

Putting aside creativity, watching videos on game design (Game Maker's Toolkit, Snowman Gaming and Design Doc are great places to start) can help you analyse the games you like to play. With analysing comes understanding of what makes these games great. And with understanding, comes recognising how to make your games great too! 

On a similar tune, watching game-making documentaries (or how video-games were made) can also help.

Using the theme "less is more"

So with all the 5 points in mind, I started drafting a bunch of ideas in a sit-down session.

I came up with 5 fully-fledged ideas before settling on the game you see now. 

1. The player wants to sell their possessions and so travels "the land" (procedurally generated) to bargain with different people
2. Player can buy items on the internet from their laptop. As the game progresses, their room gets so cluttered that you can't see your surroundings anymore
3. Player is a monkey trying to steal items form people and negotiate to get fruits and berries
4. Player is a monarch who runs away from their castle to live a cottage life
5. Player is managing a zoo of cannibalistic alien species. The more alien eggs there are, the less aliens there will be as the aliens will eat each other. The fewer amount of eggs, the more aliens there will be as they won't eat each other because of the scarcity.

Idea 1. incorporates points 3 and 4. The story of the game is about the "minimalist lifestyle" and how less is more, but also selling items to other people means what is "less" to you is worth "more" to them. 

Idea 2. incorporates points 4 and 5. I planned to have it in a minimalist art-style so that the "clutter" would be a giant shape (composed of smaller shapes) that all were the same color. It's also a game about "having too much in your life is less". 

Idea 3. is very similar to Idea 1. in how it tackles the theme (what's "less" to humans is worth "more" to the monkey and vice versa). 

Idea 4. incorporates point 4, it's about abandoning the "more" in favor of a lifestyle that's "less". And idea 5 incorporates point 2, the problem of the puzzle is that "less is more" with the aliens, so how do you find the perfect balance?

Idea 5. utilises point 2. The "less is more" dilemma becomes our problem and we need a solution to control the aliens to make the population balanced.

I settled on the "minimalist mastery idea" because it incorporated the most amount of points from the theme. Moreover, I was really interested in the minimalism art movement of the 1950s/1960s.

• It incorporates point 1, as the "core mechanic" of the game is removing shapes from your paintings ("less shapes is worth a better painting"). It is a literal design by subtraction
• It incorporates point 3, technically speaking a "design by subtraction" philosophy would encompass broader game design, but could be considered a part of the ludonarrative/player's experience as they only experience what's necessary to one mechanic. There's no filler or anything superfluous.
• It incorporates point 4 as the story is about how the player (or artist) wants to pursue this minimalist art style (which critics considered "less" but you consider to be worth "more")
• It incorporates point 5 because of the minimalist art that I wanted to use in the game

So after a day of planning, I was ready to go and use Unity!

I have made projects in Unity before but they usually would never end up getting completed. The only other released Unity game is AntiDon't (which was also made for a game jam). For this game, I deliberately went in wanting to improve upon AntiDon't on a technical level. But it was also made in response to the previous game I had released eau de parfum.

Games as "responses"

Supergiant games (Hades, Pyre, Bastion) said in their NoClip Documentary series that all of their games were responses to the games that had come before. "Pyre would've never been made without Transistor". If you're a developer who likes to make a lot of short, finished products then making your games as "responses" to previous works could be a way to go.

Personally speaking, my games not only are works that stand on their own, but in adjacency to each other: they all belong to a single collection or a single body of work. 

How is minimalist mastery a response? Eau de parfum was a great accomplishment for me technically speaking, but it was the game with the least amount of story within it. I've always been drawn to video games that carry strong narratives, so - because my previous project had no clear narrative - I wanted this game to feature a prominent story.

It is also a response to AntiDon't in terms of seeing if I had improved my skills with using the Unity engine. I had also felt that the "puzzle" element in AntiDon't was a bit lacklustre, it wasn't a "puzzle" game as much as a "navigation" game? Therefore, I wanted to design a puzzle game that had a more "elegant" design with more "sophisticated" puzzles.

Looking at your works as "responses" beckons you to do some self-introspection as a developer. It's about what kind of game you should make and how you can improve based on your previous works. Sometimes it's bad to look back on the past, but in the case of development, seeing what you think is lacking or what needs improvement can propel you forwards as a developer and help the "deciding what type of game to make for a game jam" process a lot easier.

More so than game jams, it's also about what kind of developer you want to be. Do you want their to be a consistent theme across your work? Are you a developer who specialises within procedural generation? What about a developer who focuses on visual novels? Do you want diversity in your work (mechanics, genre, story) and if so, what genre do you feel is lacking within your work?

This is entirely subjective, but I think it's important for game developers to have a "diversity" of games. Not necessarily "diversity" in terms of game engines used, art assets or themes, but "diversity" in game design. Trying to make a lot of small different types of games, can offer you a broad knowledge of game development, more than making 10 RPGs. This advice should not be adhered to if you want to be the kind of developer that develops one type of game (i.e. you only want to make visual novels) and it's also fine to have a preference for a single genre.

So, after choosing a theme and now with a more clear understanding of the kind of game I wanted to make, I set off to develop minimalist mastery!

Choosing a game engine

Ideally, before the game jam starts, you should have a game engine in mind (or have a game engine you've used before). For me, the three engines I'm comfortable using are Unity, PICO-8 and Ren'Py. I did "break" this rule because the first time I learned PICO-8 was during the AGBIC game. As that jam lasted for over a month, it gave me ample time to learn the engine I was using and make the game.

The process of choosing a game engine was relatively simple because I knew I couldn't accomplish this idea on PICO-8 (token limitation and limited use of mouse interactions) and I couldn't use Ren'Py either (was mostly made for making visual novels). And I wasn't willing to learn Godot, in a week (I'm considering picking it up though) so Unity was what's left.

I would like to write something longer about this, but PICO-8 is an excellent game engine for game jams. By it's very design (limited tokens) it forces you to have a game with a small scope and makes art/music production very easy and accessible. Be warned that it is more complicated than Unity and Godot from a programming perspective and it's not free.

But as for you, when choosing a game engine you should consider...

• what the game engine exports to

For game jams, you get more plays if your game is playable in browser versus it being downloadable. It's fine if it is downloadable by the nature of the game and if you aren't too concerned with people playing it. The majority of game engines support easy export for browser-playable modes, but it's always good to double check.

• the involvement of programming

Different engines approach how involved you are with coding differently. RPG-Maker exists for those who aren't comfortable with coding at all. Unity and Godot handle the complicated physics/mechanics of 3D games (so you don't need to code that). And Py-Game only offers you a library of tools to use, everything else is from scratch.

• how feasible the game engine is for your design

This is the approach I took. Of the engines I was comfortable with, Unity was the only one that could make this puzzle game idea a reality within a short amount of time.

• support online and documentation

If you're a beginner and planning to use a lot of tutorials to get you by, look into engines which have a large collection of resources to help you develop games. The big ones are Unity and Unreal.

Designing the game

Before designing any levels, I made a single level to test if all the ideas I wanted to put into my game were feasible...

• Shapes "hiding" behind other shapes
• Multiple shapes hiding beneath one shape
• A shape hiding underneath a shape (which is also hiding underneath another shape)
• Choosing a colour palette for the game
• Counting the number of coloured shapes in a scene and the total number of sides
• Scoring is correct
• Player is able to name their painting

Once I had this basic level designed (it's actually used as the 4th level in the game) and everything off this list was working, then I went back to pencil and paper to design levels.

In puzzle games, each mechanic should be introduced in an easy level before being used in a difficult or challenging way.

For example, the second level of the game exists to teach the player that circles count as having 1 side. The third level of the game exists to show that shapes can "hide" underneath a shape. The fourth level exists to show that shapes can hide underneath shape which is also hidden underneath a shape. The fifth level exists to demonstrate that you don't always need to uncover every shape, sometimes, to meet the goal, you have to let shapes underneath stay hidden.

With these basic principles the rest of the game is built upon, I can now throw more difficult levels at players because they are equipped with knowledge demonstrated in the first 5 levels. You see a lot of puzzle games follow this formula of having a really "easy" stage with a new mechanic and then asking you to "test" this knowledge of the new mechanic.

Keep in mind that all of the "mechanics" about the shapes aren't actually new mechanics as much as they are extensions of the core mechanic: removing shapes from a painting. This is the only thing you can do in the puzzle section. What makes this interesting are that the consequences of removing a shape changes (and the goals also change too). Introducing that shapes can be "hidden" underneath removed shapes, adds depth to the challenge. Showing that some shapes should stay "hidden" and others "revealed" adds more complexity. The Piet Mondrian-inspired level (after talking to the boss) demonstrates how what you think may be one shape may, in fact, be two separate shapes!

The actual process of development will be a bit long to explain, and talking about "adding" in features over the course of a timeline doesn't fit into this overall devlog which is "design". That would be more of a "programming" discussion which I'll leave for another time.

All I knew is that I wanted there to be a minimalist art style. I formed a "mood board" of minimalist paintings to inspire me for the level design and I listened to minimalist music to help me compose parts of the soundtrack to this game.

I've been fascinated by the minimalism art movement because, although I have a general appreciation for art, I never quite understood its appeal. Doing research into minimalism art and making this game's story helped me find an understanding for minimalism which I now appreciate.

Separate from the puzzle sections, I wanted to have dialogue and for the player to interact with their paintings (making it feel as if they've exhibited it in an art gallery). This also ties into the point earlier of how my previous game was lacking in story, so I decided to add more in this one. The walking sections and dialogue was easier to implement than expected. I did plan for multiple "dialogue options" in the game but didn't have the time to make them a reality.

Overall, I was very pleased with how the puzzles and how the dialogue sections played out.

I originally intended to just do a post-mortem and not add all the additional text you see above, but I think that the context of how I arrived to my ideas and how to make games during a game jam is important. Because a postmortem for a fully released game that has gone through alpha/beta testing should be different to a game that was made just during the jam.

The biggest issue was that I used the wrong version of Unity which didn't have the WEBGL support installed. I had 2 hours before the deadline and had to make a choice...

• reinstall Unity and redownload the WEBGL port, and bug fix the game for online before submitting it
• submit the game with a PC build now because there's only 2 hours left

I ultimately chose the second one because I knew I could always make a web build after the game jam. But also for game jams, it's important to still be healthy and get sleep (which on the last day I wasn't doing). I felt exhausted, tired and went to bed feeling dissatisfied but still with enough time to get some sleep.

This is why in the "choosing engines" section I realised the importance of knowing about what it can export to. Before you even make your game, make sure it exports to web (or whatever platform you want to use). I even planned on making a mac version, but that wasn't installed on my unity version so I'd have to redownload it too.

Additionally, I was very bad at planning for this game jam. Although I had levels planned, I didn't know when I was going to make them. I failed to make a schedule of when to implement things so I ended up deciding in the moment whether I "felt like" doing a level or composing music. This led to me crunching a lot on the last 2 days because I had procrastinated on essential features (actually making the levels) in favour of ones that weren't necessary but required more technical skill (custom colour palettes, cutscenes).

The best schedule I made was for AntiDon't because it lasted only 2 days, I knew I had to plan my 2 days extremely efficiently. I knew the first day would be just code, and the second day would be only art/UI.

For future game jams, I hope to have my days planned out after I have an idea of the design of the game.

Moreover, I was really disappointed that a really large bug managed to make it into the final product. People were unable to walk in the "dialogue" portions of the game, meaning they missed out on about half of the game's puzzles and the main "story" of the game. This was fixed immediately after the jam, but all the participants in the jam didn't get the chance to see it.

But overall, I'm happy to say that I'm very proud of everything else. 

This has probably been the most "lively" and interesting animation I've done for any of my characters. A character design concept of making everyone recognisable from a silhouette was really the driving force for this game's look. I find the geometric art-style very endearing, and would like to make more things with this style.

I am also pleased with how the puzzles ended up working! It lived up exactly to my initial vision of a simple, clean looking game.

In terms of programming in C#, I felt as if I've made significant progress from AntiDon't and surprised myself that I managed to do some implement features that I considered "outside of my skill level".

But most of all, I was overjoyed with the amazing reception this game received from the BTP game jam! Notwithstanding the comments regarding the large bug, a lot of people responded very positively to this game. Whether it was finding the art style endearing, the puzzles inventive or the story engaging, people connected to this game and that's something I truly am thankful for.

Ratings do mean something, but I found the comments and feedback to be the most rewarding thing of the ratings process. Also seeing my game in the BTP's video was a highlight. I've been following his devlog series on his games for quite a while, so it was jarring and amazing to see my game on screen (if only for a few seconds).

I saw a lot of people were upset about "bad ratings" they had received, and I can understand. AntiDon't scored decently for what it was (overall was top 10% for presentation and top 25% for overall) but at the time, it's easy to internalize ratings as a reflection on you as a developer. "You're a "2 star" developer because your game got 2 star average overall on this one game jam." But that's when you have to take a step back and focus on improvement.

Afterwards, I started making more games, and with each game I made, I ended up improving significantly! Even AntiDon't gained  a "redemption" when I made a web build and 3 months later, it started gaining traction again. But the biggest thing was that I took the complaints people had about AntiDon't and used that as sources of improvement. So by the time I published the web build, it came with all the fixes people were looking for.

I didn't expect to write this much but it turns out I have more thoughts than I anticipated! In conclusion, I'm really happy with how minimalist mastery turned out, and (whilst writing this) I learnt some new skills along the way :)

Thank you so much for playing minimalist mastery and for reading this! If you would like to check out other games from the BTP game jam feel free to click this link and go through the submissions.

Links, articles and videos

BTP video about 17 games made for this jam

Video on ludonarrative and darkest dungeon

Article on what is a game designer

Article on how to use writing prompts

Video on minimalism in art/paintings

Video on minimalism in music

Game Maker's Toolkit: videos on game design

Snowman gaming: videos on game design

Design Doc: videos on game design

AntiDon't post jam update

Link to other games made for the BTP game jam