Crash Testing

Crash Testing

Like yesterday, there were more small changes and tweaks. But overall, more and more of my time is now being put into testing as we get closer to submission.

How Good is Good Enough for Gold?

Gold Medals

I’ve had an ongoing philosophical battle with my testers. I contend that in order to get Gold Medals, you have to be truly excellent. That means saving 100%, making the time goal, and having 100% tap accuracy. But they feel I’m being too harsh.

One you get a gold in one category, you can go for the gold in another. For example, you could play a level just looking to save all the trees, while having poor accuracy, but then replay with little regard for the trees while trying hard to make sure every shot counted to have total accuracy. Seems easy enough, right?

Alas, only a couple players can really get the 100% accuracy at the later levels on Normal. So today, finally, I’ve decided to relax the accuracy standard to 97% or more to get the gold. It might be a little easier — but you’re still going to have to work for it!

The Perfect Lob

Today has been mostly a large batch of small refinements: tweaking difficulty of some levels up, some down, adding sounds, adjusting graphic tweens, and a wide range of bug fixes.

The Perfect Lob

The Perfect Lob

Perhaps my favorite small fix is in the Commando Beaver’s grenade lob. Originally it followed this behavior: (1) goes up in a straight line, (2) hangs, (3) goes down in a straight line. Now the code has a much more bezier curve to it and it feels great on the screen.

It’s funny how the little touches can mean so much in a game.


Today my project exploded.

I was publishing out the newly integrated Commando Beaver build when I encountered the Blue Screen of Death! To be sure, the first screen of my game is blue before objects are added, so it just happens to coincide with Microsoft’s crash of the same namesake. Thus, it’s really just the Beaver Smash version of BSOD.

Blue Screen of Death

Blue Screen of Death

This ultimately led me on a Version Control Journey (TM).

For the uninitiated, us programmers (the wise ones) use some form of Version Control for many situations just like this as we can “rewind” back to the steps in our programming that worked, then slowly step forward to see where the problem occurred. Now while that sounds nice and speedy like a movie editor, the actual publishing from Unity-to-Xcode-to-iPad for every commit in the version control is very, very tedious and takes a lot of time.

Worse still, after putting in four or five hours tracking down the issue, you feel very drained and unmotivated. All the things you were planning to do at the start of the day were put on hold until you worked this problem out — and now you can start on them at 4pm? Meh.

So I took a break afterward and watched John Wick. It had an 83% rating on Rotten Tomatoes, so I figured I’d take a chance. It’s too bad I don’t have Version Control on my life, because I definitely would have rewound that mistake too.

The Elusive Commando Beaver

Commando Beaver -- tap the grenades he lobs before they reach your trees

Commando Beaver — tap the grenades he lobs before they reach your trees

When I was initially building the game, I had a special beaver rigged as the “Commando Beaver,” who would first appear in the Difficult Mode. In fact, he was the only one to NOT be introduced in the initial Normal Mode.

His mechanics were different than the other beavers in that he would appear, lob a grenade at a random tree, then submerge into the ground. The challenge was either tapping him before he lobbed the grenade or disarming the thrown grenade in the air before it landed on your tree.

The original plan has changed with Infinity Mode replacing Difficult Mode, which makes the original introduction moot. Plus, I’m less reluctant to place the Commando Beaver in the Normal Mode anyway as I think the majority of players will probably play there for a while before moving on to other games. So what the heck, I might as well make use of him there.

At first I thought I’d add him at a much later level — the Ground Zero chapter being the most appropriate. But then I was struck by the idea he might actually add a lot to the game if plugged in earlier on. A kind of catfish, if you will. Thus, my new build has him showing up at level 4 and appearing roughly 1 out of every 10 beavers just to see how it feels.

I guess I’ll know if this was a good idea after a lot of playtesting tomorrow…

For Immediate Release

Beaver Smash Icon

Beaver Smash Icon

In-Game Beaver

In-Game Beaver

Today I woke up and went for a two mile run and thought through all the things I could do while waiting on that DUNS number. Obviously I need to stay away from new features, but there were certainly some polish things I’d like to squeeze in since I have just a little more time.

