next »

[dangersam]

https://dl.dropboxusercontent.com/u/157530041/GearBlocksDemo_0.1.5557.rar

GearBlocks

Well, my as yet unnamed game now has a title - GearBlocks.  It was quite hard to think up a name that summed up the game in some way, as well as being short, easy to remember, and not already in use.  In the end I had to just pick something and go with it!

Full vs. demo builds

I’ve now set up a simple build pipeline that lets me build demo or full versions of the game.  As I add more stuff to the game, this will allow me to easily exclude certain features or content from the demo.

Build versioning

Builds of the game are now versioned, and the version number is shown in the game.  This means I can release standalone builds of the game on a regular basis from now on, yay!

Phasing out the web player

https://dl.dropboxusercontent.com/u/157530041/GearBlocksDemo.html

For now the web player build is still available at the link above.  I think I’m going to stop bothering with it soon though, and just release the standalone version, as there are starting to be too many difficulties with it:-

• The new save game system doesn’t work due to the .NET serialization problems I mentioned in the last post.
• It seems getting the .NET assembly version isn’t supported due to the web player sand-boxing, and I need this for showing the build version in game.
• For some reason Unity is now always building the web player as a “development build”, even when this build setting is turned off.

[dangersam]

Unity 5 physics bug update

Over the last week I also had a look at some of the Unity 5 physics bugs I mentioned in an earlier post.

It turns out the rigidbody freezing bug only happens when I modify a rigidbody’s mass properties (i.e. mass, inertia tensor etc.)  I was quite easily able to repro this in a very simple project, so I’ll send this off to Unity when I get a chance.

After browsing the Unity forums I found out that hinge joint motors not working is caused by the motor not waking up the rigidbody.  As a temporary solution, if you force the rigidbody to wake up every update, the motor works.  I also found I had to multiply my torque values by a factor of around 50 to get similar behaviour to that in Unity 4.6.

Velocity drives definitely aren’t working for me.  Again, I was able to repro this in a very simple project.  One for another bug report.

I haven’t had a chance yet to look at the hinge joint limit and OnCollisionExit issues, but I’ll keep chipping away at these next week.  I also noticed that my gears don’t seem to be working properly, sometimes the gears (particularly rack gears) get stuck.  I checked and the configurable joints I’m using for the gear constraints do still seem to be updated correctly, so I’m not sure what’s changed here.  I always was concerned I’d find some slightly different behaviour in Unity 5 with PhysX 3.3 that would unavoidably break the delicately tuned physics setup in my game, and this may be evidence of that.  Let’s hope not, more investigation required!

[dangersam]

Getting the word out

I’ve now created an Indie DB page for GearBlocks, from now on I’ll be hosting the demo builds there rather than on Dropbox.  I’ve also created Greenlight Concepts and Facebook pages for the game.

I’ve also been playing around with a logo for the game, which was fun I have to say!



Latest build

In the latest demo build, I’ve enabled the new save game system that I mentioned in a previous post.  As well as being able to save your constructions, this also provides a rudimentary way of sharing them with your friends. Saved games are stored as files in the SaveGames directory in the GearBlocksDemo folder (i.e. right next to the executable, you can create it if it doesn’t already exist). You can load up someone else’s saved game by copying their file into this directory.

Build 0.1.5567 for Windows

[dangersam]

Unity 5 physics update to the update

For some time I’ve been trying to resolve the physics issues after upgrading GearBlocks to Unity 5.  I’ve had success with some issues, not so much with others.  I’ll sum up where I’ve gotten things to so far.

Rigidbody rotation unfreezing
When unfreezing a rigidbody, its rotations weren’t being unfrozen, this bug happens if you had already modified the rigidbody’s inertia tensor.  After submitting a bug report, I heard back from Unity - turns out the workaround is to restore the inertia tensor after unfreezing, which works fine.

Collision contact tolerance
The collision contact tolerance seems to have significantly changed with Unity 5.  What I thought was my gear constraints not working properly was actually due to the moving parts (blocks, axles and gears) within a construction colliding with each other, and everything was getting all jammed up.  One workaround I tried was to shrink the colliders, trouble is I had to shrink them by quite a large amount and even then I’d still get occasional unwanted collisions.  Another option would be to disable collisions altogether between neighbouring parts, but that’s problematic as you might actually want them to collide in certain situations.

