Saturday, December 19, 2015

Dev - CC - Set screens to, Story Dev Mode

Two chapter of Dialogue done, two chapters to go. One and a half chapters of level design, finalized.

Tuesday, July 28, 2015

Blender - Code - Delete objects by prefix

When using Rigify in Blender there are a lot WGT objects that aren't needed after animation - before exporting to Unity3D or another engine. I created a quick script, to quickly remove them:

Monday, June 15, 2015

Dev - Burden - Another Character WIP

Harry! For some reason I love seeing the characters at this stage of creation, before the textures and final details, before they're given some life.

It might be because they're closest to the great rough concept art by Aaron Alexovich.

Tuesday, May 19, 2015

Dev - Burden Ngaww!

Character and anim test in the editor. I like to do little short test animations, get'em looping and stuff!

This little fellow is Phooey! mascot for the team. testing with vertex colours only but considering texturing for most characters.

Friday, May 15, 2015

Dev - Burden Another Protagonist WIP

A work in progress snap of another character of the hero team. Just about to start on some details.

We've got quite a list of characters populating the world.

Friday, April 17, 2015

Dev - Burden

No, Burden isn't dead. Never has been, but it has gone through quite some transformation. After a whole story rewrite, art change and game play reset we can finally start posting progress reports again.
All of this leaves us with a name change - it's only fitting - And so 'Burden' has become the working title.

Just to completely throw you off, here's a WIP image of one of the heroes of the game.

Wednesday, September 3, 2014

Dev - Easy Buoyancy

A quick and easy way to make smooth buoyancy of an object. Just a small ICE tree and a constraint with low blend weights.

The mesh to float is constrained to the Null object, which has the ICE constraint attached - constraining to the water surface.

And here's a test render for visual candy.

Friday, April 25, 2014

Dev - Controlling the Beast of Burden

Controlling the Beast

Early in development, the game was controlled almost entirely using the mouse.  As the design changed, and gamepad input started being implemented, the limitations of Unity's input system became very apparent.  After a quick look through the available replacements available, we decided that none of them quite met our requirements and started developing our own.  Here's how it works.

Controller Types

Multiple input devices can be configured and enabled/disabled independently.  Each input device definition consists of a Device Name, Device Type and an Enabled flag.  For instance, for the XBox360 controller we have an input with a name of XBOX and a type of JOYSTICK.  

Game Inputs

Next are game inputs.  These are actions that you want to perform, such as "Orbit", "Select Build Spot", etc.  Each game input takes one or more Input Devices (above) and an Input Type (Button or Axis).  "Orbit", for instance, is of type Axis and has XBOX axis 6 or Keyboard Left/Right arrow.


One of the most important features of the input system is the concept of Contexts.  Since the same button or axis can be used for multiple different actions, depending on the context in which it is pressed, we need a way to specify when an action can occur.  If you're zoomed out from the giant and press left, we want it to Orbit.  When in build mode, left should select the previous tower/plot.  We can create different contexts and assign multiple Game Inputs to each context.  An example of a context could be "Choose Plot Mode", which might have "Select Plot", "Cancel Build", and "Confirm Plot Selection" as valid inputs for that context.

Callback Driven

Instead of polling the input system every frame to see if a Game Input was pressed, we register callback functions to be called whenever the desired action takes place.

The Inspector

The input system itself was finished pretty quickly, but the inspector took a bit longer.  There are several Serializable classes that reference each other, but the serialization doesn't handle references too well.  There's the ScriptableObject base class that is supposed to be able to deal with this type of setup, but I didn't have much luck getting it to work properly.  So I ended up rolling my own.  Since everything has a unique name, I serialized everything myself, storing the name of the referenced class as well as a direct pointer, using MsgPack.  This loses the references but keeps the names, then on deserialization I rebuild the references based on the names.  I'm not entirely happy with it, and wouldn't want to make it available for general consumption, but it works well enough for the two of us to use it as we understand its quirks.

Written by Matthew Bowie