TIGSource Forums

Hey everyone, finally getting around to starting a devlog!

I'm making a physics based open world construction game where you can build pretty much whatever you want - buildings, machines, vehicles, etc.  I'm taking inspiration from Garry's Mod, LEGO Technic, Minecraft, and a lot of the construction / exploration / crafting games that are coming along now.  One of my key motivations behind this project was to make an experience that is as open as possible, allowing players to be totally creative, and not constrain them to only be able to build certain things.

(http://i.imgur.com/n90iU5J.jpg)

Currently it's still just a sandbox "toy", but my plan is to add game mode(s) that will make it into a proper game, I'll expand on my thoughts on this in a later post hopefully.

(http://i.imgur.com/cnKfeIV.jpg) (http://i.imgur.com/D0DF4p5.jpg)

(http://i.imgur.com/qv0OJbK.jpg) (http://i.imgur.com/9co1ewU.jpg)

A summary of what I've done so far:-

• The first attempt at the core construction mechanic.  Everything happens in the first person view, you build by picking up parts, bringing them in contact with others, and their position and orientation then snaps into place appropriately.
• A small selection of parts that you can build with.  The most basic being beams and plates that lock together rigidly.  Then there are axles that attach to beams and can rotate, wheels and gears that attach to axles, a motor that drives axles etc.  Each type of part can have a behaviour (motors apply torque to axles, gears transfer torque to their neighbours, propellers generate thrust when rotated, a seat will lock the player into place when activated, lights turn on and off, and so on).
• Part behaviour controls.  When you've built a construction, you can then interact with it to make it do stuff.  For example, you can map key presses to activate motors, allowing things like building a car that you can drive around.
• Basic networked multi-player, you can create a server and build stuff with other players.
• Simple inventory, holds the parts you currently have, and used to spawn them into the world.
• Basic save game support, you can save out the world state including all the constructions you've built, and load it back in.
• Procedurally generated island to build on and explore, the terrain is generated from a seed string that you can type in or generate randomly, so there are essentially an endless number of islands to play on.

Here's an old video that's a bit out of date, but it gives an idea of how the construction process works: http://www.youtube.com/watch?v=b8aie7Iqtuo

I have a playable build that I keep updated regularly: https://dl.dropboxusercontent.com/u/157530041/WebPlayer.html

I've been keeping a dev blog since the start: http://dangersam.tumblr.com/, from now on I'll try and keep both of these updated, but it covers things in a bit more depth if you're interested.

Right now it's just me working on this project, all art is very much place-holder, and progress is slow!  Oh yeah, and I still don't have a name for the game yet, anyone got any suggestions? :)  Thanks for reading, and I welcome any feedback.

I'm imagining something like the Incredible Machine. You're given a limited selection of pieces and have to build something to solve the "puzzle". Is that what you're going for? Making gameplay around these kinds of things is a challenge, but there's always a way. I mean just look at Kerbal Space Program. That's a great example of a game where building is its own reward.

This has potential and I'd like to see where you go with it.

Thanks DaCo!  Yeah, something along the lines of what you're suggesting is definitely one possibility.

I was thinking it could work a bit like Junkyard Wars / Scrapheap Challenge if you ever saw those shows, where each player (or team of players) is given a set allocation of parts and they have to build something to achieve an objective (e.g. build a car then race to a checkpoint, or build a tank then try and destroy the opposing teams tank, or make a catapult and see who can fling stuff the furthest, and so on).

Following on from the introductory post, I thought I'd go through what I think needs improvement right now.  The main things that need work are:-

• Construction mechanic - I really like the basic idea of putting parts together in a first person view, but there are big problems with my current implementation, such as (among others):-
  
  • It's hard to position and orientate parts accurately.
  • Once a part is attached, you can't adjust it's position without detaching it and reattaching.
  • There are cases where jointed things (like blocks and axles) only attach properly if you put them together in a certain order.
  • It's possible to attach parts which results in them inter-penetrating.
  • And yes, if you're on a slope, parts can roll away from you as you're building, very annoying! :)
  I basically need to bite the bullet, rip out the current stuff and rework a lot of it.  My plan is to scrap the current implementation which uses contact points calculated when the player touches one part to another to determine attachment positioning and orientation.  Instead, I think I'll use the contacts only initially to determine which two parts to consider for attachment and then switch over to a different control scheme to actually position the part.  The details of this I still need to work out.
• Player stuff - improve first person controls and camera, physics interaction, add player's arm holding some kind of construction tool, etc.
• Networked multi-player - implement client side input prediction, optimise state sync / RPC usage to reduce bandwidth, make a dedicated server.
• Construction parts - add more types of parts to build with, to expand the scope of what can be constructed.

If you get a chance to check out the build (https://dl.dropboxusercontent.com/u/157530041/WebPlayer.html), I'd be really interested to know how you find the process of building stuff in the game!

Awesome! :addicted:

Is your player grounded or is it a free-flight camera? Make it so that you can't just float around and in order to build something tall you first need build stuff to climb higher. Ladders, lifts or whatever. That would be cool I think. So to build a tower you first need to figure out how the get parts all the way up there, and puzzles like that.

edit: So I tried building stuff a bit. The snap tool is a bit finicky. Sometimes the highlight appears and disappears by moving the mouse only a couple of pixels. Rotating and aligning pieces is pretty difficult and takes a while to get used to. I tried building a vechicle but it kept rolling down the hill. So I just jumped on and got the ride of my life. That was a lot of fun! :)

Will there be a way to control multiple engines with one button eventually? I can see this being a problem for your liftoff with your quadcopter. This way the proppellers would equally lift you up at the same time.

Right now you're grounded, there's no free-flight mode.  I agree that it's kinda cool that you have to build up to climb higher, and then build further.  Mind you, as it is right now you could just build a tower horizontally on the ground, then pick it up and set it upright. :)

Totally agree, all the issues you mention have been bugging me too for a while now.  Overhauling the construction mechanic has to be my next step I think.  Thanks for the feedback!

Yep, actually you can do this now by mapping multiple motors to the same button (and turning them all on).  That way you can get all the quadcopter props to lift at the same time.  The problem is it's unstable and eventually will tilt over, and there's no way to steer it.  I need to figure out a way to provide better control!

The problem you will have here is differentiation; why do I need to play this when I could fire up say Garry's mod, Kerbal Space Program or even minecraft?

I applaud your work to date, so hopefully you can find the particular niche that makes your idea compulsive to try out.

Thanks GameTheory!  I'm hoping part of the differentiation (at least from Garry's Mod) will come from making the construction a bit more user friendly and approachable, assuming I can achieve that.  But yeah, I agree, most importantly it needs a concept that will set it apart from other similar games, I have some ideas, but definitely something I'm still working through...

