Balancing the Game’s Difficulty

We have created a lot of very cool features for our RTS game, and our Dragoncraft game is almost complete. However, there is one thing that could make any game be considered boring or unfair: the game’s difficulty. Whether the game is too easy without real challenges to the player, or too hard to the point of not being an enjoyable experience, it all comes down to the balance of difficulty in the game.

In this chapter, we are going to learn how to set up our Unity project to use Assemble Definition files, and how to configure the Unity Test Framework so we can use unit tests to validate the enemy and unit configurations in our game. We will also learn how to create test scripts to simulate battles between both one unit and a single enemy, and one unit and multiple enemies. Plus, we will see how we can use test scripts to help find the right balance of the game’s difficulty for the battles and the benefits that unit tests can add...

Technical requirements

The project setup with the imported assets for this chapter can be found on GitHub at https://github.com/PacktPublishing/Creating-an-RTS-game-in-Unity-2023 in the Chapter12 folder inside the project.

Writing unit tests

We have developed a lot of features and created configurations for units and enemies, while retaining the flexibility to expand and add many more characters to our RTS game. However, with such flexibility comes the difficult task of testing all the configurations to make sure the units and enemies are balanced in strength. We could continue testing the units and enemies in battle, adding them using the Debug menu while running the game in the Unity Editor, but it would take a lot of time and effort to test multiple combinations.

So far, we have added the Warrior and Mage units, and the Orc, Golem, and Dragon enemies. Later, in Chapter 14, Crafting Buildings and Defense Towers, we are going to add a feature to train the units and level them up, making them stronger. After adding the unit level-up functionality, we will have to make sure that when the Warrior and Mage units each level up, they become stronger but not overpowered, as otherwise, we will make the game...

Using unit tests to simulate battles

So far, we have used the UTF to validate our existing ScriptableObjects containing the configuration for the units, enemies, and enemy groups. Now, we are going to add new tests using the flexibility provided by the ValueSource attribute to dynamically create tests for different battle configurations. For this test script, which we will reference as a single battle simulation, we will create a list of combat scenarios with one unit against one enemy, the level of the unit, and whether we expect the unit to win the battle.

Before we start creating the test script, we are going to introduce a new calculation for the attack and defense attributes of the units, which will consider the level of the unit and which will increase in strength as they level up. The unit level-up feature will be developed later in Chapter 14, Crafting Buildings and Defense Towers, but we need to add the logic now to be able to test it properly. The enemies do not have the...

Balancing the battle difficulty

In game genres such as RTS, it is very important to have a well-balanced difficulty, otherwise the game will either be too easy and boring without challenges for the player, or too difficult, unfair, and unenjoyable. In both cases, the player will likely stop playing the game. We need to find the right balance that will make the game strategically challenging, but with a learning curve that will not punish the player right at the beginning of the session.

We could change the values in all ScriptableObjects for each unit and enemy and play all of our levels until we find the right configurations. However, that would take a long time and it is very likely that we will miss some cases when testing in-game. Fortunately, we now have a great tool to validate our configuration changes in the form of the test script that we just wrote, which can validate configurations and simulate battles in a few seconds. Indeed, we already have 50 tests that cover a lot...

Summary

Well done for reaching the end of this chapter! Although we did not add new features to the gameplay of our RTS game, we now have a very flexible and powerful tool to validate our unit and enemy configurations, as well as simulate battles to check the game balance and make informed decisions regarding our game’s difficulty.

In this chapter, we learned how to set up a Unity project using Assembly Definition files, how to set up the Unity Test Framework, and how to write unit tests that can be executed in the Unity Editor by the Test Runner.

We also learned how to create test scripts that use a list of parameters to create dynamic test cases and how to simulate a battle between both one unit and a single enemy, and one unit and multiple enemies. At the end of the chapter, we examined our data and learned how to update the difficulty curve, evaluating the impact of our changes on the balance of the game by using our test scripts to validate the configurations.

...

Further reading

The following links are recommended material to learn more about the Unity Test Framework and TDD, as well as to refresh your knowledge of the new C# features that we used in this chapter:

• Test-driven development: https://en.wikipedia.org/wiki/Test-driven_development
• Getting started with Unity Test Framework: https://docs.unity3d.com/Packages/com.unity.test-framework@1.3/manual/getting-started.html
• Testing Test-Driven Development with the Unity Test Runner: https://blog.unity.com/technology/testing-test-driven-development-with-the-unity-test-runner
• Assert: https://docs.unity3d.com/ScriptReference/Assertions.Assert.html
• Tuple types: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/value-tuples