When I started working on this project I didn’t have any concrete milestones in mind, so I thought in “phases”, and now it feels silly to change to “milestone”. Anyway, Phase 3 is complete!

From Orbit Character Skins WIP - May 2017

Continuing on with the theme of this phase, the focus was on improving the look of the game.

We require more minerals

Refined and completed the 4 unit mode skins, and added or refined their unique animations, using blocked in gear. The Defender has a shield and pistol, The Medic a medical pack and hand-held data pad, The Engineer wields dual omni-tools, and The Harvester a two handed beam scythe. Construction and harvesting also got their own particle effects instead of just using copies of the healing beam.

Engineer Work Loop

While working on an Engineer animation I realized that I had made a mistake building my character rig, and the rotations of the two sides of the body were flipped. When manually animating each side individually this is barely noticeable, and thusly I did not notice it. But when attempting to make a mirrored action, and copying a pose from one side of the body to the other, things go awry.

Would you care to dance?

This was not at all surprising since this is the first character rig I’ve built myself, and I was pretty much waiting for some critical mistake to reveal itself. I investigated a few different options, including switching to a “proper” rig, such as one generated by Blender’s Rigify. But for the simplicity of the animations that I expect in the game, the added complexity of generating, animating and modifying such a complex rig seemed like asking for more trouble than I would be solving. Ultimately I decided to fix my existing rig, making minimal changes, and going through my existing animations, repairing and improving as needed.

RTS FX: Unit selection ring, health gauge, move confirmation, tile hover

The last vestiges of blatant programmer art were removed, replacing the selection ring, move marker, and path line with real art. The UI-style health bar was also replaced with an in-game gauge, and animated move command confirmation arrows were added.

On the audio side of things, Matt has updated the few placeholder sound effects in the game (heal beam, and laser shot/impact) with newly created FX built for the game. And the final desert environment music has gone into the game, the first fully completed track!

Not bugs, features

As for less flashy back-end stuff, I upgrade to Unity 5.6.1f1 without any major difficulties, switched to the new Post Processing stack, and to the runtime Navigation Mesh generation, from the previous statically baked system. If it occurs to you to wonder how I statically baked navigation information in a procedurally generated game: I baked an empty flat plane as the mesh, and then added dynamic obstacles at runtime to wall off everywhere you shouldn’t go. This actually worked perfectly fine as best I could tell, but it was nice to have an officially runtime solution come along.

Onward to Phase 4

For Phase 4 I’ll be focusing on some under the hood clean-up:

  • Moving things that are currently hard coded into more easily editable configuration files, like the data for loading each of the different mode skins and equipment.
  • Consolidating code duplication in shared functionality between different modes, eg. targeting and beam fx management.

As well as pushing the game to be more of a game

  • Improving level generation from completely random to tunable procedural
  • Parameterizing planet generation, and tying that into the overworld planet selection, providing difficulty progression
  • Providing at least one unlockable upgrade, completing the game loop and allowing you to take on the aforementioned difficulty progression

And working on ongoing content creation:

  • More sound!
  • More music!
  • More environment!
  • More enemy!

Defender Loop / Beetler Swipe FX