Happy New Year!

Posted on

Well, 2016 has certainly been, shall we say, an “interesting” year!  Perhaps many people will be glad to the see the back of it, but somehow I’ve a feeling 2017 won’t be any less eventful.  Anyway, here’s hoping the new year brings good things to you all!

Back in my little GearBlocks corner of the world, in many ways things have progressed pretty well this year, getting through the Unity 5 hurdle was definitely a big step forward.  I’m a bit frustrated to not be further ahead with the game generally by now though.  I’ll just have to keep chipping away at it, it’ll get there eventually.  I’m very appreciative to all those of you who have played the demo, built some amazing creations, and given me really useful feedback.  It helps motivate me to keep going!

Over the past couple of months I’ve been working on a bunch of different things.  I was looking at improving the construction controls, but kinda got stuck with “designer’s / programmer’s block” if you can call it that.  So while thinking on this some more, to keep progress going I did several other smaller tasks:-

  • Made a load of new parts (gears, control wheels, suspension parts, connectors and more).
  • Added more user settings (e.g. mouse look sensitivity and camera FOV).
  • UI tweaks.
  • Rendering effects.
  • Unity upgrade.
  • Bug fixes.

Next week I plan on going back to the controls improvements, mustn’t procrastinate any longer!

Dev update

Posted on

It’s been a while since the last update, so I thought I’d do a quick post on what I’ve been up to!  A couple of weeks were taken up with travelling back to the UK for a bit, and I was sick all last week which took me out of action unfortunately.  I have been working on the game though over the past several weeks…

First person controller

