Data flow: Game design balancing data to game

Question

I'm thinking about how to get the game design balancing data (unit values, quest conditions etc.) to a game. I wonder how you would solve/have solved it?

Conditions:

• Java server
• Unity mobile client (C# scripting language)
• Git based repositories

Requirements:

• Client needs balancing data
• Server needs balancing data
• Data origin must be Excel
• Data has be available on mobile without doing an app update

First problem: Transform excel data in something readable and get it to the client/server.

My idea would be to transform the excel data to JSON and commit/push it.

Second problem: How do the client/server get the data?

My idea would be to have a service running which delivers the data via HTTP.

These ideas are quite primitive and that must be a problem many games had so solve. Didn't find any useful though.

Answer 1

My idea would be to transform the excel data to JSON and commit/push it.

Did you consider using Excel CSV files? They are just rows separated by line-breaks with values separated by semicolons. This is very version-control friendly, it is easy to write a parser for this on your server and you can just edit them with Excel without having to do any more conversion than pressing save.

Another option is to use Excel to edit XML files. This requires some work to set up, but gives you more features than plain CSV.

My idea would be to have a service running which delivers the data via HTTP.

You can do that, but considering that your server needs to read and parse the data anyway, you can also have your server send it to the client as part of your game protocol. You could either dump all the data on login or during play when the data is first needed. You could develop a fancy protocol for encoding your game data as space-conserving as possible, but unless you already know that your data will be very large, this is likely premature optimization. And if you decide that you need to conserve bandwidth, you will likely get almost the same results by simply sending your data through a stock compression algorithm like Zip.

Answer 2

First, your storage type. Let's think about it, what can be a bigger bottleneck, calculating stuff client side or sending data from client to server? Obviously the latter one.

Let's look at the same data in both json and a format made for this:

{"a":"Some String","b":{"c":9,"d":10}}

|a.Some String,b-|c-9,d-10||

A lot shorter. Especially if you send a lot of data through a connection that' not really made for these kinds of things. The latter one actually is just a simplification for json. Everything is there and I'm sure it can be converted to a JSON object on client side. Why use a pre-made format, if you can optimize it?

The second problem: Getting the data.

This depends on what you want. If the data is not mandatory, and can be updataed some time later, then I'd do something like the following:

1.) Server sends a message to the client's about the new data, **but it doesn't send the data itself**.
2.) Here the client can say 2 things:
    a) It's busy, he will get the data later
    b) You can send the data eithout a problem, so you send it
3.) In case a) if the phone becomes available to get the data, he sends a message requesting it, and then the server sends it.

If the data is mandatory, then leave out case a)