Day 1: Conceptualisation and Prep work

I have joined the Mini-Gim Portal game jam on itch, hosted by Zobzi. Here, I would like to document my progress participating in the jam while prototyping my game that fits the jam's theme.

The theme is simple: the visuals and mechanics must relate to portals in some way. Since I will be working on the project solo, I have to be conservative in my ideas as I have limited art assets and development time. Focusing on what I excel at, I decided to focus on mechanics over art.

First, I need to decide how the theme would relate to the game mechanics. For me, portals are simply a pathway across space: teleportation. The simplest implementation would be a portal that instantaneously teleports you to another location. I settled on a simple puzzle game that has you navigate through portals to reach a goal, such as a flag.

But this would be too simple. Players would get bored if you only had to find one path to follow. Strategy was needed to make the puzzles more challenging and interesting. So I added a layer to the mechanic: 2 coloured portals where they are only connected to same colours. A toggle can alternate the colours of one or both portals.

Switches had to be communicated to the player, so they are colour-coded. Red activates red portals, and blue activates blue portals. This adds an additional layer: some portals can only be toggled to one colour, others can do both simultaneously. Finding which portals lead to which in what order became key to solving the puzzles.

This adds a problem. If multiple colored portals exist in a level, how would they know which one to connect? Do they prioritise based on distance? The order in which they were made? How would the game logic handle this? How to communicate to the player which portal leads to where?

I explored several ideas. Maybe the levers only switched portals on platforms. Or perhaps the player is assigned a colour and can alternate between them freely, but can only pass through same colored portals. Or maybe some portals are coded to link to a specific entry and endpoint. Unfortunately, none of these mechanics made sense or solved the problem

I had the core idea. Now to make the assets. I wanted to keep things simple, so I used Aseprite to make 8x8 pixel art to represent the various interactables: The player, levers and portals. I also made floor and wall assets to identify navigatable terrain and obstacles.

Now that I had a solid concept, I have to start implementing it in-engine (I used Unity2D for this project). I needed a level to test out basic navigation, and I wanted the game to be grid-based, so I used Unity2D Tilesets to set the layout. Importing the assets into the tile palette made modular level design easy. The first sprites clashed a bit in practice, but with a few minor adjustments, they worked out well..

Grid movement had to be snappy, so I wrote a movement script based on Unity's coordinates, ensuring distance travelled was in fixed units. (I had to watch a YouTube tutorial for this since this was the first time I made a grid-based game from scratch).

At this point, I stopped for the day. I had to fix a bug where diagonal movement was possible, and to start implementing the logic for the portals. UI also has to be made to reset the level in case of softlocks, and I needed to add a win condition or UI upon reaching the flag.

Considering the progress in one day, I was satisfied for now.