I noticed that it had been a wee while since a post was made, so I thought I would say hello and give you all an update.

Hey everyone! I’m Navi, the newest member of Dinosaur Polo Club. I’m here to help out with Production, Customer Service, QA, some game development, and what ever else comes up. I was born and raised in Vancouver, Canada. After several years of university education, I spent six years teaching primary school to some of the most lovely children I know. Eventually, I decided it was time for an adventure, and I wandered to Toronto for a while before landing in Wellington. After meeting the amazing dev communities in all three cities, I decided it was time to change up my career and work toward becoming a Producer at a Game Studio. I began my dev journey in QA with the lovely people at PikPok. I learned a ton about the process of how games are made, and worked on several titles in various stages of development and release. When I discovered that Dinosaur Polo Club was looking for a Producer, I thought I’d give it a shot, and now I’m here! My life is not all just fun and games *groan*, I like to ref roller derby, swing/tap dance, knit, sample a variety of beers, wines, whiskeys, and cheeses, and, of course, play games (both video games and tabletop). But that’s enough about me.

What’s new with the game?

After many hopeful requests from our community, endless mode is coming to mobile! Robert and Peter are having a good look at how to make some improvements to the existing endless mode on the Steam version of the game and will be releasing the finished product to all versions.

We are also looking into a persistent pathfinding bug that is causing our passengers to skip their trains. We don’t have a fixed date for when this fix will be out, but it’s in the works. *cross our hearts*

Cheers!
- Navi

It’s been a good long while since Mini Metro was launched on Steam, and you’d be forgiven for thinking that we haven’t done a whole lot else since then. However rest assured we are still working hard to get you more Mini Metro! We’d like to tell you a little about what we’ve been keeping ourselves busy with since the launch in November 2015.

Back in mid-2015 we teamed up with Lucy Morris (IGDA director, half of indie studio Group Pug, and lecturer at Media Design School) to organise Play by Play, a videogame festival here in Wellington in April. This took up a chunk of our time in 2015 but a much larger amount in early 2016. It was a wonderful event and a huge success, but definitely impacted the amount of time we were able to spend on Mini Metro.

That aside, here’s a month-by-month breakdown since launch highlighting how many commits we made to our repository, and the major things we did or worked on in that month:

November 2015

135 commits

Launch month! We released Mini Metro on to Steam, Humble, and GOG. Our distribution partners Plug In Digital and Playism also worked to put it on to many more digital storefronts, and Koch Media got it onto store shelves in some parts of Europe. The plan for us was to jump right onto the mobile version, however the launch went much better than we expected so it was all hands to the pump to answer emails, tweets, forum posts, respond to key requests from streamers, YouTubers, and reviewers.

December 2015

54 commits

A short month due to the Christmas holidays. As it’s summer in New Zealand we have our big family holidays at this time. We were still catching up on launch support but found some time to work on gameplay experiments such as allowing lines to cross - this change still hasn’t made it in but will be in the mobile release!

January 2016

51 commits

January saw us start full-scale work on the mobile builds. We tweaked the existing phone interface and added a tablet interface.

February 2016

80 commits

More work on the phone and tablet UI, as well as mobile performance improvements and audio compatibility work.

March 2016

51 commits

March is always a busy time for game developers, as the annual Game Developers’ Conference in held in San Francisco at this time. This year was especially important for us because Mini Metro had been nominated for four IGF awards! We were in San Francisco from March 13th till March 19th, plus a day on either side for travel. Play by Play organisation was taking up most of our time not overseas.

April 2016

29 commits

April was also a very busy month for us that didn’t see much development time. We were back in New Zealand for just a few days before we jumped back on a plane to spend ten days in London for the London Games Festival and the BAFTA Games Awards - we were surprised to find out that Mini Metro had been nominated for Best Debut. We figured we wouldn’t get the chance to go to the BAFTAs often so might as well take the opportunity! Once back in the country we had a little over a week before Play by Play began, and then that ran for the week of April the 18th till the 23rd.

May 2016

73 commits (so far)

May, a beautiful month! In May we’ve been really enjoying being back on Mini Metro fulltime after our five-week three-conference world tour. It’s seen some changes in the company too. We have adopted agile work practices to keep us focused on the important work. We’ve moved out of a co-working space and into our own office, and arranged for two interns to join the team for a few weeks later on in June and July. On the Mini Metro side we’ve implemented pinch-zooming for mobile and released a desktop patch with fixes for a lot of small issues.

So that’s been our adventures since the desktop launch! The next few months will see us back working hard on the mobile versions to get them submitted as soon as possible, working with our first interns, and also a bit of office redecoration. Exciting times ahead!

I blogged previously about the build system that we’ve written for Mini Metro; the idea is from just one command on the terminal, we can have any number of platforms built and deployed remotely without any further interaction. This has been working well for the desktop builds for months, but not for iOS.