Unstable collision behaviour
For some constructions when contacting the ground, their collision response with the ground is kinda jittery and they keep bouncing around for ages after the initial collision.  After some experimenting, it seems this behaviour is worse with the small fixed update (i.e. physics update) time step I’m using (5ms vs. the default 20ms).  Not much I can do about that though, as I need the smaller time step for accuracy with fast spinning stuff.

Instability at high angular velocities
On the subject of fast spinning stuff, despite the aforementioned small time step (and also a high solver iteration count), gears / axles spinning a high rpm now become unstable and start wobbling around.  With the same settings in Unity 4 this was rock solid.  I tried playing around with these settings but I couldn’t get it to be stable, more experimentation is required, but this could be a real show stopper.

Hinge joint motors
When switching on a joint motor, there is a bug in Unity 5 that means the connected rigidbodies don’t get woken up, and so they don’t start moving if stationary.  The workaround is to explicitly wake up the rigidbodies when turning the motor on.  I also found I had to multiply my torque values by a factor of around 50 to get similar behaviour to that in Unity 4.6.

Hinge joint limits
I use angular limits to force a hinge joint to a particular angle by setting the limit min and max values both to that angle, but this stopped working properly in Unity 5.  I found the fix was simply to ensure there is a small delta between the min and max.

Configurable joint velocity drives
I still can’t get these to work at all, I submitted a bug report to Unity but haven’t heard back so far.  Hopefully they’ll be able to fix this one.

In summary, I’ve got fixes / workarounds in hand for most issues now, but there are still a couple of show stoppers (namely velocity drives and stability at high angular velocities).  So for now I’m still sticking with Unity 4.6, I really need to get back to making actual progress on the game!

[dangersam]

New demo build

Over the last week I (hopefully) fixed some of the physics bugs that were a point of frustration for people:-

• Fixed bug where hinge attachments would sometimes drift from their correct orientations, causing incorrect physics behaviour (where the construction would jump about all over the place).
• Improved behaviour when exiting a seat, to prevent the player from colliding with the construction.
• Also added new 3x3 plate, slider x3 and slider x5 parts.

Build 0.1.5581 for Windows

Stunt plane



Over the weekend I built this in the game, a plane with working 4 cyl boxer engine, ailerons and rudder. It doesn't actually fly though because there are no wing lift physics in the game (yet), but it taxis around pretty good.

[dangersam]

Unity 4.6 UI upgrade

Hey everyone, apologies for the lack of GearBlocks updates recently.  I’ve been working on porting all of the menus and other UI over to the new UI system that was introduced in Unity 4.6.  I wanted to get the port out the way sooner rather than later, before I add any new features that require UI changes or additions.  Unfortunately it’s taken me much longer than expected, I’m getting there, but I probably still have one more week left to go on it.

Previously I was using the old immediate mode UI system, which has its well known limitations that I won’t go into here, I’m guessing it will eventually be phased out in future releases of Unity.  The new system is for sure a lot more powerful and flexible, and of course you get to properly lay out your UIs in a WYSIWYG fashion.

Issues with the new UI system

Unfortunately once I got into it, I found there were some downsides to moving to the new system.  For instance, some of the features of the immediate mode UI I was using (e.g. selection grids) do not come “built in” and I had to write additional code to replicate them.  Also, some bits of the UI that I populate at run-time (e.g. the parts list in the inventory screen) required significant rework to the code that does the populating (simply because of the totally different philosophies of the old vs. new UI system).  The most troubling issue though was the performance of the new UI system, I discovered if you’re not careful you can easily add many ms. to your frame time, with spikes in the hundreds of ms!

UI performance problems

GearBlocks has many separate UI screens that the user can transition between.  The “standard” way to implement this in the new UI system (at least from the tutorials I’ve seen) is to use an animation controller to blend each screen between an open and closed state, these states setting the screen’s CanvasGroup visibility and interactibility.  However I found that the animation blend added a couple of ms. (from Animator.Update and Canvas.BuildBatch) during a transition.  Even worse, despite all screens (apart from the currently active one) being invisible and non-interactible), they still all seemed to get processed and I found that this resulted in several ms. of overhead from the EventSystem update.

