Hex Rally Racers
Role: Lead Software Developer
Genre: Couch Multiplayer Arcade Racer
Development Cycle: 3 months
Team Size: 52 developers (12 programmers)
As Lead Software Developer, I planned sprints and coordinated 12 other programmers on an interdisciplinary team of 60 developers over 3 months - from idea generation to launch.
Gameplay Trailer
Major Takeaways
Communication on a Large Team
For many on our team, Hex Rally Racers would be their first published game. It would also be the first time they worked on a 60 person team. Keeping the studio aligned with a unified vision was challenging, but we took several steps to address this:
Giving regular informal briefs - prior to scrum each day, I would create a brief of the major decisions and changes to game features or sprint priorities. I received feedback from the team these were useful for them to reference and stay on topic.
Building a strong pipeline - our team’s daily tasks were backed up with redundancy checks and supporting documentation. This prevented information getting lost or out of date because each peace of information lived in a place where it was consulted regularly.
Playing the game publicly and regularly - As soon as we were able to show the game on screen, we played the most current build on a projector in the background where the whole team could see. Issues were often fixed faster than a bug report could be made for them, and the time from implementation to player feedback was reduced nearly to zero.
Risk Mitigation and Contingency Planning
Three months prior to the Steam launch, the only tangible piece of the game’s design was its genre - a couch multiplayer arcade racer. In order to maintain the necessary sprint velocity to hit our launch window, we lacked distinct pre-production and production phases, and took measured risks to stay on target.
Cross-discipline strike teams - we regularly used small mixed teams of designers, programmers, and artists to answer very focused questions. By eliminating production unknowns with this strategy, we could keep the larger team agile.
Plans that could be scaled down or up - sometimes, there were great ideas for the game’s design that we rejected because the minimum viable version of the idea required too much overhead, or once complete would be too expensive to scale up.
Quick Iteration Times - our modified sprints could often be shorter than a week and have very tightly scoped goals. More chances to iterate and do product reviews proved crucial for staying on target.
Channeling Team Creativity
One of the most valuable responsibilities I fulfilled as Software Development Lead was gatekeeping new features and changes. If the sprint plan deviated too much, we would not be able to deliver the existing features we had already promised. At the same time, many of Hex Rally Racer’s best ideas came from our developers having the room to experiment with features. When something of significant value showed up, the biggest challenge of the job was working with other leads to revise the project plan to make a slightly better game than the one we were previously making, within our constraints.
The Hex Rally Racers Development team poses for a picture in the SMU Guildhall atrium