Scraps fortnightly update #1

I’m going try putting out scheduled fortnightly news on what’s going on with Scraps. That way you can stay informed on what’s happening, and if anything it might help make sure I’m always working on something significant as well. If there’s a builder demo update to release, I’ll probably do it at the same time. Right now things are in the middle of big changes, and things aren’t stable or tested enough to release just yet.

I’ve heard that in the USA the word “fortnight” has fallen out of common usage and “biweekly” is often used instead. Biweekly can be a little confusing – even some dictionaries have definitions both for “every two weeks” and “twice weekly” – so let’s stick with the glorious Commonwealth and have fortnightly updates.

Code, performance, bugs

So what have I been doing recently? Mostly code cleanup and code refactoring so the game has a better base to move forward from. Some things were a bit of a mess internally, not horrible, but enough that it was letting random bugs start to creep in. This stuff has a little bit more work to do on it, then hopefully that’ll be all that’s needed for a while and I can focus heavily on new content. I don’t want to be one of those people that spends forever optimising their code and never actually releasing games.

Anyway, there’s now a massive performance improvement when building large vehicles. No more long delay when adding or removing parts from vehicles that have hundreds of them. No short delay even. Parts and snap points now go into a couple of custom dynamic octrees, which lets me calculate stuff like “will this part collide with that part?” or “is there a snap point nearby?” much more efficiently.  It’s a big tree graph of what’s in the world divided up into cubes, which divide into smaller cubes etc. If I draw in the edges of the cubes it looks like this, which the redder cubes being inside the bluer ones:

octreeFor those who know octrees, the Scraps implementation splits or merges nodes as needed (when enough parts are added or removed), grows or shrinks the outer bounds as needed (when the vehicle gets bigger or smaller), and is a “loose” octree (which helps with stuff on the line between regions). It also converts any internal positional data to cancel out the position and rotation of the vehicle base, so the octree doesn’t need to be updated if the vehicle base moves around.

That last point (and some related work) also means that the vehicle no longer has to snap to a flat position when holding a part. Time still freezes, but it makes things a bit smoother. If Unity would let me compare oriented bounds instead of AABB bounds, this would have been possible sooner.

More stuff:

  • Rewrote the whole system for checking weapon range availability. The old system started off simpler but had too many annoying edge cases to cover. All the vehicles I know of that had issues with the old system get correct results now. Hopefully that means everything does. The calculation of the “best” option for reducing the range to fit is also sometimes a little better now.


  • Bullets don’t look like they’re firing with their casings still on anymore. Oops. Bullets and their separate casings (large cannon, medium cannon, and casings only for the machine guns):


There’s also a crash bug in the current builder demo release where the game can crash going from the test map back to the build screen. Fortunately for players, but unfortunately for me trying to fix it, it happens very rarely. It also doesn’t have any clear steps to reproduce. It happened to me once, so I’ve at least confirmed it, but repeating seemingly the same steps gave me no luck reproducing it again. I need to take a deeper look at it – it looks like something to do with the physics loop trying to reference something that’s just been deleted as the test map scene unloads.

The only other crash I’ve heard of is a crash right on startup, which is caused by an issue between the engine the game runs on (Unity) and some antivirus software. More info on that one here.

M.A.V. – Sort of like Scraps with mechs

A few people have asked for walking mech bases in Scraps. Although Scraps will eventually have a few more propulsion options (tracks, hover, maybe others), it won’t have mechs exactly, but you might like to check out M.A.V.. You build a mech and fight other people’s creations, it’s also made by just one guy, and he’s got functional multiplayer that looks pretty great. It’s not available for purchase just yet but it’s currently running a Kickstarter campaign, and doing pretty well by the looks of it too. Chromehounds and MechWarrior fans will feel especially welcome.

Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Guest
    Posted February 9, 2014 at 10:51 pm | Permalink

    There’s also Robocraft , which is quite similar to Scraps. What do you think about it?

    • bill
      Posted February 10, 2014 at 8:59 am | Permalink

      I have seen it, and it’s the closest thing I’ve seen to Scraps definitely. Hopefully there’s enough difference to give each its own market. Some comments on Robocraft:
      – They’re free-to-play while Scraps is pay once and get everything, and as a result Robocraft has a significant grind to get to the good stuff if you don’t want to pay. Having said that, their implementation of free-to-play isn’t one of the really evil ones and you can feasibly pay without paying at all. There’s nothing wrong with what they’re doing there.
      – Robocraft is still under development too, but currently at least the building of your vehicle is limited to blocks, propulsion and weapons – with different tiers of each available. Scraps allows for more complex designs with weapons requiring power/cooling, propulsion types requiring engines, etc.
      – However, Robocraft lets you build a vehicle from scratch, and place the propulsion wherever you want, so you can potentially be more creative in that area.

      Both are worth checking out if you like this sort of thing. :)

    • Casey Jay
      Posted February 22, 2014 at 1:01 pm | Permalink

      Pffft.. it doesn’t support linux. Lame!

  2. torginus
    Posted February 10, 2014 at 1:03 am | Permalink

    Very interesting technical article, but reading it, what seems strange to me that you needed to implement a special spatial data structure to get what is essentially broadphase collison checking. Obviously, i’m no expert, but it seems to me that it would have been simpler,and more performant to rely on the physics engine’s spatial caching by moving around a dummy trigger collider, and checking for collison callbacks.

    • bill
      Posted February 10, 2014 at 9:47 am | Permalink

      Good question. The easy answer would be “it’s not only used for collision detection” (which is true), but a more detailed answer is that Unity doesn’t always give access to the physics stuff that I need.

      It would definitely be nice to use the engine’s built-in system! But asking “is something colliding here?” requires actually moving it there *and* letting a frame pass before the collision event fires. You can’t just move something and check if it collides right afterwards – although that ability must be there internally because there’s a special Character Controller class that does it, but only with a capsule-shaped collider.

      Say the player is holding a part, I’d have to physically sweep it over all the possible snap positions to see if it’d collide there, over several frames, and the code ends up messy as well because you have to wait for the OnCollision methods to fire and call back.

      So I have to do my own checks to see if something will collide with anything else at x,y,z position, but the physics engine doesn’t have any sort of “get objects near…” method either (although again, it obviously has a nice spatial system internally), hence the octree.