A fast-paced on-rail shooter built on Zap!, a custom engine compatible with PS5 and supported by AngelScript.
17 Developers
8 Weeks
Zap
(custom engine)
17 Developers
Level Design
Established the target player experience to design for and a set of design pillars as guidance for the process.
Picked up a custom engine and learnt to use its tools to implement gameplay beats, events and level ingredients.
Contributed to smoothen in-engine pipelines to improve implementation and iteration time.
Iterated based on data from playtesting sessions and online feedback.
Helped the team organize its Agile processes by setting up sprint goals and organizing systematic build reviews.
I contributed to the project as a Level Designer. I set up design goals to achieve a coherent gameplay experience alongside my peers, merging the team's effort towards the final result over a tight timeline in a freshly made custom engine.
Role and Tasks
Experience and Design Pillars
Hectic Action - Players fight, move constantly and dodge enemy projectiles and obstacles in intense, high-adrenaline moment-to-moment gameplay
Experience
Enemy attacks, their movement patterns and the environment stimulate players to constantly move on the screen.
Constant Movement
Pick-ups and the possibility to damage enemies require players to quickly evaluate when to expose themselves to risk or not.
Risk and Reward
LD and encounters test players’ hand-eye coordination frequently by generating short Action-Feedback gameplay loops.
Fast Pace
Design Pillars
The four-step level design process of Kishōtenketsu was used to scaffold the learning of the 3Cs and mechanics through playtime and achieve a balanced progression and experience throughout the various combat beats.
Design Intent
Each section of the level was given a player-centered user story to guide the design process.
Ki Section
Sho Section
Ten Section
Ketsu Section
As a player, I want to learn how to use the controls, so that I can move and fight without making unintentional mistakes.
As a player, I want to dodge hazards and enemy projectiles, so that I can fight and catch pick-ups without taking too many hits.
As a player, I want to use the lock-on while moving, so that I can shoot at enemies while avoiding moving hazards and attacks.
As a player, I want learn the boss attacks and react to them while attacking, so that I can defeat it while avoiding getting killed.
Research and Concepting
A sequence of interesting events
On-rail shooters are known for offering carefully curated experiences through full control over their own pacing, would force me to think of the level as a timeline of beats instead of an 3D gamespace.
I researched to understand how often action-feedback loops take place in these games, how much time players have to gain situational awareness and the impact these two factors have over the player experience.
Putting it all on paper
This knowledge impacted my approach to concepting and sketching, as I adapted to this kind of project by thinking of gameplay beats as sequences of scripted moments.
I sketched them sequentially similarly to storyboards, treating the gamespace as a corridor subdivided over time.
Getting into a new Engine
Delving into unexplored territory…
... and charting a course
The move to a new engine stimulated me to jump in it as soon as possible to learn how to produce content in the few weeks available.
This led me to experiment with the constantly-evolving 3Cs and systems, bringing me to find alternative approaches to prototyping to answer questions with what was currently available in-engine.
These experiments made me quickly pick up the engine's workflows, leading me to cooperate with programmers and technical designers to smoothen up pipelines based on the use cases that emerged to speed up implementation and iteration times.
I implemented level ingredients by using the engine's prefab system and its timeline tool.
A tool to keep track of player metrics and boundaries, built by communicating with a technical designer.
A frame is spawned every player movement's speed/second.
The event manager was made able to handle multiple splines to speed up iteration times. Its first version hosted all logic triggers on a single timeline, making iteration time slow.
Level Ingredients
I created two mechanics to support the experience and design pillars by shaking up the moment-to-moment gameplay, focusing on testing players' hand-eye coordination and baiting them into
risk-and-reward situations through pick-up placement.
VFXs were implemented alongside artists to give players a feedforward over the incoming danger and make them pop out from the rest of the environment.
A hazard easily visible from afar to give players time to properly frame the upcoming challenge.
Falling Tree
A hard-to-spot hazard with a faster animation that forces players to pay attention on a short timeframe.
Emerging Spikes
Playtesting and Iteration
To face the challenge of achieving the intended player experience and design goals while working in a completely new engine on a tight deadline, two types of testing were set up for specific purposes:
Data from internal Build Reviews was used to move each level section from Functional to Playable
Structured playtests held with players familiar with the genre to verify whether the Playable state was reached and ensuring that the intended player experience emerged from the game
Testing showed that the first block-out couldn't generate as much moment-to-moment action as expected due to the simplicity of the combat beats and how sparse obstacles were, giving way to iterations to solve these issues guided by playtesting feedback, the design pillars and research findings.
Iterating effectively
Before
This final section before the boss-fight was too hard for players, who often died due to the extremely tight timing between obstacles and poor readability of their configuration.
After
• Moving hazards were spread over space to grant enough time to read the game state and give players a chance to dodge them.
• The location of obstacles was rearranged to create a clear contrast between them and non-obstructed spaces
Ten Section - End
Before
Players could keep moving forward for several seconds without adjusting their position on screen, while encounters took little effort to be beaten.
This behavior went against the intended player experience and the design pillars set to achieve it.
After
• Obstacles were added and repositioned to stimulate players to move constantly and break their lines-of-sight with upcoming hazards, preventing them from seeing upcoming challenges too early to maintain the moment-to-moment hecticness
• Additional enemies were placed in-between the initial ones to "layer" encounters across playtime to raise intensity organically and reduce downtime between each encounter
Sho section - 2nd part
Before
This beat originally aimed to safely onboard players to one of the level ingredients (falling trees). The lack of any challenge beforehand and the ample space to dodge, however, failed to make players register it as a threat they needed to pay attention to.
This first draft also undercut the intensity of the whole Sho section by lowering its pace right before its end.
After
Obstacles were added to both keep players moving and break lines of sight to the falling tree, turning it into a surprise they need to react to.
An encounter timed to end just before the new hazard was added to reinforce this by monopolizing their attention right before its appearance.
An arch was put above the hazard to force players to engage with it, preventing them from just moving upwards to dodge it.
Sho section - 4th part
All the rest
To help the team meet its milestones, we all wore multiple hats beyond our assigned roles and worked to improve our AGILE processes.
I set up user stories sprint-by-sprint and organized daily build reviews to favor team alignment and focus our effort towards the intended player experience.
The team set up a robust QA pipeline, and I held several daily functionality tests to ensure the health of the build and be able to hold playtests as often as possible.
Takeaways
Developing Petrified forced me to step beyond my comfort zone on several aspects, turning me into a more adaptable developer and proactive team player by getting me in contact with differing aspects of the development process.
Having to quickly pick up a new tool led me in-engine sooner than in previous projects, making me faster at learning new tech and validating ideas sooner. The necessity to ship under duress made interdisciplinary communication crucial, as we relied on sharing knowledge to ship and improve our processes.
The effort put into facilitating team alignment, too, paid off: having a clearly defined player experience facilitated our process and clearly informed our sprint goals and priorities, culminating into build review "rituals" where the team became the first source of meaningful feedback for each member's individual work.
However, a core lesson learnt by being closer to these many aspect of development was the importance of caring for a project beyond your assigned role: had I taken a more holistic overview, I'd have noticed how one of the design pillars (risk-reward) wasn't fully achieved due to a lack of short-term rewards relevant for moment-to-moment gameplay, which are common in this genre.
Still, working on this project has been a blast, and seeing our game enjoyed by the players it found and running on a Playstation devkit was incredibly satisfying.
duccio.carnicelli999@gmail.com
