Entangled (*working title) is a puzzle platform game with a novel mechanic blended with physics in a science-fiction setting. You play as a robot with the ability to entangle objects to enable the solving of otherwise impossible tests…for reasons you learn over the course of the game.
This dev blog is intended to show the development of the game from the very first ideas through to the eventual completion of the game. I aim to shed light on different aspects of amateur solo game development and show my techniques, my mistakes, and what I learn along the way making my 4th game (see my other games here).
In this first dev blog I will describe the process of going from my first idea through to what became the prototype of the game as it is now.
The Game
Entangled’s main mechanic is ‘entangling’, which means the player can link objects together and therefore move two objects as one despite them being far apart. A GIF says 1000 words, so here’s a simple example:
That’s the core mechanic of the game, and it is combined with various other mechanics and ideas to create puzzles of increasing difficulty as the player gradually learns the story and begins to understand why they are being subjected to these constant tests of their abilities.
Of course a game idea doesn’t just appear fully formed. This article covers the genesis of the game idea. Without going into detail, there were a lot of prototypes and abandoned projects since my last game. My day job also makes it difficult to dedicate as much time as I’d like to game development. But at some point one of my ideas became good enough to start serious work on.
The Idea
Entangled was the end result of a lot of ideas that didn’t quite work. After a few prototypes and some fiddling around, I finally found the idea that I felt was intrinsically fun and also had a wide scope for interesting puzzles.
Copy Cat
Because I always keep a record of my ideas and notes, I can trace the main idea for Entangled as it evolved from the initial idea to the final one. Here is my initial idea for a game I was calling Copy Cat:
“The player controls a cat, and there is a 2nd cat who copies the player’s movements. The goal is to get the two cats together at the end point of the level.
The main puzzle mechanic is that the player must move in such a way as to ensure the 2nd cat also reaches the level end point. This would be complicated by asymmetrical level design and additional mechanics (e.g. buttons one of the characters can stand on).”
That was a start, and I made a prototype with 9 sample levels, and I had a bunch of notes and ideas jotted in my OneNote notebook for the game. Here are some images of this prototype:
The prototype had a few issues, the most glaring of which were:
- The gameplay was by nature ‘fiddly’. You had to split your attention between the two cats. Every action had two results (one for each cat).
- Puzzles generally had quite obvious solutions. The asymmetric nature of the gameplay gave away too many clues to the puzzle solutions.
Ball and Chain
There was about 10 days between the Copy Cat idea and this next one. I still liked the idea of something being linked or joined to the player, so that carried through to this next idea called Ball and Chain, which went like this:
The player is permanently chained to a heavy ball (i.e. A ball and chain), and must figure out how to reach the end of each level by using various techniques and mechanics to help them move with the ball chained to them.
The player can’t jump very high because of the ball, and their movement can be hindered by the ball getting stuck. Moving platforms and so on can be used to help the player move.
As you can see, I was thinking of the idea of two things being moved together, but having different qualities that turn the movement into a puzzle mechanic. This idea was almost the opposite of Copy Cat, but the idea had stemmed from the same thought process.
According to my notes, this idea was prototyped but turned out to be rubbish. I couldn’t find the prototype, so there are no pictures of it. I also remember comparing this idea to a game called Chariot, where the player is connected to a cart and has their movement hindered by the physics of the cart as they explore. That game had a more interesting use of a similar mechanic. My ball and chain idea was nothing more than a hindrance to the player with no real potential for fun gameplay. It was one of those ideas that sounds good at first, but gets worse the more you think about it.
Box Link
The notes describing Box Link were written only a few days after those for Ball and Chain, and the idea is one that evolved from the Ball and Chain concept. The notes are quite simple:
Link boxes together with some kind of cable. Requires line of sight between the boxes (don’t have to be boxes, could be anything).
Boxes could have properties that make them varied. Terrain is used to ensure there are limited solutions to linking all the boxes in a given level/puzzle.
Here is the basic, final idea for the game. The above text is literally the entirety of my notes for Box Link because I knew right away that this idea had potential, and at that point I started making a more comprehensive set of notes.
Entangled
My notes for Entangled start like this:
A puzzle or puzzle platformer where the main mechanic is joining two (or more?) items by ‘quantum entanglement’ so that actions done to one object also affect the other.
As you can see, there is a clear line from the original Copy Cat idea through Ball and Chain, then to Box Link, and finally to Entangled. This is how my ideas evolve. I didn’t give up on the original idea because I felt there was something there. So I kept my notes and then had another idea that took some of the original. It wasn’t until that idea also failed that I eventually had the idea that worked. It’s important to understand that good ideas don’t always just happen. Explore your bad ideas to see what good ideas could be hidden within or around them.
The final idea of Entangled has quite a lot in common with Copy Cat. The core idea of an object inheriting the movement of another object is kept intact, but it works very differently. It is an idea that has more potential for puzzles and fun gameplay, and it overcomes the main drawbacks of the original prototype (fiddly movement and poor puzzle potential).
Now I’d like to take a step backwards. I might have implied that once I had the Box Link puzzle the idea search was done. This was not quite the case. A game developer will develop an instinct about such things, but instinct is not scientific! I knew I had a potential game-worthy idea, but the next step was to explore it, prototype it, and think about it. My Entangled notebook has pages of notes about how the mechanics would work in different situations, what secondary game mechanics might work with the game, and various other things.
My process for developing an idea goes something like this:
- Have an idea with potential
- Explore the idea theoretically (i.e. write notes, scribble ideas down, think about it) until it becomes clearer that there may be potential there. If the idea falls down then file it away for later and get another idea!
- Prototype as simply as possible to make sure the basic idea works
- Refine, think more, make more notes.
The prototype felt immediately fun to me, and I was able to create a batch of puzzles quite quickly. These two things gave me the confidence to continue with the idea.
Here is a prototype screenshot. In this example the blue box is the ‘parent’, and the green box will inherit the parent’s movement:
Summary
And that’s how I went from an initial idea to a final game design (with some prototyping and dead ends along the way. Of course there is much more to the game than what I’ve shown here so far, and a lot of designing and brainstorming went into the overall game design. But more about that another time.