This game has been Greenlit by the Community!

The community has shown their interest in this game. Valve has reached out to this developer to start moving things toward release on Steam.

March 15 - Nition

Last time[] I talked about the fight I was having with Unity's built-in NavMesh system[], trying to get it to generate a bit of  a more complex mesh than it was really designed for.

At the end of that post I was working on a script that would automatically split my terrain into layers based on slope, so I could hopefully then assign those as different layers in a NavMesh. I finished that script and it actually turned out quite nice.


Now from that, I could finally generate a nice layered NavMesh in unity:

Slow vehicles can stick to the blue area, more powerful vehicles can include the purplish area in their path calculations, and almost everything is covered by NavMesh so targets outside both areas can still be pathed to. Basically what I wanted last week but couldn't quite get. Static obstacles still have gaps around them but that's not a big deal. It's almost too good to be true...

So of course it is. As soon as I try to calculate a path with it, Unity crashes[]! Is there no end to these sisyphean trials? It seems like the extra detail generated from the layer joins is just too much for Unity to handle (although I notice that the actual path calculation, when it occasionally works instead of crashing, is still very very fast. So er, C+ for effort Unity).

A couple of people mentioned the A* Pathfinding Project[] as an alternative option after my last post, which I'd seen before but not really looked into. It seemed like an opportune time to give that a look.

In summary it basically looks good. It gets around some limitations in Unity's built-in system by allowing 3D model meshes to be used directly as navmeshes (Unity only allows generating navmeshes based on meshes), and not crashing when you use it is a nice bonus. But its interface and API is quite different to the built-in Unity one and it'd require a bit of time to convert things over - and this whole process has already been way too time-consuming!

So I simplified the Unity NavMesh to a point where it has as much coverage as possible while not crashing.


Sometimes it's all about knowing when to stop and move on.

March 1 - Nition

AI Players in Scraps currently use a navmesh[] to work out a path from where they are to where they want to go. Unity comes with a built-in NavMesh system[] which is really nice and easy to use, until you want to do anything fancy. I've been trying to wrangle some better meshes out of it.

It feels like the NavMesh support is one of those Unity features that had enough work done on it to look awesome, but not quite enough to be great to use. You can set some parameters:

And then tell it to auto-generate a mesh based on all your static (non-moving) geometry. Here's an example on my SandyBridge map:

Using that generated mesh (the blue area), you can then simply ask it to calculate a path from one point to another, and it'll efficiently calculate the route. Now your vehicle (or other entity) can avoid hills etc and get anywhere effectively.

Except not really.

Entities can path anywhere within the mesh, and since they're always finding the shortest path, they'll often hug the edges. That path behaviour is unchangeable. You can't say "try to go down the middle." So the above mesh is actually too generous with its available area. A vehicle pathing on the bridge often falls off the side, while a vehicle pathing near the edge wall or an obstacle can get stuck on it. It doesn't help that scraps vehicles can be all different sizes, but the mesh must be baked to one specific size.

I can increase the Radius setting to bring the navmesh in, but that introduces another problem: The navmesh won't return a path - not even a partial one - to a target that isn't somwhere in the mesh area. Interestingly there is a path status called "partial", but it never seems to happen. Maybe it only happens when you use Unity's built in nav agents thing (which I don't use)? You might say well, maybe there's something to at least get a point on the mesh closest to a given point, like they have with ClosestPointOnBounds []for bounding boxes? Then at least you could path to there instead, then go straight to the target from there? Nope.

So say you're on the mesh and the AI is on the mesh and they're chasing you, right? And they have a nice multi-point path to you that goes around a hill. But then you drive off the area covered by the mesh. Now the AI recalculates - suddenly there's no path! So it has to just drive straight at you, right over the hill.

The navmesh pathing is awesome when it works. You can even link different parts of the mesh and weight them to balance when they're chosen, like here where I told the AI it could do this sweet jump on the DustBowl map but only if it was a major shortcut:

You can also have different layers, with different weights and exclusions, so I can say "vehicles can drive on the hill layer if they have x or more engine power" or "only use the hills if it's this much faster than going around."

So I figure the best thing to make this work is to make sure the whole map is covered with navmesh, but there's a normal section, a hilly section, and a usually-out-of-bounds section just for chasing targets in crazy places. Then AI will be able to path anyway, but usually will only go in good places.

But the terrain can't be split up into layers. And you can export a generated navmesh to a 3D model and cut it up there (I wrote a script for it[]), but you can't import it back in - only generate another mesh from the first mesh, which is like photocopying a photocopy.

Using two separate NavMeshes and some 3D model hacking in Blender I added a hills layer:

But there's still lots of empty space, and I need to fill the rest with like an "out-of-bounds" NavMesh so that things can get a path.

Can I just put a big flat plane underneath and generate a mesh off of that to fill the gaps automatically? No! The mesh has to line up nicely with the other mesh layers or it won't join up. You can use "off-mesh links" - if you want to manually place a million of them. Trying to get different layer meshes to join up is an art in itself.

