Games [WIP] GearBlocks - Build working physics based machines and mechanisms [DEMO]

Hey everyone, here's a game I've been developing for many years. I've been posting to my own dev blog for a while, but I thought I'd start a thread here. Hopefully some of you will find it interesting, especially what I've been doing with physics in Unity. Thanks for reading, and if you get a chance to try the game I'd welcome any feedback!

GearBlocks is an open ended sandbox game for mechanically minded builders.

You can build a car with rack and pinion steering and a working drive-train with a differential gear. Or you could make a run-and-jump parkour course with motorised bouncy platforms, or an unstoppable walking mechanical elephant. The only limit is your imagination…and physics.

Create
Build or repair your creations anywhere on the map. Snap parts together, resize them, change their materials, paint them, and link their behaviours together. Choose from over 200 parts, including functional mechanical elements such as motors, gears, pulleys, joints, springs, actuators, and much more.



Interact
Turn, grab and shove your machines and watch the parts physically interact. Jump into the driver’s seat and put your vehicles through their paces. Crash and smash your constructions to smithereens.



Improve
Learn how to build with the in-game tutorial scenario. Explore the example constructions to see how they’re put together. Test your builds in the included challenge scenarios.



Customise
Make rag-dolls from body parts and use them as your custom player character. Mod the game with Lua scripting to create your own custom tools, scenarios, challenges and mini-games.

Share
Share your creations with the community, try out what others have made, and maybe learn a new building trick or two along the way!

Out now in Early Access

The game is now available in Early Access on the GearBlocks Steam store page.

More info

GearBlocks Discord
​

GearBlocks on IndieDB

​

Other links:-

• GearBlocks website
• Youtube (tutorials and dev diaries)
• Twitter
• Facebook

 

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 save game system. 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

​

 

HOLY CRAP NICE!!!!!

i think creativity games like this is the way to go.. like minecraft, this is seriously amazing!! nice!

 

Thanks Zeblote, the save file was very useful! By disabling a bunch of colliders, I managed to stop it going crazy long enough to see that some of the hinge joints have got messed up as you can see here.





I've seen this happen before where joints sometimes drift out of position during construction, as parts get added or removed, haven't got to the bottom of why this is happening yet though.

This is probably what caused your construction to fly off in the first place, although I'm not sure how part of it went missing, that's concerning!

As for the inventory images getting screwed up, that happens when the render targets are lost. This usually happens during a resolution change, which I account for, but is obviously happening in other cases too.

Sorry your first experience was frustrating, but your feedback was very helpful, thanks!

 

Unity 5 physics issues

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!

 

Not to minimize the problems in any way - but your game is truly an actual working testbed for the new physics in Unity5.

I hope solid solutions to the issues you have materialize soon.

 

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). Thanks again Zeblote for the save file, that helped me track this bug down!
• 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.

 

Instead of adding lots of beams and plates, why not generate them dynamically and let the player chose how long/wide he wants them to be? Easy to use resize tool after placing a beam would be pretty awesome.

 

Yeah, I had toyed with this idea before. The trick is to come up with a simple interface for the player to choose / adjust the block dimensions, should be possible though!

 

How about something like this?

You'd activate the tool by looking at a part and pressing shift+s (or maye you can come up with a better way)





Dragging the balls would show a grid and start re-sizing the part in place. There should be almost no restrictions in place so you can make 1x1 plates/beams or useless 100x100 plates.

Changes would only be applied once you actually release the ball, as you might accidently shorten the beam too far and delete a few joints otherwise that aren't easily fixed.

The build menu would only need a few entries then, a beam and a plate of every material that has a default length of 5 or so.

 

Nice, yeah I think that could work well Zeblote! I'll put something in my plan to try this idea out soon...

 

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!

 

This is one of the few instances where I've seen the new UI causing more problems than it solved. Though I haven't witnessed another UI conversion with the same amount of work you've already implemented.
Nice to see your progressing.

 

