The Design of Clumsy Robots - Intro and Mechanics

I've decided to talk about the development of Clumsy Robots because it has been quite interesting.  The idea came to me originally from playing Lightbot (A programming game). I've noticed from it and other games that programming games tend to be somewhat distant from how actual programs are structured. They are mostly about initiating a strict series of instructions, while in reality most programs are structured around receiving an input and performing an output. From there the idea evolved in my mind into a sort of reverse programming game, where instead of programming the character, you place the environmental obstacles that will trigger the right responses from the robots at the correct timing.

What made me really get excited about it was the realization that robots could have commands that control other robots. Suddenly it felt like the space of possibilities was infinite (a friend told me that this set of mechanics might be Turing complete, but this engine isn't optimized enough to check that).

I held on to this idea for a few years before I actually started developing it. I had a bunch of ideas for mechanics and worlds that I slowly started writing down. When I decided to learn Unity and start actually developing games, it made sense as the first idea to execute.

Because I knew this game could get complicated, I wanted to make sure that behaviors remain as predictable as possible. That meant that every robot has to keep going at the exact same speed regardless of the amount of commands and wall collisions that happen during the run. This is why the size of each robot is the same as a square on the grid, so when they encounter a wall they will be in the middle of a square.

It also meant that I had to choose the simplest solution when thinking about robots encountering each other on the grid.  Generally I found that letting robots bump into each other reduced the possibility space instead of increasing it. The amount of levels that could be based off of robots bumping off each other is quite limited, but the constraint it provides would be large. It means that any level where the robots might cross paths becomes a lot more confusing and hard to map out. Also because of the size of the robots, making an animation for them to turn around each other was also difficult (especially with the robot timing constraint). I ended up letting them phase through each other. The simple graphics made it look slightly less ugly.

I've always wanted this game to take place on a grid, but for a long time I thought that walls would be placed as a single line on the edge of a square instead of taking up an entire square on the grid. But it was difficult to make a thin wall that stands out and doesn't ruin the timing of the robots, so I chose walls that take up full squares. That ended up being a great decision as it made each wall take up extra space on the board. Now each wall placement was more significant and you could accidentally block robots on their path. That brought a lot of extra puzzle ideas.

So those were a few of the broad gameplay decisions I had to make. The next segments will be about: UI, level design and how development ended. Thanks for reading and have a good day!