Oh yeah, and if your modified mesh doesn't line up well with the actual terrain, pathing won't work either. Objects have to been within a few metres of the mesh vertically, and that parameter can't be tweaked. I understand you have to allow for stuff like the over-and-under the bridge above, but I'd love an "automatically path using the closest mesh" option. Maybe I could use SamplePosition []to get the y position of the mesh instead of where the vehicle is an get a path based on that...

Anyway, I managed to hack together a system for filling the gaps in my mesh with another mesh that could be the out-of-bounds mesh. But it's a terrible process that could replace the preliminary Mensa test in terms of mental leaps required. The process sucks, and it still gets weird gaps and things in it anyway.

That isn't even everything but this post is too long already. Right now I'm working on a script that will export my terrain already cut up into separate meshes based on slope; Then I can generate the different layers I want based on that. But I'm sure that's also going to have issues when I try to generate a navmesh from it. One day I'll probably have to throw out Unity's built-in solution and use another one - preferably one where I can edit the source!

Thanks for for following Scraps' tortuous development. :)

February 14 - Nition

Single-player and LAN modes are looking pretty good, so I've started work on Internet play. As I've mentioned before, this will use Valve's Steamworks networking protocol because it provides some nice features to let people easily host games and connect to others. Otherwise you'd have to do all that old-school port forwarding and so on to try and get your game to show up publicly.

Things didn't start off well. This post I made on Monday has everything you'd want to know about that. I actually got everything working really fast, and I had two machines connected over the Internet through Steam and playing almost right away. Then I discovered that most of the time it didn't work, and that everything was sort of half-broken.

Eventually it turned out that it was largely a bug with the creation of my App ID on Steam. Valve recreated me to a new App ID which unfortunately meant I had to re-enter a bunch of stuff, but fortunately meant that just about all of my problems were fixed.

I still have a remaining issue with the case where a user wants to host an Internet server and play in the game on the same machine, but a couple of potential solutions have presented themselves there. That one's not a bug, it's more of an implementation issue (that's probably not worth going into details about).

In other news, I sent out a build with single-player and LAN play to a wider group yesterday. Looking for bug reports and gameplay feedback from that.

Someone on the forum pointed out that force from explosions pushes everything in the same direction[], so I fixed that (internally - it's not in the builder demo now):

Vehicle shoots, projectile hits on the far side of the cubes. Previously that shot would have pushed all the cubes away from the vehicle. Now, an object hit directly will still get pushed in the opposite direction to the projectile, but objects caught in the explosion will be pushed away from the central hit point instead (with less force for objects farther away of course!).

I also gave a reply on Reddit about the genesis of Scraps which might be worth reposting here:

Originally posted by Myself:
One of the things I really liked about I76 (apart from the amazing 70s campaign) was the vehicle customisation. Changing your weapon loadout, moving your armour around etc.

A while after that I remember playing demos of a couple of games where you build your thing more from scratch: Stratosphere: Conquest of the Skies (well done anyone who remembers that), where the game itself was pretty bad but you built your own flying fortress, and Lego Racers, where you built your car from scratch but it had very little effect on how your car actually behaved.

So then I wanted a sort of mashup of those where you could build a car from the chassis up, but the parts all had actual functions and appropriate physics, so you could build terrible cannon towers that fell over when they fired or ones that overheated and blew up or y'know, actually something effective if you were good enough.

I waited a decade or so for that to actually exist and then eventually just started making it myself.

January 31 - Nition

I got players joining games that are already in progress working last week, then I cleaned up the lobby and the menus so it all works like it's supposed to, and I'm starting to actually feel like things are really coming together. Stuff is working and hey, it's fun too.

The biggest single thing left to do before release is Internet play (single-player and LAN are working now), and I'll be spending some time with Dave (who also did the AI) next weekend to delve into that. Then there's a bunch of other smaller tasks, bug fixing, finishing up TODOs, and creating a new trailer etc for marketing... but it'll get there.

The lobby is a bit more functional now. Here's the single-player lobby:


What's "AI Infighting" you ask? Well, it determines whether AI players target everyone, or only human players. It's like extra difficulty, or instant boss battles!

Bonus graphics glitch. Somehow some textures got messed up and sort of created Steampunk Scraps?

December 16, 2014 - Nition

The recent demo update was a big jump from the last version so there were bound to be a few un-spotted issues with it. I've just updated it to fix a few things.

The main issues were that the scrap container had its snap points turned off, and there was a bug with the available range calculation for weapons. There's still at least one other bug with the range calc but it's an old one and I'll track it down some other time - it doesn't show up in most situations.

Some part stats were also incorrect and have been updated in this release. The small active cooling unit in particular was way too expensive,but some other parts were using out-of-date values as well.

Download page[].

< 1  2  3  4  5  6 >
Showing 1-5 of 30 entries