50 Things a Game Economy Designer Should Know

Importance of tight and planned game economies cannot be understated.

Frank Herbert once wrote:

"He who controls the spice controls the universe."

He was correct.

I love Game Economies and Systems and have been creating them for over a decade. Some dead simple, Some massive in scale and complexity.

Because the world needs stronger digital systems & economies, I am sharing 50 things I learned.

If you love Game Design as much as I do, let's follow each other:

Beyond this point, no looking back. Once you are ready, let's begin.

01. Starting with a simple definition: A game is an objective achieved while following a set of arbitrary rules. Game economies consist of a currency, or a set of currencies, that exist to arbitrarily reward or restrict participants. As all games have arbitrary rules, all games have economies that are either hard or soft enforcers of their rules.

02. Game systems and economy design is actually UX design, don't ever forget.?

03. Web3 games are usually bad because serious economies are not compatible with good game UX.

04. Good economies feel fair and balanced, great economies are designed to feel unbalanced in the players favour, but are actually fair in reality. The best economies never quite give enough.

05. A Game’s economy is often intertwined with its system design. However game systems & economies are separate constructs. Economies define the relationship between gameplay & all of its currencies, while system design defines the formulas that produce the gameplay itself.?

06. With enough creativity, almost all game economies can (and should) be modelled in spreadsheet software. Simulation tools (such as machinations) are no substitution.?

07. Economy editability, compatibility with core game systems and quality documentation are essential, everything else is a luxury.

08. The only ceiling an economy sheet might face is the size and speed of computation modern day spreadsheet software is capable of. This ceiling can be broken by architecting an economy in several smaller modules that can operate (and break) independently without adversely affecting the whole system. e.g level system, league system, upgrade system.

?

09. A technical but important tip: Due to the need to keep systems modular, economy designers will prefer using dynamic referencing functions such as ‘index match’ in formulas. Encapsulating ‘index match’ (and the inferior ‘vlookup’) in an Array formula results in the most versatile cross referencing techniques available.?

10. Systems of anything, from intricate combat, dense puzzlers, branching narratives or tabletop games can be created in spreadsheet software. Heck, there is even a thriving community around it (see: excel rollercoasters).

11. System Designers can be considered students of classical physicists, skilled in the art of defining a game in terms of a collection of fundamental formulas and constants.

12. At the core of balanced game economies always lies thoughtful game time and daily session assumptions.?

13. If time assumptions are not quantified before all other factors, system and economy math will be arbitrary and often dumb.

14. Well planned game economies clearly define a time target for sessions or for overall game completion as static number before determining the rate of progress for a games objectives.

15. Rate of earning currency, level completion time, event probability should be a product of the designers desired rate of progression.

16. Designing an economy only for the average player is what average game designers do, sorry not sorry!

17. Designing for the 75 percentile of engaged users is how you really make money in freemium games.

18. Excellent game systems and economies balance for multiple player engagement personas on the time and skill spectrum.

19. Everything about a player persona should be quantifiable, e.g skill in a pvp game can be quantified in terms of win %, traversal time, points scored.

20. Conceptually, multiple progression vectors sound complex to manage. But in practice, they are independent systems that may align occasionally via currency requirements.

21. It takes a few shipped games for a designer to understand how numbers in practice effect player emotions.?

22. AI in games are often decision trees, and decision trees are systems. It’s the job of system design to make your game pieces convey emotions and intelligence.

23. The best game economies often avoid complex math & dense formulas.

24. You can simulate time intervals in spreadsheet software by using rows as time slices.

25. Logarithms solve most tuning problems by allowing designers to focus on the destination rather than the curve.

26. Using logarithms/formula driven balance causes most tuning problems due to lack of curve control.

27. Manually balancing numbers to achieve the desired UX is often smarter than tinkering with a formula/curve to fit all cases.

28. Employing manual balance in all cases is the dumbest, and most difficult way to construct a system.

29. Devote 10% of your time to make sure your data can be parsed by the game code, do this to avoid refactoring your economy and systems so that it can export readable data.

30. If a programmer has to spend time building a tool, compiler, exporter, for your economy model to be readable in code, you have failed.?

31. Don’t assume your elder game will ‘work in theory’. Design with clear UX intentions and simulate considering multiple user personas.

32. While your economies and systems may be thoroughly tested, a playtest is needed to challenge your assumptions.

33. Specialised balancing tools like machinations are helpful for tuning systems, but be aware these tools are still lightyears behind modern spreadsheet software in terms of versatility and compatibility.

34. Whether in production or live ops, don't let the parameters that control your economy or systems get hard coded into the server or client logic.

35. Making the server the authority on your game economy and system parameters vastly reduces cheating & keeps everyone in sync. However this approach hinders ‘offline’ play, incurs some cost & can cause longer load times.

36. Good economies are a group of systems that cross reference to build stronger overall balance.

37. Setting up conditional error checking saves hours of debugging.

38. Refactor when a system is getting 'foggy', wherein your changes are producing seemingly random unintended consequences.

39. Random number generators should not be used. Good balance comes from defining probabilities and their outcomes over time. E.g a 10% probability of earning 100 coins on a wheel spin = 100*0.1 per spin average.

40. Good economy sheets are like good code easily readable and editable.

41. Commenting excel sheets is as important as commenting code

42. Colour code input, output cells. Guaranteed you will forget what cells required input.

43. Master Query and Array formulas to unlock versatility in data parsing and cleaner outputs, although be prepared for a harder time debugging.

44. Reverse engineer economies of other games by taking notes on any currency modifications against time and actions. Work out the dollar to in-game currency conversion to derive how much the game you are deconstructing values time.

45. Don’t use the same damn progression curve for everything, use your brain! Pick the sequence that produces the desired UX. Typically: Exponential, Exponential Decay, linear, step, parabola open, parabola close.

46. Think about the player's perception of the numbers on screen. Getting a prize of 100,000 always feels better than a prize of 10. A discount of 63% feels a lot more personalised than one of 60%. It's not always about the rate of progression.

47. A great economy is not worth much if you cannot convey its value to the stakeholders who may not be numerically inclined! Highlighting key points of an economy through graphs, colour coding and the effect on KPIs are some ways to do this.

48. Design a base difficulty before layering on additional elastic banding or any dynamic logic

49. System & Economy Design are separate muscles that need to be trained and built, seek out interesting game design tests and solve them! (Here is a quick system test: Design a Judging system for a DDR game. One song has 250 moves, three judges should score the players performance out of 10, Judges should have different personalities, a perfect performance should always result in a perfect score)

50. Real world economic case studies provide insights that are relevant to games as well! (See: Steven Levitt and Mark Duggan’s paper on cheating in sumo wrestling)

...Can you think of a point for number 51?

Thank you for making it this far, if you enjoyed reading let's follow each other and share more 'design things'!

The Spice must flow!