This update goes into a bit more technical detail than usual. I like that sort of thing in game blogs, but feel free to skip that stuff.

Since I’ll be taking scraps across the Tasman to PAX Australia at the end of October, I’ve worked out a roadmap of what exactly I need to have done by then. Without going down to task-level detail, it’s basically have LAN multiplayer working nicely, plus some testing and balancing of the game, plus some marketing and other preparation work like refreshing the website a little and getting the booth ready. There’s a little under three months to go.

Ideally I’d like to also have some basic single-player stuff to do at PAX – simple AI vehicles to shoot at or even just some towers etc that fire at you – but time is looking at bit tight for that. “Finish LAN multiplayer” might not seem like a big task considering that the basics of it are already in and working, but it’s a bit like the coastline of Britain paradox. Once you break it down into individual tasks, suddenly it’s twice as long.

My current plan is to take two laptops (which I already have arranged) and people can build and play 1v1 against each other. One of us manning the booth can play with them if it’s only one person. If two people are on but one person is busy building, the other can mess around with building and testing as well until they’re ready (it’s fun enough playing with the builder demo, so I feel like doing that for a little while won’t be too bad).

Right now I’ve been working on getting the Evac Pads working. The process will go like this:

Collect some scrap in the game (or you’ve got funds left over because you’re playing e.g. a 10,000 limit game with a 9,000 scrap vehicle) Enter an evac pad and wait for the countdown. Actual evac starts. Evac finished and you’re transported to the Build screen. Your collected scrap is banked. That is, it’s moved out of your vehicle’s containers and into your “bank.” Repair damaged parts or add new ones using your banked scrap (you may also be able to pick up whole parts to use). Re-deploy into the game when you’re ready, and you’ll appear at a spawn point. Unspent scrap stays in your bank and your containers are now empty again.

The server needs to control most of this just to be safe in case of attempted client hacks, but it’d suck to have bad latency and be trying to build a vehicle, always waiting for the server to confirm that you can afford a change. That’s why I’ve implemented an…

Undo System

With a working Undo system for vehicle building, you can make a change to your vehicle right away. The server should usually always approve it, but if something got out of sync somehow or the client’s cheating, the server can deny the change and tell the client to revert what they did, putting things back in sync. Of course, a hacked client could ignore the undo command from the server as well – but the vehicle would still only be wrong on their machine, and the server gets the final say on most things.

The other reason for putting in an Undo system is that players can use it too! This is pretty self-explanatory but here’s a video (normal building section sped up):

It can also undo suspension settings. :)

People always seem to talk about Undo support as being something you have to plan for from the start, or it’ll be a nightmare to implement. I was pleasantly surprised that I managed to implement it in a morning, and clean it up and complete it in an afternoon. As is common, my internal implementation is based on the Command design pattern. Basically each time you do something, you also remember how to do it backwards. Then if you need to undo, you just go backwards through the list of things you’ve done.

Area Effect Damage

My early just-get-it-working implementation of area effect damage was a simple thing like this:

Get where the projectile hit

Take a sphere of x radius around that point and get all the objects in that area

Apply between 0 and 100% of the explosion damage to each, based on how far the object is from the centre

Easy to implement and at first glance maybe looks like it’ll work, but it doesn’t take obstructions into account. Imagine your vehicle has thick armour for instance – the armour should protect the parts underneath!

A possible solution to this:

Get where the projectile hit

Cast a bunch of rays out from that point (like a koosh ball) to the edge of the sphere, and get everything they hit

Apply between 0 and 100% of the explosion damage to each, based on how far the object is from the centre

Things in front will now block things behind from getting hit. That’s cool, but you’re always going to have a tradeoff: More rays and you’ll hurt performance, but less rays and you might miss small stuff. An alternative:

Get where the projectile hit

Take a sphere of x radius around that point and get all the objects in that area

Cast a ray from the centre towards each of those objects

If the ray hits the object, include it. If it hits something else, ignore it

Apply between 0 and 100% of the explosion damage to each, based on how far the object is from the centre

That way you make sure you include every object, don’t cast many rays, and it’s generally a bit faster. It still kinda sucks. Imagine something like this (terrible diagram alert):

Something like a flat wall sucks because objects get blocked from the explosion more than they should. There’s also the matter of whether you cast your rays towards the closest point on an object or towards its centre, but that’s not so important.

My actual current solution is more like this:

First, I cast the original rays from slightly behind the actual hit point (based on the direction the projectile came from), which helps for a start. Then, for any objects that were blocked, I try again from further away – specifically from the edge of the area. It wouldn’t be a good idea to do just the second check because you never know what obstructions might be in the way.

This system might need some more refinement in the future, but it seems pretty good.

Strangely I didn’t really find existing info about this. Surely thousands of people have done area effect damage before. Anyway, that’s partly why I thought I’d write it up a bit more thoroughly than usual here.

Damage Effects

I also added damage FX.

Everything with a health stat gets the “grunge” effect – the increasing black marks as health goes down. Additionally, some parts get custom effects.

Right now, engines smoke and flame, generators spark and smoke, and capacitors spark. All these FX vary depending on how damaged the part is.

One more thing: Some of this stuff would be cool to add to the builder demo, but I need to focus on making the game awesome for PAX at the moment. Putting out a builder demo update will take a few days of testing, fixing up and checking everything. You’re not missing out on anything really game-changing, but I will put some of this stuff into the demo when I’ve got some more time.