So this sprint my goal was just to get the game running on iOS. Since I don’t have a mac I thought this was going to take a ton of time or even be impossible. I spent a little bit of time googling around and there was a lot of despair about it and the only accepted answers were to use a virtual machine. I was not into that idea. Thankfully I did not have to tread there because I found this.
With a few slight modifications I was able to get all of the required files to create a mobile provision and signing certificate. I plugged all of that into Unity Cloud Build and I was able to get a build of my game onto my phone, all without a mac. Ok, so that was easy, but I quickly ran into some problems.
First of all, none of the characters appeared on screen. I had been just saving .mb files from Maya and using them as the basis for my content. This works fine on the PC. It turns out that Unity Cloud Build does not support this. Unity uses Maya (and its FBX SDK) in the background to silently turn your .mb files into .fbx files apparently, and Unity Cloud Build won’t do that for you. Makes sense. I just did not anticipate it. So what did this mean? I had to open and re-export all of my .mb files to .fbx, remake prefabs based on them, fix up materials, and reconnect any references to the new prefabs. Thankfully I had less than 20 .mb files across the two models I have been working with so far so this wasn’t that bad. This could have been a production nightmare if I found this out at the end.
All of this took only a couple days so I threw a bunch of touch input work into this sprint and got busy. First I added simple taps and then I added swipe gestures. Ultimately the swipe gestures did not work out for what I’m trying to do. I really liked how the swipes worked in Tiny Rogue but that game takes place in a single screen and the pace is much slower than what I am going for, so it ended up being frustrating to swipe repeatedly to move quickly over longer distances. Anyways, it quickly became evident that the frame rate was not great. As I was googling around about input handling on iOS I came across threads talking about how terrible performance on iOS is when using OnGUI and UnityEvents. Shiiiiiiiiiit. I’m doing that. The whole architecture I am using is based on polling for events in OnGUI, processing them in Update, and rendering the camera into a texture and blitting that after doing a yield return new WaitForEndOfFrame(). I may need to rethink this.
I decided to put that on the shelf–I heard premature optimization is the devil. The last thing I did this sprint was to add a DPad control that only shows up on iOS and get tap inputs working which move the character around.
And, here is this sprint’s Task Board
Next sprint I am finally going to tackle tile layers, both dynamically created tiles and preauthored levels.