GMTK Jam 2025

2025-08-07

Last week I participated in the GMTK 2025 game jam, which had the theme of “loop”. As I often do, I got caught up in building the game engine and ended up not making much progress on the actual “game” part of my entry. However I did submit it, and since I got some comments on the submission page, I decided to make blog post detailing my plans for the game.

Rejected Concept

Initially I wanted to make a game that really leaned into the “loop” theme. I created a new spread in my bullet journal, opened up the Wikipedia page for loop, and started writing down what came to mind.

I particularly liked this definition:

  • Loop (topology), a path that starts and ends at the same point, possibly reduced to a single point

From there I had the idea to make an idle game (like Cookie Clicker) where you always return to the same point. You would start off with access to only a single point, and then make a loop containing just that point. Making that loop would give you some score, and then you would use score to buy upgrades, etc.

The problem with that idea was that I wasn’t really interested in it. I’ve played my share of idle games, but I just didn’t feel like making one myself.

New Concept Pitch

You gain access to a remote control interface for a robot. Starting out, you can only see nearby nodes and then travel to them. As you explore, you discover software that upgrades your interface, and notes that explain how to properly use the robot.

Among the the interfaces available to you is a camera. A noisy, poorly calibrated camera, which takes multiple seconds to download the image to your remote control interface. Do you have what it takes to find the signal buried in the noise?

The following sections may spoil puzzles for the game, if I develop it further. I’m pretty bad at finishing projects, but you’ve been warned.

Ideas for Puzzles

In case it wasn’t clear from reading the pitch, I mostly have ideas for things that could be puzzles. I didn’t have any idea for a broader narrative or a satisfying conclusion.

NavMind

The start of the game would revolve around exploring different “points of interest”. At these points of interest you would be able to find various notes and interfaces. Exploring a new point of interest would be as easy as clicking a button. In universe, a separate processor called the NavMind is responsible for tracking these points of interest.

Crucially, the NavMind is not designed to expose every possible corner of the world to you, the remote operator. It’s purpose is to make it easy to maneuver the robot to where it’s supposed to go.

The key to this puzzle would be:

  1. Giving the player another way of moving the robot.
  2. Giving the player another way of seeing the world (the camera would be a big part of this).
  3. Making the player realize that “points of interest” are an incomplete description of the world.
  4. Having the player discover how to “manually” explore the world.

I wasn’t sure how I was going to give the player manual movement of the robot. One idea was to make a software package the user can find; e.g. an upgrade that the player can pick up. However I wasn’t thrilled with this idea because I wanted the game like Outer Wilds, where the only only barrier to solving the game is your knowledge of it.

Command Line

A potential way to have hidden functionality is by adding a command line to the robot. This is how Basilisk 2000 deals with this problem. Now instead of needing an upgrade, you just need to know the magic word.

This wouldn’t necessarily rule out having upgrades either. The upgrades could instead be a more discover-able or more convenient way of using the commands.

Camera

This one draws a bit more from my day job. We use a camera as a part of a measurement system so I’ve needed to learn and implement techniques for reducing noise in the output images. I wanted to put some of that into the game.

Making this an actual puzzle instead just “Scientific Camera Simulator 3000” requires a bit more thought, but I have a couple ideas:

As for the hurdles the player would have to overcome:

Download Speed

To prevent some of the puzzles from being trivially brute forced, I decided to make the images take a while to “download”. While the image is already stored on the robot, seeing it in the remote control interface requires downloading it over an agonizingly slow connection. This also puts more importance on the NavMind, as such a slow frame rate would make navigating using only the camera impossible.

I did also have the idea to add a compression software upgrade that improves the download speed somewhat.

Signal Processing

This is less thought out, but given the slow connection mechanic, perhaps it would make sense to introduce reports that take less time to download? It would depend on the puzzle, but one of the key concepts is that it’s not the robot or user interface that is slow, it’s the connection between them.

The puzzle here might be in learning to understand how to read these plots of data, and when to use them.

Influences

Here’s a short list of games that influenced the ideas here: