Gameplay Demo - Current State of the Project (March 2025)
The Sporadic Puzzles
Solo, University Final Year Project
5 months (In progress)
-
Extensive Research
Concept Development
In-Engine Implementation
Playtesting and Iteration
Documentation (learn more about these in the design process below!):
Want to try yourself? Download the latest build here!
(work-in-progress | Expected delivery: June 2025)
Project Pitch
AAA Action-Adventure games often offer puzzle minigames.
They can help to break the pace and bring some variety to the player experience.
However, these are sometimes considered tedious by both action fans and puzzle fans alike.
Too often, the necessity of being quick comes at the price of being trivial.
Can a puzzle minigame for AAA Action-adventure games be fun for both action and puzzle fans?
As production progresses, the development blog below is being updated, to cover subjects such as initial research, concept, implementation, cohesion & identity, visual development etc.
The same puzzle, from concept…
… to prototype …
… to the current version!
Alternatively, you can also download the 50-page slide-deck development report (Feb. 2025), originally produced for project supervisors, featuring a more comprehensive overview of the project:
The Sporadic Puzzles
DEVELOPMENT BLOG
PART 1: INITIAL RESEARCH
In the first two weeks, I set out to:
define puzzles, minigames and obtain vocabulary for comparison and analysis
analyze the purpose of a minigame inside of a bigger project
study puzzle types appropriate to the specific context
compare dedicated puzzle games and puzzle minigames on a number of parameters such as length, challenge, noise etc.
From these findings, I was able to set out a number of project parameters that, if met, would theoretically provide a successful project.
Project Parameters
-
Puzzles will have 1+ optional challenge on the side of the screen.
Completing these challenges will get the player more rewards.
-
The main puzzle aims to be solved in approx. 1 min.
The same puzzle with optional challenge aims to be solved in approx. 3 min.
-
Main puzzle should require some limited effort from the player. It is quickly rewarded.
Optional challenge forces the player to be more intentional in their puzzle solving and forces the player to use the mechanic in a novel way
The player can choose themselves the level of challenge for each level by partaking on optional challenges or not.
-
The puzzle should be grounded in the game world and not feel fully separated from the main gameplay. It will be instanced but it should be elegantly transitioned from main gameplay. Option to use the world as background for puzzle.
If visual noise is added, it should not detract from the puzzle or make it harder to read in any way
Distance between different elements should be kept to a minimum in order to limit the realm of possibilities.
The number of puzzle pieces should be of (or very close to) the necessary number to solve the main puzzle.
-
Instructions will be given in a sentence: a few words must be enough to explain the puzzle goal. Icons and Pictograms can be used to reinforce communication.
Both failure and success must be clearly communicated to the player with puzzle animation and eye-catching text.
Controls must be simple and always clearly present on screen.
Excerpts from the initial research paper (9000+ words)
PART 2: CONCEPT(s)
During these two weeks, I sought to develop a puzzle concept, fitting for the parameters previously established (see Initial Research). I ended up doing two different concepts (NEXUS & LightPath), and pitted them against each other.
In order to better judge of future potential, I:
detailed the original concept;
designed an example puzzle;
explored expansion possibilities;
went through a full round of iteration, looking to solve all the issues highlighted by the first puzzle;
iterated on the first puzzle to test the changes.
designed a new example puzzle.
All of these steps were fully documented for both concepts.
After completing this process, I evaluated both project on a number of aspects (i.e. difficulty, scalability) and picked the most fitting to the specific context of this project. I then went through project parameters established in the initial research again one by one, checking if any conflicts could be found.
This process was documented here:
Result: NEXUS is brought forward.
NEXUS concept documentation
Concept Extras
Since I have been working with pen and paper to test puzzles, I also filmed a little demo for my supervisor. It was off the cuff and so a little bit rambly, but it might give an insight into the design process:
Curious about LightPath, the concept left behind?
Download the full concept documentation here:
PART 3: IMPLEMENTATION - Gameplay Loop
Project Needs
NEXUS presented a number of specific needs:
The player can select different rings and rotate them.
Rings can only stop at specific angles (8-directional).
They can drop objects from the outside in, and these need to get as close to the centre as possible when dropped.
Objects and lasers are not directly controlled by the player but need instead to find their own way inside the puzzle.
Object and lasers can only stop at specific points inside of the puzzle.
Objects, once set in position, will need to attach to the ring they are on.
Objects will affect other objects (i.e. blocking the path) and lasers (i.e. making it turn).
The optional challenges (a key project parameter for this project) will require to keep track of every object used.
Splines
It was apparent that the solution to a lot of these needs was using splines.
Every path a block or laser can take would be a spline.
Every position where an event could happen (e.g. stopping or turning) would be a spline point.
Since rings can turn, and by extension the configuration of a radius line can change, each radius could not be composed of just one spline, but three: one for the outer ring, one for the inner ring, one for transitioning between the two.
In total, each puzzle is composed of 30 splines:
10 on the outer ring (8 radius + 2 circumference);
8 for the transitions between outer and inner rings;
10 on the inner ring (8 radius + 2 circumference);
1 for the “drop zone” (outside of the puzzle);
1 for the centre.
Data Tables
Each spline point is referenced with a code, which can be found in each puzzle’s data table.
The first four columns do not require any modification, as they are used by the system to retrieve information about a specific spline or spline point. They correspond to (left to right):
The spline point code (SplineName_PointNumber)
The spline name
The spline number
The point number
The last two columns need to be manually set for each puzzle, and they set the starting state of the puzzle:
The 4th column manages the block behaviour.
The 5th column manages laser behaviour.
Since data tables are read-only, the data is fed into a struct array, which will allow for modifications at runtime.
Implemented Gameplay Loop
In time for the mid-point review (End of October 2024), and on schedule, we were able to implement a complete gameplay loop, with the following features:
Rings and objects automatically align with possible target splines.
Objects travel through the puzzle, respond to then modify puzzle configuration.
Lasers find their way inside the puzzle and respond to configuration changes.
Puzzle have specific main and side objectives, tracked by the system.
Transition from player-character to puzzle mode.
Rudimentary UI for objectives and success/failure feedback.
PART 4: IMPLEMENTATION - Controls
Controls: Prototype Issues
Up to this point, controls had only been functional, allowing for self-testing of the systems. With the circular design, controls became unexpectedly challenging to design for. For example:
Selecting Rings
Situation: the outer ring is selected; player wants to select the inner ring.
Expected behaviour:
If they are looking at (A): Push Right button
If they are looking at (B): Push Left button
If the 3 rings system (outer, inner, drop), this doesn’t work!
Rotating Rings
Situation: Player wants to rotate the outer ring so (A) or (B) is aligned with X
Expected behaviour:
If they are looking at (A): Push Down button
If they are looking at (B): Push Down button
If the ring movement being built on a clockwise, counterclockwise system, this doesn’t work!
A circular, spline-based design can bring a level of complexity to the controls. Since these must stay intuitive for the player, that complexity, while still present, should be hidden from them as much as possible.
For example, the diagram below represents the 8 positions where the module indicator can stop. This is, in fact, a spline (growing numbers indicating direction). But for the player, for instance moving from (3) to (2), it would be natural to press down. Alternatively, it would be natural to also press down to go from (6) to (7)… even though these are opposite directions on the spline! The solution was to customize controls for each position, to respect expected behaviour in a completely unintrusive way:
PART 5: VISUAL IDENTITY
If NEXUS had been created as a minigame for a specific title, the visual identity would have been greatly influenced by said title. But since this title does not exist, we had more freedom on the matter.
With the player looking to break into a safe, but also with puzzle part being quite bulky (and so not very modern), we started to look at antique bank safes, which would often feature dark background, and rich, golden accent colours. They also usually featured ornate frames and fonts.
These elements could be then brought into the puzzle itself and the user interface, for a cohesive and immersive experience.
The result of visual concept and UI research all came together. It allows NEXUS to look and feel more cohesive, and more importantly, a lot less abstract than at the prototype stage.
PART 6: USER TESTING
In progress
PART 7: FURTHER PUZZLE DESIGN
In progress