To get around the transition blend cost, I did away with animations for the in-game UI and just did the transitions directly from code (I kept using animations in the main menu though as the performance cost isn’t so critical there).  For the second problem, I wanted to eliminate any cost for a non-active screen - it’s not really practical to go through and disable each and every UI behaviour, so I tried deactivating the screen’s root GameObject.  Unfortunately, while this does eliminate the continuous frame-by-frame cost, it can result in huge performance spikes when activating / deactivating the GameObject (I found hundreds of ms. if you have a complex screen with ScrollRects), so it’s not a viable option.

Luckily I found another solution, which is to have a separate Canvas and GraphicRaycaster for each and every screen, then enable / disable these to transition between screens.  This way you get the best of both worlds, no cost for inactive screens, and no cost to activate / deactivate them.  I get the impression this is a common trick people use to get around this problem.  It seems like there are a few performance tricks people are discovering (such as disabling Canvas “pixel perfect” when using ScrollRects).

Well, hopefully I’ll be done with the UI port soon, and then I can get back to adding new stuff to the game!

[dangersam]

UI upgrade complete

It took way longer than I was hoping, but finally I’ve completed the re-implementation of all the menus and screens using the new Unity UI system!  This will hopefully pay dividends down the line by making it easier to add new features that require UI.

Build 0.1.5605 for Windows

[dangersam]

Full game features

Over the past couple of weeks I’ve been working on some new features: the challenge game mode and construction damage.  These won’t be in the demo (got to hold some things back for the full game!) but I thought I’d talk about them so you know what I’ve been working on.

Right now the challenge mode just consists of built in saved games that you can choose from as starting scenarios.  The plan is to extend this to add various possible constraints (e.g. a limited part budget) and scoring / win criteria.  Eventually there will be a system where you earn points by completing challenges to unlock later, more advanced challenges.  There’s still a long way to go on this feature!

I’ve also been working on my first attempt at a damage system.  Each attachment starts with an initial “integrity” level based on the material strength of the two parts it joins.  When a construction sustains impact, damage is propagated to its attachments, reducing their integrity level.  Once an attachment’s integrity reaches zero it is deleted, causing parts of the construction to break off.  Note that the parts themselves don’t get damaged or destroyed, only attachments; I decided to do it this way for simplicity.

UI improvements and bug fixes

There are still plenty of new things in the demo though, I have made some UI improvements (animated loading screen, saved game images, and other tweaks), plus a bunch of bug fixes.  I’ll keep continuing to update the demo, wherever I improve or bug fix an existing feature.  I’ll still be adding one or two new parts to the demo as well!

Build 0.1.5623 for Windows

[dangersam]

Spring dampers

The latest GearBlocks demo build now has coil-over spring dampers that can be used to build all kinds of suspension for your vehicles!  The spring rate and damping can be adjusted through the part behaviour menu (accessed in the usual way, hover over and hold Shift + E).

I had the physics side working nicely early on, but it took a while to figure out the best way to present the spring / damper functionality to the player, within the constraints of my construction system.  In the end I decided to have two parts, a “barrel” and a “piston” that the player fits together to form the spring damper unit.  Originally I was hoping to provide a pre-assembled unit to avoid making the player do this, but it would have required too many changes to the construction system to allow for “multi-element” parts.  Anyway, this way allows the barrel and piston to be attached in different orientations which is a bonus.

Now, actually using the spring dampers for something useful (like car suspension) might not be immediately obvious, so I’ll make a video soon to go over this.



Ball and Socket joints, CV joints

I have also just finished working on adding a whole new set of connecting joints to the game.  There are ball and socket connectors that snap together and can attach to axles or blocks.  They allow the connected parts to rotate through all three axes, and are essential for building a proper steering mechanism with a vehicle that has suspension, but they have many other uses too.

I’ve also added constant velocity joints, which attach axles together and allow rotational drive to be transmitted through changing angles.  These are useful for building drive shafts for vehicles with suspension, and / or front wheel drive (or four wheel drive).

These parts are not available in the demo, as I’m keeping them back for the full game.  I’ll be doing a video on these too though, to show how they can be used, it can get pretty complex!

Build 0.2.5649 for Windows

[dangersam]

A new GearBlocks dev diary demoing the spring damper parts.

[dangersam]

Block sizes and materials

