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!

SRG Update #14

The Animation Problem

The BAWD rewrite has two underlying systems that combine to produce animations.

The first is the actual data updates, which are scheduled and queued. For simple line clears and gravity, the scheduling is unnecessary, but it enables some pretty neat visuals for abilities.

The second is a rendering layer that watches for those data updates and takes care of all the fiddly details that make the visuals progress sensibly for players.

For far too many hours, I was struggling to get player abilities to animate consistently. Once in awhile, a certain set of actions would render in a bizarre fashion. Because of the way the two systems interacted, it was quite difficult to step through in a debugger, so I ended up building a lot of small tools to expose the progression of the data in different ways.

Eventually, something pointed to the data update system as a potential source of trouble. I was surprised, because that code felt simple, and I had written something very similar for the previous iteration of BAWD.

After a week or so of trying to manually identify what was wrong in the data updates, I resigned myself to writing unit tests to simply validate every state progressed as expected. That meant a lot of additional work, because I hadn’t written the prototype code to be as testable as some would prefer. Oops! More on that below.

The unit tests were successful, and after a brief debug session I was able to correct the issue. A few more tests later and I was able to nail down what had been messing with the animation, and voila, I was free.

Prototypes and Unit Tests

Software development is an endless journey. Every issue is a new lesson, and this one I think was valuable.

I’m generally a big believer in unit/automated testing, but not a zealot. Sometimes unit tests are overkill and don’t provide a good ROI. That said, there are some pieces of code that benefit heavily from a test harness, and the BAWD data updates fit the description.

When prototyping, I think the “this needs unit tests” hurdle is much higher. My 25/100/300h system in particular demands that I minimize unnecessary work.

What I’ve learned will hopefully help me navigate these conflicting values.

My four take-aways:

1. Writing testable code, within reason, should generally be a priority, even for a prototype. Even if I don’t write the unit tests, being able to quickly introduce them will allow me to make the right choice. This contrasts sharply with my reluctance to add them to BAWD, even when it became obvious they were needed.
2. When a piece of code starts to require that I find inventive ways to debug it, that’s a vote in favor of adding unit tests.
3. Certain kinds of code (data manipulation, especially) are often both easy and valuable to test. This is also a vote in favor of adding unit tests, even in a prototype.
4. Unit tests are a great tool for countering poor focus (from sleep deprivation, stress, burnout, etc.).

I’m sure I’ll continue to refine my sense of when to add tests to prototypes and when not to, but this experience has prompted me to adjust the 25/100/300h plan: Now, as soon as a project passes the 100h hurdle (which could occur before 100h, but either way requires that it’s had a “successful” playtest), that project shifts to a quasi-TDD mode.

I won’t strictly require (yet) that the prototype be rewritten from the ground up, so it won’t be Proper TDD. But all functionality added after that milestone will be TDD, and existing code will have tests added to it as appropriate.

The point of this decision is that after passing the 100h hurdle, I make a commitment to finish and ship the game. If I am to produce low-defect games quickly, such testing seems crucial. It’s even more crucial when working on a portfolio of games simultaneously.

Anyways, here’s to lifelong learning.

-C