Executive summary:
Zentera was a student group project game based on a custom engine the programming students had written the prior block.
Our job as designers was to build a game on top of this engine showcasing its strengths.
Design process
Concepting,
I played an integral role as designer in the concepting phase of our project.
This revolved around finding feasible design ideas that play into the strengths of the custom tech our programmers made, meaning small levels that displayed the voxel rendering in an appealing manner.
We ended up unanimously deciding on a puzzle game with platformer like elements taking heavy inspiration from the captain Toad games made by Nintendo.
Within the first few days of our project we finished our game concept with considerations made to the custom tech and limited time and resources, a process that would normally have taken at least a week, thanks to my decisive input and that of our other designers and team members.
Concept sketch 1
Pictured here is one of the physical sketches made in the first week of our project meant to demonstrate the basic interactions of our player character.
The pushing and pulling both continued on to be essential elements of our puzzle design with grappling being scrapped later in the project as we leaned away from platformer elements in favor of a slower, methodical puzzling experience.
Concept sketch 2
Another early sketch during the concepting phase of the project depicting level objects such as a mirror, gate, poison mushroom, fly, pits, buttons and pushable crates.
These quick dirty sketches were often used to quickly convey ideas to the rest of the team.
During this stage of concepting things move so fast there was little use in refining the sketches, the elements were explained in person and the drawings merely served to help paint a picture in the head of other team mates.
These concept sketches were then refined into a feature spec that depicted the various “features” of our concept, to which I contributed the push and pull as well as the level feature spec.
It should be noted the feature specs were refined by our tech designer after they were established together with him.
Feature spec "diorama level"
Feature spec "Tongue mechanics"
Feature spec "push and pull"
Puzzle + level design,
In this project I took on the responsibility of a puzzle and level design at the same time as the two were integrally tied together for our concept.
I ended up making 2 of the 3 levels, those being the second and third level.
(note, because of our file structure the actual “in house” name of these levels was 1 and 2, with the first level being level 0, confusing I know)
Levels started out as puzzle sketches that showed enough promise to be tested and built out, usually revolving around a novel way to interact with the existing puzzle mechanics.
Emphasis was put on “gotcha” moments, achieved by giving the players a seemingly straightforward solution only for that solution to be false, making them retrace their steps and look at the puzzle from a different angle.
Level sketch
The final sketch made of the first level before being cleaned up into a one pager, these sketches weren’t annotated as they were only meant to be seen by me and the other 2 designers who were aware of what each depicted element meant.
It served its purpose to put my idea on paper and refine it down into something worth exploring.
These sketches were then translated into a one pager that would serve as the blueprint of the level, dictating what goes where and how the puzzle is supposed to be solved.
Initial one pager of level 2
A swiftly thrown together one pager of the second (confusingly named 1st) level supported by the level sketch and a 3D mockup I made in magicavoxel.
It lacked a guide and detailed breakdown of the level itself and as such it was improved upon for the sake of having clear documentation for our team.
Updated one pager of level 2
The updated version of level 2’s one pager, now including a top down representation of the level along with a legend to describe each element present.
This then served as a blueprint for the second level.
Once the one pager was in a complete enough state we began on the level blockouts, creating the voxel assets in a tool named “Magicavoxel”.
The assets were then assembled into a prototype level inside our custom engine for further testing and refining.
Adding the blockout in engine and placing the level elements.
I am using some examples from the 3rd level here as I didn’t have many saved of the second.
This in engine blockout was freshly imported and the puzzle elements were swiftly set up still lacking much of the functionality they are supposed to have.
Refining this initial implementation into something that can be tested.
Here the level start, finish, gates, pressure plates and the push/pull crates are properly implemented and ready for testing.
These early testbed blockouts helped me and every other team member better understand how the puzzle mechanics actually played out in practice, allowing us to tweak the puzzle, puzzle elements and 3Cs in accordance to our findings.
Art asset integration was up next, this being the stage where my role as lead designer became most obvious as I had to coordinate with the visual artists of our team to ensure their assets matched our designs.
Later this also involved coordinating with the programmers to iron out some unforeseen issues related to collision, this was perhaps the most involved step of the level design process.
Initial art asset integration
Here level 2 has its art assets partially integrated, during this stage we were encountering a lot of collision errors, misaligned assets and just all around weirdness.
A lot of the interactable puzzle elements haven’t gotten their model yet and issues that weren’t picked up earlier in the production cycle of the art assets come to light.
Completing art asset integration
After the initial “shock” wore off we got to work properly integrating all the assets and fixing the most readily apparent errors.
The level quickly starts to shape up to something resembling the intended end product, but before we move forward to polishing there are some technical issues that need addressing.
Namely the inconsistent, bumpy and just all around terrible collision the high fidelity voxel assets have.
Fixing collision with the programmers
We couldn’t afford our artists remaking their assets, nor did we want to compromise on the art style they spent so much time and effort on.
These issues stemmed mostly from the way collision was handled in our custom engine and together with the programmers I dove into the matter to find a solution that’d give us the best of both worlds (that being high fidelity art assets and smooth collision).
Me together with one of our engine programmers ended up separating the collision layer from the voxel assets completely and instead used the blockouts of our maps as a collision layer owing to their simplicity.
It was a clever way to reuse old assets and with the implementation we saw a notable improvement in gameplay during playtesting.
Last but not least was polishing, once most assets were implemented and the puzzle logic was working the process of smoothing out the kinks and crossing our Ts started, a process supported by our quality assurance process.
With each bug patched and oversight fixed our level approached a presentable state
Quality assurance,
I played a major role in the game’s quality assurance by performing playtests with the target audience using our development builds.
The observations I made during these playtests were instrumental in steering our game’s development and polishing, especially in regards to visual communication.
Aside from these playtests I was frequently involved in checking for technical issues and bugs.