I experience some of the same issues on one of my projects with the new UI also- I had to complete redo everything differently sadly, I hope you find a more elegant solution. The game itself though has an absolutely stunning premise, definitely steam-worthy

 

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

​

 

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

​

 

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

​

 

A new GearBlocks dev diary demoing the spring damper parts.

 

Come on, where are the resizing blocks!

 

Pretty darn cool, seems a bit garry's mod inspered ?
Keep up the amazing work.

 

Heh, I know I know. Actually, first off, my plan is to make the material choice for blocks be on a separate menu, the reason being that I want to support these material variations also for sloped, curved and angled "blocks" (which won't be as easily resizeable) that I plan to add later on. This would dramatically reduce the number of blocks in the top level inventory menu, so maybe resizeable blocks wouldn't feel so necessary then, we'll see!

 

Thanks! Yeah, definitely gmod is a big inspiration!

 

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. Also, after thinking about it some more, I decided I should at least try Zeblote's suggestion of having 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…

 

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

​

 

Re-sizable parts

As I mentioned before, I wanted to try Zeblote's idea of 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

​

 

It works really well

But the rack gear should be resizable aswell and the I beam is gone

 

Thanks! I'm glad you nudged me to try the re-sizable block idea!

Making the rack gear re-sizable is tough because I want the ratio between the number of teeth and length to be a whole number (while keeping the teeth size as close as possible to those of the other gears). It worked out that the rack gear needs to be a multiple of 7 units long.

As for I-Beams, the old ones are gone, but I have new re-sizable ones now, they're just not in the demo.

 

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

​

 

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.

 

That's very impressive. I don't think I've ever seen a game that let's you build functional vehicles with that much detail. A few different ones have come up that let you build functional vehicles (and for their purposes, it works well, e.g. robocraft, terratech, scraps, and that one where you break down defenses in levels), but this one takes it a level further it seems, to simulating a greater number of internal parts.

I think I saw a video on this already, but how do you map controls to the different actions? Is there a hotkey assignment system, or is there some kind of scripting interface?

This comes to mind because I'm currently working on a visual scripting system (mostly done) for my game, that would make this game extremely flexible/configurable when combined with the level of detail of the vehicle parts. When it's further along and fully functional, I'll try posting some screenshots here in case you think something like it is worth adding. (if you already have one, of course, you'd just build off of that)

Also, what is your target audience/action-type for this game? First-person combat? Robot-like-vehicle builders, that then fight and do stuff on their own? First-person-controllable vehicles for the sake just of enjoyment from building, driving/flying, interacting, and such?

 

Thanks! Yeah, the builder / sandbox game space is pretty active right now, with the games you mention, plus many others that keep popping up! I'm trying to differentiate by focusing on detailed mechanical parts with real (ish) physical behaviour. Right now GearBlocks is just a sandbox, but I do plan on eventually adding a series of challenges to complete that will give a sense of progression to the game (and also serve as a tutorial to help ramp players up).

As it happens I'm just about to release a build that changes how controls map onto actions. Before the keys were fixed, but now you'll be able to assign keys to control motors, servos etc.

I don't have a scripting system, but it is something I've thought about. It would be particularly powerful if combined with sensor parts (light beam, trigger pad etc.) It's likely not something I'll be looking at any time soon, but I'd definitely be interested in seeing your system once you're ready to show it!

The nature of GearBlocks is obviously very niche, I'm not expecting a huge audience. I'm hoping to appeal to people who like building and being creative primarily for the sake of it, although that doesn't necessarily preclude combat & smashing stuff up! Some of the stuff people have built and shared already is amazing, so there's definitely some interest out there.

 

This is awesome! I love how everything actually plays a part. Really liking those pistons though

 

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

​

 

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.

 

Part type pairing

