Daily Life at Skookum

A daily standup meeting at 8:30 AM gets all three of us on the same page. Examining the current sticky notes on our collaborative Miro board lets each of us know what work needs to get done this sprint. Anything worth showing off in the past couple days gets shown off and reviewed by the team. With no further discussion points and action items assigned, everyone breaks to go handle their tasks and sprint objectives.

Details of Working

Working remotely for a game company is less than ideal, but it worked perfectly well for the size of the team. Our schedule was divided into quarters, builds, and sprints. Each quarter was given an overarching goal, such as a first-pass of narrative scenes, or major mechanics being implemented. Each quarter had a pair builds, where everything that had been built up to that point was compiled and packaged into an Unreal executable. These builds would be play-tested by each of us as we hunted for bugs or updated thoughts on the game design itself. Each build consisted of three sprints of two weeks each. Sprints were standard Agile-style sprints, where tasks were assigned to each team member to be completed during the sprint. If one of us finished ahead of schedule, we could pull from the backlog and continue working. Alternatively, the completed work could be further polished and debugged before the sprint was over.

I adapted well to working within this framework, and I appreciated having a continual list of work items, which maintained my focus on the project. I could also easily see how my work contributed to the project at a higher level, and everything I built could have a purpose. There was always more to polish, more to implement, more to debug. However, the workload was never overbearing or problematic either. The pacing felt appropriate, and steady progress was always being made. Being able to showcase to the other team members kept morale high across the team, and I really appreciated seeing things get done in fields that I had no experience in. There were a few times when I didn't know exactly what a mechanic's design called for, and in those instances, I had the freedom to make my own implementation before the design got finalized. Although this did cause some mechanics to be overhauled later, it allowed prototyping to proceed even when certain design conditions weren't fully defined.

While I unfortunately did not get to work in-person, I nonetheless traveled to collaborate on ideation and the design of several mechanics. These design meetings took multiple days of dedicated brainstorming to define mechanics for me to build. The core team sat in front of a whiteboard for hours, discussing different implementations of The Extractor and how said designs would flow together in the gameplay loop. This experience was an invaluable reference to me as I programmed the new mechanics, and it further convinced me that working in-person is the ideal scenario for working on games.