Hey everyone, it’s been a while since my last update, sorry about that!  For a long time I’ve wanted a better (& larger) selection of materials for the block / plate parts, as well as to allow their colour to be changed.  I realised however, to facilitate this I need to redesign the part inventory system (otherwise the huge increase in parts would become unmanageable), and also to implement some kind of paint tool to change colours.  I’m also thinking it might be better to have resizeable blocks / plates (and perhaps other parts where possible) to give more flexibility and reduce the number of parts cluttering up the inventory.  This would be a fairly big change to implement, and has some awkward design implications for features I was hoping to add later on, so I want to be sure before I decide to go ahead with it.

So over the last few weeks I have been working on designing how this is all going to work.  I have a way to go but I think I’m getting there.  It has rather thrown my project plan off track though, so I need to try and get back on track.

Over the coming weeks I’ll be prototyping resizeable blocks, continuing with the design work, and hopefully making some progress on implementing the new systems.  So things might continue to be a bit quiet while I work on this.  In the meantime however, I have just released a new demo build with some improvements and bug fixes, details coming shortly…

[dangersam]

Gear, motor and spring damper tweaks

This updated build brings increased motor torque and spring damper values, which should work better with larger, heavier constructions.  It does mean however that you will probably have to tweak the spring damper settings in your existing constructions, as well as perhaps remove some motors if you’re currently doubling them up to increase torque.

I have also made some tweaks to reduce gear slip under high torque loads (in fact this is what allowed me to increase the motor torque).

This build also has a bunch of bug fixes (see the release notes for all the details), but one fix in particular affects motors.  Depending on what order motors and axles were attached together, the motor rotation direction could be different.  This has now been fixed so that the direction is always consistent, but it does mean that you may have to flip the reverse direction toggle in your existing constructions.

Build 0.2.5682 for Windows

[dangersam]

Re-sizable parts

As I mentioned before, I wanted to try having re-sizable parts as a way to make selecting which part to spawn more manageable for the player while at the same time having a greater choice of part sizes and material variations available.  Over the past month I have been working on prototyping and building this feature, and it's now in the latest build and working pretty well I think.  Beams, plates, axles and slider rails are all now re-sizable to a range of different sizes, eliminating the need for a separate entry for each different size in the spawner menu.

To achieve this, I implemented code to procedurally generate the render meshes for these parts rather than use pre-made meshes.  Also, I had to modify the construction controls slightly to allow the player to easily re-size parts.  Figuring out how to nicely integrate the controls for re-sizing with the existing control scheme actually took most of my time.  I explored a few different ideas, but I'm fairly happy with what I ended up with.



Re-sizable parts can be identified in the part spawner menu as the ones with the +/- icon in the top left corner of their preview images.  Parts can only be re-sized if they're not currently attached to any other parts.  If something is already part of a construction you have to detach it first, re-size it, then re-attach.  Any existing saved games will be automatically converted on load to use equivalent re-sizable parts in place of the old fixed size ones.  Let me know if you have any problems with an old saved game not loading properly, but hopefully I have covered all of the cases!

Construction controls changes

Note that the following only applies when a construction is currently selected by the player:-

