Triptych

The three camera controllers and input paths are working. Here is a composite shot of the a scene that I took with all three cameras.

• On the left, the scene with my build camera which you can use to spin the scene and move a 2D cursor to add and remove bricks.
  
• In the middle, a "minifigs-eye-view". This is a first person view from the minifigs perspective showing what he sees. You are free to walk around the world as a minifig.
  
• On the right my third person "adventure" controller where you can see your character and explore the environment. This out-of-body experience lets you control the minifig like a traditional game character.

I've bound F1, F2, F3 to switch between them while playing which is good enough for now.

There is still a little more work before a public build is ready. The new cameras, camera controllers and input controllers are all wired together using manual dependency injection and while the scene is still a directed acyclic graph I'm worried that it would be difficult to do in a clean factory so I think a code review is in order.

The build palette is pretty rudimentary, with only a half-dozen bricks in that I've been testing with but it should be trivial to include most of the basic bricks, plates, tiles etc... that I had in the prototype and the new LDR importer should mean adding custom bricks is reasonably quick and painless.
I need a mesh cooker - this has been on the backlog for a long time. I'm currently importing OBJ and LDR meshes on startup but a really quick mesh serializer would be much better. Now I'm doing small iterations, the import time is really starting to annoy me.

Other than that, there are a few misc tasks to address, including some visual glitches that are going to bother me if I don't take time out to address them, including the difference in shadow depth precision on nVidia and ATI hardware (yes. that's still broken) and adding more config options for the render quality.

Comments and questions about Pioneer, programming or game development welcome - I'm thinking of doing an Q&A blog post to answer a bunch in one go.

So until next time, keep building!

Brick by Brick

Now the third-person controller works, I'm integrating it with the previous first-person and the free camera mode from my Mesh Tool/Import application.  Along with the improved build UI, the game will soon be back together and I'll be pioneering in a new tiny world to run and jump around.

There are still a couple of bugs, and rendering issues to resolve, but it totally feels like I'm on the road to a new public release now.

Code wise, there isn't much too the new camera/camera controller works.  The input and camera stacks are now both trees, with the Game Input responsible for switching different input policies in and out, and for switching different cameras and camera controllers in and out at the same time.

There is a slightly weird C++ workaround in my camera hierarchy because of the reference counted pointers I am using, but I'll either fix it or declare "No Fault Found" and move on.

My reference counted pointers are built on incomplete types, and point toward concrete implementations. However I ended up with a public method on a camera subclass that doesn't belong in the interface. Conundrum.
I'll revisit the problem before long, and the workaround doesn't create any cyclic dependencies or garbage collect problems, but its no longer code I can be proud of which is a non-trivial problem.

Usually I can sleep on problems like this, and it all comes out in the wash during review. Which seems like a reasonable plan this time too.

Until next time, think inside the box!

Let there be life!

Its one small step for man, one giant leap for a minifig! Since all of the heavy lifting was done, I thought I'd take a break from technical tasks and do something visual...
...Its pretty satisfying to run a minifig around the environment.

Once the mesh was imported and post processed, it needed a skeleton, rigging and animating along with a third person walk/run controller.

As these are reasonably trivial there isn't much code detail to show off. The skeleton is a hierarchy of about a dozen physics objects. My physics evaluation runs in two passes. The first pass handles integration and the second resolves hierarchy - so its ideal for a simple skeleton with forward kinematics.

The skeleton is rigged in the minifig factory to a cheap one-bone-per-vertex system, which is enough for prototype although I'm itching to make it look nicer.

The animation is a procedural walk/run cycle, and I've stubbed out a keyframe animation player and anim blend tree that I'll fill in later to do some more fancy anims including idle loops, blending between gaits and partial body anims for actions.

The walk run controller is a modified version of the orbit camera from my Mesh Tool application with WASD movement pushed onto the skeleton Root motion. There is no footstep matching so there is some skating, especially on turns.  Again, this is good enough for prototype and it'll land on the backlog when it need to gets resolved.

The minifig is parameterised by colour and body element but without painted torsos or heads. I'm probably going to play with the root motion, gravity integrator and collision for a while, and then look at minifig customization more when I roll out a multiplayer server.

Until next time, stay plastic!