Taylor Cadwallader
KnightLight
Project Overview
KnightLight is a 2D puzzle-platformer where players light their way through the darkness.
This game was developed during the sophomore-level GAM 200-250 courses at DigiPen, with the primary goal of fostering collaboration between designers and programmers in building a custom C++ engine. Using Dear ImGui as the foundation, our programming team developed the engine, integrating a variety of features and components tailored to meet the designers’ requirements.
My Roles: Design Lead, Systems Designer, and UX Designer
My contributions included:
-
Player Prototyping: Designed both the initial and final concepts for the player controller using Unity.
-
Mechanic Prototyping and Implementation: Created and implemented the majority of gameplay mechanics, prototyping some in Unity and integrating others directly into the custom engine.
-
Lighting and Particle VFX: Developed various visual effects using the custom engine’s lighting and particle systems to enhance the game’s atmosphere and overall feel.
-
Playtesting and Documentation: Conducted numerous playtests throughout development to refine gameplay and ensure alignment with the project’s vision. Documented user feedback to guide iterative improvements.
Design Process
Ideation
First Semester: The Initial Concept
Our team’s first official meeting led to the creation of KnightLight’s original concept: a player exploring a dark environment with a flashlight to find and activate lamps that open doors. At the time, there was no engine available for us to work in, aside from a few JSON files and editable variables. As a result, the first semester was dedicated to rapid prototyping in Unity, with playtests conducted bi-weekly.
This early concept evolved into a mini-metroidvania experience featuring:
-
A knight wielding a flashlight to navigate dark environments.
-
Shadow creatures that could be burned away with the flashlight.
-
Lamps to activate and unlock new pathways.
-
Secret collectibles scattered throughout the levels.
-
Unlockable flashlight colors, each with unique effects for navigation and combat.
The beginning of KnightLight
Despite the ambitious scope, the first semester's prototypes focused primarily on basic enemy encounters, lamp mechanics, and player movement. Each prototype was rigorously playtested, and I documented the findings to guide future iterations.
Sketches of the original concept
by Jared Callupe Lopez
Second Semester: Refined Scope and Custom Engine
Over the break, it became clear that the project had grown beyond what was achievable within our timeline, especially with the custom engine still under development. To address this, we held a brainstorming session and decided to narrow the game’s focus to one core aspect: puzzles. We scrapped combat entirely and centered the game on the original idea of locating and lighting lamps.
Sneak peak at the brainstorm session
With this new direction, I set out to design mechanics that complemented the puzzle gameplay, ensuring they were engaging and integrated seamlessly with the other designer’s level designs. This led to the creation of a new player controller concept, splitting the light source and armor into two distinct entities. This opened up exciting possibilities for puzzles and gameplay interaction.
Why Not Separate Characters?
Early discussions included the idea of controlling the light and armor as two separate characters. However, I advised against this approach, as it often leads to player favoritism and frustration when required to switch between characters. Instead, we focused on making the light and armor feel like two cohesive parts of the same entity.
The New Player Controller and Mechanics
The new player controller formed the foundation for all subsequent mechanics, which naturally emerged as we explored how the light and armor could interact with the world and each other.
-
Light:
-
Flash: Emits a burst of light for visual aid and to activate lamps.
-
Pipes: Form of transportation that requires leaving the armor.
-
Light Recall: Returns Light to the armor from anywhere.
-
-
Knight:
-
Hazard Invulnerability: The player cannot die as Knight, and can walk on hazards.
-
Armor Recall: Summons the armor at interacted torches.
-
Launch: Allows the player to propel Light in any direction out of the armor.
-
FLASH CONCEPT
LAUNCH CONCEPT
LIGHT RECALL CONCEPT
Mechanic concept art by Jared Callupe Lopez
Additionally, I proposed several other mechanic ideas during discussions with the programmers. If you'd like to review those ideas, you can find them here: [Insert Link Here]
Prototyping and Iteration
First Semester: Early Prototypes
At the beginning of the project, I developed numerous prototypes to establish the vision and core gameplay for KnightLight. These prototypes, created almost weekly in Unity, explored various gameplay elements while the custom engine was still under development. Most of these early ideas were later scrapped as the game’s direction evolved, particularly when we decided to exclude combat and focus on puzzle mechanics.
Individual Prototypes:
-
MVP.v1: Initial gameplay concept and basic mechanics.
-
Entity Silhouettes: Testing visual clarity and character design.
-
Camera Examples: Experimenting with different camera systems.
-
Health & Energy Systems: Early concepts for player vitality mechanics.
-
Enemy Experimenting: Preliminary work on AI behaviors and combat scenarios.
-
Raycast Lighting & Enemies: Initial lighting mechanics combined with enemy interactions.
-
More Raycast Lighting: Expanded testing of light-based gameplay systems.
-
Tile Lighting: Testing tile-based light interactions for environmental design.
ENTITY SILHOUETTES
RAYCAST LIGHTING
HEALTH & ENERGY SYSTEMS
TILE LIGHTING
Collaborative Prototypes: (both designers were involved)
-
MVP.v2: Revised core gameplay mechanics with input from the team.
-
Level & Enemy Test: Combining level layouts with basic enemy interactions.
-
Tutorial Test.v1: First iteration of an introductory tutorial.
-
Tutorial Test.v2: Updated version incorporating feedback from the first test.
MVP.v2
LEVEL & ENEMY TEST
TUTORIAL TEST.v2
Second Semester: Finalized Prototypes
By the second semester, the custom engine had reached a stable state, allowing designers to work directly within it. This reduced the need for Unity-based prototypes. However, I continued refining gameplay mechanics with a focus on the finalized player experience.
Individual Prototypes:
-
Start of the New Player: Initial start of the redesigned player controller.
-
New Player: Refined version of the redesigned player controller.
NEW PLAYER CONTROLLER
Collaborative Prototype: (both designers were involved)
-
Movement Playtest: The final Unity-based prototype, focused on testing the new movement mechanics within a level.
MOVEMENT TEST
After completing the Movement Playtest, all subsequent work was done within the custom engine, where I continued to prototype and implement the finalized mechanics for the player controller and other game systems.
Prototype Access
All Unity prototypes are available for download: [Insert Link Here]
Testing and Evaluation
Playtesting Reports
Over the course of the project, I authored a total of 12 detailed reports:
-
9 User-Focused Playtest Reports: These centered on gathering player feedback to refine gameplay and user experience.
-
3 Custom Engine Testing Reports: These focused on evaluating the functionality and usability of our custom engine.
For each user-focused playtest, I recruited three participants, ensuring they were fully briefed on the process and had provided consent. My testing methodology included:
-
Observing and documenting areas where players showed confusion or frustration.
-
Identifying tasks that took players longer to complete.
-
Highlighting elements players particularly enjoyed to expand upon.
Each report was organized into a comprehensive, team-readable format:
-
Executive Summary: A concise overview of the report for quick reference.
-
Key Observations: Documented player behaviors and experiences.
-
Conclusions: A summarized list of the most critical findings.
-
Recommendations: Actionable solutions or enhancements for each conclusion point.
Playtesting Timeline and Focus Areas
During the first semester, I conducted bi-weekly playtests focusing on:
-
Entity Silhouettes: Ensuring visual clarity of objects and characters.
-
Player Mechanics: Evaluating usability and enjoyment of controls.
-
Enemy Encounters: Testing balance and player interaction.
-
Overall Game Feel: Assessing pacing, immersion, and engagement.
-
Custom Engine: Verifying stability and functionality.
Over the semester break, I proposed a redesign of the player controller and a streamlined game concept to address scope limitations. This led to an additional six playtests in the second semester, focusing on:
-
The Redesigned Player Controller: Testing new controls and mechanics.
-
Updated Custom Engine: Reevaluating improvements and changes.
-
In-Engine Gameplay: Testing the integrated game in its official engine.
-
New Mechanics: Analyzing the newly implemented puzzle mechanics in levels.
Engine Design Guide
The final document produced was an Engine Design Guide, co-authored with the team’s other designer. This guide served as a resource for users interested in understanding how we as designers leveraged the custom engine to develop KnightLight. Unlike the playtesting reports, it focused on the technical and design workflow rather than player experience. Not everything from the engine is covered within the document, only of which the designers focused on/used.
Documentation Access
All reports and the Engine Design Guide are compiled and available for reference: [Insert Link Here]
Key Contributions and Features Implemented
1. Flash Ability
The flash ability was the first mechanic I implemented, designed to assist players in navigating and surveying the environment. This ability also became the primary method for activating lamps. To ensure it remained a reliable and versatile tool, the flash was designed without limitations like cooldowns or usage limits, making it a permanent aid throughout the game.
FLASH ABILITY
2. Lamp and Door System
The lamp and door system was the core gameplay mechanic from the project’s inception. Players activate lamps using the flash ability, which in turn opens corresponding doors.
-
Implementation: Lamps and doors were paired using a tagging system. For example, the first lamp is tagged as “L1,” and the first door as “D1,” linking them for activation.
-
Gameplay Significance: Activated lamps also serve as permanent light sources, aiding navigation throughout the game's dark environments.
LAMPS AND DOORS
3. Checkpoint System
To provide save points, I introduced a torch-based checkpoint system.
-
Design: Torches from the tilemap were repurposed as checkpoints due to their thematic alignment with light and their visual clarity.
-
Functionality: Activating a new torch deactivates the previous one, ensuring the active checkpoint is always clear to the player.
-
Additional Mechanic: The torches were later integrated with an Armor Recall feature. This mechanic allowed players to retrieve their armor at checkpoints, adding strategic puzzle elements. Initially, the armor system faced UX challenges; players struggled to understand how the mechanic worked. I iterated on the lighting and sound design to make the feature more intuitive and visually clear.
CHECKPOINTS
ARMOR RECALL
4. Pipe/Vent System
The pipes served as a traversal and puzzle mechanic.
-
Concept Evolution: Initially conceived as “vents” for single-tile traversal, they evolved into larger pipes based on level design needs and tilemap limitations.
-
Implementation: Pipes were linked using a tagging system similar to the lamp and door system but with directional specificity. For example, “V1AR” and “V1BR” represent a paired pipe system with directional output (e.g., "R" indicating the right direction for the exit). This tagging approach provided flexibility for level design.
PIPE NAVIGATION
5. Signiflyers (Guidance System)
I introduced the Signiflyers, glowing blue fireflies, as an additional guidance mechanic.
-
Purpose: They serve as visual goals and navigational aids, helping players progress and reducing the risk of getting lost.
-
Design: These were implemented as a safeguard to enhance player experience and align with the overall theme of light as a guiding element.
SIGNIFLYERS
Design Thinking Process
My design philosophy centers on adaptability and user-centered solutions. I approach each design problem by first understanding the core needs of the players and the constraints of the project. For KnightLight, this meant balancing creative aspirations with the technical limitations of a custom-built engine.
I prioritize creating intuitive, enjoyable experiences that resonate with players while ensuring the systems behind them are robust and well-integrated. This is reflected in the iterative development of the player controller, where early concepts were tested, refined, and aligned with the engine's evolving capabilities.
Personal Design Pillars:
-
Player Empathy: Ensure mechanics resonate with players and are easy to understand.
-
Adaptability: Balance creative aspirations with technical constraints.
-
Iterative Refinement: Embrace feedback-driven development for polished results.
Methodologies:
-
Design Thinking: Emphasized empathy, ideation, prototyping, and testing.
-
Agile UX: Collaborative iteration to align gameplay with user needs and technical feasibility.
Reflection
Working on KnightLight was an incredible experience. It marked my first time collaborating with a multi-disciplinary team and working within a custom engine. The programmers on our team were outstanding—patient, supportive, and always willing to teach us designers how to navigate the engine and request new features. Beyond the programmers, our other designer also did phenomenal work, single-handedly creating all the levels and UI elements. If given the chance to collaborate with this team again, I would take that opportunity in a heartbeat.
Throughout the project, we faced numerous challenges but overcame them together. The biggest initial hurdles were learning to understand "programmer-lingo" and mastering the tools they built. For instance, when custom C# scripting was introduced, we had to adapt to its nuances and learn how to write functions that translated seamlessly into C++. While there were occasional quirks- like the text component size only working in intervals of 20- we found workarounds and pressed forward to make KnightLight a success.
If I could change one thing, it would be locking in the genre earlier. During the first semester, we toyed with ideas ranging from puzzle-platforming to combat-heavy gameplay with enemies. In hindsight, focusing on one concept from the start might have streamlined our process. That said, I’m still incredibly proud of what we accomplished.
Oh, and one other lesson: never even entertain the idea of making a metroidvania as a student project!
For student projects, the key is sticking with one genre and finding ways to make it interesting and unique.