Cubix
Project Details:
- Duration: 4 Weeks
- Engine: Unreal Engine 5, C++
- Tools Used: Rider, Github Desktop, Figma, Ableton, Miro
- Team Size: Solo
Goal of Cubix:
Cubix is intended to be an extremely simple "bare bones" game, allowing me to prioritise improving my C++ capabilities in Unreal Engine. For this reason almost all actors in Cubix were created in C++. With only a few exceptions created using Blueprint visual scripting.
What is Cubix:
Cubix is a short 3D voxel puzzle game where you must rotate and position puzzle pieces to create specific shapes. The game is level based with each level having a "target shape" to make using the provided puzzle pieces. You move pieces by dragging them, and rotate them using UI buttons.
C++ vs Blueprints:
When coming up with Cubix, the goal was to solely use C++. But very quickly I realised the limitations of this approach, and why many Unreal developers promote using a mixed workflow with both C++ and Blueprints visual scripting.
As I began prototyping and creating the core mechanics of Cubix (grid based movement, draggable pieces), it was obvious that prototyping with C++ significantly slowed down my workflow.
This is primarily due to the slower compilation speeds when compared to Blueprints and the added complexity of writing code relative to dragging nodes.
When prototyping my aim is to experiment with ideas as fast as possible, not worrying about organisation, optimisation, or "tidiness". I found this approach clashes with C++ and is much better suited for Blueprints
I quickly shifted approach to prototyping Blueprints first, to later be converted into C++ classes once finished prototyping. Doing so saved LOADS of time and made sense considering the purpose of Blueprints.
For most actors I defined their class and core behaviour in C++, afterwards creating a Blueprint that inherit from said class.
The only classes made entirely without C++ were the UI elements (Widget Blueprints), as they only required relatively simple functionality which I intended to constantly tweak and edit.
Overall, Cubix strongly highlighted why veteran developers recommend using Blueprints and C++ in tandem. Unreal Engine is designed for developers to use both, and each developer can decide where and where not to use each.
They both have benefits and drawbacks, but by using a mixed workflow you get the best of both worlds.
Challenges & Solutions:
While creating Cubix I encountered 2 main challenges trying to achieve my games vision.
Grid Based Movement:
Creating grid based movement was a fun challenge to overcome, as I'd never made such mechanic. For Cubix all puzzle pieces need to be aligned to the grid, alongside any movement or rotation.
INSERT GIF OF SHOWING MOVEMENT
The approach I settled on was this...
Each level has an actor named the "Grid Manager". The grid managers role is:
- To keep track of every puzzle pieces state and check if they're in the correct spot
- To provide puzzle pieces with location data for where to move on the grid, based on their desired direction
- To render the grid and define its size
At the start of each game or whenever a puzzle piece needs to move, the puzzle piece tells the grid manager:
"Hey, I want to move in this direction!" or "Hey, can you align me to the grid when the game starts".
Then the grid manager then take puzzle pieces location and it's desired direction, and it calculates where the puzzle piece should be, then it sends back the information to the piece.
While this approach is fairly simple and straight forward, it worked well for Cubix's small scale.
Checking for Puzzle Completion:
Verifying when the puzzle is completed and the pieces are in the correct location was absolutely the biggest challenge for this project.
The initial plan was each point on the grid would keep track of if there was a puzzle piece on it.
Then when you move a piece the grid manager could check every occupied point to see if it formed the levels "target shape"
But attempting to make this verification system proved to be a challenge slightly too large for this "simple C++ project".
When checking the puzzles completetion, you have to account for the fact that the "target shape" can be rotated multiple ways and positioned anywhere within the grid, and still be correct.
Taking this into account, I realised this approach was too complex and large of a scope for this "small project".
The new approach was to give each puzzle piece a "joints" which are invisible colliders, that when overlapping with another joint send out a signal saying "Hey I'm in the right spot".
Then by putting joints selectively on specific corners and checking that all joints were "In the right spot", you could figure out when the puzzle is solved.
INSERT JOINTS VISUAL
Doing this massively simplified the check for whether the puzzle is completed since you're essentially seeing if a hand full of colliders are overlapping.
I thought it was problem solved, until I found some major flaws...
Taking this approach added many more complexities such as:
- Any puzzle pieces that can be mirrored on any axis will required multiple joints to account for its multiple rotations.
- And then you add in conditionals like "Ok for this puzzle piece only 1/2 the joints need to be in the correct spot".
- Alongside also finding multiples "cheese's" where even when the puzzle pieces are in the wrong location, you would still win because all the joints were overlapping.
In the end the problem was never fully fixed with this "band-aid" approach, and I only got around it by creating some interestingly shaped puzzle pieces that couldn't be mirrored.
It really showed me how sometimes the simplest things in games can be significantly more complex.
Reflection:
After finishing and reflecting on Cubix, I feel as though this project pushed me and improved my C++ capabilities greatly.
It also highlighted all the complexities that can occur in such a simple game, and how often we don't realise the amount of work required to make games.
At the end of the day, I've come out of this project as a better game developer and more excited to keep improving.