So far it looks really cool! As for direction I think it would be cool if you had several different gamemodes all based around the building mechanic. The main trouble with this would be making sure each gamemode has enough depth. You'll probably have some work to do design wise so that your game is dynamic enough and interesting enough to keep people coming back. If you can achieve that though I think you would have a really stellar game on your hands! ;D

For now though just keep working on that building system  ;)

This looks really addicting, can i do the music for it?

We can never have too many of these games. I'm curious to know what game modes you have in mind.

Ok, I'm going to follow up on game modes a little bit and brain dump my thoughts so far on this.  The problem with allowing players to build whatever they want is that it's a little tricky to directly measure player progress, or to even define what it means to progress through the game.  Whatever game mode(s) I come up with need to be flexible enough to allow players to come up with different solutions to the same problems.

I have a few vague ideas so far:-

• Challenge mode.  For each challenge the player is given a set allocation of parts and they have to build something to achieve an objective.  I think objectives with fairly simple outcomes (that could be measured in terms of times, distances, speeds etc.) would work best for solution flexibility.
• Survival mode.  This would be along the lines of Minecraft and other similar games, where you gather resources, craft parts, and then build things with them that help you survive.  For the survival aspect you'd probably need NPC creatures (which can be killed for resources, but can also attack the player and can damage your constructions), or maybe you're just surviving against hunger and the environment (sun, weather, etc.)
• Escape mode.  This would combine aspects of the above two ideas.  Essentially, while trying to survive, you'd be building things to complete challenges at various places in the environment, which would somehow gradually build up to allow an "escape" from the island you're trapped on.  It would give a reason to explore, and an end goal to work towards.

I'm not sure yet what direction I'll end up going with, but right now I'm most intrigued by the third option, so I'm gonna try and expand that idea a little more.  In the meantime, any thoughts / ideas are welcome!

Construction Improvements - Freezing

In the first step towards overhauling the building game mechanic to make it easier to use, I have changed the controls a bit.  Now, you have to “freeze” a construction before you can attach other parts to it.  You do this by holding shift and left clicking, either when highlighting a construction with the cursor, or when a construction is selected (i.e. picked up).  In either case, it gets frozen in place (with a blinking bounding box outline to indicate that it’s currently frozen).  Shift + left click again will unfreeze, as will selecting it.

Because you can pick up a construction and then freeze it, it can be frozen in any position & orientation, making it easier to modify less accessible areas, as in this example:-

