A big challenge I've faced recently has to do with data.
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
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.
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.