Over the past few weeks I’ve totally reworked the system that decides which types of parts can be attached to other parts. Previously there was a predefined list that explicitly specified the legal pairings between the various part types, including which set of attachment points to use, and what attachment types to allow (e.g. fixed, rotating, sliding etc.) This made it awkward to add new part types. When adding a new part type, you had to make sure any existing part types that you wanted to connect to it be updated too, essentially meaning the list would grow exponentially the more types you added. Unwieldy now, totally unworkable in the future.

So I scrapped the predefined list, and now legal part pairing is determined implicitly, simply by what attachment points each part exposes. For example, if a part has at least one fixed surface attachment point, it will attach to any other part that has a matching fixed surface attachment point (an example being a block attaching to another block). This opens up the possibility of parts now being able to attach together that previously couldn’t because a pairing relationship happened not to be explicitly specified.

This task took a bit longer than I was expecting because it exposed some workarounds that were relying on the old explicit part type pairing. I managed to get around most of these, but there’s one I still need to go back and address properly.

New attachment types

The attachment types have been renamed (”rigid” to “fixed”, “hinge” to “rotary bearing”, and “slider” to “linear bearing”). In addition there’s a new attachment type: “linear rotary bearing”, this allows parts to slide relative to each other along the sliding direction, and rotate relative to each other at the same time.

Axles can now be attached to blocks with the “linear bearing” and “linear rotary bearing” types (as well as “fixed” and “rotary”, as before). Gears can now be attached to axles with the “rotary” type (as well as “fixed”, as before).

Construction controls changes

Finally, there have been some tweaks to the controls. In the builder tool mode, pressing Q while highlighting a part now clones that part. In the painter tool mode, right click now removes paint from the highlighted part, and Q now samples the paint colour from the highlighted part.

Next up

As previously mentioned, I need to revisit a hack / workaround that was relying on the old explicit part type pairing system. This all ties into how I use physics collider contacts to determine which of a part’s attachment points to use, a method I’ve never been completely satisfied with. So a big task coming up will be to investigate into perhaps finding a better way of doing this.

Also, I want to revisit the Unity 5 upgrade, and see if the recent Unity updates have helped with any of the long standing physics issues I’ve had with it. I’m not expecting anything, but you never know…

I also plan to start adding some new parts that will take advantage of the new part pairing system I’ve just put in place!

Build 0.3.5834 for Windows

​

 

As promised, here's a screenshot of the visual scripting system I finally made an update post about on my project thread:


I'm open to thoughts and criticisms, if any come to mind.

It's a work in progress, although nonetheless I'm pretty happy with it so far; it seems to me that it should make the operational flow pretty clear, even for the observant beginner. I'll have to see how it pans out with actual players in the future, though.

 

Your visual scripting system looks cool! Is it intended only for development use, or also for end users to create behaviours in game?

 

New parts

Since the last update that introduced the new part pairing system, I’ve been creating new types of parts that take advantage of this, including new connectors (ball and socket, CV joint, etc.) and specialised suspension parts. These new parts allow for fully independent suspension with steering and front / rear / four wheel drive (even four wheel steering if you want!) I’ve also added other new parts with new behaviours - a stepper motor and hydraulic actuators whose linear movement can be controlled by the player.

I’m keeping these new parts under wraps for now, but I can show some others that I’ve also added which are variations of existing parts - a new large spring damper, new gear sizes, new motors of different sizes, and more wheel variations. I got tired of the old motor and wheel models so I spent some time brushing up on my 3D modelling skills and made some new ones! I’m pretty happy how they turned out although they still need tweaking and UV mapping at some point. I plan on adding many more variations for wheels, seats, lights etc.



Note that no additional parts are in the demo, but I have updated all the existing demo parts with their new versions.

Part alignment

