What is the problem I'm trying to solve for game developers?

It is unclear how to go from ideation on a game, to prototyping the game, to I knowing what game mechanics and loops work, to I knowing that people will pay money for it in the way which you plan to monetize the game.

How do I propose We Fix it?

Building lean inspired MVG (minimal viable game) prototyping which leads to a series of data driven build, measure, learn cycles.

Game Ideation

• I want to make a game that is like game X, but it does Y and Z instead.
• My game idea would combine game mechanic X and game mechanic Y together into the core game loop.
• The art will be of style X with flare from style Y and Z. I want it to feel like game A, but in a much further into the future
• I want the store of the game to lead the player through X, Y, and Z realizations, and bring them back to the point that they started with a new perspective A, B, and C.

Hypothesis

Anything which I believe is true about my game mechanic, core game loop, and monetization strategy, but which I cannot IMMEDIATELY present HARD DATA to support.

You will discover hypothesis in your game mechanics, core game loops, your art direction, and most certainly in your business model.

To help articulate the business model, I recommend a Lean Canvas

Simplifying Hypothesis

Sometimes a hypothesis involves too many pieces to easily test. Generally speaking, each hypothesis should be around one game mechanic or a single part of your monetization strategy. Do try to test your whole core game loop (or relationship between multiple loops) with your first hypothesis.

If you find yourself with a complex hypothesis, or you are having a hard time coming up with a simple prototype to test your hypothesis, then it is time to break it down.

To break down a hypothesis, think about splitting out one or more of the following:

• Who are you testing? What demographic? On what device? What gaming experience level?
• What about the user's experience are you testing? Are you looking for quickness to complete a mission? Or how often the person has to turn around? Or how often they have to retry the level?
• What is the viable range of responses? Can we split the ranges that people are able to respond with? If 1-5 (hate to love) is too much, asking a simple "would you recommend this game which had this game mechanic in it to a friend"

This process is also helpful if after you do your build, measure, and learn cycle, if your metrics come back inconclusive — go back to your hypothesis and follow the steps above to break it down before you test again.

Prioritizing Hypothesis

Ask yourself just two questions per each hypothesis:

• how hard is this going to be to build in a testable way
• How much of a risk to my project is it if I get this hypothesis wrong

Build

Paper prototype, existing game in engine prototype (mod), asset store "kit" based prototype, anything that is quick and dirty which will let you test the smallest number of hypothesis in isolation.

Make sure to know what it is you want to learn from this cycle, so that you can build in measurement tools to capture the data needed.

Measure

DeltaDNA + Survey Money surveys

• Best if done anonymously, but immediately after play testing the prototype
• best if done without affinity to the people you are measuring

In person process:

• Have QR Code and shortcode urls to survey monkey survey for this hypothesis
• after the person completes their survey, have them show you the "I'm done" page and then you can reward them with in game items, currency, early access, or sweepstakes to name a thing in the game.

Learn

Based on what we wanted to learn and the data that we got back, play devils advocate first. Look to see if your data can disprove your hypothesis in any way, or if it can invalidate your test methods.

Now, look to see if this data is conclusive enough on the entire hypothesis. Does it show a strong affinity to positive or negative on your feature?

If it's right in the middle and a high risk hypothesis, you have some iterating to do on this hypothesis.

If it strongly proves your hypothesis, immortalize the hypothesis with a video showing what you wanted to test + the data you got from the test (and perhaps save the playable build).

Game Mechanic

• I want the player to be able to walk around freely in a large world and to enter into challenging dungeons.
• In a dungeon, I want the player to be able to attack enemies with a combination of nanobot "magic" spells and hand weapons
• After completing the dungeon, I want the player to be able to take their rewards back to their "base" and be able to "upgrade" something.

Game Loop

The game loops are the repeated tasks that a player must go through to move forward within the world of the game.

The sandbox "base builder" core game loop:

• player must defeat and collect resources from enemies and bring them back to their "base" with a collection of functional blocks
• the player will place the raw materials into a functional blocks meant for refining
• the resources will then be refined into ingots
• the ingots can then be moved to a functional block focused on assembling components
• portions of the the ingots can then be combined to form components
• components can then be combined to form new functional blocks using projections placed by the player
• nano machine swarms will then use the components to build the projected functional blocks
• the new functional block gives the player either more capacity if it is a duplicate of an existing block,
• or the new functional blocks can offer a new "level" of function which the lower tier could not
• or a functional block might be a turret, or defensive nanobot swarm, or a shield generator, or a new power block, etc.

The sandbox "mining and world shaping" core game loop:

• either by hand (first or third person) or by building a vehicle or controllable "arm", the player is able to apply a tool to a destructible object or surface.
• the destructible object or surface has some level of resistance and a selection and measure of resources rewarded
• there may be some level of wear and tear on the tools being used to mine and shape the world
• shaping tools will require some kind of resource for fuel

The research loop:

• When the player starts the game, they have the most basic weapon, suit of armor, and blueprints to place "essential" blocks — all built into their suit.
• As the player continues to find dungeons and fight bosses, they discover new blueprints for optimized blocks (leveling up the blocks)
• After the functional block reaches its maximum level, it can now be upgraded to the next tier of block (assuming the player also has the raw materials to build the components needed for that upgrade).
• after reaching a new tier of a block, the blueprint for that tier is unlocked, and duplicates of that tier can be placed.
• A block maintains some percentage of its bonuses granted up the tiers, so that an upgraded "tier 3" block which was fully upgraded at each tier before reaching tier 3 will be much more capable than a freshly placed their 3 block.

Game Prototype

Game Monetization

Why does my game have to make money?

• To pay the developer for the opportunity cost spent when designing and developing the game that could have been used working on someone else's game (or other software) and getting paid for the work.
• To pay for art, acting, level design, character design, music, sfx vfx, and dozens of other aspects of game work that the initial developer may not be a specialist at.
• To pay for marketing and sales driving efforts to help more people play and enjoy the game
• To pay other developers to help grow and refine the game
• To be able to invest into the developers next project.