Design Context

Project Summary

CUBOID is a 3rd person puzzle platformer from an isometric perspective designed for current and next generation consoles. The gameplay focus is a mix between linear and nonlinear levels that focus heavily on platforming skills and fast-paced reflexes to properly switch and interact with different sets of world geometry, hazards, and collectable items.

Game Pitch

CUBOID is a clumsy program lost in a seemingly endless simulation. There appears to be a path ahead, but it is fraught with danger. Control CUBOID in order to escape the simulation and unravel the mystery of this world one level at a time.

Goals

Internal

  • Experience feelings of excitement and immersion during regular gameplay through platforming in a minimalist and vibrant environment.
  • Experience level design patterns that promote feelings of tension and conflict while avoiding hazards.
  • Experience a desire for completionism of the game as a result of the meta game progression by achieving the best score and time of each level. Achieved by practicing each level through multiple runs, and prioritising either completion time or high score based on level layout. Easy to learn but hard to master.

    • External

  • Develop my level design skills using only basic geometric shapes (Primarily cubes and spheres) to establish interesting and engaging level design patterns, promoting the minimalist and brutalist themes present in the visual design of the game through highly expressive forms.
  • Practice creating self-projects through the lens of a portfolio piece, further establishing my game design and development process while maintaining strong design documentation for future reflections and a post-mortem.
  • Build a stronger portfolio of design work to leverage as evidence of the necessary skills to secure a game design or level design internship at an indie or AAA game studio in Europe for the completion of my Bachelor of Science degree program.

    • Project Details

    Development Time 2021, 3-4 Months
    Team Size 1x Developer
    Role Lead Designer and Developer
    Client Self Project
    Genre 3rd Person Platformer
    Controls System Playstation Dualshock and DualSense Controllers
    Target Audience Playstation Gamers Aged 10 - 40
    Game Skills Puzzle Solving, Platforming, Quick Reflexes, Leaderboards, Speedrunning
    Software Dreams Engine, Miro, Trello
    Management System Agile, Scrum, 2 Week Sprints
    Development Platform Playstation 4 Console
    Target Platform Playstation 4 Console

    Inspirations

  • The post-war era minimalist art style combined with geometric abstraction, as well as the brutalist architectural style to promote highly expressive forms. Minimalism was specifically inspired from the artists Piet Mondrian, Dan Flavin, and Michael Arnold.
  • Tutorialisation through level design via a laddered introduction of game mechanics and level design elements, increasing in contextual complexity during individual levels and the overall game progression. Specifically from Super Mario Bros (1985), Level 1-1 on the Super Nintendo Entertainment System - Shigeru Miyamoto and Nintendo.
  • Traditional action-adventure platformers with a strong focus on the skillful application of platforming gameplay, combined with numerical score based collectables and level completion objectives based on scripted level set-pieces. Specifically from Spyro: Year of the Dragon (2000) on the Playstation 1 - Insomniac Games and Sony.

    • Slideshow

    ❮ ❯

    A collection of in-editor and in-game images featuring game levels, node based game programming logic, the HUB level, meta game progression analytics, and prototype testing levels.

    Design Challenge

    Design a modern platforming game held to current gameplay standards of smoothly animated movement with animation cancelling through player input, and highly accurate collision on both player and world geometry.

    Promote a fast-paced locomotion style inherently connected to level navigation to quickly establish a flow state within players.

    Write a compelling narrative in a genre that traditionally prioritises flashy gameplay and iconic character recognition over morally challenging and thought-provoking stories.

    Pre-Production

    Brainstorming

    I began by ideating what the core themes of the game should be, and how I would unify gameplay with visual identity. I found a minimalist painting by artist Michael Arnold which inspired me to look to primitive cube shapes as a source of inspiration for form and style. I utilised “Freytag's Pyramid” as a narrative methodology to write a brief narrative outline, which follows roughly the same structure as the classic “Hero's Journey” plot structure. I then composed a moodboard mainly focused around minimalism and cube geometry.

    Paper Design

    To understand the gameplay I created a rules list that allowed me to determine enough of the core gameplay rules and how they would be handled via player input to begin prototyping. This rules list also allowed me to design environmental reactions such as sound effects, visual effects, and several metrics for game values. Aside from this, I established several colour palettes based on my brainstorming which allowed me to finalise my vision for the visual experience of the game.

    I didn’t spend too much time creating an extensive moodboard, as I already knew I wanted to focus on a highly expressive form using geometric abstraction. Instead, I focused on discovering how I could unify my vision for minimalism with cube geometry in a 3D environment.

    This was my first time using “Freytag’s Pyramid” for story structure. In the end I found that it wasn’t very different from the more common “Hero’s Journey” model, but was very useful for quickly putting together my main story beats.

    This rules list was the most useful method for me during my paper prototyping. In doing so, I was effectively able to play through the core gameplay loop in my head before moving forward. This also allowed me to solve some core design problems early on, such as how player input would be handled, and how I would treat failure and player death in gameplay levels.

    Design Solutions

  • The main design solution to unify my vision for geometric abstraction, minimalism, and brutalist architecture is the three sets of colours that the player can switch between linked to both world geometry and the player character themselves. With this, gameplay focus revolves around the immediate area of the player, pushing the player towards a flow state wherein they can focus entirely on the skillful execution of platforming gameplay. This also allows player input to inherently connect to the expressive forms of the environment while maintaining a minimalist visual experience.
  • The second design solution is how the aforementioned player flow state could be challenged during regular gameplay. I solved this through designing several obstacles and hazards inherently linked to player input and the core gameplay loop through the switched colour sets to promote an ebb and flow of progression within levels, wherein the player is challenged in their skillful application of platforming gameplay without directly halting locomotion. These hazards are realised in the form of turrets that can track the player and shoot slow moving projectiles that produce an outward spherical force to push players away and off of platforms, as well as turrets that emit a straight line of flames to kill the player. Flame turrets can be stationary or rotating at a fixed speed. Obstacles were realised in two new cube block variants, purple blocks that sink downward when stepped upon and yellow blocks that rise upwards when stepped upon.
  • The final solution was designing an intrinsic motivation for players to complete levels as skillfully as possible, outside of just completing a level to progress the story. This was realised in the form of level specific meta challenges as both numerical points based collectables and a counter tracking level completion time. Neither of these statistics have in-game rewards connected to them, I wanted to promote players to seek achieving a higher maximum score or fastest completion time for their own satisfaction and bragging rights rather than to chase a cosmetic reward. I chose to use a timer that counts level completion time upwards, rather than a countdown timer, so that players are incentivised to try new platforming techniques or methods to get around obstacles faster. There is no par completion time for levels, as I understand that some players will find ways to complete levels faster than designed anyways. Having a timer that counts the fastest level completion time upwards allows groups of players to set the par standard for themselves. There is however a maximum score per level based on the number of collectables placed, I designed this system so that it’s not always possible to achieve the highest points score and fastest completion time in the same run of a level to promote greater replayability.

    • Programming and Scripting

    The Dreams game engine utilises visual scripting and node based logic to achieve the majority of its programming functionality with a strong focus on inputs and outputs bound by “wires” to represent communication paths. It supports common boolean operators, if-else statements, keyframes that can act as function returns, timelines that can be used for scripted sequences, gadgets that act as function libraries, and more.

    These “gadgets” contain the majority of the game logic, including variables for managing the core gameplay loop and overall game progression. Local variables track level progression and the colour switching mechanic, which are overwritten on level restart, exit, or completion. Global variables track game progression from level completions, and update both the highest score and fastest times achieved per level individually.

    Score variables of the same type are added together when all five levels in a region of the HUB world have been completed for the total region scores. (i.e, Your high score from levels 1-5 is added together, and shown in the HUB world as your Region 1 High Score. The same is true for your fastest level completion times.)

    These variables, selectors, and if statements control the functionality of the switching mechanic. When player input is detected, variable values are modified respective to each colour switching set allowing keyframes to be activated and deactivated in a highly performant manner for the Dreams engine.

    I included a randomiser that runs one time at level start for each colour set, ensuring that the starting composition of selected colours is always randomised.

    Turret logic is very straightforward. There is a spherical collision zone around each turret that checks for player collision. When detected, the turret will rotate on its horizontal axis to face the player and begin emitting projectiles in that direction. Each projectile has a sphere around it emitting an outward force to push the player away from and off of platforms.

    Flame turrets have a box collision zone that will put the player in a death state when collided with, and a single rotator that can be enabled or disabled as well as set to rotate on any specific axis.

    Colour Switching

    The player has access to three sets of colours that can be switched between. One set (black and white) controls the colour of the player character itself and allows the player to collect collectables of that corresponding colour. The other two sets (red and blue, green and orange) relate to world geometry and hazards of the same corresponding colours, effectively creating a “two worlds” mechanic.

    When the player swaps between sets, one of the colours is hidden with only a dotted outline of the geometry visible creating the basis for the core gameplay loop wherein the player must utilise quick reflexes and spatial recognition to successfully platform through the levels of the game while avoiding surrounding hazards.

    This logic was incredibly easy to script and test in the Dreams engine by using a variable and keyframe to track the players switching input for each colour. When the correct player input is detected through the controller actor, one of the variables in a colour set is set to 0 while the other is set to 1. Using an if statement, the variable is checked which then activates and deactivates the relevant keyframes which control visibility and collision.

    It was very important to have strictly enforceable metrics to stay aligned with the project goal of ensuring highly accurate platforming gameplay with clear collision on world geometry. These metrics are displayed using the “ruler” tool within the Dreams engine.

    Metrics

    The two key metrics of CUBOID are that of the cubes, and the player itself. Each cube is exactly 2m cubed, the character is slightly shorter than half of a cube at about 0.85m in height. These metrics combined with utilising a grid snap feature in the Dreams engine allow for levels to be quickly composed and tested. Based on the characters jump and double jump height, I was able to establish the minimum and maximum spacings for platforming gameplay with relative ease.

    This is demonstrated clearly in level 1 of the game, where spacing between platforms is slightly lower than the maximum allowable distance to teach players the metrics of platforming gameplay through an approachable and low difficulty experience.

    Level 1 - Colour Switching Demo

    To ensure accuracy throughout all platforming gameplay from the isometric camera angle, I have the global light source in the world tracked to be directly above the players current position at all times. This results in the character's shadow always being directly underneath them, giving players a visual identifier for their approximate location which allows them to easily reposition themselves in midair before landing on a platform.

    Hazards and Obstacles

    To establish an ebb and flow within the core gameplay loop of platforming while switching colour sets, I built several obstacles and hazards. The differentiating factor between the two being the level of resistance they produce for the player in terms of level completion. Obstacles take the form of sinking and rising platforms that are outside of the players controllable colour sets so that players must engage with them.

    Hazards can directly impede the player resulting in character death and level failure and take the form of turrets that track the players position and flame hazards that can be stationary or rotating. All hazards are connected to the player's colour switching sets.

    Rising and sinking cube obstacles simply check for player collision before linearly interpolating between two points. Turret hazards track the players position and emit projectiles that themselves emit a spherical outward force to push players away from and off of geometry. Flame hazards also check for player collision in a box volume sized around the flame particle effect, and will instantly kill the player. Flame hazards can rotate at a fixed speed and on any axis.

    Technical Challenges

    The majority of the technical challenges that I faced during development revolve around the limitations of the Dreams engine itself. Despite being an incredibly robust and accessible engine, some technical burdens take a significant deal of effort to overcome through optimisation and limited both the scope and creative freedom I was able to pursue.

    The first challenge is that there is a hard limit of twenty levels that can be included in a singular package within the engine, which forced me to compromise on scope early on. This resulted in the decision to have only twenty levels in the game that each take three to five minutes to complete, when I had originally intended to support hundreds of levels in varying lengths and sizes.

    The second major challenge was overcoming the performance limitations imposed per 3D space / level in the engine. In total, the logical costs of the game are incredibly low because I used a single variable and keyframe for each switched colour, and the rest of the gameplay logic is controlled through standard boolean operators and variables which are also very low cost. By duplicating geometry such as all cubes which are derived from the same simple mesh and combining them with painted outlines when invisible, rendering costs and draw calls were significantly reduced. However this was not enough to build levels to the scale and complexity that I desired. In the end this wound up being the real limiting factor, I could only place around one thousand cubes in a level before hitting a rendering bottleneck that the engine could not reconcile.

    The final major technical challenge that I faced was that the Dreams engine is effectively both a game engine and social network with a shared but closed asset economy for all users. This means that users can easily share assets between each other, with included support for asymmetrical multiplayer leaderboards. However, it also means that no assets, projects, games, or other materials can be directly exported or packaged from within the engine itself into an executable file. This significantly reduced my ability to conduct playtesting, and effectively eliminated the concept of ever releasing the project as a commercial title.

    Production and Development

    The majority of prototype production took place over the course of roughly three weeks, including completing all of aforementioned programming and scripting.

    I began by building the base cube shapes for platforming geometry, as well as the spherical turrets and collectables. I focused on establishing forms for the visual style as well as getting all of the colour set switching mechanics implemented, with no other game functionality built other than the player character being able to walk around and double jump.

    I moved on to building the functionality of the turrets to be able to track the players position and fire projectiles, as well as the flame turrets to be able to kill the player when collided with. This required adding some additional logic to handle the failure state within levels, so I wound up building systems to reset the level on player death as well as to detect when the player fell too far below the level geometry to also result in level failure.

    The next step was to build the remaining functionality for level progression including transitioning between levels, handling the success state, tracking variables such as score and completion time, restricting player movement to the starting block until the start countdown has completed, and building a level intro cutscene sequence. I decided to add in a layer of abstraction to unlock the final exit so that players can’t just skip past all of the level content, this took the form of five gems that must be collected before the level exit can be activated.

    Finally, I consolidated all of the aforementioned systems into a singular level building kit. This kit contains all of the core game logic, variables, geometry, hazards and obstacles, music and sound effects, cutscene scripts, and level progression systems combined into a fairly performant and modular system. I established a pipeline for myself to begin building all of the game content levels and HUB world using this kit.

    Blockout

    To begin to understand interesting level design patterns to challenge players with, I blocked out two test levels in the same environment, one linear and one with nonlinear but symmetrical segments. I also experimented with having slanted geometry for the player to slide down to see how I could also challenge quick reaction times within the core gameplay loop. These blockouts were very quick and easy to develop with elements from the level building kit I established by simply duplicating the base cubes over and over again.

    I created an annotated map from these blockouts to further identify several level design patterns that could be explored to a higher degree of fidelity. From this I was able to establish some of the core patterns that I used in my final iterations of the game, as well as how I could incorporate more puzzle solving elements into levels through spatial awareness of multicoloured chunks of cubes that require players to discern the only correct path forward via the colour switching mechanic.

    Iterations

    Large chunks of the level design feature neutral cubes (black and white), that are not affected by the colour changing mechanic. I did this to give players plenty of breathing room to start with, and to give them time to understand switching between one set of colours for platforming in a very clear context.

    My first major iteration was completing the first level of the game, which also functions as the tutorial level. I like to create tutorials for my games first, as the process often allows me to understand how I will communicate design concepts to players more quickly and I can already begin to establish how I will combine base mechanics into more complicated contexts for later levels.

  • This first level is quite short and entirely linear, taking about a minute to complete if you can platform through it without making any mistakes.
  • The difficulty of this level is incredibly low, and it only features two out of the three available colour switching sets to use so as not to overwhelm the player early on.

    • The next major iteration for the game was extrapolating the game and level design patterns I established in both my blockout levels as well as the first level from the previous iteration into a more complicated context. To do this I created a level to fit in at about the halfway point of the story progression, with a much higher degree of difficulty and level length.

  • This level is semi-linear, with two branching segments at different intervals that both reconnect with the critical path. The first branching segment is clearly visible but has a high risk-reward tied to it. The second one is off the beaten path and slightly hidden, but is a shortcut to ascend the fortified tower and contains quite a few extra points collectables for the keen eyed.
  • I planned to have all structures continuing downward further which would extend outside of the player's frame of reference. This would avoid a “floating island” visual sense, but I began to hit the upper limits of the allowable rendering costs for the scene in the engine and had to trim down the level geometry to accommodate greater performance.

    • I wanted to explore a theme for this level of an abstracted medieval Western European castle, having the player start by dropping onto a dirt road in the surrounding land and progressing to the heart of the castle. I focused only on the most significant motifs typically associated with those structures, which revolve around defensive functionality. These wound up being moats, drawbridges, walls, fortified towers, and a central keep which is the level end point.

    Design Philosophy

    My design philosophy with any game that I create is to focus on adding as much value as possible for the target audience. Within this, I focused on adding the greatest potential value for both platforming genre enthusiasts and speedrunners.

    Laddered Diegetic Game Design

    The primary philosophy I implemented was establishing a laddered approach to teaching game mechanics to players through diegetic elements in levels. Instead of providing detailed descriptions of functionality, I established clear contexts to teach players game mechanics one at a time.

    This allows players to learn mechanics the first time in a simple context, and then apply those mechanics in more complicated contexts later on without needing additional instructions. This is also the fundamental basis of puzzle design in games.

    This technique was directly inspired directly from Super Mario Bros (1985), Level 1-1, where Shigeru Miyamoto expertly crafted the level to teach players the majority of the games platforming mechanics as well as Mario’s abilities which are then applied in more complex contexts in later levels.

    The level begins by introducing points collectables via the players switched colour sets, as well as the collectable gems required to unlock the end zone. This is followed by low risk platforming requiring the player to switch colours, as well as switch camera angles for the first time. After this, a small sliding segment with no other interactions is present to demonstrate the character's locomotion behaviour when walking on slanted surfaces, followed by a low risk platforming segment requiring mid-air colour switching to an elevated platform.

    The final segment of the level requires players to consistently jump between increasingly elevated platforms while switching both geometry and player colour sets to progress to the end zone and collect points collectables at the same time.

    Some of the other techniques used here include:

  • Vistas are established in the introductory cutscene, to give the player a preview of the most significant level elements before they encounter them and create tension.
  • Leading lines from expressive cube forms guide the player to the end zone without additional instruction or guidance.
  • Replayability supported by player agency from level objectives via the minor branching path at the level start. Players must choose between setting a faster completion time or higher points score in their run. Attaining the highest points score requires minimal backtracking on that branched path, not enough to cause frustration, but enough so that both objectives cannot be completed in one level playthrough.

    • Accessibility In Game Flow

    Something that’s always been a pain point for me in games is when accessibility isn’t layered directly into general game flow, especially in games where objectives will inherently require players to engage with levels or challenges repeatedly to pursue high scores or completion times. After a certain point, a player will be able to recognise that they have made a mistake and won’t be able to set a new high score, and need a way to quickly reset their gameplay environment in as few interactions as possible.

    To accommodate this, I built two reset methods into the player controller to ensure that players can always reset levels or attempt others quickly without needing to navigate through unneeded user interfaces. Holding right on the directional pad for three seconds immediately resets the current level, and holding left will return the player to the HUB world. This ensures that these resets are accessible without being accidentally triggered during regular gameplay.

    Aside from this, I created a set of analytics that track the most significant metrics of the overall game design. These analytics are shown in the HUB world and are not inherently tied to rewards in any way. The objective of these metrics is to add greater value to the players game experience, and translate the qualitative experience of player effort into a quantitative metric showcasing the merit of their efforts in a clear and digestible format.

    I designed the controls scheme to be as accessible as possible and support the core gameplay mechanic of colour switching through the most commonly used controller face buttons. Some additional accessibility options I included are the ability to hide HUD elements for a more immersive experience, as well as the option to switch the currently playing song within the ten tracks included in the game.

    As difficulty in games is a qualitative element, it can be challenging to precisely define how it will be implemented. There are of course commonly used practices such as increasing enemy statistics and lowering player statistics, however this often fails to fully convince players of the value of the added difficulty. I opted to instead pursue a more diegetic approach, and layer added difficulty directly into level design patterns and a greater demand of the skillful execution of the core game mechanic from players.

    Higher levels of difficulty are realized in an increase in more extreme and exotic level themes, a greater number of level obstacles and hazards, more challenging platforming segments, more moving world geometry, and an overall faster pace of gameplay being required for the player to perform.

    Difficulty Curve

    My approach with game difficulty is to avoid creating a “frustration factor” as much as possible. I want to challenge players incrementally, and avoid having inconsistent and large gaps in difficulty between levels located closely to each other in game progression. Because I chose to pursue twenty levels in the game split between five regions, I had to make a choice between distributing difficulty in a range locally within each region or to distribute it globally across all levels. I found local distribution to be less consistent, and opted for a global distribution instead.

    Game difficulty increases over time, leveling out in some areas and climbing more drastically in others. Difficulty is represented in an approximate scale of 1 being the easiest level of difficulty present in the game, and 10 being the highest level of difficulty present in the game. In each level the player only has a single life, and should they fall from a platform or die from hazards, they will be returned to the level start with all level elements reset.

    Testing

    Methodology

    I utilised the method of creating user task scenarios based on general gameplay goals for testers to pursue, and formulated these into a testing plan document that I reused over the course of multiple in-person testing sessions. This allowed me to quickly adapt areas of the game that I wanted to evaluate into an actionable test plan that could easily be scaled up as more content was added.

    Results

    Testers responded very positively to the core game mechanic of colour switching, and enjoyed the feelings of excitement and tension that the flow of platforming gameplay established which verified the first two internal goals I set for the project.

    In comparison to this, testers did not feel inclined to pursue full completionism of a level and immediately replay a level to set a higher score, but would rather continue the game and play future levels before returning. This indicates that greater value should be added to some of the meta progression systems to further incentivise players towards higher engagement levels and meet the intention of the third internal goal, while not compromising the desire to engage with the story and narrative progression.

    I created three alternate colour sets for all of the world geometry and asked testers which one they would prefer the most. To my surprise, most testers appreciated all four colour sets and wanted the option to be able to switch between them. This leads to a possible solution towards adding greater value to completionism and meta game progression via being able to unlock alternate colour sets as a purely cosmetic reward.

    Testers also indicated that the tracked player analytics were nice to have but were not very motivating to pursue reaching higher values for outside of what would be achieved in a standard game playthrough. I wanted to avoid incorporating rewards into the analytics system so players wouldn’t feel compelled to fudge the numbers through pressing buttons repeatedly and advancing in ranks, however there should be a greater reward or motivation added to the system to encourage players to engage with it in the first place. A possible solution to this is to unlock new colour sets via a new analytic of overall game completion which is tracked from level progress, or from completing each level region for the first time.

    I like to create a well documented testing plan for any game that I create in order to evaluate it in a repeatable and verifiable methodology. I focus on creating simple to execute task scenarios that don’t take players too long to complete to maintain a good flow during sessions, and so as to not exhaust my testers. I typically follow this up with a feedback form, or I incorporate the “Think Aloud” method during testing and actively take feedback notes.

    The tenth game level wound up being too difficult for quite a few playtesters to complete, and did create a frustration point near the start of the level where there are many repeated flame hazards in a small area. This indicated that levels should have difficult segments spaced out a bit more, and that I shouldn’t overwhelm players with a highly difficult platforming pattern too early in the level so that players can feel like they are making more level progress before being confronted with a potentially significant challenge.

    Post-Mortem

    What Would I Do Differently Today?

    Overall, I’m very happy with how the core game mechanic of the colour switching system turned out. It led to a very comfortable pace while performing platforming gameplay, and when combined with both points based high score and fastest completion time level objectives established a fun core gameplay loop for players to engage with per game level.

    Despite this, I feel that the overall game concept is not different enough from other platformers being released today. The colour switching mechanic wound up being quite similar to a “Two Worlds” mechanic, and I was originally aiming for it to be much more unique than that. If I were to approach this again today, I’d spend much more time prototyping different cube, obstacle, and hazard variants to add more depth to the core gameplay loop while enhancing the colour switching mechanic. This would also give me a ton of creative freedom to build new level patterns and add more diversity to the game.

    In terms of visual style, I feel that I was able to establish a sense of minimalism quite well via the expressive cube forms but fell short on showcasing the brutalist architecture that I was inspired by. I would spend more time adding elements to the background space that is otherwise an empty void to establish this today.

    The largest aspect of my original design that I didn’t incorporate was the narrative that I wrote using the “Freytag's Pyramid” method, as I didn’t have enough time to create all of the animated cutscenes I envisioned. If I were to do this again today, I’d spend much more time building a scalable framework for animated cutscenes while prototyping so that I could at least establish a minimum viable version of the story early on in production.

    Within my approach to level design, if I were to create this project again today I would spend more time establishing my method for laddered and diegetic design to teach gameplay principles within game levels. The levels themselves wound up being too short in my opinion as well, with level one taking an average of about a minute to complete for most players and level ten lasting about three minutes on average. To remedy this, I would either re-scope the individual levels to be much larger or choose to re-scope the overall game progression to accommodate hundreds of levels at the existing average completion times.

    I also never really figured out how 3D puzzle solving would work with the colour switching mechanic, so I would spend much more time prototyping that concept and establishing some interesting level patterns to use in conjunction with new cube variants for players to platform on.

    Based on testing feedback, I would enhance the meta game progression linked to the player analytics system by integrating more relevant analytics such as a percentage of game completion. A good intrinsic motivation for engaging with this system would be layering in cosmetic rewards such as additional colour sets that could be applied while in the HUB world.

    In the end, I’m satisfied with what I created in the relatively short time frame I had and at the height of Covid-19 pandemic. Despite the overall small scope of the game, it wound up being quite fun to play and I think it’s a good basis for a future project to be built from.

    Learning Lessons

  • Spend more time prototyping my core game mechanic to make it truly unique and act as an instant attention grabber to new audiences. Do more market research into comparable games in the same genre to ensure I’m not repeating established designs without a unique twist.
  • Playtest earlier and much more often with my core target audience. This will allow me to solve design challenges earlier in my process, and pivot towards a solution while remaining in the project's scope.
  • Research the game engine I will use as a part of my pre-production process to ensure that the engine will meet the scope and goals of the project. The Dreams engine proved to be one of the largest technical challenges to overcome, and I am using Unreal Engine 5 from this point onwards for all future projects.

    • Major Accomplishments

  • I was able to create a fun game prototype in a relatively short time frame of roughly one month of pre-production and documentation, and two to three months of production, development, and testing. I can rebuild the game in Unreal Engine 5 fairly easily with the current game as a very strong foundation to start from.
  • I significantly refined my development process and level design skills, and I was able to successfully challenge myself to create interesting level design patterns using fundamental geometry which was one of my primary external goals.
  • I became much more comfortable with visual scripting programming, utilising boolean operators, object oriented programming, and working with variables to abstract game data into scalable systems. Aside from this, I became much more confident in my ability to break down a game concept into pseudo code, and then build up that functionality through visual scripting software.

    • I hope you enjoyed reading through this design and development breakdown of CUBOID. If you have any questions or comments about the project please feel free to reach out to me, I’d love to hear what you think about it!

    Walkthrough Video

    Circa - August 28th, 2021

    ×