Last year, Pat shared the way that we make games in Alpha-Driven Development, which describes One More Game’s approach of rapid iteration and gameplay validation through early feedback from players. We’ve put this philosophy into practice since One More Game’s inception, and wanted to share more about how it has worked so far, and what we’ve learned.
Building a Foundation
The first game we developed was what Pat and I affectionately called, “The Win Button”. It was a blisteringly fast paced game where whoever pressed the Win button first... won. Fun! Well, not really, but it was deployed automatically by our build server, ran on our cloud-hosted infrastructure, and was a networked game. So while “The Win Button” wasn’t very fun, it provided us with an early testing ground for our technology. “The Win Button” and its sequel, Blackjack, were minimum viable solutions (MVS) that enable us to test the technical and operational foundations required to begin Alpha-Driven Development so that we didn’t waste our players' time when they began to test the real game we intended to build.
Oh, and I won the majority of “The Win Button” games against Pat. Just thought you should know.
Alpha-Driven Development asks developers to iterate quickly, own the reliability of their code, and deliver changes to players without interruption. That’s a tall order! To enable this approach, we need tools that unburden developers so they can stay focused on delivering player value instead of triaging problems. That manifests in a few practices and imperatives:
- Automate Everything: Anytime we can invest in technology that automates necessary but repetitive tasks, we will. For instance: anytime we make a change — any change — it gets automatically tested in our staging environment to ensure that it doesn’t break the basics (i.e., you can log in, play and complete a match without crashing). That frees developers up to focus on the qualitative aspects of the change they’re deploying, without having to ask “did it work?”
- Rapid Deployment: We need to make it dead simple to make a change, validate it, and deliver it to players in 20 minutes or less, but optimally under 5. There is a large technical foundation required to deliver on this promise, and so we built processes for continuous integration and continuous delivery from the very beginning to unlock developers.
- Near-Zero Downtime: We strive for 100% uptime. Our services and infrastructure have been built to eliminate interruptions between updates. We value our players’ time, and long maintenance periods (scheduled or otherwise) aren’t acceptable.
Once our foundation was in place, we moved from building something that could be described as “yeah, technically that’s a game” to something suitable for real capital-G Gamers.
Building a Community
That brings us to another tenet of Alpha-Driven Development: get our game in front of players.
One of the first things we did was reach out to a small handful of friends outside of the games industry. We knew we couldn’t throw open the doors yet, so we started small, bringing in a handful of folks we thought would bring an open mind towards a very early stage game full of incomplete assets and less-than-fully baked game design.
We sent out a handful invites for Halloween night, 2020. A year later, many of those first few folks continue to play during our weekly playtests. Exactly why tester retention has been so strong boils down to a few factors:
- The pace at which we iterate on player feedback is essential to maintaining a happy community. We want to both communicate with players and roll out new changes rapidly as a way to say, “We heard you, and made changes to improve. Thank you for the feedback!” This creates good will in our community, and because players are heard they feel invested in our success.
- We’ve been fortunate to have dedicated, thoughtful, and constructive players join us during this first stage of our journey
- While the early experience wasn’t polished, or complete, there was always an element of sheer fun to the game we’re building, and so our players continue to return.
We’ve steadily grown the Alpha community since kicking off last Halloween, continuing to reach out to our network of trusted friends (and widening that net to friends of friends). We’ve added new players each time we feel we’ve made significant progress to get fresh perspectives alongside opinions from veterans, so we ensure we haven’t lost the “it” of our game.
Building a Game
We’re able to put significant changes in front of players every single week. It is hard to overstate how valuable this is in terms of keeping the community engaged (there’s almost always something new each week), so we’re always working on finding & improving the fun, and ejecting what’s not.
Here’s the outline of a weekly iteration loop:
- Alpha Playtest: Once per week we play the latest & greatest version of the game with our Alpha community. Everyone hops on Discord and our team shares what’s changed and where we’re looking for feedback. We split into groups and have players stream their gameplay while members of the OMG team spectate, then ask questions and listen to feedback. We record gameplay sessions and take comprehensive notes.
- Debrief: The following day, the entire team regroups to share what we learned from players from viewing and from feedback by players in Discord, and prioritize emergent work (things we hadn’t planned for) alongside our existing efforts.
- Build: Following the debrief, the team sets out to work on new content, balance updates, improvements to existing content, and optimizations to the player experience.
- Show & Tell / Internal Playtest: At the end of each week, we hold an all-hands meeting where team members demonstrate what they've been working on, and then dive into an internal playtest to eat our own dogfood.
- Final Touches: Following the internal playtest, we address smaller fixes and polish where necessary.
- Smoke Test & Publishing: The afternoon before our weekly playtest, we do another internal playtest where we ensure what we’re going to promote is in good working order. We spend an hour playing to identify any fires that exist in the build, and to generate the patch notes for the testing community.
- Alpha Playtest: We start all over again: once more unto the breach!
This iteration loop optimizes for emergent work, but not every development decision emerges purely from player feedback. Our team collaboratively authors milestones that outline outcomes for the current stage of development we want to deliver. Outcomes aren’t quantitative (“How many NES games do you own?”) in nature, but rather qualitative (“What is your favorite NES game and why is it Punch-Out!!?”), which we use to reason about which features and content to build and how to prioritize that work.
Combining our milestones and weekly iteration loop with players allows us to frequently validate what we’re working on is what players want. If feedback doesn’t match what we thought we should be working on, then we’re working on the wrong things.
This tight feedback loop has enabled shockingly fast progress. When we first invited external testers, we observed that it took players around five games to “get it”. We want our game to be intuitive and frictionless to adopt so we aimed to get this number down to one game. So we employed a weekly research session we call the “New Player Experience” (NPE), where we run new players through our game with no instructions on how to play, and no tutorial (because we haven’t created one yet).
We observe where players were having difficulty by silently observing, asking them to speak out loud about their experiences: what they are seeing, how they are feeling, what is working, what isn’t working.
By making changes every single week aimed at the list of sharp edges of our interaction model, we saw that the number of games required to successfully on-board dropped precipitously — four games, then three, then two. By April 2021, after five months of weekly testing, the vast majority of new players were grasping the interaction model and core gameplay in the first match. In the last few months, we began measuring this as minutes into the first game, and now players typically “get it” within the first two or three minutes of play.
An engaged development team is crucial to making this approach work. Since the whole team is actively involved in seeking out and understanding player feedback, and because we’re obsessive about keeping records from past playtests, very little falls through the cracks. We’ve got a lot of redundancy in the form of a group of committed developers who were up to the challenge of moonlighting as user researchers.
Finally, Alpha-Driven Development demands reliability. We prioritize improving things that undermine testing, which we call “finger in the eye” issues, as we aim to make the most of our players time. In addition, players expect the game functions properly and that servers are always available, and we’ve maintained 99.9% server uptime over the last year.
There are thousands of games released each year and our players could be spending their time anywhere else – maybe even going to that place I’ve heard so much about, the “outside” – but we’re glad they’re here, and we appreciate their participation.
—
Sound like an approach to game development you’d like to be a part of? We’re hiring!
