Game Balance and where to store Variables

I have been thinking about this aspect of my game for a little while, and I have come up with the following solution. I am sure that there are problems with the way I have implemented it so any kind of feedback would be very helpful.

The idea is that there are a number of different variables in the game that together have an effect on the balance of the difficulty as well as the potential "fun" of playing the game. These variables will need to be tweaked repeatedly on the way to finalizing the game balance. Unfortunately, they are scattered around in different classes based on the scope of their effect, so some of them have to be in the Game class, some of them have to be in the Tower class, and some might even be in the Dwarf class or any other class that might be created. I don't see a way around this in an OOP context.

At first I was simply declaring constants at the top of the class, so at least they were all in one place inside the file. But trying to remember where I have the value of food and where I have the value of the cost of building a farm can be troubling. I would rather look at a list of all the variables that will potentially change for balance reasons and see/change their values all together in one place.

To achieve that I have built a GameBalance class. It provides access to the variables stored in a Settings dictionary that contains other dictionaries for the GameSettings, TowerSettings, RoomCostSettings, and any other settings that might be needed. It loads all of those values from a property list (very much like XML if you don't know Objective-C) and then the objects that need various settings make calls to the GameBalance object asking for whatever setting value they may need. That way, I can make any variable changes directly inside the property list and they will be automatically loaded into the game.

Because of the number of properties total, I have omitted some of them for this post.

DTGameBalance.h

```
#import
#import "

If you feel that the massive list of NSString * const declarations at the top of the file makes the file feel cluttered, you can always put them in their own file(s). You could even do one file for each category of constants.

My projects will frequently have a handful of files that are nothing more than NSString const declarations that I use for keys into NSUserDefaults and other dictionaries I might make use of. I even also define every storyboard segue identifier as an NSString const. There's an entire SegueNames.h file in almost every one of my iOS projects. There's usually an UserDefaultKeys.h file in my projects as well.

There's no reason why you can't have a setup like this:
DTGameBalanceKeys.h

#import "DTGameBalanceGameSettingsKeys.h"
#import "DTGameBalanceTowerSettingsKeys.h"
#import "DTGameBalanceJobCostsKeys.h"

And however many other constant files are needed. Define all your keys in those three files. Now DTGameBalance.h is nothing more than importing those three files, and then your DTGameBalance.h just imports DTGameBalanceKeys.h.

What I would definitely recommend is providing a way for this class to fetch a file provided by you online so the app checks for this file say once a day or so. This way, if you need to update the game balance, you can do so without going through the app store. If you need to change executable code, you of course need to go through the app store, but tweaking a few numbers in game balance shouldn't require going through the app store, and providing your app the ability to look online for these tweaks means your end users can get the balance changes a lot faster than having to wait for an average 5-8 days for Apple to review your update.

When you do make these server-side tweaks, I still suggest sending an update through the app store with these changes in the property list so that eventually new downloaders of your app will have the correct settings in the property list on first download without checking online for tweaks.

StackExchange Code Review Q#60076, answer score: 2