CHOSEN
A retro First-Person Shooter
Tools
.png){kind=small}
Affiliation
Find me on:
Play now on
CHOSEN is a single-player First-Person Shooter with a weapon-stealing twist: players use hooks to steal weapons right out of enemies' hands. Use your hooks for movement and combat, grappling across the environment and stealing weapons. Experiment with and master a suite of weapons, and overcome challenging combat scenarios full of enemies with unique behaviours and mechanics. All packaged in an artstyle that emulates early-2000s era sci-fi shooters.
Award winner: LevelUp 2024 Runner-Up Best Overall Game & Runner-Up Best Technical Achievement.
Team: Team Schmeam
Abigail Norris
Carlo Tejeda
Chris Dichmann
Sam Cameron
Sarita Sou
Tiggi Pengelly
Team: Slommy Studios
Awards & Showcases
Level Up 2024
The team presented our final build of CHOSEN at the 2024 Toronto Level Up Showcase, where it was played by hundreds of attendees.
Out of over 150 student teams, we were proud to be awarded Runner-Up for both Best Overall Game and Best Technical Innovation!
The whole team gathered together at Level Up to present our game!
We gave our elevator pitch for CHOSEN hundreds of times, making sure to emphasize the game's gameplay hooks - pun intended!
The showcase was very busy, so we set up extra monitors so passersby could get a peek at gameplay.
The whole team gathered together at Level Up to present our game!
Game Design
Establishing Metrics
Early in the project, the team recognized the importance of establishing metrics in facilitating efficient and consistent development. I set out to establish and document the project's metrics for internal team reference.
Collaborating with team members from the Programming and Environment Art teams, we created firm Character Movement and Modular Kit metrics. The resulting metrics documents served as constant references for the team throughout the project.
Metrics Playground
To test the established metrics,
I built an in-engine Metrics Playground, which allowed the team to visualize our metrics, identify gaps in our Modular Kit, and test new mechanics in a practical game space.
A planning map of the Metrics Playground made to scale in Illustrator. Shows the metrics that each area of the Metrics Playground are meant to test.
A graybox version of the Metrics Playground made using untextured modular pieces.
The final version of the Metrics Playground, constructed using the Modular Kit made by our Environment Artist.
A planning map of the Metrics Playground made to scale in Illustrator. Shows the metrics that each area of the Metrics Playground are meant to test.
Core Mechanic Prototypes
The core mechanics of the game (Hooking and Weapon Stealing) underwent many changes throughout development. As a part of the iteration process, I created diagrams of various prototype versions of these mechanics. These diagrams used clear, technical language to communicate functionality to team members.
Diagram detailing the mechanics of throwing a Hook. Specifies Hook's mid-air behaviour.
Diagram detailing the mechanics of recalling a Hook. Shows the intended behaviour of the Hook when it hits a non-enemy object, or reaches the end of its chain.
Diagram detailing a system through which players could gain altitude through the weapon stealing system. While it allowed for some cool aerial moves, testing proved it to be too complex for players, and it was scrapped.
Diagram detailing the mechanics of throwing a Hook. Specifies Hook's mid-air behaviour.
Once the prototyped mechanics were implemented, the team hosted playtest sessions with members of the public. I created a Playtest Survey to record feedback, tracking player understanding of and reception to gameplay mechanics. After the playtests, I created a full playtest report to guide the team's development.
Weapon Profiles
As a First-Person Shooter, it was important for the game to have a diversity of interesting and fun-to-use weapons that filled specific roles in the combat sandbox. To facilitate rapid weapon prototyping, I created a Weapon Template document that could easily be filled out to track weapon behaviours.
Template for general team use: tracks a weapon's basic statistics, such as projectile type, damage per shot, rate of fire, range, and ammo type.
The Interceptor underwent the most change of any weapon during development. Remnants of the team's old design philosophy can still be seen in this document, such as classifying the Interceptor as a "Defensive" weapon - at one point, all weapons were planned to be either offensive or defensive.
The Chow-Chow Turret is a great example of the flexibility of the weapon system: the Chow-Chow started as a duplicate of the Hellfire, with the range and rate of fire stats dialed up. Add a ramp-up effect and a new model, and suddenly a whole new weapon has entered the sandbox.
Template for general team use: tracks a weapon's basic statistics, such as projectile type, damage per shot, rate of fire, range, and ammo type.
Collaborating with the Programming team, I broke down every measurable element of a weapon's firing behaviour into a simple statistic. These statistics matched directly with the weapon's adjustable variables in-engine, which allowed for rapid adjustments and immediate testing from any team member.
Enemy Behaviours
Complex enemies with varied behaviour were a critical component of CHOSEN's core gameplay loop. Early playtesting showed enemies needed to react and respond to player action to keep gameplay lively and avoid the emergence of dominant strategies.
I mapped out in-depth behaviour trees for each enemy in the game. Each diagram was intended to translate easily into pseudocode, so the Programming team could use them as a direct reference when implementing the enemy behaviour.
While very detailed, this style of documentation proved to be too dense to be utilized as an accessible reference. I overhauled the previous documentation by simplifying and streamlining enemy behaviours, making the diagrams much more readable and standardizing enemy states to be much clearer for the team and players alike.
Level Design
Level Planning
As a Level Designer on the project, I was tasked with mapping out the game's entire playspace so the team could have an overview of the game's pacing and environmental narrative.
I created Level Sketches to keep the team informed on the structure and layout of the game's level space.
These resources were fluid, constantly being updated to meet the ever-changing needs of the project throughout development.
Very rough early whiteboard sketch.
Composite of detailed arena sketches.
Final draft of level layout.
Very rough early whiteboard sketch.
I also created a Beatmap to guide the difficulty and pacing of the level.
This resource ensures that the game properly teaches mechanics before later testing and challenging the player.
Arena Design
To guide my design process when creating level spaces, I created a list of general level design strategies observed in games with gameplay elements similar to CHOSEN. I also established a short list of strategies based around gameplay elements unique to CHOSEN, and tried to incorporate elements from both rulesets when designing level spaces.
Sewer Arena
The Sewer is the first interior combat arena in the game, and introduces a new challenging enemy for the player to overcome.
This arena emphasizes choice paths and vertical space, with the player able to choose between multiple routes of varying safety to engage with the new enemy.
Grapple Arena
This encounter challenges the player to demonstrate their mastery over CHOSEN's unique movement mechanics while engaging in fast-paced combat.
A challenging enemy holds the high ground, so designing safe zones that use the environment to block line of sight and are quickly accessible to players was key.
Bridge Arena
Adhering closely to the "classic" ruleset, the Bridge is a symmetrical enclosed space that follows the "Donut Arena" rule.
To make sure the design of this level space properly matched the gameplay of CHOSEN, multiple grapple points and vertical paths were included, allowing the player to quickly traverse the arena.
Ribcage Arena
The Ribcage features a large open space flanked by vertical paths that create safe zones.
The Ribcage limits the player's access to the easy traversal that is usually core to CHOSEN's gameplay, encouraging thoughtful repositioning.
I wrote a full Case Study taking a deeper look into the design considerations of each arena. The document contains a more detailed explanation of the "classic" and "unique" rulesets, as well as breakdowns of how each arena caters to individual rules.
Graybox vs. Final Level
Level spaces were first sketched, then constructed using Grayboxing. Graybox level spaces were playtested internally and using volunteers. After adjusting based on feedback, I worked with the Environmental Art team to create and place assets.
Ribcage Arena
Interior Arenas
Bridge Arena
Sewer Arena
Grapple Arena
Major Setpieces
Broken Bridge
Final Arena
Planetary Wall
Sidewall Overlook
Outdoor Spaces
Canyon
Scaffolding Pathway
Outdoor Overview
Cave and Armoury
Tutorial Design
The first few moments of the game are the most important: the player needs to be immediately hooked by the game's premise, but also carefully taught its unique and often complicated mechanics. Some players will only engage with the game for a few minutes, leaving the introduction as the only part of the game they experience. Months of work was dedicated to refining the game's tutorial section, making sure it properly entertained and onboarded players.
Playtest Tutorial
In our first playtest build, the tutorial was focused on function over form, consisting of sequential rooms teaching core mechanics one after another. This early tutorial also provided an opportunity to test and fill gaps in the Modular Kit created by the Environment Art team.
Initial whiteboard mockup of tutorial layout and elements.
More detailed exploration of tutorial space.
Tutorial space as it appeared in early playtest builds.
Initial whiteboard mockup of tutorial layout and elements.
Full playthrough of the original tutorial.
Initial sketch of updated tutorial.
Grayboxed tutorial annotated with mechanics.
Initial sketch of updated tutorial.
Tutorial Rework
For the final build, the team wanted the game's introductory moments to be more visually interesting and include exciting gameplay immediately. I altered the design of the tutorial into a winding canyon that gradually teaches mechanics while interspersing bursts of introductory combat scenarios to generate excitement.
Final Tutorial
A playtesting pass showed the tutorial took too long to clear and needed to be slightly truncated. The level space was reworked, shortening its overall length and offsetting the combat sections.
Narrative Design
Building a Narrative
As a Narrative Designer, I worked to write an overarching story about the world and characters of CHOSEN. The team knew ahead of time that, due to the limitations of our project, much of this story would only serve as narrative context for the characters and environments we were creating.
I created a rough story timeline and wrote a narrative synopsis to organize the core points of CHOSEN's story. Ultimately, very little of this content made it into the final game, which taught a valuable lesson: just like other aspects of game development,
Narrative Design should operate within the constraints of the project.
Rough outline of the story planned for CHOSEN.
Writing & Recording Dialogue
To flesh out the game world, I wrote a large script full of dialogue and barks for the game's characters. Extensive dialogue was written for a "guiding character" to direct players through the game's level space, and enemy characters were given various barks to make them more interesting.
Directive Scripting
The script was formatted to best accommodate the needs of our Sound Designers and Voice Actors, containing sound file names for organization and context notes for the voice performance.
Cross-Discipline
Collaboration
We worked with students from the Sheridan Music and Sound Design program to hold auditions and recording sessions with many talented Voice Actors. Through this collaboration, we were able to record through the entire script and give a voice to all of the game's characters.
Enemy Barks - Highlights
Fun Idle Barks
Enemy dialogue was designed to be incredibly robust, with voice line variations that can be played in response to various key player actions. The talented voice actors also brought out a decidedly comedic side to these characters.
Player Guide - Highlights
Danny's dialogue is much more linear, which allows for more direct tutorialization and the ability to draw attention to specific narrative details in the environment.
An unseen character was intended to communicate with the player as they progressed through the game, providing helpful leads and commenting on aspects of the game world to flesh out the narrative. Ultimately, much of this dialogue needed to be cut.
Cut Content - Boss Antagonist
An antagonist intended to be a character foil to the protagonist and the final boss of the final build was cut due to time constraints. Fortunately, a Voice Actor had already provided her talents before this content reached the cutting floor.
Project Management
Internal Documentation
One of my core responsibilities was maintaining a database of internal documentation for team reference. My goal was to record the team's decision-making process to ensure a unified team vision. This helped the team avoid unnecessary conflict and dependency-based setbacks.
I organized all team documents in a Confluence document that was accessible at any time to all team members. This document doubled as our rough-draft Game Design Document.
Note: Due to errors with Confluence's PDF export feature, this document contains many broken links and images.
Schedules & Submissions
I also created and updated the team's schedule throughout the project, maintaining a general weekly schedule as well as a Trello Board for organizing individual tasks. I also created multiple roadmaps for the team to follow before major deliverable deadlines.
Loosely tracked recurring team commitments.
More detailed schedule tracking weekly tasks.
Roadmap graphic used to organize general milestone goals.
Loosely tracked recurring team commitments.
Milestone Delivery Documents
In addition to team scheduling, I was also responsible for ensuring bi-weekly Milestone Deliverables Documents were completed and submitted. Each document recorded team members' total individual contributions to the project over a two-week span.