A big challenge I’ve faced recently has to do with data.
“All i see is blonde, brunette, redhead…”
Getting data from non-technical people.
James created this fancy spreadsheet for Barbara to fill out for the divination part of fortunes and only have to deal with one card at a time. After handing me this huge spreadsheet I had to figure out how to get the game to use this data.
Proprietary data formats and multiple build targets
After a little bit of google research I got Unity3d and excel to play nicely and had a pseudo-database set up running pulling in data from multiple sheets in the excel file for various parts of the game. Now if any of the card values needed to change, not just the divinations but card names we could modify the spreadsheet and not worry about changing any of the code. Sounded brilliant but it only worked on a standalone windows player. A web player or android build got stuck repeatedly trying to pull in the data from a class it couldn’t properly access.
You must take your eyes away from the tree before you can see the forest
This image may or may not be a non-sequiter
I spent awhile butting my head over many days trying to get this excel file reading to work on various formats. I was almost ready to set up a PHP script on our site for the web player, but didn’t like having a separate solution for that and for android. Eventually looking at workflowy I realized i was trying to solve the wrong problem. I shouldn’t be trying to read the excel file on these separate platforms. I just need the relevant data from the excel file. Some poking from that angle revealed the Resources class in unity3d. Between a little bit of work condensing the data I need into one sheet, saving that off to a tab delimited text file, and writing some code to parse that file I’ve got the current version of fortunes working with the data on android, windows, and the web player. I don’t have a mac to test that but I’ll probably get my fiancée to test that sometime soon.
No Just Deserts today, been trying to clean up Fortunes so our client can show off what we have so far at RavenCon and at her talk at the library of congress. She wrote up an impressive amount of copy in this ungodly dark magic excel spreadsheet James designed and I’ve had fun wrangling getting unity to read from that. Apparently even if you get it working in the editor that does not mean the excel file will be moved properly when you go to build so I have to copy it manually after building each time. Future task: automate that process.
I additionally have poked around in conditional compiling since our code for saving a divination doesn’t work in a web player which is something we want to be able to do. Just in case you’re trying to do the same thing this page http://unity3d.com/support/documentation/Manual/Platform%20Dependent%20Compilation.html is helpful but not the first thing to come up when I was searching myself.
When I started working on our current project(I’ll wait until James thinks its a good idea to announce it to say what specifically it is). I was thinking let’s start on the most visible part first. Thinking that if there was something to show off it’d be helpful in gaining support.
Minor problem with this outlook is that backend type things are more of my forte, whilst graphics are a weak point. Still I wanted something to be able to show people so i trudged along getting frustrated.
The point of having something to show isn’t to have something visual though, its to have visible progress. A change in tack led me to work on the database first and come up with a way to showing the work I had done so far there. A chart of game flow and a command line prompt worked much better to both show progress and maintain motivation then my crude user interfaced hooked up to a non-responsive system could ever be.
What have I learned from this? In the future focus on the backend with the minimum amount of interface needed to be able to show what you’ve done. Even if the dummy interface isn’t going to make it into the game it can use the same hooks you will use later for the real interface, and may be how you will look for bugs later anyway.