I’ve also been working on how parts align together during construction, so that this system works better with the new parts I added. This was mainly to prevent axles penetrating through parts, and to make the alignment behaviour a bit more intuitive. Some parts (such as motors) are now slightly more restrictive in how they can attach to other parts. On the other hand, the spring damper barrel and piston parts are now less restrictive in that they can now be attached together at several different alignment points, which allows for different “default” spring extensions when the construction is frozen.

Other changes

I’ve changed the underlying physics implementation of rotary attachments (hinges) to be in line with all the other jointed attachments. Among other things, this allowed me to add a configurable torque value to the servo motor part behaviour. Finally, a bunch of other things have been tweaked, including new UI elements, SFX and so on.

Build 0.3.5893 for Windows

​

 

This is still looking really nice! I wish I had the knowledge to create objects during runtime. You wouldn't mind giving me a super basic rundown of how it's done would you? I'm working on a game (still haven't fully worked out the name yet, but here it is) and I really want to implement a modular building system like yours. Cheers in advance

 

Your game looks interesting, are you planning on having players edit the voxel vehicles in game? That would be cool.

As for my building system, there's no magic really. Each part is it's own game object with meshes, colliders etc. When parts are attached together rigidly they're parented to another game object with a rigid body. Jointed attachments are created by adding constraints between the rigid bodies. That makes it sound easy, but it's a lot of work to make it work properly!

 

For players as well, with the two main uses being: custom AIs, and advanced scripting for in-depth campaigns and such.

I know scripting will never be completely 'usable at sight' for the standard user, since even at its simplest level you still have to pay attention to make sure you're entering your thoughts into a brand-new medium properly. But my aim is to at least remove the 'set up barrier' to learning scripting, by embedding a scripting system directly into the game--one that's as accessible as opening a map or browsing the tech-tree. (and it should be easy enough that the observant player will be able to understand the basic instruction flow, and potentially start making small changes)

P.S. Just finished an update that adds 'subscript' capabilities to the system; they're roughly the visual-scripting equivalent of methods.

 

As I haven't put out an update in over a month, I thought it'd be a good idea to explain what I've been working on. Be warned, this is gonna be long (and probably tedious)!

As I alluded to in an earlier post, I wanted to come up with a better system for determining attachment points between parts when the player is building their constructions. The existing old implementation (which had been around since the initial prototype) had some fundamental problems and was long overdue for replacement. I'd been putting this task off since it's a big job to re-implement such a core part of the game (during which the game is basically broken) but finally the time came to tackle it!

Construction system overview

Before I get into implementation details, let me describe the construction process a little. Here’s the scenario; the player has a part selected (which may be part of a larger construction consisting of many parts), they rotate their selection to the approximate desired orientation, and highlight another part with their cursor (again, which may be part of a larger construction) at roughly the location where they want the selected part to go. During which the construction system continually ensures that their selection is aligned correctly to the highlighted part, and checks that attachment is allowable. Once the player is happy they can opt to finalise the attachment, in so doing merging the two constructions together.

So, every frame, as the player moves their selection and / or highlight location, the construction system must update itself in order to be ready for merging the two constructions together. There are essentially two phases to this update.

Phase one - alignment

Automatically align the selected part to the highlighted part:-

1. Search for two alignment points, one in the selected part that is closest to the position at which the player has selected it, one in the highlighted part that is closest to the position at which the player has highlighted it (while prioritising some alignment points over others, as well as ignoring some others, e.g. those that can have no valid pairing between the two parts).
2. Make the two alignment points line up by repositioning and reorienting the selected part (and thereby the construction it is part of) relative to the highlighted part. This is what "snaps" parts together.

Phase two - attachment search and validation

Based on the current relative locations of all the parts in the selected and highlighted constructions (after being aligned by phase one) it must then:-

1. Determine if the two constructions are allowed to be merged together, the rules for this are:-
   1. There must be at least one valid attachment between one part in the selected construction and one part in the highlighted construction.
   2. No parts in the selected construction can be interpenetrating those in the highlighted construction, unless they have a valid attachment between them.
