0
\$\begingroup\$

I have URL information for services (dozens of them) that I want to store in a Unity3D web player project. What is a good practice for storing it. (please don't say hard coding them)

I've recently joined a large scale Unity 3D project in the business world. I've noticed that there is no configuration file of any type. I.e. All URLs for service calls are hard coded. (among other configuration settings that are not typical for player editing)

While looking for a good solution to store/load, I'm seeing that: 1) Unity does not appear to have any kind of AppSettings. I.e. like Visual Studio dlls/exes/services might. (PlayerPrefs expressed in #3)

2) Web Player (which the project uses) does not support File IO, to store my own config.xml/config.json type file.

3) PlayerPrefs appears that it will remain isolated to the local machine. Updating the project does not replace the player prefs, and new variables are supposed to be hardcoded to populate the PlayerPrefs if those variables didn't already exist.

4) Hard Coding the values creates a hefty inconvenience, as we push our solutions from Dev to Test to Staging to Prod, we have to make sure to replace a code file. (typically systems are designed to change config files.) Additionally, once the code was built, we wouldn't be able to reasonably change the settings to experiment with different servers or other configuration changes.

What would you recommend?

\$\endgroup\$
  • \$\begingroup\$ I also have this same question on the LinkedIn Unity Group, and also on the Unity Scripting forum. --> I will repost the solution from the others if they have it first. \$\endgroup\$ – Dan Violet Sagmiller Jan 2 '15 at 14:20
  • \$\begingroup\$ Presently I'm leaning towards a Settings class with a dictionary. The settings will attempt to be populated from JSON, and attempt 2 paths. 1) it will try to load from a File IO, to find a JsonSettings.dat file, which works in everything but Web, and 2) it will attempt to send a JS Network message out to the page it is hosted in, to get the JSON settings from it instead, which only works in the web. In either case it is a JSON file, it has 2 locations it needs to live. but that I think might be the best solution at present. \$\endgroup\$ – Dan Violet Sagmiller Jan 2 '15 at 14:34
3
\$\begingroup\$

We actually got over this problem in a non-game application by using an XML file (you could also use JSON if you prefer). This is compiled into our application so we don't use IO for it, we instead use XML. This does obviously mean you have to re-compile when making changes though.

Our file looked something like this:

services.xml

<services serverURL="https://services.our-api-url.com">
    <service>
        <label><![CDATA[GETSTATUS]]></label>
        <url><![CDATA[/status]]></url>
        <method><![CDATA[GET]]></method>
        <header></header>
        <type></type>
    </service>
    <service>
        <label><![CDATA[LOGIN]]></label>
        <url><![CDATA[/session]]></url>
        <method><![CDATA[POST]]></method>
        <header></header>
        <type></type>
    </service>
    <service>
        <label><![CDATA[LOGOUT]]></label>
        <url><![CDATA[/session]]></url>
        <method><![CDATA[DELETE]]></method>
        <header><![CDATA[x-spk-auth-token]]></header>
        <type></type>
    </service>
</services>

For every new service we add a new entry on here, then we simply search for a service with the matching label name that we pass into our little setup service call function. This function then extracts out the method, any headers that are required and types and append it all correctly to our serverURL that is pulled out first.

It's a nice little way of doing this that lets us really quickly change any URL's as required.

The other alternative is to hard code one service call in that pulls down this information and parses it into an object that's held around if you really can't use a json or xml file.

\$\endgroup\$
  • \$\begingroup\$ +1 Its a good way to get this to work. I'm hoping for a solution to resolve the post compiler changes as well. thanks. \$\endgroup\$ – Dan Violet Sagmiller Jan 2 '15 at 17:49
  • \$\begingroup\$ @DanVioletSagmiller Thanks. This is going to be your biggest problem, it's always the most difficult part of building a deployed application as opposed to a web application. Normally I'd say don't compile the xml file and have a call done as part of the main setup that pulls down any deltas of the file, but you can't use File IO. It's a tricky one but I'll update if I think of anything! \$\endgroup\$ – Elliot Blackburn Jan 2 '15 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.