Not a Good Fit [GAME PRODUCTION]

My goal with the rough prototype is to have a small playable scene that reflects the core mechanic of the game. Since I’m careful on the development time of the entire project, I wanted to make sure I would not invest too much of it on the rough prototype. Even if some controls contain minor bugs, I am satisfied with the results and can now focus on adding context and narrative.

Player movement
The player controls a cube on a plane, which can move up, down, left, right. The movement tries to stick to a 1×1 grid. While moving, the cube rotates in relation to the given direction input. To make things easier, the cube’s rotation reset itself after each movement step so it can be ready to be triggered again, without having to calculate any further quaternion maths. Since it’s a cube with identical faces, it’s impossible to notice the rotation reset after each step.

Ejected
The goal of the game is simple, get in the hole and stay there. But series of events always happen to get you out of the hole. In the rough prototype, I integrated one scenario. The simple eject event. The way it works is that every time the player steps in the hole, the cube is sent in the air at a random direction and thrust.

Returning on the grid
Since players’ movements are lined up on a grid, making sure that the cube is always aligned with the hole, I needed a method to get the cube back on the grid after it falls off. This happens for instance when the cube get ejected from the hole. I didn’t want events to always make the cube interact with the grid. In the eject example, the cube gets thrown in the air at a random direction. Being free of any constraint aside gravity and velocity.

When the cube is no longer on the grid, it doesn’t respond to any player inputs. Only when it comes back on the plane and stops moving (checking if velocity is at 0) that it declares itself stuck. Then, inputs can be triggered again, but no matter which direction the player passes, the cube will move to the closest cell of the grid as a first step. Only the rotation reflects the direction passed by the player’s input. Finally, once back on the grid, player movements are back to normal.

Known issues

The rough prototype was made quickly, thus, some bugs were found and ignored. Here’s a list of the major issues that need to be resolved for the next release (Final Prototype).

Multiple inputs get the cube off the grid
After holding down a direction for some time, or after a long series of inputs, the cube seems to be off synch with the grid. This could be fixed by adding some sort of safe offset when a movement is declared complete.

Return to grid is not accurate
When returning to the grid (after ejection), the cube doesn’t always move to the closest available cell. Some error of calculation is mainly the cause here, but should be fixed easily.

Next

The next release will be the final prototype. This one will be heavier in terms of content and/or gameplay. The main goal will be to add more rejection scenarios and to determine how these can be triggered. I don’t think I’ll change the visuals that much for the next iterations, even though, they won’t require a lot of time on my side anyway.

I wish to have a linear path of scenarios, divided in 3 categories; mild, moderate and extreme. Thus, it will look more like a complete game having a start and an end, even if I don’t plan to define the ending right now.