So here’s my new short list:

  • New chapter and beaver type added. A little known secret is that I’ve actually had one beaver that was rigged and ready to go but unused. The chapter the beaver is in would require more programming than the other chapters, and I just ran out of time to implement it. The reason I’m being so vague about the beaver and its chapter is that it will likely be at the very end of the game. And if you get there — you’ll know why it took more to make it work!
  • Revamped iOS icon. Look, it’s not that our icon isn’t cool. It just doesn’t exactly fit the game, really. The beaver in the icon is a bit too cartoonish with its smaller, wide apart eyes, a rounder head and fat neck, which are counter to our rigged 3D beavers with big eyes, oblong head with big ears and skinnier necks. This won’t be a small task as it is truly the most important art you make for the game.
  •  Revamped gameplay video. This one is a no-brainer. Many graphic and effects have changed since I last captured, so I’ll need to recapture and reedit for our 30 second app store submission.

I was able to get the first task bullet mostly done, but then I had to switch gears and work on the new press release instead. (Guess which of these I enjoyed the least!)

What the DUNS?

It’s now less than two days from our intended submission date, and I’m starting to think we’re not going to make it. You might be assuming, as I would have, that it is due to us being unfinished with the work for finalizing the build. But actually it is in a pretty stable place now.

This time the bottleneck is in another’s hands, Dun and Bradstreet’s approval of our DUNS number.

If you’ve never heard of a DUNS number, you aren’t alone. I myself only learned of them six years ago when involved in some government contracting bids, which is what it is typically for. But Apple also requires them as easy screening method (on their part, not ours) to further verify the legitimacy of a business.

When I initially called them a couple weeks ago, I was pleasantly surprised that they had a special email address, appdeveloper@dnb.com, that would “expedite the process of getting a DUNS” number. I emailed them right after and got a response just a couple hours later. So far, so good!

The response pointed out that I couldn’t register “Iron Ninja Games” under the Apple app store as a Sole Proprietorship using a DBA (as I mentioned in this post earlier), which is what led me to convert us to an LLC. The conversion to LLC was a major pain and took a while, but once done I figured I could get back on that magic D&B connection and resolve the DUNS number ASAP.

But naaaaaaah.

I’ve emailed them three times over the last week and haven’t gotten a single response yet. Not feeling the expeditiousness.

Tomorrow I’m calling them again until I speak to a human. It wouldn’t be the worst thing in the world if we had to delay just a little longer, but I’d prefer it wasn’t due to something like this.

A Tale of Three Bugs

Today has been extremely productive. But to be sure, much of that productivity would be less obvious from a distance. Here’s a few examples all developers could relate to.

The Might-As-Well-Refactor Bug

I had the end credits in a “Scene” on its own in Unity, which is all well and good, but it turns out that my third party sound manager doesn’t play well with multiple scenes. Sure, I could set it up so it was persistent across scenes with a bit more coding, but instead I decided I might as well tailor the credits in the main scene anyway.

This required some refactoring of the original credits objects and the code that supported it. All in all, I think I ended up redoing about half the work I originally built. But the credits are much, much better now.

The Less-Is-More-Anyway Bug

The Video Settings page has three options, “No Video Capture”, “Buffer One Level At A Time” and “Buffer The Last 5 Minutes”. The bug was with the final choice, but ultimately it became obvious that almost no one would use it anyway, so I just subtracted the option altogether — which makes the page look better and easier anyway.

The You-Lie-Computer!!! Bug

Every single programmer deals with this, I don’t care what they say. It’s the bug that you keep rereading the same lines of code over and over and over again certain that you’re reading it properly and that everything is in order. You feel so confident that the computer is just flat wrong or maybe the application you’re building it with has a true bug in it. Sure… that’s it…

But years of experience tells us time and again that the fault lies with us, the programmer, 99.99% of the time. And most of these times it is something so small and innocuous, we can’t believe our ability to overlook it.

That was my last bug of the evening. The last level on Normal Mode wasn’t recording to disk properly and it turned out the culprit was just an extra character in one of the functions. It took an hour and a half to track that little sucker down.

Okay, computer, you win this time…

Will Our App Size Be An Issue?

Earlier this week Xcode gave the “estimated size” of our app for the App Store at 127mb. Too much! We have to be under 100mb to allow for downloads over the air, so it’s a no-brainer to optimize that last 27mb+ off.

One of the last big tasks I was set to hit was progressive download of our music. Since the music takes up 12 megs compressed and 2-3 times that uncompressed, I figured I’d get some good savings with this new structure. But after completing it, the new estimate came in at 120mb. Cue the sad violin.

What rattles me is the .ipa file — the actual app file for Ad Hoc builds — is just 48mb. These files decompress when installed onto the iOS device to become much larger of course. But I’d presume the App Store size would be more like the .ipa file than this larger estimate Xcode is giving me.

I guess as our first submission, we’ll get to find out the reality soon enough…