Mowin' & Throwin'
For the last two years I worked as the associate producer at House Pixel Games. Since our studio was so small, I took over several production responsibilities to ensure we met internal deadlines, found music and SFX to fit our game and budget, had adequate quality assurance, and made sure we had a fun, safe, and less stressful work environment. All documents related to my production work are under NDA at House Pixel Games so unfortunately I cannot post examples on this portfolio.
Game Summary
Play as lawn gnomes and wreck your neighbor's yard by throwing rocks, fertilizer bags, and psychedelic mushrooms. Race around in a nitro boosted mower to pickup grass and blast unsuspecting opponents with its hidden tank cannon. Mowin' & Throwin' is great to play with friends, family, or people you only sort of like. The experience is best played locally, but is playable online through PARSEC on the PC version of the game. The game is available on Steam and the Nintendo Switch eShop.
Mowin’ & Throwin’ is a competitive lawn mowing experience where the objective of the game is the have the LEAST amount of grass on your lawn before time runs out. Mow down the competition in our 2v2 or 1v1 game modes. Customize your experience by choosing between two zanny gnome avatars as well as their hat.
Mowin’ & Throwin’ is a competitive lawn mowing experience where the objective of the game is the have the LEAST amount of grass on your lawn before time runs out. Mow down the competition in our 2v2 or 1v1 game modes. Customize your experience by choosing between two zanny gnome avatars as well as their hat.
Production Responsibilities
- I managed the external composers and sound effects studio because we did not have anyone in-house to produce music and sounds
- Created and maintained a Google Sheet containing all the sound effects and music required for Mowin' & Throwin'. I tracked the SFX and soundtrack name, a description for the sound designer / music composer, a description of where the sound is supposed to play for those implementing it, delivery dates, and whether or not it was implemented. For sounds that were implemented in engine, I kept track of whether or not the SFX / soundtrack was placeholder, minimal ship, final, or needs iteration. I also kept track of where the sound effects came from since we used multiple sources for sound effects. I also maintained the document's organization by creating sections such as Menu SFX, Gnome SFX, Fertilizer SFX, Music, etc. to keep all related sounds in one place.
- Communicated weekly with our sound designer to update him on sounds that needed iteration, find out what new sounds are coming in for implementation, and go over any sound effect descriptions that may be unclear.
- Posted an advertisement in Reddit's classifieds for a music composer and sifted through several responses and portfolios to find the perfect composer for our game's particular style. Once we found our composer, I worked with him on Discord (since he worked remotely) and communicated multiple times a week sending him examples of instrumentation, tempo, and musical themes to fit the level he was composing music for. We wanted unique music for every level in the game so I also sent him gameplay footage of each level so he had an understanding of the theme and mood for each level.
- I helped manage our quality assurance team to make sure we were addressing bugs and communicating with the studio that worked on our console ports
- For most of the project we had a dedicated QA team and QA lead that interfaced with me and the programmers, kept track of bugs in our task management software, and adequately regressed bugs while finding new ones. However, we had three different QA teams over the course of the project so I made sure that the transfer of QA responsibilities and pipelines were passed along to the new team.
- Listened to the QA leads whenever they had suggestions that would improve our pipeline and communication. I made sure that all the new information was passed down to everyone involved in the QA and bug fixing processes.
- We lost our QA team at the very end of the project and didn't have money in the budget to find a last minute team so I took over the QA lead responsibilities. At this point in the project we had three different branches of our game engine: PC, Switch, and Xbox / PS4. We had to track and fix bugs separately for each version of the engine and I tracked them in a Google Sheet, creating a closet list of items we needed to finish before sending builds to certification. Fortunately, most of the major bugs had already been fixed and regressed so we mainly focused on each console's specific certification issues.
- We used a third party studio (Snowed In Studios) to port the Xbox and PS4 versions of our game. We were still in the middle of fixing some of the worst bugs and performance issues when they started porting the game on a cloned branch of our engine. Once they were finished, we had to integrate our changes with theirs, which caused a lot of issues. I worked with them and our programmers to track all the issues, track all the files that both studios needed to use, and help facilitate the communication to avoid as much rework as possible. Once we had builds that we felt confident in, we held exhaustive QA tests to make sure no new bugs popped up and also ensure old bugs didn't return before we sent the builds to certification.
- I worked hard to make sure the management fostered a culture with psychological safety to maintain a fun & reduce burnout
- One aspect of our studio that I was very proud of was that we never crunched. Ever. It was important that everyone worked no more than 40 hours a week. Productivity was high since time was valuable and everyone in the studio had 8 hours of focused work each day. In the very rare instance someone had to work over 40 hours (usually in the form of outside deadlines and conventions), we gave those hours back the next work week.
- As much as I would like to say that strict 40 hour work weeks was a silver bullet that kept developers from burning out, it came with its own baggage we didn't anticipate. With our 'work smart, not hard' mentality, we ended up cutting a lot of features and experiments from our game. A lot of these features were very promising and our developers really believed and loved working on them. The constant cuts added up and I could tell it was exhausting our development team, since a feature they were working on could get unexpectedly cut. Unfortunately we never came up with a solution for this, even though there were several discussions about making exceptions to our anti-crunch culture in order to complete these features.
- Physical and mental health are very important to me. It was a general assumption by management that we could avoid burnout by simply avoiding crunch. However, we still experienced burnout from our development team. One of the factors that I believed lead to this burnout was a lack of psychological safety from the management team. There were moments from all of us in management where we failed to demonstrate adequate leadership responsibilities resulting in a lack of trust, lack of job safety, and added pressure to get things done right the first time in a timely manner. I had recognized this for a while in our team's dynamic, but could not adequately articulate what the issues were or what management could do to address them. This is when I found articles about psychological safety and how important it is to maintaining a highly motivated team. As a lead, I made sure I was transparent, vulnerable, and humble in front of my team to encourage them to trust me the way I trusted them. Mistakes happen, it is just the nature of game development. I worked hard to make sure we had a culture where no one was shamed, humiliated, or threatened for making a mistake. As far as mistakes made on the management side of things, I was open and honest with my team whenever I made a poor decision and listened to any and all feedback from the team about ways management could improve.
