Finding the core mechanic

As is mentioned in its description, this project started as a hastily thrown-together, half-baked idea for the 2020 GMTK game jam, where the theme was 'out of control'. During that game jam, I had the basic idea of panels showing different points of view. Starting from there, the project gradually developed into a simple puzzle game about moving blocks around a 3D space. It didn't go very far, though, and received a deservedly low rating. Despite this, I think there is the kernel of a good idea there, which I want to explore further.

The first idea was to fill out the environment with extra elements, such as obstacles that reset the cube, or triggers that rotate the point of view (such that the direction of the cube for that panel changes).

After adding various elements such as this, it became clear that something more fundamental was missing, and that adding more gameplay elements was the wrong thing to do, without developing the basics further first. Similarly, the graphics needed to be revised and simplified, as they had been very quickly scrambled together during the jam.

At this point, the idea of a central overview camera came to mind, which would give an overall perspective of the environment. After playing around with this new setup for a while, it became clear that the panels were making less and less sense. Now that they were pinned to the corners of the screen, it was less clear how they related to the movement of the cube. To make this more clear, I added physical objects to indicate the cameras, which are only rendered in the background, on the 'overview' view point. Around about this point is also when I colour-coded the cameras, panels, and cube (later this became 'cubes'). 

I am a fan of games that can explain themselves without words, by using animations and directing the user's attention such that the mechanics become clear. In order to try to achieve this, I have setup a system for revealing the objects in the maze gradually. This is especially important for the cameras. The cameras and their respective panels are revealed together, one-by-one to make it clear that they are linked. I also animate the currently selected camera by pulsing it repeatedly. 

I also decided to wait for the cube's movement to complete, before moving the panel. This is a very subtle change that I think also clarifies the connection between the cube movement and the panel movement.

After implementing all of these subtle but important changes, I was still left with something missing. The issue was that the movement of the panel didn't really have any significance, beyond changing what buttons need to be pressed. That is to say, it didn't matter at all which panel was selected in order to reach the goal. I decided I needed a way to tie-in both the cube position and the panel position to the goal state. My current solution to this is to have a cube for each panel. Each point of view only controls one cube, and all of these cubes need to reach their respective goals in order to complete the maze. I think this brings the two mechanics (moving the cube and moving the panel) together and creates a more unified puzzle structure.