2. Find a list of valid attachments between pairs of parts in the two constructions. These will be used to create joints (hinges, sliders etc.) if the player chooses to merge the two constructions together.

The first phase isn't a big deal because it only ever has to search the alignment points within two parts. However, the second phase (at least naively) needs to compare every alignment point in every part in the selected construction against every alignment point in every part in the highlighted construction. This O(n^2) type of search is obviously not practical as it would quickly get very slow with larger constructions (or even with parts that have many alignment points). A more optimal approach is needed and this is the crux of the problem.

The old solution - physics collider contacting

Early on in the project, rather than creating my own spatial search system, I decided to try and simplify things by making use of Unity's physics in order to help with the second phase attachment search described above. At a high level, this worked as follows:-

1. Use Unity's OnCollisionStay method to detect which part's colliders in the selected construction are colliding with those in the highlighted construction. For each pair of parts for whom there is such a collision:-
   1. Take all the contact points from the collision and average them.
   2. Store this average (along with which two parts are contacting) in a contact list.
2. For each entry in the contact list:-
   1. Use its location to search for the alignment point closest to it in the first part.
   2. Take the alignment point found in the first part and use it to search for the alignment point closest to it in the second part.
   3. If a matching pair of alignment points is found, it will form an attachment.
   4. If such an attachment is not formed and parts are interpenetrating (not merely adjacent), then bail out early, as merging of the two constructions is disallowed.
   5. Otherwise, if an attachment is found, then add it to a list that can be used to create the joints (hinges, sliders etc.) when merging the two constructions.

As a side note, you may wonder why I used OnCollisionStay rather than OnCollisionEnter and OnCollisionExit. That's because if the player moves parts relative to each other but their colliders don't happen to exit and re-enter, I wouldn't get updated contact points.

Problems

Despite serving fairly well for a long time, this implementation had some fundamental issues that I was never able to satisfactorily work around:-

• OnCollisionStay is called from Unity once per fixed update (except when the frame-rate drops below the fixed update rate!), whereas the resultant collider contact list was used in the frame-rate dependant update (to update the list of attachments). Despite using some tricks to get around this, at low frame-rates I found that the contact list would be empty on occasional updates, causing construction merging to momentarily be incorrectly disallowed.
• For some parts the averaged collider contact points weren't always close enough to the alignment points to guarantee that a matching pair of alignments would be correctly found. Again, this meant that construction merging would sometimes be incorrectly disallowed.
• The rigidbodies of the selected construction have isKinematic enabled so that the player can move the selected construction around. This meant that in order for collisions with a highlighted, frozen construction to register, the frozen construction's rigidbodies couldn't also have isKinematic enabled. Instead, the rigidbodies in frozen constructions had their constraints set to RigidbodyConstraints.FreezeAll so that physics was still active on them, with the performance cost that implies. This cost ramped up dramatically if two large constructions were being aligned together with a lot of colliders interpenetrating each other.
• Also, I found that using the rigidbody constraints to freeze them doesn't work that well in Unity 5, not only does it wipe out the inertia tensor (which I had to restore every time after unfreezing), but also there seems to be a frame or so delay before freezing takes effect.
• In order to find surface to surface attachments between adjacent (but not interpenetrating) parts, I had to scale up their colliders slightly so that a collision would be detected between them. Not a big deal, but kind of hacky.

In short, this method was buggy, slow, and would make upgrading to Unity 5 awkward.

The new method - bounds checking and alignment grids

I decided I needed to break my dependency on using Unity physics for solving this problem. This would avoid the fixed update vs. frame update problems as well as the frozen rigidbody performance costs and issues.

The solution I'm currently working on goes somewhat like this:-