The current first person camera controller in the game is basically a prototype implementation.  It’s buggy and missing a lot of features, for example: camera smoothing, crouching, head bob, and so on.  My plan was to switch over to the excellent UFPS from Opsive (available on the Unity asset store: http://u3d.as/2Jc) which has all these features and more.  Unfortunately that didn’t work out, mainly because I couldn’t bring across only the code I wanted from UFPS (character and camera controller) without either modifying it or also including a lot of other stuff I don’t need (e.g. inventory, weapons, damage etc.)

I think UFPS is great as a starting point for a first person game, but trying to integrate it in at this late stage of a project probably isn’t practical.  So now my plan now is to keep what I have and gradually improve it, probably stealing code from UFPS as necessary!

Deprecated networking API

I have a rudimentary networked multiplayer mode for GearBlocks, and in fact even the single player mode runs through the same code paths.  I want to keep this working so that I have a good starting point should I wish to revisit multiplayer in the future.  Right now I’m using the old Unity networking API, which was causing a bunch of annoying “obsolete API” compiler warnings, because it’s recently been deprecated in favour of their new system, UNET.

I looked into what it would take to upgrade to UNET, using their high level API (HLAPI).  Unfortunately there were all sorts of awkward problems with this (like needing to derive from NetworkBehaviour, which didn’t play nicely with my generic singleton implementation for some reason).  The whole thing was turning into a massive change that would break the entire game until I completed it.  Not to mention it’s still fairly early days for UNET and it’s changing quite a bit as Unity continues to develop it.

Besides, ultimately I might be better off using their low level networking API, but that would obviously take even longer to implement.  Or, perhaps using a third party system like Photon Bolt would be a better way to go.  I’d need to spend a lot more time on this to figure out the best thing to do, so I’m leaving it for now.  Instead, I um…disabled those pesky deprecated API warnings, there you go, job done!

What’s next

So, it’s generally been a frustrating few weeks, hopefully I can get back to being more productive now!  I’ve been prototyping something for the game, not sure if it’ll work out yet, but I’ll be continuing with that.

Also, I’m going to work on improving the construction controls, in particular to help new players pick up the game and get started.  Well, that’s the plan anyway!

GearBlocks Demo 0.4.6095

Posted on

GearBlocks Demo 0.4.6095

New desert map

At long last, I have done away with the old procedurally generated terrain.  I decided that it made more sense to have a few decent “hand crafted” maps in the game, rather than an almost infinite number of crappy ones!

So, now in it’s place there is the new desert map.  This is still a work in progress, I have a lot of details still to add to it, but the main thing for now is that it at least has a flat area to build on without stuff rolling away.  In the full game I plan on adding other maps based in different settings (e.g. forest, grassland, salt flat, snow / ice, etc. haven’t quite decided yet).

Rendering improvements

Having upgraded to Unity 5 this allowed me to make the switch over to physically based rendering (PBR).  Besides making things look pretty, PBR serves a practical purpose in that you can now visually distinguish materials (e.g. metal actually looks like metal now).  It also makes it much easier to achieve consistent lighting across the whole scene.

I’ve also upgraded the time-of-day system, and tweaked the post effects too.

Saved game format

The saved game format has changed slightly, so old saved games won’t work in this build.  However, saved constructions from the previous build version (0.4.6034) should still load OK.  If you have saved constructions from versions earlier than that, I’d recommend loading them in build 0.4.6034, then save them back out, they should then load properly into the new build.

Posted on

First pass of new “Desert proving ground” map for GearBlocks, this (and other maps too eventually) will replace the old procedurally generated maps.

I’ll be adding more details to this map as I go, but for right now it has a variety of terrain types (sand dunes, rocks, large and small bumps), as well as (most importantly) a large flat area to build on!

GearBlocks Demo 0.4.6034

Posted on

GearBlocks Demo 0.4.6034

Unity 5 upgrade done (mostly)

The last remaining bugs caused by the Unity 5 upgrade (at least, those that I’m aware of) have now been fixed.  In the end I decided to postpone migrating away from the deprecated APIs for now as the game still builds ok without doing this (albeit with some warnings), and it’s been so long since the last build – I wanted to get one out as soon as possible!

New world tool

image

There is now a “world tool” in the game (that can be activated by pressing 0), and with this tool active, holding / pressing Q brings up the world tool UI.  In this UI you’ll find the world constructions tab (moved over from the builder tool UI).  You’ll also find a new “settings” tab that allows global settings to be changed during gameplay.  You can change things such as the current time of day, but perhaps more interesting are the new simulation settings.

These allow you to adjust the trade off between physics simulation accuracy and performance.  For example, if you have a slow computer, you can reduce accuracy to get a better frame rate.  Or, if you have a model that requires higher physics accuracy, you can increase it at the expense of performance.

Here’s a brief explanation of these settings:-

Update rate – This slider sets the number of times per second that the physics simulation is updated.  The higher the update rate, the smaller the time step from one update to the next which gives greater accuracy, at a higher performance cost.  The sim time step is particularly important for constructions that have parts with high velocities, especially large angular velocities (i.e. high RPMs).  In these cases, it may be necessary to increase the update rate to prevent instability or “glitching”.

Constraint accuracy – This slider controls how tightly rotary bearings, linear bearings, and so on are constrained (how little they “sag”).  It also affects how much torque gears can transfer without slipping.  If a construction has parts that exert large forces between moving attachments or gears, this may need to be increased (again, the downside being reduced performance).

A science experiment

As (I think) an interesting aside, it turns out that actually two factors affect how accurately constraints are resolved.  Increasing the number of physics solver-steps-per-update increases constraint accuracy, but so does reducing the simulation update time step.  However, I want the player to be able to adjust the sim update rate without also affecting constraint accuracy, so I did an experiment in the game to try and figure out how to keep a consistent level of constraint accuracy while varying the time step.

image

I built a construction that put some gears under torque loading (using a lever and a big weight on the end to provide the torque loading).  At various sim update time step settings, I adjusted the number of solver-steps-per-update to just the point where the gears no longer slipped.

image

Plotting these results out on a graph showed what looked to be some kind of power relationship.  With a little help from Wolfram Alpha, I found that yes indeed the number of solver steps required was proportional to the time step raised to a power – a power of 2 in fact, handily enough!

So, now I set the number of solver-steps-per-update equal to the square of the time step multiplied by the constraint accuracy value that the player can adjust, and this gives a nice consistent behaviour.

Collision behaviour improvements

You can no longer accidentally deselect or unfreeze constructions under the ground or inside other constructions (this used to generate large impulses as the physics engine tried to resolve the collisions, flinging stuff all over the place).  For the same reason, I have also prevented collisions between frozen constructions and the player or other non-frozen constructions.  This has the added benefit that you can now walk inside frozen constructions to get a different perspective when building them!

Well, this is a big update for GearBlocks with lots of changes, particularly the Unity 5 upgrade.  There could still be bugs or problems introduced that I haven’t spotted yet, so do please let me know if you find any, thanks!

Unity 5 physics issues finally sorted

Posted on

At long last, I have resolved all the remaining physics problems I was having with Unity 5!  As I mentioned in my previous blog post, I had solutions that I was working on for most of these issues, but the one thing I wasn’t sure about was how to fix the joint velocity drives.

Configurable joint drives

One of the things that changed from PhysX 2.X and 3.X, is the way that joint drives are configured.  They no longer have a mode flag to specify whether they are position or velocity drives.  Instead, if you want a “position drive” you set the drive’s spring value to be non-zero, if you want a “velocity drive” you set its damping to be non-zero (and if you set both to non-zero the drive behaves as a damped spring).

The question is, what non-zero value to actually use?  Nothing in the Unity or PhysX documentation seems to help much here.  I use both position and velocity drives in the game, and I want them to be constrained only by the maximum force that the drive is set to use (in other words, fully “stiff” as if the spring or damping values were effectively infinite).

So I tried setting them to float.MaxValue, but this caused some odd behaviour.  Drives configured to be “velocity drives” would not work if the rigidbody’s mass was below some threshold, and those configured as “position drives” would sometimes cause Unity to crash completely without any warning.  In the end, after some experimentation, I simply used a smaller (but still very large) value for the spring / damping settings.  This seems to work alright, although I’m somewhat concerned it could still fail in some unforeseen situations!

Simulation update rate

As I mentioned in the last post, swapping joint rigidbody ordering (i.e. owner vs. connected) helped a lot to improve simulation stability at high angular velocities.  Unfortunately it was still not quite enough to get back to Unity 4 / PhysX 2.8 levels of stability.  The simulation update rate also needed to be increased a bit (by reducing Time.fixedDeltaTime), at the expense of performance.  So, as a compromise, I will be exposing a setting in the game to allow the sim update rate to be adjusted.  Advanced users can change it based on the construction that they’re building, and how fast their computer is.

Last few bugs

With these issues taken care of, there’s now nothing to prevent the upgrade to Unity 5.  I’m still working on migrating away from some deprecated APIs and fixing a few remaining (non physics related) bugs, once this is done I’ll be able to put out another demo release.