Sandbox Logo
18 June 2018

Devblog 7

What we've been working on.
The deathmatch gamemode has been our planned first gamemode from the start. It's been through a lot and needed a rewrite to remove the junk its picked up along the way. The new version uses a shooter base so the code is minimal. The idea for this is to include the base and change a few rules to quickly make your own fps game types, like modding hl2dm back in the day. As an example we're mounting source engine games but we're going to use our own content before beta testing.  



Suicide Barrels is a Garry's Mod gamemode that's been rewritten for Sandbox as an example. The code for this gamemode is on GitHub so you can get an idea of what it's like to make gamemodes in Sandbox. This gamemode now uses the shooterbase but the original code in the repo shows how you can make a gamemode from scratch without any bases. For testing I coded dumb bots, they actually manage to win rounds even though they just run around in circles and follow people. 


Before we start giving this game out to a few people, I want to get a classic sandbox gamemode working. I started with implementing the basic tools and entities. Physgun, solid welds, thrusters and balloons. We want to rethink tools and see how they can be done better but for now I decided to stick with what we know so we can make sure it all works in multiplayer. Unreal by default is missing a few things for a multiplayer physics sandbox, luckily I can add support for everything without forking the engine.


Over the weekend I decided to make use of the native voxel library that James made for Chunks. Right now this is working in the sandbox gamemode. I will probably make it an entity you can spawn and save as a mesh. Basic multiplayer is supported.

I added support for mesh particle emitters so I could use it for block break effects.
Using assets from other games is cool but games don't make their assets in the same ways. Different file formats are solved by importers but we need something else to make the assets "fit in" with Sandbox. It's probably worst with models because they can use a completely different scale, orientation, and pivot point (center). For example you might need to scale up a model 1,000x before it's a decent size in game. We could just scale up the entity and that would work but then anything attached to it will inherit the scaling. The settings are all 3D vectors if you wanted to stretch something just to make it fatter or whatever. Origin is the pivot point and 0.5 just makes it use the center of the mesh. Also, any of these can be left out to use the original model's properties.
Addons and assets can now be loaded by clients from the server. It uses HTTP so it's like FastDL but works with all files, supports streaming, and works automatically. It can be any HTTP server (with some special files) or, if you use ours, it will just work and also enable hotloading over HTTP. When connecting to a server the game tries to find the addons it needs on your PC before grabbing them from the server. It also checks versions to make sure the addons it found are compatible, and if they aren't it will use the server's copy. The game server can optionally load all addons from a content server instead of the harddrive. It wasn't intentional but people hosting multiple servers could use this to make updating the servers easier by having it all in one place and then telling all their servers to load addons from there.
With a little setup we can now code addons together in multiplayer, with hotswapping working between the server and all clients when anything changes. This is using Visual Studio Live Share which is like Google Docs but for code, and the content server lets the game server and clients know when changes are made.

Technical stuff. We're using a virtual filesystem to load game content now. This means addons don't access your harddrive directly (but still can for now, will probably have permissions or something later). The obvious benefit to this is that addons can't try to delete your Windows folder or do other stupid things. But there's a lot more to them. We start with an empty filesystem and then mount the things we need. For example if we wanted to load Half Life 2 assets we just find the files on your harddrive then mount it to /hl2. All this means is the Half Life 2 files show up in the /hl2 folder in game. That's useful but it's not the interesting part. That mounted a folder but we can mount any filesystem. That just means anything with files in it, real or not. We can write some code to read those VPK files and mount them too. Then the importers can read those files the same way you would if they were on your harddrive. Addon folders are mounted into /Addons on demand so you won't see addons that aren't in use. When an addon is loaded from the server we just mount it from the content server filesystem instead of your harddrive and the rest falls into place.
More technical stuff. A while ago I made some assets load on multiple cores or at least in the background. This improves load times but made our asset load time profiler (shown in devblog 1) useless because everything was mashed together. Now we show different timelines for the other cores so we can see how the work is being split up.
It could do with some more labels but each row is a different task that needs to be done to load the asset. The first row is always the starting point and it should be as short as possible so the game doesn't freeze when loading. The other rows branch off to do work on other cores. LimitedConcurency is used to prevent the CPU from being completely used by asset loading so the game can still run. I need to make waits use a different color to show that it's not actually working for those times.