The Flow From Lean Game Design to Game Success
The Flow From Lean Game Design to Game Success

The Flow From Lean Game Design to Game Success

How do you go from a Lean Game Design and Single Page Game Design doc, into Agile software Development that fills your hypothesis with data points to support or modify your hypothesis, and then end with LiveOps measuring game play fun, user retention and optimized monetization flows?

TODO: Research "SAFE" agile methodology and see how much we can connect it into this game design, development, and live flow.

Just asking that question is a mouthful, so this document will break all of those concepts down and then serve as a guide to walk you through our process.

Demystifying the Buzzwords

Let's start with a very quick list and definition of all the buzz words in the description of this article.

Lean Canvas

A single page diagram which defines your business's needs, its strengths and its weaknesses.

We use this tool to find and express where we have facts and are relatively certain of things around the business, and where we know the most risk is.

Having to fill out a full Lean Canvas, you, as the product owner, will have to answer questions that must have answers for your business to succeed.

This is the singular most powerful tool in our tool-belt for identifying the unknown, unknowns and getting them into the open.

Single Page Game Design Doc

A single page, ultra simplified game design document that explains the core game loop, mechanics, art style, inspiration, and unique elements that will stand out in this game.

Agile Software Development

I was surprised when I left the traditional software app development world and came over full time into game development and found that people weren't using feature branches, sprints, or retrospectives in game development. I've even hear people say that Agile Software Development is too much overhead for game development — and for a team of two where one is the programmer and one is the artist, and they both share all the same inspirations, ideals, and goals, I agree. But for most game development teams, I can point to emphatically research that shows the long term value of following many if not most of the agile software development discipline.

It just so happens that agile ties in very nicely to the lean business processes of testing your lean hypothesis, so stay with me on this one.

Lean Hypothesis

When you are starting a new project, even when you've done many other projects similar to this one before, there are going to be parts of your plan that are based on solid, empirical facts which don't need to be argued, but there will be just as many (and perhaps more) guesses, synthesized opinions, and inferences on what your perfect customer wants, and how you will be able to meet that need.

These guesses , ideas, and inferences are rolled up into the single term of the Lean Hypothesis. The earliest part of your work is to prove out and de-risk your highest risk hypothesis and to clearly articulate your path forward with data that you can always depend on.

Build / Measure / Learn

So now that you know that you are going to have at least a handful of hypothesis that you need to prove or disprove with data, Lean Business has a method to test those things that it calls the Build, Measure, and Learn cycle.

This process begins with you saying clearly what you believe your current highest risk hypothesis is. We will then build a Minimal Viable Game proof of concept that will allow us to test your hypothesis in isolation and with the smallest amount of effort.

An example might make this clearer.

Lets say for example that during our first meeting we say that our highest risk hypothesis of we don't have any data on how people will respond to an animated cat as the avatar in a stealth game about rescuing mice from research labs.

This is the core of your game design, so if your hypothesis about the game mechanic (stealth), the character (a cat sneaking on all four legs), and the game goal (rescuing mice from research labs) are all hypothesis that we believe will make for a fun and long term engaging game for our players, but we don't know.

Traditional indie game development will tell you to just go out there and build that game just like you imagine it and hope for the best.

Build

Lean Business says to first break that down into the 3 hypothesis we expressed above, and to then build the cheapest, smallest, most lo-fi prototypes that you can build.

Measure

You will bake in LiveOps metrics and end each prototype with a survey so that you can measure user engagement and gather their explicit feedback.

Learn

After a predefined amount of time (1 week, 4 weeks, however long you feel it takes to get feedback that feels like it has covered the range of possible feedback), you now take the user engagement raw data and the the user survey feedback and you learn from what your users have said.

Going back to our example case above. To test the goal and premise of the cat saving the mice from research labs, a lo-fi way of doing that is to draw up a very rough story board for the first few missions with quick and crude sketches showing the cat sneaking past traps, avoiding guards, finding keys, and opening cages, then afterwords the cat can safely lead his new friends to freedom.

We would then take that story board and share it to all of our social networks far and wide, asking for specific feedback via an anonymous form. People who send feedback need to be able to send you harsh criticisms even if they like you as a person, and an anonymous form is the easiest way to gather that kind of feedback.

We will ask very specific things after people complete their reading of the story board such as: Did you like the idea of a cat rescuing mice? Would you play this as a stealth / puzzle game? And the most important one that is: Would you recommend this kind of game to your family and friends?

👉
Make sure that after the person completes the form, you can should always provide them a link takes them to a separate page that allows them to join your discord, signup for your mailing list, follow you on twitter, or to wishlist your game (or all of the above). This is not just where you start to gather invaluable feedback to prove and disprove your core hypothesis, it is also where you begin to build your community. You will need to keep track of anyone who has ever asked to play a demo, to be be put on your beta, to answer surveys, and you will add them to the long list of your friends and developer peers which have expressed interest in your project. These are the people that will wishlist your game, share and back your crowdfunding, and leave you positive reviews once you launch, so make sure to ask them lots of questions, engage with them often, and listen and respond to their feedback as often as you can.

After we have sent out those story boards and surveys on the main character and core premise, we would then start our prototype work on building or buying an animated cat, designing our first 3 puzzles, and merging the story board into the game play to test the next highest risk hypothesis — that players will play and enjoy our animated cat stealth game play core game loop.

LiveOps for Game Design

I am a a big fan of how Microsoft's own Crystin Cox describes the eras of games. And along with her read on the situation, I also believe that games as a product are either near the end of their their viable life, or already past it. Shipping a game and never touching it again just doesn't happen if you want to make a business out of it.

Crystin goes on to describe Games As A Service (GaaS) to be when when MMOs and other online games were updating their content with more regular cadence including things like entire new areas of the game, new missions, and new game mechanics.

But development and shipping a Game as a Service as a lean indie is something that is very rare, and might not have been possible at all due to the complexities and costs of doing it. And that leads us to where we are today.

As a community of game makers and game players, we've learned from online games where we can update things to create better experiences for our players.

We now know that we can offer more value to our players by updating not just the content, but even the ways in which we present that content.

All of this is driven by looking closely at how our players play our games, what brings them back, and what keeps them engaged.

Building a game where you have designed with, gotten feedback from, and communicated regularly with your players all along the design phase poises you not just to have the most successful game possible, but also converts regular players into a community.

This is what Crystin Cox calls the era of Games as Cummunity.

With the LiveOps tools baked into the entire Lean process, you will already have everything in place you need to both hear and respond to how changes to our game, content, and presentation impacts your community so that you can celebrate your successes with them, and own up and correct any mistakes along the way.

Though Crystin doesn't use the Lean practices I'm proposing here, I believe strongly that her Games as Community is the best way to describe the next era of successful indie games, and my proposed combination of Lean + Agile is the most indie friendly way to de-risk, build, and manage your game as a community over the long term.

LiveOps for User Retention

LiveOps for Monetization

[ ] TODO: A Tall diagram that shows the flow from lean canvas + single page game design all the way down to Liveops loops
[ ] TODO: A Tall diagram that shows the flow from lean canvas + single page game design all the way down to Liveops loops
image
TODO: build diagram for our process

Our Process

LiveOps for Games implies the support from a lot of disparate pieces, and that is why we are here to help.

Sources

lean canvas
lean process
highest risk hypothesis
build / measure / learn