After Rust took off we spent a week improving the back-end. Previously, deploying new versions was slow and bug ridden. It was compiled on some cunt’s computer. The whole thing was an ordeal.

So, improvements were needed. Here’s what happens when we change something now.

Something Is Committed

Someone commits something to SVN. This can be code, or a model/texture/material/sound/etc change.

A build is triggered

Jenkins polls the SVN every minute. If a change is detected it tells the Windows build server to download the changes and build.

We have different jobs for the server and client. This means that the server and client can be built at the same time – halving the time it takes. Building was taking 40 minutes before on some cunt’s PC. On our windows build server it’s taking less than 10.

A lot of this time is spent constructing bundles. We don’t want the player to have to download 300mb each time. So we create 60+ bundles – and try to keep the size under 5mb. We have found that if the size is under 5mb the browser will cache them – like it would an image – so the client doesn’t have to download them. These bundles are created and a manifest file is created – to signify which bundles are needed, and which order they should be loaded.

When it builds it commits the binaries to a different SVN.

Upload Client

Another Jenkins job. When it detects changes on the client SVN, it runs a php script. This script loads the manifest file and turns the renames the bundles to be crc hashes. Then it uploads the files to Amazon S3, so we can serve them nice and fast. We use CRC hashes because sometimes the bundles don’t change – so the client can keep using that bundle. But if it does change we want to be sure as shit that the client is getting the updated version. This was a fault we had previously – and causes a whole bunch of problems.

Once the bundles are uploaded, the PHP script sends the manifest file to our playrust server – and playrust creates a new version.

Testing New Version

Admins can test the new version immediately on the website. They have this box visible under the webplayer.

It shows the current ‘live’ version (green flag) and clicking on one of the versions allows them to switch to that version.

Make It Live

Once that’s done we can make it live in the admin section on the website.

The Future

Hopefully this whole system will mostly become redundant. It’s our hope to get on Steam eventually – and what I’m doing here pretty much re-creates the steampipe system. We don’t have a system for updating servers yet – we just use SVN – which has worked OK so far.. but probably won’t work so great once we let other people host servers.

With the Steam stuff – I think we’re going to go through the greenlight system. This is for two reasons. First of all I’d feel kinda like I was stepping on all the other people on greenlight if we went around it, and second of all – if it doesn’t get greenlit then it shouldn’t be on Steam in the first place.

Alpha Papa

The demand for alpha keys has been immense. Totally totally immense. We want to start selling access as soon as possible.. but we obviously can’t open that up for everyone or we will be swamped. So we will probably be putting a limit on it, so only so many keys a day will be available.. Hopefully that limit will increase over time as we optimize and make the servers support more people, get more regional servers of our own online, and start supporting third party servers.