Development Update

01/06/2016

I know it’s been a long long time since my last development update, almost a year! The reason is very simply because the things I’ve been doing have been tediously boring, at least to my mind anyway. Here’s a brief summary of what I’ve been doing on Alaska for the last 10 months. I expect this will be my last development update before I start my greenlight campaign, I currently estimate i’ll be ready to go on greenlight in July or August.

Anniversary

Last month was the 5 year development anniversary of Alaska, my original estimate was a 3 year project but I’ve changed jobs twice, got married and had 2 amazing kids in that time and those things all take priority, as they should. This is what it looked like 5 years ago:

1

It’s come a long way since then. I’m pretty proud of what I’ve achieved, personally.

So What have I been doing over the last 10 months?

Moving Repo, Moving IDE, C++11 (Aug-Oct)

So the first thing I did after my last blog post was do a lot of long overdue clean-up. Moving to visual studio 2015, updating build flags and dependencies and generally tidying up the build. As part of that I also moved to git which has taken a load of as subversion is a pain to work with. I backed up all my source assets too. With the move to visual studio 2015, I can now support C++11 properly which meant I could clean up some crusty code.

Moving from Windows 7 and Visual Studio 2012 to Windows 10 and Visual Studio 2015 forced me to migrate from the old DirectX SDK to DirectX included in the Windows SDK. I’m still using D3D10 and effects. I’m not moving mid development and this meant reworking some stuff to work better with the new SDK & IDE. It’s better in the long run but PIX still doesn’t work properly with old effects and that’s a nuisance.

This all took a few months but It was important because it made a lot of things that had become a slog less so and it was time away from the mammoth job i’d unwittingly undertaken in my last blog post, the dreaded character import pipeline rework.

Bug Fixes (Nov & Febuary)

Mainly as a consequence of changing lots of stuff related to the build there were a few weird bug fixes that needed addressed, I did some of these in November and some in February.

  • BSP Loading was very slow (one small part was 75% of the load time)
  • luabind threw exceptions in the destructor and vs2015 rightly didn’t like that
  • a couple of materials and reusing some render buffers were causing visual issues
  • The Game Entities used their address in memory as their guid! Need real guids.

Fixing all these issues meant I had to do the job I’d been avoiding:

The Dreaded Character Import Pipeline Rework (Nov-Mar)

AlaskaPromo.png

My character import pipeline is a disgrace, It is laughably fragile and I’ve paid dearly for it. If this was my full time job I would have allotted much more time to making it more stable but I figured I would only have to do it once or twice and so I could just suffer.

My import pipeline currently consists of:

  • Build and Rig the characters in Mixamo Fuse
  • Load the model in Blender and cut away all the hidden verts (teeth, joins)
  • Reduce the poly count as much as possible with decimate
  • Import the Rig with all the animations, repose & bind it
  • Export the rig and all animations, one by one to collada
  • Make DDS versions of all the textures

Alaska is quite rare for a small indie game in that it has 13 unique characters and this process is very manual, laborious and error prone. It took me a long time doing it manually before I decided to try and automate it.

By March I had generated all the Final Models and used a couple in the test map to prove them out. At this point I realised I could use python in blender to automate the export and It made one of the most laborious parts trivial, It really is easy to write scripts for blender and I thoroughly recommend it, this is the script I used to export all the animations:

import bpy
import os

for action in bpy.data.actions:
    outname = None
    for object in bpy.data.objects:
        if object.animation_data != None:
            object.animation_data.action = action
        bpy.ops.pose.transforms_clear()
        if object.name != "Armature":
            outname = object.name.lower()
    root = os.path.dirname(bpy.data.filepath)
    if action.name == "Idle":
        file = root + "\\" + outname + ".dae"
    else:
        actionname = action.name
        if actionname.endswith("StrafeWalking"):
            actionname = actionname[:-7]
        if actionname == "Walking":
            actionname = "Walk"
        file = root + "\\" + outname + actionname + ".dae"
    bpy.ops.wm.collada_export(filepath=file

A few loops around this script and the final models were in the game but something was wrong!

Human Readable Formats (March-April)

I always knew I was going to need to implement binary formats and now was the time, the final characters where massive collada files and they had a lot of redundant garbage in them. This caused loading times to explode to about 2 minutes if I remember correctly so I was forced to address the issue. I ended up making unified binary formats for the following files:

  • skeletons
  • objects
  • atlases
  • fonts
  • bsps
  • shaders

This reduced the load times to ~10 seconds and was pretty satisfying. There were quite a lot of minor bug fixes as a result of this and it took me into April.

Kinematic Character Controllers vs Nav Mesh Based Character Controllers (April – May)

I had been using a kinematic character control for the full length of development and while I was fairly happy with it, there were a couple of issues. Primarily I couldn’t achieve the kind of control over it I wanted, getting pushed out of the way, sliding down surfaces, climbing vertical faces and tunneling where all issues i’d been fighting all through development.

Kinematic Character Controllers are good because they give you a strong connection to the physical geometry (walking into a door, knocks it open for example). Nav Mesh Based Character Controllers are good because they give you a strong connection to AI reasoning (If an AI decides he wants to go somewhere, he’s not going to get stuck on the way).

Weighing these two options up I decided to take the plunge and try to remove and replace the kinematic controller I wasn’t really happy with, with a nav mesh based controller. It turned out to be a lot simpler than I anticipated and now I feel like I have a good character controller which I can tweak much more easily without having to fire off rays and apply forces to.

Animatic (May~ongoing)

animatic-01.png

 

I had been looking for someone to do an animatic for me to help with promotion and to cement some of the themes of the game more firmly at the start to help the demo pop better. By April I had decided, as usual to stop waiting for someone to come to me and try and throw something together with my extremely limited artistic capability, it’s ongoing and may not pan out but If I can manage to achieve what I’m after it’ll really add something to the game I feel it needs.

What Next?

The greenlight submission really is coming soon (although I wont submit it until I am completely happy with it). To get there I need to block off the areas of the map I don’t want the player going and finish the animatic, I also need to make an updated in game trailer and then make my greenlight page. Following me on Twitter is the best way to keep up with ongoing development, fingers crossed my next post will be about the greenlight submission!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s