SRG Update #15
My focus recently has been on preparing BAWD, incomplete as it is, to be “submission ready” for the iOS app store.
I imagine almost everyone in the “solo indie app dev” space has struggled with with getting an initial game or app out the door. It begins to feel quite critical that something get shipped.
Once a thing is shipped, the story of your indie dev-ness can change a little.
If you work on games at all, without a publisher, the sentence “I am an indie game dev” is true. But if I were to say that to someone, I would feel an urge to immediately clarify: “But I haven’t shipped anything yet.” I don’t want to lie through omission or implication.
After you ship, you’re likely to still feel that urge, but at least the sentence is different. I expect mine to be something like “I’ve got one little game out so far, but hey, got my first dollar!”
That’s important. In the same way that people taking tests in lab coats may perform better, I think that “wearing” a better story about yourself can have an impact on your motivation, your focus, and your happiness.
So: my goal is to ship BAWD “soonish”, definitely in 2019, but ideally Q3. To achieve this, I am aiming to get it within a button push of submission to the iOS app store, and maintain that status until it’s time to ship.
The App Store Submission Process
Submitting an app for review is not what I’d call complex, but there is a sense of lurking unknowns.
To pursue this, I initially just read around, trying to figure out how difficult it is. What I came to believe is that an ounce of prevention (hiring an attorney to – at least – review and bless my policies) is worth a pound of cure (whatever horrific judgments the legal system might foist upon my legally unsound flegdling company).
So, with that in mind, I met this month with someone from a law group who has experience working with indie game studios. I was directed to them by someone in my local indie dev game group PIGSquad, and I was not led astray: it was an encouraging, valuable conversation.
Now, I merely need to decide what data will be collected, and for a modest fee I can get that converted into something that will hopefully reduce my legal attack surface.
So what I’ll be doing over the next month or so is:
- identifying games that do something similar with data, then
- take a look at their privacy policies (and other policies/docs, if available)
- from that, develop a sense of what I find personally skeezy, and what seems acceptable
- then cross-reference that with the things I feel I need to do (e.g., I really feel gameplay analytics are crucial to develop an enjoyable game)
- finally, come up with a final list of what I expect BAWD (and, perhaps, other future games) to need to disclose
Then I send that list to the aforementioned law group, pay the invoice, and voila: my app is dramatically closer to “submission ready”.
In addition to working on sorting out legal documentation, I’ve been trying to determine the list of features that I think are required for this game to actually survive the review process.
Then, I’ve been prioritizing those features and starting to work on them.
First and foremost is “data persistence”: your efforts as a player should survive the app being shut down.
Follow the theme of this (and, I expect, every) rewrite, this has turned into much more work than expected, thanks to an odd alignment of factors.
I had been using the Unity Asset “Easy Save 2” for years, and haven’t had any problems with it. It’s pretty intuitive, performant, and stable.
I figured upgrading to the new edition, ES3, would be straightforward. Normally, I think it would be. However, a small tweak I made to BAWD at some point came back to bite me: I’m using a custom Main.dll assembly.
ES2/3 make heavy use of C# Reflection to do their work, but with my custom assembly in place I was getting strange exceptions that I couldn’t follow.
Thankfully, Moodkie are awesome and helped me sort it out before long. Full steam ahead!