Validating a game idea using a text-based adventure

Three weeks ago I published the first version of "You can establish a trade route". It was a short text adventure. The plater is presented with a short text and an image and can choose their next action.

My goals in this version were:

1. Validating decision model
2. Validating the theme
3. Creating some content for future versions

Being stuck

I've been trying to work on this game for a while now. Each time I would start wireframing some UI or even start coding. And each time I got the feeling that it's not really clear to me what exactly am I doing.

At some point, I watched a video by Jonas Tyroller titled How to design a decision. I liked the analytic approach to designing the player decision, so I set down to specify the core decisions the player would face in my game:

Freedom - what can the player do?

1. Travel or stay
2. Buy food (in future versions: buy equipment and properties)
3. Negotiate deals and prices

Impact - what are the results of the player actions?

1. Get and spend money
2. Create demand for trade
3. In future versions: change prices, equipment and property have impacts

Understanding - what does the player understand about the meaning of their actions?

1. Money and inventory demand if the player wins or loses. Not enough money means losing.
2. Demand is affected by the player's reputation as a treader.

Challenge - what should the player find out during playing and overcome?

1. Waiting in a town allows to collect more goods and make more money but also costs money

I then realized a few things. First, in order to validate this model, I don't need to have the UX, UI, and code of the full game. I only need to implement this decision model in some game mechanics, and the fastest implementation will enable me the fastest validation.

Second, that it might be that my can will be made of several parts, each in its own genre and own code. High-budget titles back different genres into the same code and engine, but it's not a must for me.

What does validation mean?

My day job is as a product manager, and product validation is a great deal of a product manager’s work. Usually, it is made of verifying with real users that two statements are true:

1. People do have this problem or need, which we aim to solve, to a degree they are willing to do something about it (in most cases: pay).
2. Our product can solve this problem or need.

The first is also known as Market Risk and the latter as Product risk.

An interesting book recently recommended to me by a colleague, The Mom Test, strongly argues that for games, only the product risk matters:

Video games are pure product risk. What sort of question could you ask to validate your game idea? “Do you like having fun? Would you like to have even more fun?” Practically 100% of the risk is in the product and almost none is in the customer. You know people buy games. If yours is good and you can find a way to make them notice it, they’ll buy it. (p. 54)

So how to validate a video game? I decided to combine two notions: the first is a well-known game design principle stipulating that “All the best games are easy to learn and difficult to master”, also known as Bushnell's Law or Nolan's Law. The second notion comes from classic product management thinking: the best metric for product value is retention. If people come again and again to use your product it means it solves a problem for them.

Combining both, I drew the following:

If people find the game both interesting and easy to learn - hard to master, we should expect them to lose a few times and try again.

If they don’t lose it means the game is not hard to master. If the game is not easy to learn they won’t understand how the game works and won’t have a general or vague notion of why they lost, thus no motivation to try again. Last, if the general experience is not appealing, they won’t try again.

Implementation

So I wrote down a script and specified the decision points and made sure they demonstrate my decision model.

Then I quickly created a text-based adventure. It was a very bad code. Not scalable, hard to maintain and test. But I knew I don't need anything more than that as it was made only to hold this very specific script.

Overall, end to end, the game takes about a minute to complete (it is a very short script). You can either lose the game or win it and get a score between 1-5.

The reason I developed from scratch in Unity and did not use a text-based engine like Twine is that I wanted to implement a strong analytics platform I am familiar with, namely Mixpanel. Since my goal was to validate, I needed to analyze player actions in a deep way.

A Windows version of this version is attached to this devlog.

Results

A total of 37 users played the game. Out of them, 27 (73%) played the game more than 3 times, and 11 (30%) people played it more than 5 times.

Out of the 37, 17 (45%) won the game. Out of these, 5 (41%) won the game more than once.

Conclusion

For me, these numbers were a positive result. They demonstrated that a big enough portion of the player lose and want to try again. Of course, these are small numbers, but they are enough for some validation. If only a few people were willing to play again after losing, it surely meant the game is either not easy to learn and hard to master, or just not interesting.

So I moved to create the next version of the game, now available on the game page on itch.io. The second version starts with a similar text-based adventure and then moves to a map-based (slightly) open-world style.