1. Each construction has a bounding volume hierarchy to encapsulate their part's bounds. These are used to find which parts in the selected construction have intersecting bounds with those in the highlighted construction, in which case they are likely to be interpenetrating or adjacent.
2. For each pair of potentially adjacent / interpenetrating parts found:-
   1. Compare the alignment points in one part against those in the other to find a matching pair (there could potentially be multiple matching pairs, in which case just use the first pair found). Comparing individual alignment points between two parts would be too slow, so instead I take advantage of the fact that alignments are often arranged in a planar grid pattern (e.g. those on the surface of a plate or beam part). This allows a whole grid of alignments to be compared against another grid of alignments in one step, much more efficient than comparing each alignment individually.
   2. If a matching pair of alignment points is found, it will form an attachment.
   3. If such an attachment is not formed, use the two part's collider shapes to do a proper interpenetration test. If they are interpenetrating, then bail out early, as merging of the two constructions is disallowed.
   4. Otherwise, if an attachment is found, then add it to a list that can be used to create the joints (hinges, sliders etc.) when merging the two constructions.

Still to do

Right now I have a good portion of this new solution working, including the new alignment grid system, but there are still two major pieces left to do:-

• Currently there's no bounding volume hierarchy (I'm just comparing every part's bounds in the selected construction against those of the the highlighted construction). I haven't decided on what type of BVH to use yet, probably K-d tree or octree.
• The part collider intersection test isn't done yet. Because I'm not using physics for this anymore, I'll have to take the collider shapes (boxes, spheres, capsules etc.) and perform my own intersection tests with them.

Once this is all done, the new construction system won't seem much different from the outside to the player. However, it will be more stable, perform better, and remove one more roadblock to the Unity 5 upgrade.

Speaking of which, the Unity 5 upgrade is what I want to look at after, although I may put together some stuff for another demo release first, we'll see!

 

Monster truck does wheelies

Having some fun with a monster truck I just made in GearBlocks. This design will be included as an example construction in an upcoming demo release very soon!

 

New construction system done (mostly)

In the last dev update I discussed the new part alignment search system I was working on. At that point there were a couple of things left to do: implement a bounding volume hierarchy for part bounds, and implement the part collider intersection tests. The second of these two is now done, which means the game is now functional again. I decided to do the BVH as an optimisation step later, as the game works fine without it (albeit with reduced performance in certain cases), and I wanted to get a new demo release out ASAP!

UI improvements



I have also implemented some new features that are in the latest demo. In the construction menu (to access, highlight a construction and hold shift + hold / press Q), there are some additional buttons to activate / deactivate all of the construction's part behaviours. So you no longer have to hunt through all the parts in a construction and activate each behaviour individually.



In the builder tool UI, there's now a new "world" tab. This contains a list of constructions currently in the world and provides the ability to pick a construction and then remotely: select it, activate / deactivate all of its behaviours, toggle it frozen / unfrozen, clone it, save it, or delete it. So if you ever lose a construction because it rolled away down a hill, at least you can always get it back now!



There are also a few other improvements and tweaks, such as a help window summarising the game controls (accessed by holding / pressing F1).

This dev diary demos all of these changes:-

Next up

