Droids! + Dead Reckoning

I developed a strange addiction to Castlevania: Harmony of Despair recently. During the last IGDA game jam, kindly hosted at UAT, I sought to explore what kept me so drawn to a game a game that felt fairly basic.

I spent a good deal of time trying to make a platformer that would exist within a Dyson sphere. Unfortunately, Unity's CharacterController class, while awesome for a great many things, doesn't work well if your concept of up is a variable thing. I could write my own CharacterController, but I know it's a lot of work. Just seeing what I could do with the existing controller ate most of my time while at the game jam, leaving me with just a single untextured robot made up of cubes and cylinders warped into a mockery of a mechanical being. It could jump, yes, but there were bugs.
Why Droids? I'm not very great with modeling/animating/rigging. Robots need little to no rigging at all, if designed right. I can also have robots do things that normally just don't make sense for carbon based life-forms, and it won't break immersion. In other words, I can focus easily on making the game fun.

I've had a little time to work on it, and I've produced some satisfactory but less than amazing results. My game is now networked, borrowing heavily from my progress on Spell Blade. An interesting thing I discovered in all of this was how easy it was to implement dead reckoning using Unity's network serialization event. The game plays quite smoothly over the network.

This code does a read or write depending on who is controlling the droid (different players control different droids). The outbound is pretty simple. I serialize all of the relevant stateful data (location, orientation, desired movement over x/y, etc). Inbound is just about as simple, but the other half of this is that the remote player's input comes from the network. Since I knew at time of sending that the player was trying to move full-speed to the left, I'll give that same input to the robot until I get another update, where the location, orientation, and desired directions all get forced to new values. Maybe the player rapidly changed directions or something, in which case I might see some jerkiness depending on lag. What I definitely will see is the game moving the droid smoothly when the player is moving relatively smoothly, which I expect will be happening a lot. This isn't perfect, but it sure beats watching the player snap positions as he moves across the screen.

Each droid is controlled by a player over the network,
using a simple platformer scheme

Where do I go next? My plan is to demo this to my gaming group and ask "What would you like to see?". I've seen games evolve into some really wonderful things when designed this way. I believe I'm at a pretty good point here to do that.

Try the game here. I haven't been able to host any Unity games yet via the web player, but I test joining as a client with the web player all of the time. I'm using port 6112 if you're having connection issues.

You can also check out the code here.