We faced two problems getting the build system to support iOS properly. First, Unity’s build command doesn’t output an executable for iOS, only an Xcode project. Second, how can we deploy an iOS app from the command line?

Command-line Xcode build

The first step was the easiest to solve. Once Unity’s built your Xcode project, you’re just a couple of commands away from a packaged iOS build. We run the following command from the Xcode project folder:

xcodebuild -project Unity-iPhone.xcodeproj -scheme Unity-iPhone archive -archivePath [output.xcarchive] -configuration Release OTHER_LDFLAGS=“-framework GameKit” PROVISIONING_PROFILE=[provisioningProfileId] CODE_SIGN_IDENTITY=“[codeSigningIdentity]”

The tricky bit is (as always!) the provisioning profile. You need to specify the id of an Ad Hoc Distribution profile that you’ve got loaded into Xcode. The id is tricky to find; go in to Preferences, click View Details… for your team, right-click on the appropriate profile and select Show in Finder. What you’re after is the filename (it should be all hex, with a few dashes) without the .mobileprovision extension.

The code signing identity is of the form “App Developer (DUCNFCN445)”. If you don’t know yours off by heart, you can get a list of all entities with the command security find-identity -v -p codesigning. (Thanks, as always, to Stack Overflow.)

Also note the GameKit reference! Unity produces an Xcode build without GameKit included, so this line just ensures that it’s linked to. Took me a while to figure that one out. :|

Assuming the stars align, that command will produce a signed archived build with the .xarchive extension. You can’t do much with it directly (most of this iOS voodoo is a mystery to me!), but with one more command we can extract a distributable package.

xcrun -sdk iphoneos PackageApplication -v [input.xcarchive]/Products/Applications/[appname].app -o [output.ipa]

And, Thor willing, you’ve got yourself a nice shiny .ipa file! From here, you can take the easy route and distribute this build through whatever means necessary to your dev or test team. Double-clicking it will load it into iTunes, and from there you can sync it on to any devices that were included in the provisioning profile it was packaged with.

Or …

Wireless deployment

This part is a fair chunk of work, and might not be worth it. It depends on how frequently you do builds, how difficult it is to get the builds to everyone on your team, and how decent your sysadmin skills are. For the record, my Linux-fu is barely adequate. I know just enough to follow step-by-step guides and get myself in trouble.

Apple have a good write-up on how the wireless deployment goes here. It’s a fairly straightforward process, but it took me a while to get it properly automated on the server.

The first step is actually getting the .ipa up to the server. We already have an SCP deployment target for our builds, so I simply hooked that target up to the iOS build configuration.

Second, we had to provide an SSL connection. As this isn’t a front-facing website I’d normally just use a self-signed certificate and click through the warnings, but you don’t have that option with wireless deployment. If the SSL certificate isn’t on the device’s Trust Store it will ignore the request. After a Twitter rant about how shady SSL certificate providers are, a number of helpful people pointed me to letsencrypt.com. Big thumbs up! This tool allows you to generate secure, trusted 90-day certificates nearly instantly. It’s still in beta, and only provides automatic certificate installation for Apache—as we use Nginx we had a bit more coding to do, but not much. It all worked straight out of the box.

Next, MIME types! As your server will be serving a .plist and .ipa file, you need to ensure that the server knows the correct MIME types for those extensions. I had to add them both to our Nginx configuration.

Now you need to provide access from the server to both the manifest .plist file describing the build (an example manifest is in the Apple docs linked above), and the build itself. You could simply copy Apple’s example manifest, edit the appropriate fields, and dump that on your server. If you know what the filename of the .ipa is going to be, then that’ll work fine—just strip out the optional checksum fields and you’re set. I wanted to support multiple named builds, so had to automate the .plist generation. My first solution was to specify a .php file as the manifest URL, and have that .php file generate the manifest. However Safari just didn’t like it; I think it needs the manifest file to have a .plist extension. I had a stab at redirecting the .plist link to execute the .php file but … err, I’m not sure what went wrong. Amateur sysadmin, remember! So in the end I took a less elegant approach. The process is now as follows:

1. Build is uploaded to the server.
   
2. I send an install URL to the dev team; this is something like https://test.com/install.php?build=[buildname]. Anyone who wants the new build opens the link on their iOS device.
3. When install.php is executed, it finds the appropriately named .ipa on the server. It calculates the checksums and generates a manifest for the build, saving it to disk.
4. install.php sends a Location HTTP header to redirect Safari to the manifest. This is the itms-services:// link documented in the Apple docs.

And it works! Stoked that I managed to bumble my way around the process, and that we have an iOS build deployment system that’s much more automated than I thought I’d be able to manage.