I'm now at a point where it's time to revisit the Unity 5 upgrade again (can't put it off any longer!), so I'll be looking at that next. I'm not entirely sure how this is gonna go, but I just hope I can find a way around the remaining physics issues.

Beyond that, there are a ton of things I really want to get to, the main ones being: improving the environment / map (having flat area to build on), making the construction controls better, and implementing a challenge / tutorial system.

Build 0.3.5971 for Windows

​

 

Unity 5 physics update (again)

Over the past few weeks I have been working on resolving the physics issues that are preventing me from upgrading to Unity 5. For those that don't know, Unity 4 uses PhysX 2.8, whereas Unity 5 uses PhysX 3.3, the new version being a major re-architecture of the PhysX implementation as I understand it. The resulting differences in physics behaviour have caused me a fair few problems.

A while back I outlined these problems, but I'll run through the remaining ones again here, along with the current state of play for each of them.

Collision contact tolerance
The collision contact tolerance is important to set up so that adjacent parts in a construction have enough leeway to slide past each other without jamming up, while also not allowing parts to sink too far into each other. In order to replicate the same contact behaviour in Unity 5 as in Unity 4, it turns out you have to set the collider's contactOffset to the same value you had Physics.minPenetrationForPenalty set to in Unity 4, and then also shrink the colliders by this same amount in all directions. This shrinking was a bit annoying to have to do, as I use the collider dimensions for other stuff, but at least it seems to have done the trick.

Instability at high angular velocities
Physics engines, given that they integrate at discrete time intervals (rather than being continuous like IRL physics), often struggle with objects with high velocities, the only way around this really is to update the simulation more often with a smaller time step. So in order to allow for rapidly spinning parts like gears, axles, etc. in GearBlocks I have to use a small time step (Time.fixedDeltaTime), otherwise things would become unstable and start wobbling all over the place. However in Unity 5, I had to set it to be even smaller in order to get the same level of stability, unfortunately offsetting much of the physics performance gains over Unity 4!

Each joint connects two rigidbodies, one being the owner of the joint, the other the connected rigidbody. One thing I discovered that helps with stability is to set up the owner / connected relationship in a particular order. The PhysX documentation recommends having the rigidbody with the higher mass of the pair be the owner. I found that it was even more effective to have low velocity parts (e.g. blocks, motors, etc.) be the owner, and those with high angular velocities (e.g. axles) be the connected. Setting joints up in this way meant I could get stable behaviour in Unity 5 without having to reduce Time.fixedDeltaTime by quite so much. Unity 5 / PhysX 3.3 seems super sensitive to this ordering, whereas Unity 4 / PhysX 2.8 doesn't seem to care. It's tricky to set up though because I don't know ahead of time which parts of a construction are going to be the fast spinning ones (and I can't change the ordering once the construction is unfrozen and moving without causing other problems which I won't get into here). So right now I'm working on something that'll use an educated guess and hopefully get it right in most cases.

Unstable collision behaviour
In Unity 5, for some constructions when contacting flat ground, their collision response with the ground isn't very stable and they can keep bouncing around for ages after the initial collision. What's more, this gets worse the smaller the simulation time step. Setting up the joint rigidbody ordering as I discussed above seems to reduce this instability though. Also setting the rigidbody's maxDepenetrationVelocity to a smallish value helps too.

Joint drives (used for motors)
I was finding that the same force numbers for joint drives were giving different results between Unity 4 and 5. I discovered that in Unity 4 the JointDrive's maximumForce value should be multiplied by Time.fixedDeltaTime (which is what I was doing), whereas in Unity 5 it should not. In other words, Unity 4 expects an impulse value, but Unity 5 wants a force value!

Configurable joint velocity drives
Once I grasped the differences in the way the settings behave, I was able to get these working, sort of. I found that they still don't work if the rigidbody's mass is below some threshold, and there also seems to be a dependency on Time.fixedDeltaTime. Not really sure what's going on here, I need to do some more investigation on this one.

Getting there, but more to do

Well, if anyone out there is still in the process of upgrading to Unity 5, I hope my findings might be useful to you! I'm hopeful I can resolve all this stuff soon, after which I still have to migrate away from some deprecated APIs, and work around a bunch of other bugs and issues I'm having in Unity 5. Anyway, I can't wait to put this upgrade to bed so I can get back to actually making the game!

 

There is "Scrap Mechanic" on Steam which looks similar. Check it out for some... inspiration.

 

Thanks, yeah, I've seen that one!

 

Unity 5 physics issues finally sorted

At long last, I have resolved all the remaining physics problems I was having with Unity 5! As I mentioned in my previous 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.

 

Hello, how do you created the wheels blocks? There are some tips and tricks or it is just a cylindrical collider with a mesh model?

 

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



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.



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.



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!

Build 0.4.6034 for Windows

​