SRG Update #16

BAWD work since my last update has been fairly one-note, but also high-value.



As I mentioned last time, it seemed crucial to the play experience to get persistence working. The bulk of work recently has been on getting that operational. ES3 made this significantly easier than it was in my prior BAWD implementation, though there were still some hiccups to resolve with regards to model and procgen consistency (seed values, etc.).

Now, the player, galaxy, and individual mines are all persisted through a consistent interface, so the game world feels a bit more real.



In testing, I noticed that when I would get a ‘line clear’, the game froze for a split second, which is bad enough. It felt doubly awful to be “punished” rather than rewarded for completing a line.

My initial hunch was that this might have been a consequence of mine persistence: maybe I was saving to disk dozens of times when you landed?

Profiling fairly quickly revealed that I was completely wrong on that. It was actually a consequence of the way I implemented mine animation and updating. Every tile change was causing memory allocation and garbage collection, a huge no-no on mobile.

Fairly trivial fix in the end: object pooling. Microsoft has a nice open source ObjectPool implementation that, as far as I can tell, is extremely performant. Mining is pretty smooth now.



As usual, when a major feature or fix is implemented, it can expose weaknesses in other features (or their absence). I think this is because while some part of the game is incomplete, you can explain away anything “wrong” with the incompleteness. When that excuse goes away, you can see all the warts.

Now that the game saves everything, and mining is super smooth, I’m being bothered by a few key gaps:

  1. Mines have no “difficulty”. They’re interchangeable and bland.
  2. Though the abilities are implemented, they are not accessible – there’s no store to sell them!
  3. Speaking of – money means nothing at all. Zzzz.
  4. You’re stuck in a single solar system, still. It really dulls the sense of being a spacefaring mineral maestro.
  5. No music. No sound. Zzzz.

I’m still trying to decide what an MVP for this game requires, but I feel like the first three are critical. Abilities are how you cope with the awful 6- and 7-tile blocks, after all.

So my short horizon tasks are to implement the shop and module purchases, then use that to re-introduce mine difficulty. I’m sure that will expose other shortcomings, but this was always going to be a release with shortcomings.


Precious: Don’t Be

I’m continuing to push to get this ready for release ASAP.

One of the nice things about being indie and unknown is that I don’t have to be precious about an app’s first release. As long as it can make it through the app store review, what do I care if it’s not wonderful? Odds are that approximately nobody will play it, so there’s plenty of time to iterate.

In that spirit, every day I fight to keep the scope minimal. Tiny. Dainty. “Shipped” is an awesome feature.

Posted in BAWD, Developer Blog Posts, Games, News, SRG Updates

SRG Update #15

The Automyth

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.

One of the earlier things I bumped into was the requirement that I link to a privacy policy. BAWD collects no data at all, currently, so I could probably make this dead simple. However, I’d rather allow for at least some analytics, and perhaps eventually some ads, distasteful as they are. So I’ll need a reasonable policy.

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).


Legal Stuff

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”.


Dev Stuff

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!

Posted in BAWD, Developer Blog Posts, Games, News, SRG Updates