Hey everyone, here’s a brief update on some of the things I’ve done over the past couple of weeks.

Attachment type filtering

Sometimes when attaching a part, other unwanted attachments might be created between that part and other adjacent parts, which the player then has to go and delete afterwards.  It would be more convenient if these attachments weren’t created in the first place.

Here’s an example where we’re aligning a beam to an axle, but additional unwanted attachments are being created between the beams:

As an attempt at a solution to this, I’ve implemented a way to filter out attachment types during part alignment.  There’s now an “advanced options” panel in the builder tool UI, which allows each attachment type to enabled or disabled for part attachment.

Here the fixed attachment type has been disabled in the advanced options panel:

Any disabled attachment types won’t be considered when determining if parts can align together, and any newly created attachments won’t be initialised to a disabled type (and will fall back to the next available allowed type).

So in the example with the beam and axle, disabling the fixed attachment type will prevent attachments from being created to the adjacent beams, but will still allow a rotary bearing attachment to be created between the beam and axle.

Here a rotary bearing attachment is about to be created between the beam and axle, but no other attachments between the beams:

I’ve also modified the builder tool display screen to show which attachment types are currently allowed, as you can see in the images above.

Part interpenetration

There was a bug where, by quickly dragging a selected part while clicking to attach it, it was sometimes possible to attach it such that it interpenetrated another part.

To solve this I now use the attachment’s position and orientation to calculate each part’s new local position and orientation when merging composites together.

However, I think there is value in allowing part interpenetration, as it opens up creative possibilities for advanced users!  So, I’ve added an option to the builder tool UI advanced options panel to turn off the part interpenetration test.

I’ll be releasing a demo update very soon with these changes, plus the new builder tool model, and more, so watch out for that!

Hey everyone, time for a quick update on what I’ve been working on over the past month or so.

Scenario mode

If you’ve been following the development of GearBlocks for a while, you’ll know that my plan for a long time has been to build something on top of the current open ended “creative mode” game-play.  This is something I’ve been wanting to work on for ages, and now I’ve finally made a start on it!  I’m calling it the “scenario mode”, but you could equally refer to it as “campaign mode”, “challenge mode”, or “tutorial mode”.  The idea being that it’ll be flexible enough to cater to all of these use cases and more.

My plan is to create a series of scenarios of increasing complexity to gradually introduce new players to the concepts in the game and act as a tutorial mode.  Beyond that I’d like to include an additional series of scenarios for experienced builders to challenge them further, but that will come later.

Each scenario may have a limited selection of tools and / or parts to build with, and certain objectives to achieve.  Once the objectives are achieved, the scenario is complete, and it may then unlock more scenarios.

The process for creating a scenario is pretty simple.  You set it up in creative mode, save the game tagged as scenario, and then it’ll be available to launch as a new game in scenario mode.  This way players can create their own scenarios and upload them to the workshop!

So far I have done the following:-

• Changed the UI and code to now refer to a saved “game” as a saved “world”, I felt this made more sense because a saved “game” from creative mode can now serve as a template for a new game in scenario mode.
• Modified the UI and code so that a new scenario mode game can be launched from any saved world that’s tagged with scenario (this includes built-in, locally saved, and workshop downloads).
• Implemented code support for parameters to specify which game features are allowed when a scenario is active (such as which tools are available, whether new constructions or parts can be spawned, etc.)
• Added a scenario editor panel in the world tool UI for editing these parameters while in creative mode.

Here’s what the scenario editor UI looks like right now.

There’s still plenty more to do, for example:-

• Add the ability to test a scenario from within creative mode without having to exit first and start a new game in scenario mode.
• Implement an option to reset / restart a scenario while playing it.
• Add support to save / load in-progress scenarios (not sure if this will be strictly necessary, but could be good for scenarios that take a long time to play through).

Beyond that I need to build out some features to facilitate creating objectives (e.g. special parts for start / end trigger zones, gates, etc.) but this is something I’ll discuss in more detail in a future update.

Player tool model

I’ve also been mocking up some ideas for the player character’s tool model, I’m sick of the crappy “box on a stick” placeholder that’s in the game currently!

Originally I was thinking of having a separate model for each tool (builder, linker, painter, etc.), but to reduce scope and simplify things I’ve now decided to have a single universal tool model.  However, when the player switches between tools, I still want it to visually represent this somehow, e.g. with a display, visual effects and so on.

I think I know the direction to go in now, and soon I’ll be firing up Blender and getting to work on it.

Hey all, here’s an update on what I’ve been up to over the past several weeks.  I’ve mostly been focused on providing more UI feedback for players in game, and improving part behaviour control.

UI overlays

I’ve overhauled the in-game UI overlays to show the player what actions are available to them depending on the current context.  These overlays show which keys are bound to these actions, so that they can always see what can be done at any given moment.  I’m thinking this will replace the current text based hints, as it pretty much renders those redundant.

Below you can see the player overlay on the bottom left, the toolbar overlay in the middle, and the part overlay on the right.  Each of these overlays have been modified to show various available actions and their key bindings.

The player overlay now shows the current camera mode and whether free flight is enabled.  The toolbar overlay shows which keys to press for the tool and construction menus, and the part overlay now shows whether the part behaviour is active and which key to press for the part behaviour UI.

I’ve also added new overlays in the top left corner to show the available actions depending on which tool is active:-

Selection overlay (for select, delete, attach, detach, etc.) and transform overlay (for translate, rotate, resize, etc.):

Material overlay (apply and pick):

Link overlay (add / remove, and delete all):

Paint overlay (apply, remove and pick):

My plan is that eventually the tool models themselves will also show additional status information, for example the painter tool will show the currently selected paint colour.

Gear engagement indicator

While attaching gears and trying to align them so that they’re engaged, it’s not always totally clear whether the game thinks they’re actually engaged or not, at least until the construction is unfrozen and the player perhaps finds that things aren’t working the way they expected.

So I’ve implemented a gear engagement indicator – when a gear is highlighted, arrows point to the other gear(s) it’s currently engaged with.  Here’s an example where the idler bevel gear in a differential is highlighted, showing the other two bevel gears it’s engaged with:

It also works while aligning a gear during construction, so that the player knows what to expect once they attach it:

Part behaviour improvements

I’ve unified the way key bindings work between the actions you can configure in the controls options screen and those in the part behaviour UI.  This allows part behaviours to now use modifier keys, and to have a secondary key binding.

Controllable part behaviours can now be configured so that their bound keys either toggle activation on and off, or have to be held down to keep the behaviour activated.

I added a parameter to controllable part behaviours to configure input smoothing.  When smoothing is set to a higher value, input is less responsive but it’s easier to hold it at a roughly constant value by tapping the key.  Conversely, when smoothing is set to a lower value, control is more immediate and responsive.

This can be really useful when using servos for vehicle steering for example.  Increasing the servo’s maximum RPM while also increasing input smoothing provides responsive but still nicely controllable steering:

Finally, I also added a parameter to the electric motor part behaviour to invert the motor’s direction.  This works regardless of whether keys are bound to control the motor or not, but obviously is particularly useful when they’re not.

I’m planning on releasing a demo update with these changes soon, so keep an eye out for that!