Thanks! We're evaluating a release on PC after we get the mobile release sorted. Our current plan is to launch a free ad-supported version and a pro paid version to remove all ads side-by-side on iOS and Android. After the launch we're going to look into maybe a cheap or donation-incentive release on itch.io and other similar markets. Our build system we wrote for this can distribute to all 3 major PC OSes so at this point it's just porting over all the features optimized for mobile to a controller based input scheme (mainly menus).
This has been the first mobile game we as a team developed, so the lessons learned are almost wrapped up into the whole experience of getting it to build, getting it on the app stores, and currently how to market it. I'm the lead programmer and I can lay out a lot of the technical stuff that has been helpful for us.
A few things off the top of my head I really valued:
1. Instead of building our dependencies once or including prebuilt libs we built a C++ build system that automatically pulls down the source code from our dependencies, applies any patches we need to them, and builds them. This allowed us, on several occasions, to quickly fuzzy search for SFML symbols in our IDE to see how SFML implements something, check if a perceived problem might come from SFML, or even fix up SFML to our liking and make a patch out of it (always tried to give back with a PR into SFML when it was wise to do so). Most of our patches related to Android and iOS bugs or CMake configuration that didn't play nice with our methodology of CMake.
This didn't just extend to SFML, but rather any of the dependencies Squatbot had. We used rapidjson for JSON parsing, SFML for all the SFML-y stuff, and then our engine Ancona is pulled down and built in the same way as the other dependencies. Parallel work on the engine + game was incredibly easy with this tactic.
You can find our build system source here:
https://github.com/ild-games/Raft. An example command would be something like
raft build -r -p iOS -a x86_64
which would build our game & dependencies in release mode for iOS with an architecture of x86_64 to test it out in the simulator.
2. Instead of OS compiler directives all over the code we utilized a common pattern for OS specific code using CMake and multiple source files, 1 for each major OS. To take an example, our logging macro needs a different implementation on Android and iOS then it does on PC, so we have one header defining the macro, and then folders named after all the implemented OSes. Within each folder is a source file that implements the header in whatever way is necessary. Then finally we have a CMake file alongside the header that picks the correct source file based on the current platform chosen for the build. You can see this exact sample in our engine here:
HeaderAndroid sourceiOS sourceCMakeLists.txt next to the header3. Mobile development with one codebase is hard... but CMake can do it! I don't recommend this approach, but we actually setup CMake to create a fully loaded Xcode project every time you rebuild the game when building for iOS / macOS. This is a lesson in how powerful CMake customization is, because we can set nearly all required Xcode attributes needed for a released iPhone app. It was incredibly difficult, and not 100% there yet. Most people would make their Xcode project once and have it look towards the build folders for stuff like your dependency libs (in fact, this is the exact approach we used for Android).
4. Test early, and often, with as many phones as you can get your hands on. I have an iPhone 4 & 6, and a Motorola X4 for testing, but I've been able to utilize friends and family for testing on a wide array of modern devices. This has let us catch some problems before release. (The Samsung Galaxy line of devices seems completely broken with SFML RenderTextures in a lot of weird ways. See this thread for details:
https://en.sfml-dev.org/forums/index.php?topic=23083.msg160350#msg160350)
Show Posts
