Behind the curtains: Internal note for Bronze Age II test (Part I)

Pavlenko Daniil
Mithraeum
Published in
6 min readOct 14, 2022

Introduction

Game development is an exciting and creative process, but let’s be honest — it is also challenging. And while players enjoy the game, they rarely see how the development happens — the process of building a game, making decisions, and reasons for taking one particular path remains behind the curtains.

We decided to lift such a curtain and offer our community a glimpse into the process of how game design decisions are made within the Mithraeum team. And thus, we publish one of the internal notes written before the Bronze Age II test. You can see what problems were significant for the dev team, how we tried to solve them, and now knowing the Bronze Age II situation, consider to what extent we succeeded in solving them.

Challenges and Limitations

After the winter test, the Mithraeum team analyzed the test results, collected the players’ feedback, and reflected upon the findings. In the summer test, we plan to solve two main problems at the level of game design:

  • Increasing the impact of liquid transferable resources as a counter-strategy for the winter test practices, where internal non-transferable resources played the primary role.
  • Fighting against the algorithmic behavior of the players, which includes both pure bots and the “bee swarm” strategy, where each player simply follows the instructions from above.

In addition, it is essential to note that we are in a situation of “great ambitions, limited opportunities,” which in many cases is the reason for the unusual and non-standard solutions chosen.

Another limiting factor is the relatively small number of tests we can afford and their unique specifications. These conditions nearly exclude the possibility of creating a game balance in the classical empirical way — when an ideal or satisfactory balance is selected from many tests and iterations. We also do not and cannot know in advance the motives and preferences of the players, so the theoretical balance calculation is not an option for us. Therefore, most mechanics include the concept of “stable equilibrium” — a concept from physics where a state tends to continually return to one close to equilibrium.

We demonstrate further how it can be applied to our game design.

We try not to use mechanics that fall under the definition of an “isolated problem,” a problem that a player can solve using a limited amount of data and factors, ignoring everything that happens outside this mechanic. Such a mechanic has a limited number of solutions. As a result, it does not compensate for gas and development costs — therefore, it should not be an option on the blockchain in principle.

Let’s separately consider the military mechanics and the ideology of the conflict. We want to avoid the situation described in the joke about eating soap in turn on a dare. That is when the potential benefit from the dispute does not exceed the costs spent on it. Particularly considering that the enemy may also want to take revanche, at least to restore the reputation and status quo.

We believe that in a good situation, the benefit for the player should be many times greater than the expected costs and losses. Along the way, the circumstances may change if the enemy wishes and finds an opportunity to raise the stakes. But such a development should not be analytically calculated. It should expand the conflict’s geography and size, capturing even those who have not even thought about war or considered they are in a safe position.

Bonding Curve of Troops

One of the main failed mechanics in the winter test was turning settlers into the infantry. Despite the initial assumptions and logical argumentations in its favor, this mechanic turned out to contain the following disadvantages:

  • the inability to balance the proportion of two components: tools as an “external” resource and settlers as an “internal” resource, which inevitably led to a situation where one of these components began to dominate and reduce the influence of the second to negligible;
  • extreme predictability of the battle devoid of the risk factor and uncertainty;
  • impossibility of a flexible balance between war and economy;
  • the devastating effect of long or failed military operations on the economy of the settlement;
  • extreme attacker’s dependence on the defender’s desire to make peace;
  • disregard to diplomacy — the goal of 90% of military operations was the competitors’ destruction. A diplomatic solution in the form of a mutually beneficial payment of tribute was not even considered;
  • the break of the entire chain of logic for the creation and use of resources as a whole, which resulted in huge surpluses and accelerated devaluation

We decided to radically change the principle of hiring troops to solve this problem. Now they are:

  • do not require settlers;
  • require only tools, and the zonal Bonding Curve determines the price with mechanics similar to hiring settlers.

While this approach solves the abovementioned problems, it is expected to cause another range of issues. We can distinguish the following:

  • fort problem;
  • balance problem between shortage and surplus of settlers;
  • low predictability of the price and number of troops, which seems to interfere with balancing their impact on the economy

We return to these problems later. For now, we will just say they are solvable.

Types of Troops

The main complaint to the military system was its dependence on a simple number of troops and not on the management quality (if we ignore a couple of abuses). In most cases, it led to a situation where two factors were decisive in the war: the number of supporters and the willingness to sacrifice their economy for the common good.

We are not satisfied with such a development of events for many reasons. The solution to this problem would be to increase the individual contribution of each player to tactics and strategy, preferably with the help of not expensive mechanics in development. One of these mechanics is the variety of troop types, and we decided to focus on it.

It is crucial to bring the solutions that open up to the player beyond the scope of an isolated problem. In no case could it be possible to come to a situation where the player simply finds one universal build and uses it all the time. This same build is likely to be used by all other players, leading to the same quantity competition, not quality.

The solution was found in the situational position of each player and the fact that the players do not fight evenly but rather tend to get an overwhelming advantage, and their goal in most battles can be described as “getting the most profitable exchange” — ideally, 1 to 10. We decided to give players this opportunity.

Now the player must choose an army composition so that, for example, when he is in the majority, he can destroy the enemy army almost without loss, or vice versa, being in the minority, scare away the superior enemy with significant mutual damage. The system encourages the change of the battle beneficiary. Reinforcements, insignificant in number but very sudden, can seriously damage the counterpart’s calculations

The present article is the first part of the internal note. We will publish the second part in our next post. We hope that by providing our community with a glimpse into the game development, we answer some questions that our players might have had in mind. There is always room for improvement, and we will continue developing the game further, bringing new mechanics and making the game more ambitious.

Have questions or ideas? Join our discord, and participate in discussions.

Join Mithraeum community:

Website: https://mithraeum.io/
Discord: https://discord.gg/bna7WrWmBn
Twitter: https://twitter.com/MithraeumIO

--

--