8 Tooltime data parsing

 

This chapter covers

  • Simplifying our development workflow and helping with testing gameplay changes by storing our balance data separately from runtime assets.
  • Eliminating costly runtime checks by validating balance data during tool time.
  • Handling live balance updates and A/B testing.
  • Handling substantial gameplay changes.

We have seen how separating the dynamic, editable parts of the asset data from the asset itself can both simplify and accelerate our development process. We took the dynamic parts of our menu assets and stored them in the GUIRef script. This serves as an additional check for artists to ensure they have included all the necessary components, and makes it easy for engineers to identify the components they need to modify via code.

We want to do the same thing with our balance data. At this time, our balance data can only be edited through the Game GameObject in the Unity scene. We want to separate the balance data from our scene by moving it to an external asset, making it easier for designers to work on it. After all, we may be working with multiple game designers who all want to modify the balance simultaneously.

8.1 Moving balance data to an external asset

8.2 Parsing the balance

8.3 Loading the balance

8.4 Validating balance data at tool time

8.5 Handling live balance updates

8.6 A/B Testing

8.7 Handling changes

8.7.1 Moving enemies at a constant velocity

8.7.2 Enemies should move towards the player

8.7.3 Enemies should spawn off-screen in a circle around the player

8.7.4 Enemies should not overlap

8.7.5 The player should always be in the center of the screen

8.8 Conclusion

8.9 Summary