Game Designer
Familiar
Battle of the Labyrinth
Shipped On
Team Size
8
Role
Producer, Technical Designer
Duration
Aug 2022 - Apr 2023
FBotL was a game project I led with an 8-person team during my 2nd year at DigiPen.
This game was my third published game on Steam
This project was in active development for over 7 months
As a producer, I was responsible for organizing and mobilizing my team to produce a feature-complete game in 8 months.
As a tech designer I was responsible for rapidly prototyping and building game features as we moved to ship.
I also became a father during this project!
If you want to hear the full story - read on!
Preproduction
Where an idea took shape
The Core Idea
​I created a framework to reduce the subjectivity of evaluating game pitches, my team used my framework to standardize our game pitches.
​
The elements of this framework was:
-
Game Core - what was the elevator pitch?
-
Pre-Production Prototype Description - what would a prototype would look like?
-
Team Strengths/Interests - how did this game idea align with team member's goals?
-
Risks - what were the biggest potential challenges for creating this experience?
-
Possibility Space - in what ways could this idea be expanded and scaled?
-
Comparables - what games would be useful references to get an understanding of this idea?
​
By setting criteria, I streamlined the brainstorming process, allowing my team to have productive conversations around which game idea we wanted to settle on.
The initial pitch document for Familiar (originally called Custodian).
After 2 days of discussion, we settled on the project we wanted to build: an autobattling strategy game!
A Team Is Formed
With a clear understanding of the game we wanted to make. We onboarded a number of new team members and had a team with:​
-
4 artists
-
1 audio designer
-
3 designers (myself included)
The pre-production team (from left to right): Katherine Amersbach, Sophia Chien, Michael Walter, Shawn Huang Fernandes (me), Lily Harrang, Suzanna Freund, Riley Bangs, Jacob Gross
The first step I took as the team's producer was establishing clear expectations through open dialogue:
-
Conduct - how each team member should expect to behave within the context of our project
-
Commitment - how much each team member should expect to commit to the project (this included boundaries)
-
Roles - what body of work each team member should expect to take responsibility for
​
I scheduled, facilitated, and managed meetings to make sure the voice of each team member was heard.
A preliminary systems analysis on Square Off
A meeting agenda I wrote and facilitated for our kickoff meeting.
Schedules and Strike Teams
With our team kickoff completed, I broke down the major project deliverables using a production schedule. Using Excel, I created and managed a gantt chart that visualized our tasks and priorities for my team.
Part of the production schedule gantt chart
This schedule worked well, however I assessed the team's productivity and observed that due to tasks being assigned on an individual basis, tasks that required cross-disciplinary collaboration struggled to get completed on time. I reorganized our team's working structure to better serve to collaborative nature of the incoming work.
​
Instead of delegating tasks to individual team members, I grouped related tasks based on their common feature, and assigned multiple team members to the feature. These smaller groups were called "Strike Teams" and always consisted of multiple disciplines.
​
I significantly improved the accountability and inter-team communication on my team by adopting this Agile-adjacent production approach.
Building A Validated Prototype
As the technical designer I worked closely with my team to build the key features required for our prototype to be ready for our stakeholders.
-
I worked with our artists to ensure that I built systems that allowed for visual assets to be updated easily
-
I worked with our audio designer to ensure the systems in Wwise could generate audio in the build
-
I worked with our design team to ensure the core game systems could support the features that were planned
In addition to this, I also ran 8 observational playtests with first time users to provide relevant data for our design team to make updates.
The playtest report I compiled for my design team
As our game progressed, I iterated on the game mechanics and systems to rapidly validate design concepts as well as provide opportunities to demonstrate higher level design such as game feel elements and audio feedback.​
A screenshot of the first major update (visual and design) for Familiar
The Prototype
By prioritizing features, promoting collaborative work through strike teams, and carefully maintaining our schedule, our team was able to produce a feature complete prototype that was received very positively by our stakeholders (the instructors).
The pre-production prototype showcasing core gameplay
With the first semester coming to a close, we had created a game which was a good representation of what we initially pitched at the semester's start.
Pre-Production Reflection
To improve our team's processes, I used a data driven approach and surveyed my team to learn about various aspects of our team's operations:
-
Meetings - how well did our organized conversations serve the team?
-
Communication - how well did our channels for communication work?
-
Direction - how clear was the objective and tasks throughout pre-production?
-
Accountability - how well did the team follow through on their commitments?
-
Support - were the channels to get help on tasks effective and accessible?
-
Satisfaction - was the project enjoyable to work on?
-
Chemistry - did the relationships on the team work well?
​
I was able to leverage a project in a user research class I was in to collect data and report my findings to my team.
The team dynamics study I conducted for pre-production
In addition to this, I hosted a post mortem to identify areas of improvement in our team's pipelines and dynamic as we moved toward production.
The post-mortem presentation I created for the end of pre-production
Production
Where an idea became a game
Creating The Game Loop
With a prototype that demonstrated our core gameplay, our biggest challenge was wrapping our core gameplay in a system that provided:
-
A start
-
A middle (that built over time)
-
A resolution
​
Unfortunately our system designer was unable to continue on our project due to extraneous circumstances not related to the project. While I began searching to hire another designer, I assumed responsibility for the growth of our game's systems, specifically with designing a functional and engaging core game loop.
​
I maintained documentation and made it accessible to our entire team to accelerate the ideation process. For example, I created a comprehensive pitch document and sought feedback from my team to identify risks and opportunities.
The pitch document I shared with my team to get feedback
In addition to this, I rapidly prototyped combat, UI, and progression systems in Unity to evaluate the feasibility of game systems outlined in my pitch document.
Some prototyped systems I built to explore potential new systems for production
I practiced accountable and transparent game design, sharing gifs of the systems as I built them, and prior to our official production start, I had created a functional build with additional systems that our pre-production build did not have:
-
A node travel system that allowed players to pick their battles
-
A behavior tree that allowed a mixing and matching of movement and attack behaviors for experimentation
-
Updated units who had stats that could be progressed
-
A simple economy that afforded the player to spend and gain resources
Cutting Scope
Our team started production with 2 builds:
-
Our pre-production build from last semester
-
The system expansion demo I built
​
By proactively prototyping a technical demo, I informed stakeholders of the potential direction our game could take. During our first milestone meeting during the first week of our project, I stood excited in front of our stakeholders with the new systems expansion demo built with my technically validated systems and played it in front of them.
​
They had a lot of feedback, majority of which was criticism.
​
And rightly so, because in my pursuit to expand the game's core systems, I had forgotten to think about the cost of a large system expansion: scope creep.
​
A couple items that they found particularly alarming:
-
All of the art in my systems expansion was placeholder, and the stakeholders were concerned that the amount of art that would have to be replaced would overburden the artists on my team.
-
There was no audio in this build, which similar to the art concern, made it seem like a large burden for our audio designer to cover.
-
The systems expansion included a lot more complexity, with the management of unit stats and an economy with multiple resources. The placeholder art in my build did not clearly communicate the new information, and it was clear the UI design requirements were significantly higher than from the original build.
​
Luckily, this was not a setback for my team, as my prototyping work was done in preparation for production, not during production. I received the stakeholder feedback and refactored my design to prioritize their requirements. This meant strategically (and selectively) incorporating elements from my system expansion into our pre-production demo, which had all of the art, audio and UI pipelines established.
​
Looking at what our game was missing (a core loop), I facilitated a discussion with my team where we triaged what we could, which we believed would be the critical path to establishing a core loop given the current gameplay in our pre-production prototype.
​
It was difficult cutting the majority of my expansion work, but I also knew this was a necessary and normal part of the game design process. I didn't have the luxury to get emotionally attached to my work. With that, our team officially moved into production.
Simplifying Our Communication
With our new project specs in hand, our team needed to mobilize and begin breaking down the larger deliverables into smaller tasks as it was relevant for our artists, designers, tech and audio team. During pre-production I organized our team using a combination of Gantt Chart for long term planning and Trello for sprint planning.
The current process I set for my team for project planning worked well but I sought feedback from my team about our existing project management strategy and I made some adjustments based on their feedback:
-
Many team members struggled to update their status on Trello's Kanban board or did not use it properly, creating delays as I needed to check in with team members frequently to correct mistakes.
-
The Gantt Chart was difficult for me to update in real-time, as the technical and artistic direction were still being updated after team meetings. The Gantt Chart quickly became less useful for long term planning.
​
To solve both of these problems, I reviewed alternatives to our current project management strategy and simplified our team's process by using a central spreadsheet to break down our team's tasks.
-
Each team member added their own tasks during our standups, which increased transparency in our work pipeline.
-
Team members were responsible for tracking the progress of their task between "In Progress", "Finished" or "Next Week", reducing the overhead of project management and allowing team members to focus on their work.
-
This spreadsheet was reviewed and updated each week during stand-downs, improving our team's accountability and helped prevent tasks from remaining unfinished for multiple weeks.
A section of the task spreadsheet I created to simplify my team's project management process
Feature Implementation
As the technical designer on our team, I was responsible for the development of the main features of our game, while ensuring those features were accessible to our design team. The largest features were:
-
A node travel system which allowed the player to select from a number of battles in order to progress
-
A combat system with three distinct units that had a balanced triadic relationship akin to Rock Paper Scissors
-
A collectible system that allowed players to find and collect hidden objects
​
I had the following pillars when implementing these features:
-
Make features designer-friendly: When building these features, there needed to be enough hooks for designers to experiment and change how the game systems worked.
-
Focus on functional: I prioritized getting the features functional in engine as soon as possible so designers, artists, and audio could see their work in-engine and make adjustments accordingly.
-
Get feedback: I provided frequent updates on my work by notifying my team when I was beginning and finishing my tasks. I also provided gifs to make it easier for my team to see the changes without having to boot up the build.
-
Solve visible problems: Avoid scope creep by only solving the issues and making systems as extensible and scaleable as they needed to be for the game to ship.
​
Following these pillars, I built the 3 major systems
UI crowding around player avatar
Avatar/UI double coding demonstration
Combat System
Collectible System
Conducting Playtests
Because our game was heavily reliant on UI, designing our UI for clarity was a large focus of our design team. I designed a survey to collect data on whether players were understanding critical elements of our UI such as:
-
Our game's tutorialization
-
Game icons for combat units
-
Health meters
-
Team indicators
​
I conducted my study with 12 first-time-users, collected survey data, and created an analysis report for my team's review.
My playtest report analyzing the UI clarity of our game
As our project was reaching its ship date, this playtest data helped identify areas of improvement, which helped our team use time more efficiently on tasks with higher returns-on-investment.
Prioritizing Critical Tasks
This project had many requirements and constraints, but I had a personal constraint that my team had been aware of since pre-production.
​
My wife and I were expectating our first child 2 weeks before our game was to ship.
I was to go on parental leave 2 weeks prior to that.
​
I had prepared for this eventuality in the following ways:
-
I made all my production processes transparent to the entire team.
-
I worked closely with my co-producer to ensure he was in the know about any large project risks.
-
I onboarded our design lead and began transitioning her into my producer and technical lead role weeks in advance.
​
In order to prepare for my parental leave, and leave my team with a strong direction in my absence, I drafted a prioritization matrix that helped identify the critical tasks our team needed to focus on.
A part of the prioritization matrix I drafted for my team before I went on parental leave
The prioritization matrix I made reduced the subjectivity of prioritizing outstanding project tasks by evaluating items by:
-
Whether they were address experience breaking bugs, or were core requirements in order to submit our project (such as abiding by an EULA contract)
-
The improvement in our overall grade that would be had if the task was addressed
-
If none of the above, how critical/meaningful it was to the team that the task be completed
​
I was confident that my team had the information they needed to make informed decisions to finish this project, and I prepared for my parental leave.
Parental Leave
I relinquished my role as producer and technical designer to my design lead and left the project in the hands of my team. I'm incredibly happy with that decision as it allowed me to focus on the wellbeing of my family and take care of my wife during one of the most important events in my life.
​
Our daughter, Maelynn, was born on March 27th, 2023!
.jpg)
Our first child, Maelynn, born during the last 4 weeks of this project!
Another Game, Shipped
My team shipped this game successfully, earning a fantastic grade from our DigiPen instructors (111%) and successfully shipping this game on Steam. I was so proud that my team carried the torch in my absence, and they managed to make many visual improvements before it had to ship.
​
This was my second project at DigiPen where I found myself in a combination of leadership, design, and technical position. I learned so much about managing cross-disciplinary teams, performing system design with scope in mind, validating designs with technical knowledge, and leveraging player experiences to improve decision making.
​
I also built many great relationships both within my team, faculty , and students.
Our game, on Steam!
Reflection
Where I look back
Lessons Learned
Familiar - Battle of the Labyrinth was the largest project I collaborated on to date. I grew as a leader, a designer, a programmer, and a person. Although I wasn't able to host a post-mortem for my team due to the timely birth of my daughter at the end of the project, this project had many take-aways that I will carry with me into my next projects and in the industry.
​
The important takeaways from Familiar were:
​
-
Leadership through empowerment. As one of the leaders in terms of design, tech, and production, my best work happened not when I led the efforts, but when I guided them. Whether that was re-structuring our project management pipeline to reduce the "busy work" for my team, building designer-friendly systems based on conversations with designers, or rapidly updating game builds so the team could give critique to their own work in engine. Good leadership did not come from above as orders, it came from below as support.
​
-
Design without attachment. As designers we have to look at our work not as a part of ourselves, because that improves our ability to handle feedback and make better decisions. There were points during this project where I had to recognize my attachment to my designs (like when I made a major systems expansions), and let go of it in order to cut and remove uneccessary systems from our project. Had I remained attached, it would have caused large scope issues for my entire team.
​
-
Reduce subjectivity. Making informed decisions in a space that is rife with creative thought and ambiguity is critical to get a game to ship. It is my responsibility as a developing design professional to reduce that ambiguity for any decision that is within my purview. I did this on my team by collecting data through user research, placing every team members work in-engine as soon as possible for feedback, and making the evaluation criteria we were given at the start of the semester more objective using a prioritization matrix. Subjectivity can crater projects if left unchecked, and I will be vigilant to reduce it when I can.
​
-
Rapid prototyping is awesome. I think one of my most significant contributions to this project was my ability to validate design through implementation. The value of bringing a design to life for critique and feedback is very gratifying, as I know that criticism on a real tangible gameplay system is far more useful than on an idea. Ideas are cheap, prototypes are invaluable. Working on this project as one of the dedicated programmers made me interested in leveling up my scripting skills to be able to do more functional, tangible design.