Producer
-
Led 11 people virtually via Teams & Perforce
-
Completed production in 10 two-week sprints; Roughly 30 work days
-
Planned and led Scrum events, team meetings, and one-on-one check ins.
-
Held Sprint Plans, Reviews, and Retros at the beginning and end of each sprint
-
Filmed & presented video developer logs at the end of each sprint
-
Wrote & analyzed QA feedback surveys with each release
Narrative Designer
-
Designed an abandoned, 'discarded' world
-
Made that world one lived-in by mangled toys
-
Developed meaning behind set pieces and characters
-
Wrote multiple choice narrative events for the player
Cinematics & Cutscenes
-
Created the trailer and all camera operation within
-
Designer and built all camera animation within the game
-
Gave each environment multiple introduction cinematics
-
Worked with artists on establish framing for each of the combat camera
Points of Growth
This development process gave me the opportunity to be an autonomous, self-managing producer for a team of truly passionate developers. As our production continued, I learned more and more about my own style of management, where I could improve, and what ideas I had to scrap for the continued success of our team. I’ve listed some of those learned lessons here:
Production Team Pillars
From the outset, I felt the need to establish a flat hierarchy and an equal playing field regardless of which discipline (design, art, programming) a team member was operating within. So we all agreed on a set of simple pillars to abide by:
-
Everyone has product ownership
-
Everyone is a designer on this game
-
Everyone will be heard, whether it pertains to the game or not
I can’t guarantee what effect stating these pillars aloud had on the team. I can only say that I worked with 10 other quality individuals that maintained a high level of respect for their fellow peers. The environment we maintained to is a definitive contributor to the success of our game.
Agile Framework
We operated within a scrum/agile framework, but the members of our team, myself included, weren’t well-educated in it. We improvised our way through sprint plans, retros, and reviews until I took up the challenge of becoming officially Scrum-certified (PSM1).
This enlightened me to the rhyme & reason of the sprint events we were putting ourselves through every increment. I could finally appreciate why time-boxed stand ups were important, how to get the most from Retrospectives, and how our backlog could best be prioritized based on value. I believe that this understanding helped me use the tools of Scrum & Agile to our team’s advantage as the weeks rolled on.
Pivoting the Game
At the beginning of our Alpha Milestone, we presented the prototype and plan for Discarded to a panel of industry professionals. Though impressed with the unique qualities of our mechanics and ideas, they came down hard on two key points. The first was that we were extremely over-scoped, and the second was that our game wasn’t showing its fun in the first 5 minutes of play (which is roughly the amount of time players get at an expo like PAX or Dreamhack).
This was a key moment for us. We were already a quarter of the way into production, and as the team’s producer, I could feel a team-wide drop in spirit. I gathered everyone up after and opened the floor to any and all ideas. This gave the team a chance to promote concepts that were far outside the box we were working in.
I can’t thank those panelists enough. Their feedback became the barometer for our game’s quality through the rest of production. When we playtested, we would always ask ourselves if the first five minutes were fun or not, then analyze why not and fix it.
.png)
Task Management
In the middle of our Beta Milestone, we realized that we had rushed the completion of certain game features instead of cutting them as we should have. This caused massive technical debt for our team because, with the incomplete features, the product was no longer working end to end.
We cut down on these features, but I wanted to ensure that these issues wouldn’t become a pattern. I met with team members individually, who informed me they felt a lack of understanding between what designers wanted from a feature and what they believed the feature should be. In scrum-centric verbiage, I wasn’t facilitating enough transparency for our ‘definitions of done’. From then on, I made sure that each task and its user had clear, actionable goals to achieve its definition of done.
This was also helpful during meetings and reviews. I would create a list of tasks for our goals going in, would use those points to keep our conversation and time on track, and would end the meeting by recapping our tasks and how we addressed them. This was a powerful tool, as it always gave the meeting’s members informed plans to act upon.
Finishing With 'Strike Teams'
In our final sprint of production, to create the final Plan for the time we had left, I divided our 11 members into specific ‘strike teams’ based on everyone’s proven skills:
-
“Detailing/Finishing”
-
“Juice/FX”
-
“Bugs/Balance”
Each of these had at least one designer, one programmer, and one artist to ensure a well-rounded perspective.
The strike teams split up, played through the game on their own, and wrote out a list of the elements they felt needed work. Once everyone was finished, we reconvened and established the Sprint Plan based on our findings. This gave us a revitalized look at how our game was playing and a lens with which to suggest improvements.
This is NOT part of any Scrum Guide. However, it WAS effective for our team and the constraints we were under.
Please check in again to see this page grow along with Discarded's development!