Missions

I got a few more characters and basic interaction with non-player characters (NPCs). There is some dialog and missions that can be activated through a scripted sequence of events. I want this to break up the monotony of otherwise just slaying zombies while unlocking equipment. Here are some ideas featured in some missions:

• Restriction to just one specific weapon
• Run nonstop, shooting and avoiding obstacles
• Defend behind a wall (Zombie Guard)
• Escort an NPC targeted by all zombies
• Recover item(s)
• Survive over time
• Passively only heal NPCs

Comparably, Zombie Guard has no story and the dialog is semi-random. It has unique survival modes, but otherwise is just wall-based defense. This limitation was not necessarily a bad design choice.

Quick creation of an additional character (also seen in-game below)
The body parts replace the existing skeleton animation, so no additional animation is necessary.

NPC interaction

Taking advantage of Unity's powerful Canvas rendering system for arranging UI.
A reference to a classic film.

An active mission

The text will be in English, and voice sound effects are just mumbles and gibberish so I can localize into other languages later.

The controls (bottom right of screenshots above) ordinarily used for weapons dynamically changes to NPC interaction options. Keeping it simple.

Speaking of simple, I spent the evening learning more of Unity's Canvas rendering system to avoid having to implement my own custom interface components.

Canvas related components for rendering multiple lines of text 

Just the Text component alone is insufficient for multiple lines of text that automatically scale and constrain within a desired width. An additional panel with components like ContentSizeFitter was necessary. None of this was obvious, but now it makes sense and I can see myself utilizing more of these built-in components.

Melee

It seemed necessary to include melee weapons. The collision is checked with a line segment during a key frame of the animations. At first it was not working correctly at all times, so I used Debug.DrawLine which showed me I was not properly setting a transform to the correct parent object.

I'm putting effort into better animations, and properly using a multiplier in code for the animation speeds so feet do not appear to skate across the ground. The Spine tool for animation is really practical and allows multiple animations to be blended together automatically, like walking, swinging, and pain reactions, all simultaneously.

Spine Animation Tool

Also the shader has been modified, so I can apply additive and modulated tints. As soon as I did this, it became clear that some bullet projectiles were hitting multiple targets if collided in the same frame, so this has been fixed by adding a flag that permits only one target.

Half dozen weapons

I got four weapons to show, plus more just about finished. Some extra effort was necessary for the green ooze gun which creates debris and a puddle. These components can be reused just by changing the sprites.

Oozer

Mini Blaster

Ricochet Cannon

Shotgun

The projectile system will automatically use ray-casting for continuous collision, if it is moving faster than a certain speed. There is absolutely no gun or projectile specific code in the small projectile system, because everything is data-driven through code. There are all kinds of ways of doing this, but this works best for me in the long run.

Projectile data for the Ricochet Cannon above.
Member variables are not readonly because I do change these values live.

This style is kinda something I derived from Quake games written in C, my first exposure to game code. The style just kinda stuck with me. I could instead just use more prefabs and the Unity editor interface, but I prefer code to easily search and manipulate many at once if necessary.

Xcode

Gem Heroes has successfully been built for iOS and sent off to be reviewed by Apple. There were many technical problems, as expected. In my experience distributing an app for the Apple App Store is about 20 times harder than distributing for Google Play.

Unity does not actually build the iOS app. It instead just creates an Xcode project to continue to build on a Mac. I rent one in the cloud, conveniently through a browser. It actually is pretty remarkable; I get to use the latest versions of Mac operating system without owning a Mac or upgrading the operating system.

The build settings are extraordinarily sensitive, and the errors tend to be vague and seemingly unrelated to the actual solutions.

Fail.

Fail.

The first time I added an incompatible framework which turned out to be unnecessary anyways. The second time I thought I had to change permission settings with a chmod command on a framework, but the solution was to change it from embedded to dynamically linked.

Then there were the usual certificate and provisioning problems. Apple has improved this by providing the option to automate it, but I still had to change a certificate manually when I submitted the build. Strange.

This is some really esoteric stuff. It took a lot of Googling and trial-and-error.

But I got it finished, and now I can resume progress on the new zombie game which I find to be much more interesting.