I’ve been wiped out with a nasty bug over the last couple of weeks which slowed productivity somewhat, still got quite a few things done though!

Text decals

I implemented a decal shader that can modify material properties in the g-buffer independently of normals.  This allows for rendering over the top of objects already rendered in the scene, modifying albedo, smoothness, etc. while leaving the underlying normals as they are, which gives a “painted over” look.  I wrote this shader specifically to work with rendering font text from the Unity UI.

Then, I added a Canvas in World Space mode and a UI Text component to the resizable plate part, and implemented a new text label part behaviour to configure the text string to be shown.

With a “painterly” font, it’s quite a nice effect, here’s an example of what it looks like:-

And here’s the part behaviour UI the player can use to configure the text string:-

This will be handy for labelling things on constructions, and I’m thinking I might make use of it in future challenge game mode scenarios / tutorials.

Data links

I refactored the part behaviour linking code using various interfaces to better decouple the code and make it easier to add new link types.  I also made some minor fixes and improvements to the linker tool.

I then implemented a new data link type, which allows part behaviours to expose “data channels” that can be accessed by other linked part behaviours.  Where appropriate, I added data channels to all the part behaviours already in the game, for example the electric motor now exposes its current RPM, torque, and power values.

Electronics

Now the dawn of a whole new category of parts, electronics!  I hope to expand on this a lot more in the future but here’s what I’ve done so far.

Putting the text decal shader and the data links together, along with a LCD display font, I implemented some text display screen parts that show the data channels of the part they’re linked to.

Here you can see the new data link type being used as we link a display to a motor:-

The display screen showing the motor’s data channel values while it runs:-

These displays have a part behaviour that lets the player assign a data channel to each text line on the display.  Here’s the UI for this, it needs some improvement but is functional for now at least:-

I also added some “sensor” parts which are little modules that calculate their own speed, acceleration, or attitude (i.e. orientation in the world) and report these values via data channels.  These can then be linked to from the LCD displays to show their current values.

The speed sensor in action, as well as speed it also reports its altitude and rate of climb (RoC):-

The accelerometer sensor, reporting longitudinal, lateral, and vertical acceleration separately, as well as overall acceleration:-

Finally, the attitude sensor, which reports heading, pitch, and roll in degrees:-

I have loads of ideas for more sensor modules I could add in the future, e.g. for reporting angle, angular velocity, proximity (think radar / lidar) and so on.  Let me know if you have any ideas too!  Combining these with the control links I have planned will really open things up to some very cool possibilities I think.

Anyway, for now I’ve just been enjoying messing playing around with these parts, like adding some sensors and LCD screens to the Mosquito flyer for flight instruments!

Most of my time over the past few weeks has been spent on a major reworking of the code for all of the tools in the game (builder, material, painter, etc.) in order to improve the building experience for networked client players in multi-player games.

Previously the tool code that responded to player inputs in order to perform various actions (such as attaching a part, breaking an attachment, applying paint, and so on) would always run on the server for all players, with each client simply sending their inputs to the server for it to deal with.  This setup made it relatively easy for the server to handle things like arbitration between players, seeing as they were effectively all running locally as far it was concerned.

However this approach was flawed, the most significant problem being the latency between client player input and an action happening, which made building really awkward to say the least.

So I’ve now re-implemented every tool so that player input is processed locally on each client.  In some cases the client must still request the server to complete certain actions, so that the server can validate and arbitrate where needed (for example, while one player is attaching one part to a second one, at the same time another player could be deleting that second part; the server needs to have the final say on the outcome in this scenario).  In many situations however, it is not necessary for the client to check with the server first (e.g. moving or resizing a selected part, painting a part, etc.), instead the client just informs the server of the change made so that it can be broadcast out to the rest of the clients.

The result is that the building experience for networked clients is now basically the same as it is in single player games.  The other benefit of these changes is that because input is processed locally for each player, it simplifies the code and makes it a bit easier to modify and improve the tools.

Builder tool tweaks

On which subject, I’ve made a couple of minor improvements to the builder tool thanks to some suggestions I’ve received.

• Remove actions (delete part, destroy construction, etc.) are now delayed, during which time the action key has to be held down.  This should hopefully prevent annoying accidental deletions from mis-clicks!
• I changed the default key binding for duplication from “Q” to “Left Alt + LMB”, by default “Q” is now dedicated just to opening the tool menu.

The usability of the builder tool controls is still an ongoing concern, and something I’ll have to keep plugging away at over time, but at least now it’ll be easier to implement any further improvements I need to make.

New demo coming soon

Finally, I’m getting close to releasing another demo build, and I’ve been fixing a bunch of bugs in preparation for this.  There have been a ton of changes to the code since the last demo, so I’m slightly paranoid that some as yet undiscovered bugs might have been introduced.  Time to do some more testing I think, hopefully I don’t encounter any last minute issues!

Hey all, hope everyone has had a good holiday break.  I thought I’d give a quick update on what I’ve been working on over the past few weeks.

Toolbox code refactoring

Up until now, the code for the various tools (builder, linker, painter, etc.) was pretty much all in one (very large) source file.  This was driving me crazy as made it a real pain to to fix bugs, or add new features.  So I finally took some time to do something I’d been wanting to do for ages, which was to refactor this monolithic beast into separate source files for each tool.

There are still things I’d like to improve and clean up (further code decoupling, mainly), but it’s much better than it was, and makes it easier to add new tools, on which subject…

Material swapper tool

After the refactoring, I started work on a new tool that allows you to swap the material on certain parts (such as beams and plates) after they’ve been spawned, and even after they’re already part of a construction.

The first step was to add a material definition that encapsulates all the various part material properties (i.e. the rendering & physics materials, density, strength, and “is it paintable”).  Next I had to refactor the part descriptor code to allow parts to use this new material definition (seems like I’ve been doing a lot of code refactoring lately!)

Then on to the material tool itself, which I’m still in the middle of building.  Right now I have a first pass implementation working, with the basic UI done, and the ability to change material on the highlighted part.  There’s still more to do however; for example, save / load (including converting old save files to the new material swappable parts), and probably more refactoring as I’m not quite happy with how the part descriptor code is structured just yet.

Anyway, it shouldn’t take too much longer to finish up, once it’s done I’ll reveal more about how it works.  After that I’ll probably get back to finishing up the linker tool, as that’s been on the back burner for way too long now.

In the meantime, I’d like to say a big thank you for following my progress, particularly to those of you that have been following for a long time, and who continue to play the demo and give me feedback.  I know development of the game is frustratingly slow, but I will get it done eventually, I hope!

Happy New Year, and all the best for 2019.