Sandbox Logo
Page Header

Devblog 7

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.
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.

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. 

User Comments