• Hold shift + move mouse (used to be shift + WASD) - Translate the selected construction relative to the cursor.
• Hold shift + directional keys (WASD) - Re-size the selected part, as long as it's not attached to any other parts.
• Hold Q + left click (used to be shift + left click) - Attach the selected construction (if it's currently being aligned to some other frozen construction), after first cloning it.

Here's the latest dev diary video that shows the re-sizable parts in use:




Next steps

An often requested feature is to have flexible key bindings for controlling part behaviours (e.g. motors, servos etc.), rather than only being able to use the directional keys.  For a few different reasons that I won't get into now, this is not as easy to do as you might think.  To facilitate this, I need to overhaul the input system somewhat, so this will be coming up on my horizon soon.

I also want to introduce a painting tool to allow the player to easily change the colour of beams and plates.  I think this will be big improvement to the creative flexibility afforded in the game, but I'm not quite sure how it's going to work yet.  Something I'll hopefully be looking at soon.

Finally, to support some more complex parts I want to add down the road, I need to totally rework the current system I have that decides which types of parts can be attached with other parts, in order to make it a lot more flexible.

So...lots to do!

Build 0.2.5712 for Windows

[dangersam]

It’s been a long while since the last update, I was away for a bit, then got sick which took me out of action for a while.  But anyway, finally I’ve gotten a new build out the door - here’s what’s new…

Painter tool



There is now a new tool in the game that allows you to apply colour to the currently highlighted part (if it is paintable).  Paintable parts can be identified in the part spawner menu as the ones with the colour icon in the top left corner of their preview images.



The numeric keys select which tool is currently active, 1 for the builder tool (i.e. the pre-existing construction controls) and 2 for the new painter tool.  The currently active tool is indicated in a new toolbar at the bottom of the screen (you can also select a tool by clicking on the icons in this toolbar).  When the builder tool is active, using Q will bring up the part spawner menu as before, but when the painter tool is active, Q brings up a different menu, one that lets you choose a colour to paint with.  Note that in the demo, some of the paint colour controls in this menu are disabled, but you can still choose from a fixed palette of colours.



When the painter tool is active, the following controls are available:-

• Left click to apply paint to the currently highlighted part (if it is paintable).
• Hold shift + left click to remove paint from the currently highlighted part (if it is currently painted).
• Right click to sample paint from the currently highlighted part (if it is currently painted) and make it the current colour for painting.

The latest dev diary shows the painter tool in action:




Other improvements

Also in the latest build, Q can now be optionally made to toggle the tool UI, instead of having to hold Q.  To activate this, there is a check box option in the input settings.

The electric motor peak RPM and torque are now configurable from the part behaviour configuration dialog, which allows the motor to be fine tuned to better suit the construction that you’re building.

Build 0.3.5771 for Windows

[marcgfx]

really unbelievable what you have been building here! great stuff

[QOG]

Looking nice. Seems like it may be a bit complicated, but the UI doesn't look to intimidating, so hopefully that won't be an issue.

[dangersam]

really unbelievable what you have been building here! great stuff

Very kind, thanks!

Looking nice. Seems like it may be a bit complicated, but the UI doesn't look to intimidating, so hopefully that won't be an issue.

Thanks!  Yeah, it's definitely on the complicated end of the spectrum.  It does give a lot of flexibility in what you can build, but the learning curve is steep.  Something I hope to do eventually is to flatten that curve somewhat by leading users into the building process more gently with tutorials, challenges etc.

[dangersam]

Forklift truck



A forklift truck I recently built in GearBlocks, making use of slider rails and rack & pinion gears to move the forks up and down.

[dangersam]

Another demo build is out, here’s what’s in it!

Part behaviour controls



Rather than only being able to control motors, servos etc. with the directional keys (i.e. WASD), you can now assign your own keys in the part behaviour dialog (highlight the part, hold shift & press E).  This opens up all sorts of possibilities as you can now control multiple motors at once using separate sets of keys.  There is also the option to have the motor only accept control input when the player is sitting in a seat that is part of the same construction as the motor.  This is handy, say, for when switching between vehicles that are set up to use the same key assignments.

Motor and servo improvements



The motor now has a “brake” option that stops the motor from spinning when it is switched on but not activated.  This ability to “hold in place” the drive train attached to the motor is useful for lifts, cranes, and many other things.  The fork lift truck I recently posted a video on makes use of this feature to hold the forks in place when you’re not moving them up or down.

Rather than snapping immediately to its required angle, the servo motor now transitions smoothly at a fixed speed.  I’ve added an RPM setting that allows this speed to be adjusted to suit the purpose you’re using the servo for.

This dev diary demos the new part behaviour controls and the motor & servo improvements:-




Save / load of constructions



An individual construction can now be saved out by highlighting it, bringing up the construction menu (by holding shift & Q), and clicking the save button.  This brings up another window that shows any currently saved constructions, lets you choose a name to save under and so on.  The constructions get saved into the SavedConstructions folder under wherever you’re running the game from.

To spawn a construction you previously saved, in the builder tool mode, hold Q to bring up the builder tool GUI and click the Constructions tab.  There you’ll find all your saved constructions, just click on one to spawn it.  Also, I’ve included some built-in example constructions for you to experiment with!

Build 0.3.5796 for Windows

[dangersam]

The Mosquito



Here's a sort of helicopter thing. The controls are super touchy (I ended the video before the part where I crashed into the mountainside!), but it's just about flyable. I name it...The Mosquito.