(http://i.imgur.com/3xOWBWS.jpg)

In addition, when a construction is frozen, any parts that freely rotate with respect to each other (e.g. blocks and axles) are reset to a default orientation that realigns everything within the construction.  For example, you can see in the image above moving parts such as the wheels, gears, and steering beam are all aligned at right angles to the rest of the construction.

Right now, the main benefit is that it prevents stuff rolling away while you’re trying to build!  However, the plan is that it will also allow me to improve the part snap-to behaviour and make positioning & orientating parts easier.  More on this soon hopefully!

Wow, it's been a long time since my last update!  I've been locked away working on the building mechanic for the last couple of months, but now I finally have something new to share.  After the construction freezing stuff that I posted about before, the next step was to work on how the player positions, aligns and attaches new parts to a frozen construction.  The implementation I had in place for this (dating right back to the beginning of the project) was clunky and difficult to use, and was in need of a major overhaul.

Over the past two months I have been prototyping many different ideas for alternative solutions.  It has been a challenging and frankly frustrating experience, because every method I tried seemed to have its own pros and cons, and no single idea jumped out as the "correct" way to go.  It's not been an easy problem to solve, but I have now settled on what is hopefully the least worst solution!  I think with further refinement it can be made to work quite nicely, certainly it's already much better than what I had before.

Original method

The original implementation I had for alignment and attachment was done just using physics collider contacts.  You had to position your selection, so that it touched the frozen construction roughly where you wanted it to attach, and it would snap in place based on that.  The problem was that you had to be very precise with the positioning in 3D space, otherwise things might not contact where you wanted.

Rejects and epic fails

To try and help positioning the selection, I tried various ways of aligning it to a plane oriented relative to the frozen construction.  This helped a bit, but it was clear that manoeuvring stuff in 3D space with high precision was still gonna be too fiddly.  I decided that more of a screen-space approach was needed with smarter, more automated alignment.

Unity's physics system can sweep a rigidbody through the world, determining which colliders it would contact.  I tried using this to sweep test your selection away from you in the direction you're looking, to see where it might contact a frozen construction.  But because the test is done in world space, not the perspective space of your POV, it felt weird and I couldn't really find a way to make it work.

So then I tried raycasting from your view position through every attachment point of your selection, to find intersections with a frozen construction, and use these results to determine where to position / align for attachment.  This had potential to work well, but simply required way too many raycasts for reasonable CPU performance.

One last raycast

In the end for the final solution I decided to keep it simple, I now do a single raycast through the screen centre to find an attachment point on a frozen construction.  The selection point (position of the cursor relative to the selected construction) is used to find an attachment point on the selected construction.  These two attachment points are then used to snap the selection into alignment.  The effect of this is that the point where alignment is happening is always right under your cursor at screen centre which is quite nice from a usability perspective.

This approach had a problem however - you could only align relative to a single point on your selection!  Rather than having to drop it, and pick it up again at a different point, I wanted the player to be able to move their selection underneath the cursor.  So now when aligning a selection to a frozen construction, by holding shift and using the directional keys (i.e. WASD), you can do exactly that.

Next steps

After all the prototyping, some of the code has ended up a bit of a mess, so first I need to clean that up.  After that there's a bunch of further work to the construction mechanic that I need to do:-

• Selection movement improvements - as I mentioned, you can now move a selection relative to the cursor using shift + WASD, but it's still a bit clunky and needs some work.
• UI / visualization - now that the core mechanic is close to being done, I need to add some visual feedback during construction, as (unless you've memorized the controls ahead of time!) it's hard to figure out how it all works.
• Part multi-select on a frozen construction, selected parts can then be picked up for re-positioning, cloning, or deleting.
• Ability to flip block to axle connections between rigid and hinged, post attachment.
• Various bugs and other minor issues.

Once I have some basic UI / visual feedback elements in place, I'll put together a video to demonstrate the new building mechanic.  In the meantime feel free to try it out in the build: https://dl.dropboxusercontent.com/u/157530041/WebPlayer.html

(http://i.imgur.com/YCLSndV.jpg)

(http://i.imgur.com/EkdPyt5.jpg)(http://i.imgur.com/WsrXXjd.jpg)

Glowing highlight

I’ve just replaced the old construction highlighting (line drawn bounding boxes) with a new glowing outline effect.  When a construction is selected it glows blue.  Then, when aligning it to another construction, the colour changes to green if the attachment is valid, red if not (i.e. if parts are interpenetrating).  Constructions also glow blue when they’re frozen.

More UI / visualisation improvements coming soon hopefully...

(http://i.imgur.com/bqtrBXf.jpg)

Energy beam

Over the last couple of weeks I’ve mostly been doing code cleanup and bug fixes, so there’s not much new to show.  I have added a new energy beam effect though, for when you have a construction selected.  It’s a first stab at it and still needs some tweaking, but it works pretty nicely.  Once I add the construction tool held by the player, the beam will emanate from that, but for now it comes from just below camera.

Construction controls walkthrough

The construction game mechanic is getting close to being finished now, barring a few minor tweaks here and there, so I’ve made a video to demo how the controls work to position, align and attach parts together.

http://youtu.be/_AfpQTPzdqA

Apologies for the lack of updates of late, I've been struggling with physics stuff for a while, and I also had a pretty bad flu a few weeks ago which slowed me down a lot!  However, I've now finally made some good progress on the physics front, much improving the way gears and motors work.

Gears

For the gears to work, we want neighbouring gears rotate in sync with each other, taking the ratio of their respective diameters into account.  My old implementation for this synced neighbour gear's angular velocities, but didn't sync angular displacement (so gears would slip under high torque loads), and didn't take rigid body inertia tensors into account (particularly noticeably wrong with gears that were part of rigid bodies with large moments of inertia).

The proper way to do this is to have a physics constraint that forces the angular velocity and angular displacement to stay in sync.  Unity comes with a configurable constraint (or joint), which is almost flexible enough for what I need, except that you can't specify any kind of gear ratio.  PhysX 3.X supports custom constraints, but Unity is still using an old version of PhysX (2.8.3 I think).  So I had to implement my own constraint, which gets applied in FixedUpdate to modify rigid body angular velocities.  This works OK for the angular velocity part of the constraint, but because I don't have access to the internal physics update code, I found it problematic for syncing angular displacement.  This is because Unity doesn't provide the current total angular displacement of a rigid body.  I attempted to track it myself, but because I don't have direct access to the changes made by the physics update, it was not accurate.  So instead, over every update, I accumulate an angular displacement delta between the two rigid bodies using their respective angular velocities, and then use that to apply a correction back to their angular velocities.  This isn't as good as syncing the angular displacements directly, as it means the gears still slip under high torque loads, but they do eventually correct themselves with a kind of delayed "springyness".  At least now they won't slip indefinitely, so it's certainly better than my old implementation!

Motors

As Unity physics doesn't "know" about my gear constraint that is modifying angular velocities outside of the main physics update, the built in joint motor no longer worked properly.  So I had to implement my own motor constraint (which was pretty simple because it only constrains angular velocity, not displacement).  An added bonus to doing this was that it gives me much more control, and I was able to add a torque curve that makes the motor behave more realistically, and can be customised for all different kinds of motor.

Also, now that the new gear constraint properly accounts for rigid body inertia, I was able to increase the motor torque to a much more reasonable level, and have it behave consistently regardless of whether gears are part of large or small rigid bodies.

Well, that's it for now, these changes are now in the playable build: https://dl.dropboxusercontent.com/u/157530041/WebPlayer.html.  Hopefully they'll allow you to build more complex and interesting machines!

I find the tools frustrating to use, but the end results seem really awesome.
Perhaps if you could generate a more interresting world, this could be even better :)

This, looks, awesome.

Bringing back memories of creating shitty vehicles in Little Big Planet, but only now the vehicles will make sense.

Seriously can't wait for something playable.
OH there is! Well I know what I'm doing then.

Attachment indicators

I’ve added new indicators that show the attachment points between parts, these indicators appear when a construction is frozen.  There are two types of indicator, one for rigid attachments, and one for rotating attachments.  I had to add extra data to the constructions for this, which unfortunately meant a change to the save game format, so old save games likely won’t load properly.

Rigid vs. rotating attachments

For a while now it’s been possible to attach blocks to axles either rigidly or free to rotate (pressing E to cycle between these two modes when a construction is selected).  However, gears and wheels could only be attached rigidly to axles.

Well, now gears and wheels can also be attached free to rotate, just like blocks.  This opens up more possibilities when building, but it does mean you have to be careful to select the correct attachment mode for what you’re trying to do.

Physics rigidbody mass properties

Unity’s physics automatically calculates the centre of mass and inertia tensor for a rigidbody based on the colliders attached to it.  The PhysX API allows you to specify a mass or density per collider, but unfortunately Unity doesn’t expose this, it just assumes a uniform density.

Given that the parts you build from can have very different densities based on their material (e.g. wood vs. metal), I wanted the centre of mass and inertia tensor of a construction to properly reflect its constituent parts.  So, after writing a whole load of code that essentially duplicates some PhysX functionality, per-part densities are now taken into account when calculating the total mass properties.

This is more physically correct, but what’s the practical benefit to the player?  Well, when building you can now decide to use heavier parts to affect the stability of your constructions (e.g. use metal parts for the chassis of a car, and lighter materials for the body, to give it a lower centre of gravity).  This will have more benefit once there are more part assets made from a greater variety of materials.

TL;DR The materials that parts are made from now affects physics game-play, not just the visuals.

Tried for a while to make the electric motor rotate a gear on an axle, but never got it to work. Am I missing something obvious? Tried for quite a while in every imaginable way (I feel).

Other than the issue, it's very promising. Could I get it to work, I'd enjoy it a ton I'm sure.

Hmm, I really need to figure out a way to make the UI more obvious. :)

Once a motor is switched on (by hovering over it and pressing E), you hold Shift + A/D or W/S to control it.  To configure whether the horizontal or vertical directional controls (i.e. A/D vs. W/S) drive the motor, you have to hold Shift + E while hovering over it, which brings up its configuration dialog.  Hope this helps!

Ah, that worked :) Thank you.

And remembering to unfreeze ones construction is also VERY helpful :shrug2:

Just updated the playable build with a bunch of miscellaneous small changes and bug fixes, the main ones being:-

• After detaching a part from a construction, it now becomes selected rather than just dropping onto the floor.
• Added a “no control” mode to the motor part behaviour, in this mode the motor runs continuously when switched on rather than being controlled by player directional inputs.
• I (re)disabled free spinning attachments between gears and axles as it doesn’t play well with physics when the axle spins quickly (too unstable - gears wobble all over the place).
• Fixed a bug where part attachment intermittently doesn’t work during low frame rates.

(http://i.imgur.com/YXELJlF.jpg)

New part added: Servo motor

Frustratingly my video hard died last week which slowed progress quite a lot (I’m resorting to my notebook PC at the moment).  However, I have added a new part, a servo motor.  Unlike the regular motor, it doesn’t spin continuously but, based on directional input, it’ll rotate between +/- some maximum angle (that you can specify).  This is intended for controlling vehicle steering (as shown in the image above), or any other situation where you need precise control.

Another long gap between updates I'm afraid!  I thought I'd gotten through the last of the really tricky physics issues once I'd sorted the gears, but oh no...  Over the past month I've been battling through a bunch of problems with wheel physics, but I finally have a solution that I think is satisfactory (albeit at some performance cost unfortunately, as I'll explain later).

There are two things to deal with when two physical objects contact each other (in this particular case, a wheel, and the ground), these being collision and friction.  In Unity, you'd normally just attach colliders to your objects, and leave it to PhysX to take care of it all, but this is not particularly well suited for wheels.  First of all, there are no colliders available that properly match the shape of a wheel (i.e. a cylinder), and that also roll smoothly across the terrain, really the only options are a sphere or capsule collider.  Secondly, you don't have enough control over friction, which is particularly important for wheels / tires.  Unity's built in wheel collider is a specialised solution that includes a spring / damper model, and must be attached to a vehicle chassis, not directly to the wheel itself, so it is not suitable for my purposes.


Various attempts

I tried several approaches to deal with the wheel to ground collision and friction response, which I'll briefly go through now.

Built in collider

Until now the wheels had been set up to use a capsule collider, but this doesn't conform to the wheel shape, the capsule ends stick out of the wheel itself which means the wheel can't tilt over properly while contacting the ground.  I even tried using a mesh collider to approximate the cylindrical shape of the wheel, but because it is faceted it doesn't roll smoothly across the ground.

Raycast to find ground contact

Given that using a built in collider wasn't going to work, the first thing I had to do was find the wheel's contact point with the ground for myself.  To do this, the wheel fires raycasts towards the ground (perpendicular to its rotational axis) to find a contact point and normal.

Custom constraint solver

I implemented a constraint solver that resolves the collision by calculating an impulse along the contact normal to push the wheel away from the ground so that it doesn't penetrate.  It also finds an impulse (tangential to the ground contact) to resolve friction, using a simple Coulomb friction model.  Essentially, exactly what PhysX does internally to resolve contacts, except now I'm able to use my own contact points.  This took a while to code up as I had to brush up on my physics knowledge a fair bit, it's very easy to screw things up and introduce energy into the system if you're not careful!  Once I got it sorted though, it worked great, the wheel rolled smoothly across the ground, was able to tilt over properly, etc.

However, there was a problem, with heavy constructions the wheel would sink into the ground and spring back out.  This is actually a similar issue to the laggy springiness my gear constraint solver suffers from.  I think it's because my solver update runs independently of the PhysX internal solver updates, and so doesn't get a chance to properly "compete" with the built in constraints (joints etc.)

Configurable joint

So, rather than use my own constraint solver, I tried to recreate it using a configurable joint (as available within Unity), connected to the wheel's rigidbody.  Every update the joint gets repositioned above the ground contact point, and has a linear limit set up to prevent the wheel going below the ground, thus providing the collision response.

For friction, the configurable joint's velocity drive is set up to force the ground relative velocity (tangential to the ground contact) to zero.  This alone would result in essentially infinite static friction, so a maximum impulse is set on the drive.  As per Coulomb, this impulse clamping needs to be based on the contact normal impulse.  However, there's no way to find out what impulse PhysX is applying to constrain the wheel to the linear limit, so what to do?  In the end I had to estimate it by using the approximate mass over the wheel and the force against gravity along the contact normal.  Kludgy, but it'll have to do.

This solution worked nearly as well as the custom constraint solver, and without wheels sinking into the terrain, so was the one I settled on.  The only downside of this method is that when you have a lot of wheels, the configurable joints seem to incur quite a noticeable performance cost.


Hopping wheels and sagging joints

The wheel collision and friction were not the only issues to deal with.  A problem I found a while ago after adding the servo part and using it in the game to build cars with steering, was that during cornering, the lateral forces would cause the wheel (or rather the hinge joints connecting it) to flop over.  It would then lose contact with the ground, snap back, gain contact again, and so on, causing the wheel to skitter and hop across the terrain.  Also, if the construction was heavy, the joints attaching the wheels would sag under the weight.

I tried to think of ways of forcing the wheel to remain vertical to the rest of the construction, but because the player is free to build in whatever way they want, I have no way to know which direction a wheel should be constrained in.  To be honest, the physics engine isn't really designed for what I'm trying to do, normally you wouldn't model vehicle physics with joints and rigidbodies for all the moving parts, instead you'd build a specialised vehicle physics engine.  For my game I can't do this though, as players construct the vehicles themselves in game.  In the end the only fix I was able to come up with was to increase the physics solver iteration count, which has the effect of tightening up the hinge joints and lessening their sloppiness.  This comes at the cost of a significant performance hit though unfortunately.


The build is now updated with the new wheel physics so you can try it out!  I've also added a wheel skid sound effect, and fixed a bunch of bugs, including a pretty major screw up with the rigidbody mass properties update that I've now sorted.

Just updated the build, it has a bunch of bug fixes and minor tweaks, but the main change is that part behaviour settings are now stored when you save a game.  For example, a motor’s directional controls and “is reversed” settings will be saved, so they won’t get lost whenever you save and then reload a game.  Unfortunately, as this required a change to the save game format, old save games won’t work.

(http://i.imgur.com/fsW7VUA.jpg)

(http://i.imgur.com/qJRMj5H.jpg)

Just took a break from working on the game, and had some fun playing it instead!  Here’s a pickup I built, it features dual motors in the back, working steering and lots of lights. :)  Top speed is around 160 km/h.  Being narrow and fairly top heavy, it takes some finesse on the steering not to flip it over!

Release build only, game breaking bug, oh joy

Gah, bloody typical.  It’s Friday evening and I’ve just discovered a game breaking bug.  In both the standalone and web-player builds, it seems Unity sometimes decides not to call my “on collision stay” callback, which breaks the whole construction mechanic - it means you can’t attach parts together!  I’m not sure how long it’s been like this, I usually test the game in the editor, which naturally enough doesn’t have this issue.  Lesson learned: I really should properly test the standalone builds more often!  Hrm, it could be a while before I figure this one out… :(

Non-collision bug update

I’ve been away on vacation for a couple of weeks, but after getting back I’ve been looking further into that non-collision bug. After some further investigation, it turned out that not only was my “on collision stay” callback not being called, but collisions between the parts were not happening altogether. I also managed to reproduce the issue in the editor as well as standalone / web-player builds.

I haven’t found a work around yet (not sure if I even can), but I put together a special cut down version of my game project and sent it off to Unity to help them reproduce the bug. In the meantime, the game is still broken unfortunately, the only way to get around the issue is by removing and re-adding parts to your construction until Unity physics corrects itself. I hope the Unity devs can fix this issue soon, but I guess we’ll just have to wait and see!

(http://i.imgur.com/6pKRNvB.jpg) (http://i.imgur.com/mXNFtA6.jpg)

(http://i.imgur.com/o1egiBM.jpg) (http://i.imgur.com/AWpWsYx.jpg)

New time-of-day / sky system in game

I felt like I needed a change after being bogged down with the construction mechanic and physics issues for so long, so I decided to do some rendering stuff over the last week or so.  As of the latest build, I have integrated Mod Monkeys' fantastic Time of Day system (available on the Unity asset store: http://u3d.as/4fg) into the game.  It implements atmospheric scattering, dynamic time-of-day, clouds, weather etc. and is really nicely done, a quality asset.  It wasn’t quite a straight drop in for me, as I had to apply the scattering to my terrain shaders and make a couple of minor mods, but overall it was very easy to integrate.  So far I have the time of day changing as you play, but the weather doesn’t do anything yet, I’ll have to look at hooking that up later.

Next up for me is back to the construction mechanic.  Still no word on that Unity collision bug…

(http://i.imgur.com/hFXMDJc.jpg) (http://i.imgur.com/xwWhUwJ.jpg)

(http://i.imgur.com/oW8hVR3.jpg) (http://i.imgur.com/Kg6UPZM.jpg)

Time-of-Day timelapse

Having too much fun playing with this at the moment… :)

Hey, This looks like tons of fun. I'm using Chrome and the game loads to a black screen? After I select play from the map seed menu it loads and I can open the inventory and options and everything, I can even hear the sound but visually nothing. The speed and altitude update as I use the controls as well, I attempted lowering the graphics thinking it may be that but to no resolve. Any suggestions?

Hrm, that's odd.  Did you try turning off HDR in the graphics settings?  Sometimes the HDR auto exposure can go a bit screwy.

Deleting attachments

Over the last week I’ve made a couple of changes to the way parts can be detached from one another.  Firstly, when you right-click a part, all attachments connecting that part are now deleted (not just hinges only or rigid only).  Secondly, and perhaps more interestingly, attachments can now be deleted individually.  This is done by hovering your cursor over the attachment to highlight it, and then right-clicking it.  For example this allows you to detach and re-position an entire sub-section of your construction by deleting only those attachments that are connecting it.  Remember though, stuff will stay attached together until all attachments connecting them have been severed.

Hopefully these changes will make it easier to modify your constructions, re-position things, and so on.  The plan is, in addition to deleting, you’ll soon be able to make modifications to highlighted attachments.  Hopefully I’ll have this done in the next week or so!

Couple of updates in the build...

Attachments

Previously, when attaching parts together with a hinge, the game would attempt to remove any rigid attachments that would prevent these parts from rotating with respect to one another.  Now that you can go in and delete individual attachments after the fact, I’ve removed this behaviour as it was somewhat arbitrary.  At this point I think it’s better to leave it up to the player to decide which attachments to delete.

In conjunction with this, any hinges whose connected parts can’t rotate (due to being also rigidly attached in some way) are now highlighted red.  This will hopefully help you debug stuff in your constructions that isn’t rotating as you want it to.

Physics collisions

Up ‘til now, subsections of constructions that were directly attached together with a hinge would not collide with each other.  As of Unity 4.5, the PhysX flag that enables these collisions has been exposed, so I’ve now enabled it in game.  No more parts passing through each other, woop!

(http://i.imgur.com/CqX4mQG.jpg)(http://i.imgur.com/GOh4xo6.jpg)

Alignment indicators

When aligning a selected part to another (frozen) part, prior to attachment, the game now shows where the available attachment points are.  These indicators reflect the type of attachment, either “surface” (e.g. as in block to block) or “interior” (e.g. as in block to axle).  The idea is that this should make it easier to accurately position parts where you want them.

Other stuff

In order to implement the alignment indicators I had to refactor a bunch of code, one side effect of which was that I was able to slightly reduce the per-rigidbody network data by calculating more stuff on the client side.  I also fixed a bug in explore mode, that was causing parts to not spawn.

Tutorials

Here's a series of tutorials I've made that attempt to explain the basics of how to build stuff.  Hopefully they'll be useful to anyone who's just starting out playing my game!

Tutorial 1: Attaching parts rigidly - http://youtu.be/uS8IoqsjW_Y
Tutorial 2: Attaching parts that can rotate - http://youtu.be/duHJivDlXDI
Tutorial 3: Part behaviours - http://youtu.be/cCqKnFoQqFw
Tutorial 4: Gears - http://youtu.be/WtG95K2A0nw
Tutorial 5: Building a simple car - http://youtu.be/VdtGsk2zJWY
Tutorial 6: Making a car steering mechanism - http://youtu.be/wzYQ_9hRqkY

A few minor updates

Over the last week I’ve mostly been working on project planning stuff, but I did make a few minor tweaks to the build.  Now the graphics and sound settings get saved and re-loaded.  There’s also an option to enable vsync, and when creating a new “sandbox mode” game, you can set some basic time-of-day settings.

Next week, more project planning.  Wanna get this out of the way so I can get back to designing & coding!

(http://i.imgur.com/CNZs3cb.jpg)

New stuff in the game this week: improved the rendered images of parts in your inventory, did a whole bunch of asset tweaks, and added some new parts to build with!

Rendering overhaul

In Unity, full-screen image effects, such as screen-space ambient occlusion (SSAO), bloom and tone-mapping, can only be applied after everything else has rendered.  You can optionally flag image effects to render between opaque and transparent stuff, but that doesn’t help me because image effects wipe the stencil buffer, which I need for object highlighting.

Previously there were many things about the rendering order in the game that were just plain wrong.  For example, SSAO was being applied after water and atmosphere / fog, and 3D UI elements were being bloomed and tone-mapped.  Ideally you want to be able to interleave image effects and other rendering at will.  The only way to do this in Unity is to use multiple cameras (with only the first one clearing the screen, the rest rendering on top).  Here is how I have things set up now to achieve the correct rendering order:-

Camera 1

• Clear screen.
• Render opaque objects (e.g. terrain and other solid objects).
• Render object highlighter mask texture using stencil values written by object shaders.  This has to be done before any image effects, as they wipe the stencil values.
• Render SSAO full-screen image effect.
• Render atmosphere / fog as a full-screen image effect.

Camera 2

• Render transparent objects (e.g. water), these apply atmosphere / fog in their shaders.
• Render object highlighter full-screen image effect, using mask rendered earlier.
• Render sun shafts, bloom and tone-mapping image effects.

Camera 3

• Clear depth only.
• Render 3D UI elements.
• Render 2D UI / menus etc.
• Render anti-aliasing full-screen image effect.

Unfortunately, using multiple cameras like this exposes some long standing bugs in Unity which really screwed me up for a while.  Luckily there are known workarounds for these, for more info you can check out these threads:-

• http://forum.unity3d.com/threads/deferred-renderer-multiple-cameras-posts-ssao-bugged-ufps-onrenderimage.198632/
• http://forum.unity3d.com/threads/grabpass-problems-when-using-multiple-cameras.167676/

Ambient occlusion

I’ve also fixed some issues with SSAO that were causing black speckly artifacts to show on the distant terrain.  Now that SSAO looks much nicer, I’ve enabled it by default.  I’ve also fixed a bunch of other bugs and issues!

Hey! Great stuff so far =D I love Garry's Mod, and you got here some of its charm.

Do you plan on adding some kind of survival mechanics? like having to eat or waves of enemies from time to time?

Thanks Thanar!

I am planning on having a system based around energy (e.g. motors, lights etc. cost energy to run, materializing new parts costs energy, energy can be gained from solar panels, reactors etc.)  I want to incorporate player health into this too somehow, which would make it a survival mechanic of sorts.  I had thought of having NPC enemies, but they're cut for now, the scope of this project is already way too big! :)

This looks awesome! definatly following ^-^

Dev diary: http://youtu.be/u5fDuKqZoUk (http://youtu.be/u5fDuKqZoUk)

Construction controls update

Over the last couple of weeks, I’ve made a couple of changes to the controls:-

• After parts have been attached together, you can now cycle their attachments between available types (e.g. rigid or hinge), by hovering over attachments and pressing E.
• Cloning and deleting entire constructions is now done via a separate menu (accessed by holding Shift + Q).

More rendering improvements and other fixes

Also now in the build:-

• A load more rendering improvements following on from the previous overhaul.  The main difference being that the sky and distant water are now rendered before everything else, using another separate camera with a much larger far clip distance.  This prevents the horizon line from being clipped out.
• Time-of-Day upgrade.
• Reference grid in inventory part preview images.
• Force zones now slow down objects at world boundaries.
• A bunch of bug fixes.

Looking really good an interesting. Love the idea of game modes you had on the first page.

One of the first things that came to mind when I was seeing your devlog is the idea that you might need to build certain machines to create bigger machines or contraptions. Maybe it contradicts the freeze mechanic of building. But for instance, have to come up with some kind of crane to lift other players in order to build taller structures.

Anyway, just a random thought for the future. It's looking really good. Following.

Thanks for the words of encouragement Didi, means a lot!  Yeah, using machines to build even bigger constructions should be possible, using lifts and cranes etc.

Centre-of-mass indicator and bug fixes

This week not much outwardly apparent has changed with the game but I’ve fixed a load of bugs, including a fairly major error in the gear constraint code that sometimes caused gear trains to gain too much angular velocity.

I’ve added an indicator that shows a construction’s centre-of-mass when you freeze it.  This will be useful when you want to balance a construction around a pivot point or centre-of-lift (e.g. flying vehicle, see-saw, etc.).

Gear physics - a bit of a setback

I just realised it’s been ages since my last post!  This is because there hasn’t been anything new in the game to speak of over the last few weeks.  Unfortunately, progress on the project was completely halted when I discovered a serious flaw in my gear constraint implementation.

The problem is, it is only transferring rotational motion between gears, not linear motion.  This works for static constructions with rotating gears, but as soon as the gears themselves move about, it is totally (noticeably) incorrect.  If I can’t fix this, then it pretty much screws up the rest of the game as I have it planned.  So I need to try and get it sorted before proceeding with anything else.

Over the last few weeks I have been digging through Box2D and Bullet code for inspiration, and have tried a few different solutions with varying degrees of success.  I have one idea I’m pursuing at the moment that seems promising, but we’ll see, it may come to nothing.

The good news is, if I can fix this gear physics issue, it’ll fairly easily allow me to add rack and pinion gears (where linear motion is obviously crucial).

Honestly, I’ve been very demotivated by this setback.  The game wasn’t progressing as quickly as I’d like anyway, and this really hasn’t helped.  It’s been a real struggle to keep going.  Hopefully I’ll figure out a solution soon, wish me luck!

New gear physics

Well, after many weeks of trial and error, experimentation and frustration, I think I finally have a solution for the gear physics!  To recap, the problem with my old implementation was that it was only considering relative angular motion between the gears, and not linear motion as well.  This made the gears behave incorrectly if they had any relative linear velocity.

Need for a new solution

My old gear physics implementation was inspired by the one in Box2D, so I looked there again for ideas.  It turns out they work around this problem by also taking into account the angular velocity of the rigidbodies that the gears are attached to.  I played around with this idea for a while but I found it didn’t really extend well to my more general 3D case.

There were also other things to consider, like supporting other types of gear such as rack and pinion.  Also, the fact that my gear physics was only updated once per FixedUpdate (and not as part of the main PhysX solver update) caused lag, or “wind-up” between the gears under high torque loads.  A compromise I was living with, but was never really happy about.

Using configurable joints

So I decided to throw out my old approach and instead make use of the built in PhysX constraints (or “joints”), as exposed by Unity’s ConfigurableJoint.  The idea was to position the joint anchors at the current contact point between the two gears (right at the edge of the gears where they touch), and then lock the motion only along the tangent at that contact point.  Then every FixedUpdate, the joint anchors are re-positioned to the current contact point (as the gears will have moved slightly).  By carefully positioning the anchors like this, the gear ratio (relative torque transfer), and the relative angular and linear motion are all taken into account automatically.  This approach also makes it relatively easy to add support for rack and pinion gears.  And…by using built-in joints, the gear constraints are solved along with everything else, so there is minimal wind-up.

(http://i.imgur.com/A4xhJCv.jpg)

Sounds good in principle, right?  However the re-positioning of the joint anchors is where things get tricky.  If every fixed update, they are simply re-positioned exactly to the new contact point, the gears will gradually slip when under load.  This is because a joint doesn’t perfectly rigidly lock its anchors together, and there will usually be a small difference in position between them, event after the physics solve.  This error gets fed back into the new joint anchor positions and the error accumulates over time.

Correcting the joint anchors

So I tried correcting for this error by figuring out what the anchor position delta was vs. what it should have been.  This is not easy because there is not really an absolute angle for a rigidbody, only an absolute position.  The orientation angles of a rigidbody wrap every 360 degrees of rotation, so you’ve no idea how many of these rotations have happened since the last update.  You end up having to integrate velocity over time and accumulate the positional delta as found at the contact point between the two gears.  There are two problems with this.  First, I found that when comparing the contact point velocities between the two gears as reported by Rigidbody.GetPointVelocity, they seemed slightly off if the gears were moving linearly relative to one another.  Close, but not spot on.  This small error was compounded by the second problem, which is that by accumulating the contact position delta over time, any errors also accumulate - quickly.  It creates a feedback loop, the error feeds into the joint anchors, which causes the joint to pull the rigidbodies around too much, causing more positional error, which feeds into the new anchor positions in the next update, and so on.  This leads to unstable physics behaviour - high impulses, oscillations, and your machines exploding like crazy.

At this point I got pretty desperate, thinking I might have to abandon gears altogether, maybe even the whole game.  I even tried mocking up a solution using physics colliders (one BoxCollider for each gear tooth!), and using the collisions between the teeth to provide the gear behaviour.  Er yeah - that didn’t work unsurprisingly.

Predefined anchor positions

Then I came up with the idea for the solution I have now.  Re-positioning the joint anchors exactly to the gear’s contact point leads to accumulated error and gear slip.  So instead, each gear is given predefined positions at equal intervals around its circumference, and every update the one closest to the current contact point is found, and that’s the position used for the joint anchor.  As long as the distance between these predefined positions is greater than the distance between the joint anchors after the physics solve, you get no gear slip.

(http://i.imgur.com/foLbF4C.jpg)

However, there is a problem with this if the gears are different sizes, as shown above.  The next / previous predefined anchor positions as measured along the contact tangent don’t quite line up due to the differing radii.  I tried correcting for this with a fun bit of trig, the maths worked out beautifully, but in practice it led me right back to another feedback loop, the joint and its corrected anchor positions ended up fighting each other, causing oscillations, exploding machines and much cursing.  In the end I just went with a simpler approach of just upping the number of predefined anchor positions, so that any differences along the contact tangent were minimised.  However, this of course means the distance between each predefined position is smaller, so increasing the chance of gears slipping under load.  In practice it’s actually not too bad though, it takes quite a high torque load to cause slip (to the point where axle hinge joints are also being noticeably pulled apart).

Next steps

This whole endeavour has been very frustrating, as the ideas I tried often worked fine most of the time, only to fail in particular use cases (certain combinations of bevel gears seemed to be particularly sensitive).  I spent a lot of time switching back and forth between my various approaches, trying different modifications, until homing in on what I have now.  It was so time consuming as I had to do lots of testing every time I made a change to check that I hadn't broken one of my many test cases.

Well, hopefully the implementation I ended up with will see me through.  I’ve tested a lot of situations (complex gear trains, high torque loads, high rpm, etc.) but the open ended nature of this game means I might have missed a case where things go bad, let’s hope not.  Next up I’m going to work on implementing rack and pinion gears, and probably worm gears too, I wanna really be sure these will actually work with no problems, before going ahead with any other part of the game.

(http://i.imgur.com/KZcIVTN.jpg)

(http://i.imgur.com/JgNMnUf.jpg)

New gears now in the game

This week I’ve been working on a Python script for Blender to procedurally generate the meshes for all the various gears I need.  I’ve also added support in the game for crown gears, which engage with neighbouring spur gears at 90 deg.

Next I’m gonna extend the Blender script so it can generate a rack gear mesh, and then have a go at implementing support for rack gears in the game.

New rack gear added

I’ve just added a rack gear to the game, useful for rack and pinion steering among many other things.  Rack gears engage with spur gears that are positioned directly above them.

(http://i.imgur.com/K3Lo7NB.jpg)

The implementation is still preliminary and still needs a bit of refactoring / cleanup, but it seems to work well so far, which is a relief.  It looks like my gear physics solution is holding up!

There is one significant issue remaining with gears generally however, which applies to all gear types but is particularly highlighted by rack gears.  Whenever a construction is modified (by adding or removing a part), a search is performed to find pairs of gears that are next to one another and should be considered engaged, and then a physics constraint is set up between each pair.  However this is done only once, after the construction is unfrozen and things start moving about, the gear engagement pairings are not updated.  Obviously this becomes a problem if the gears move apart from one another, it also won’t engage gears that start off apart, but then move together.

So I think my next big task will be to overhaul the gear engagement system so that it updates dynamically.  It will need to be reliable, and not incur a big performance cost doing lots of spatial searches etc. could be tricky!

Dynamic gear engagement

The engagement between gears is now activated and deactivated dynamically.  This means (as the various parts of a construction move around) gears will engage if they move close enough to each other, and disengage if they move apart.  The test that checks if a pair of gears are engaged is fairly expensive, and obviously I now have to do these tests every update.  So to avoid doing this between every pair of gears in a construction (i.e. O(N^2), not good), I use trigger volumes around each gear to find pairs of gears that are close to each other, and then do the engagement check only on these.

New steering wheel part

I've added a steering wheel part to the game that attaches to axles.  It has a behaviour similar to the motor, where if "switched on" it will rotate in response to user input (i.e. the usual hold shift + directional controls).

(http://i.imgur.com/7OeIFMD.jpg)

Its obvious application is as a vehicle steering wheel, but more generally it can be used as a "control wheel" anywhere you want to rotate bits of your construction in response to user input.

Collision bug update 2 - fixed!

A while back I encountered a bug in Unity where adding parts (that had a mesh collider) in a particular order to a construction would cause physics collisions between some parts to fail.  This would break the construction mechanic from then on as I rely on getting collision callbacks to know when parts are positioned appropriately for attachment.

Well, as far as I can tell this has been fixed as of the latest Unity release!  I didn’t get any update on the bug report I submitted, so perhaps it was fixed in relation to some other bug, either way it seems to be sorted now which is awesome.  Here’s hoping I don’t find any other similar issues…

But…of course there’s always something else to worry about!  I’ve recently noticed an odd behaviour where long, thin rigidbodies (such as axles) that have angular velocity around their long axis, tend to completely lose that angular velocity when rotated around other axes.  It’s like a massive braking force is applied to their rotation.  So I need to do some experimentation to figure out if there’s anything I can do to mitigate this (perhaps by fudging the inertia tensor or mass).

Another physics problem

A few weeks ago I noticed an odd physics bug in the game, where if part of a construction was rapidly rotating around one particular axis, that rotation would be massively slowed if the construction as a whole was also rotating about another, perpendicular axis.  For example, a rapidly spinning axle (acting as a drive-shaft) running longitudinally in a car would be almost completely stopped if the car yawed or pitched (say when steering or coming off a jump).

There is a gyroscopic effect that applies to a rapidly spinning object, where if you try and rotate it about a second axis perpendicular to its spin axis, it will want to rotate about about a third axis perpendicular to both.  Similarly, if you prevent it rotating about one perpendicular axis, it will resist rotation about the other.  This happens in game physics, just as it does in the real world (it's what keeps bicycles up!)  In Unity's physics (PhysX 2.83) when this resistance to rotation is counteracted by the hinge constraints holding the object's rigidbody in place, it's as if a large torque gets applied that dramatically reduces the rigidbody's angular velocity about its spin axis.  I'm no expert on the physics of gyros, it's possible that this is a real world effect that is just exaggerated in PhysX - but regardless it didn't feel correct to me and could completely screw up a construction's behaviour in the game.

I did some tests using other physics engines - a later version of PhysX (3.3) and Bullet.  I reproduced the same issue in both, so I'm assuming it's a common behaviour among most, if not all, physics engines, and that porting over to a different one isn't going to help me.

Hack and slash

I tried hacking around the problem by overriding the mass and inertia tensor of a rapidly spinning rigidbody, but to no avail.  I tried adding an "artificial" torque to counteract the slowing down effect on the spinning rigidbody, but that just caused stability issues with the hinge constraints.  It was as if all the forces were fighting each other, and something had to give!

I considered implementing a custom pseudo-physical solution specifically for drive-trains (i.e. motors, axles and gears), but this would have been a huge amount of work, it would have been very difficult to integrate nicely with the PhysX physics, and would have almost certainly limited the behaviour and physical realism of the constructions.

At this point I was really stuck.  I contemplated ignoring the issue and simply living with it, but that just wasn't acceptable to me.  Another option would have been to completely remove all rapidly spinning stuff (like gears and axles) from the game, but after all the work I've done so far, I really didn't want to do this.  Besides, it would have hugely reduced the scope of what could be built in the game, and taken away from what I think will make it unique compared to other building / sandbox type games.

An error / performance trade-off

Fortunately I found a way out.  I discovered that reducing the physics fixed update time-step minimised the problem to an acceptable level (albeit not eliminating it altogether).  I believe the issue is due to mathematical error that occurs with a combination of very rapidly spinning rigidbodies and a fairly large time interval between physics updates.  I can't really lower the cap on how fast stuff can spin (not without placing undue limits on the constructions that can be built), so my only option was to update the physics more frequently with a smaller time-step.  Of course this comes with a significant performance cost, but it looks like it's a trade-off I'll have to make.

So when you play the game now you may notice a performance slowdown (depending on the complexity of your constructions, and your computer spec).  Next up, I plan to remove as much code as possible from my fixed update callbacks (these get executed at the same rate as the physics update), to try and mitigate this as much as I can!

Fixed update optimisations

Now that I’ve had to reduce the physics update time-step, any code in my fixed update functions is much more performance critical.  So this week I tried optimising as much of it as I could.  Unfortunately there weren’t really any places I could move update code out of the fixed update altogether, but I did manage to speed up a few things.

I’ll probably have to revisit fixed update performance at some point, but for now I’m gonna move onto the next thing.  Next up I think I’ll look at reworking the system that determines how parts can attach together, to make it more flexible and allow for more interesting part pairing relationships.  This’ll be required for some of the new parts I want to add in the future.

Here’s a dev diary vid showing the results of my work over the last few months!

http://youtu.be/BCJqG68kLHo

Dude, this is wicked, I used to love making things like this in the garry's mod sandbox. This game looks like it takes that and makes it intentional with physics that can handle it and make more interesting things possible

Keep up the good work