Networking bandwidth – Gonna need a bigger pipe
Not much has changed recently that is directly visible in game, instead I have been doing a lot of work under the hood to improve networked multi-player. Primarily to reduce bandwidth, but also to make things a bit smoother on the client side during packet loss situations and so on. There is still much more to do however. For example, I don’t yet have client-side prediction for the locally controlled player working in a way that I’m happy with. Also, I need to implement network culling so that clients only receive data for objects that are near them in the world. Anything I can do to reduce bandwidth is a must. I may end up having to bypass Unity’s networking altogether, as it just doesn’t give you direct control down to the byte level over what gets sent, and there seems to be a large overhead per networkview state sync, and per RPC call.
This whole effort was to help me evaluate if networked multi-player is even viable for a game like mine with a large number of dynamic objects, and whether my current server-authoritative model is the best fit. This has a huge impact on the game design as a whole, so is important to figure out.
As it stands right now, each client sends roughly 1000 bytes / sec of controller input to the server, and receives about 1000 bytes / sec per player connected (including themselves of course) for position, animation state and so on. Add to this up to 1000 bytes / sec received per currently moving rigidbody in the game (i.e. a single solid construction – a construction made of two things jointed together counts as two rigidbodies). You can see it soon starts to add up.
Things are even worse for the server – it has incoming input data from every client, and has to send out object states to each client. Assuming 16 players with 100 moving rigidbodies, that’s 16 * (16 +100) * 1000 = ~1.8Mb / sec outgoing bandwidth for the server! The actual data I’m sending per rigidbody should only add up to 780 bytes / sec, so the per networkview overhead clearly isn’t helping here, but even assuming this can be solved, it would still come out to ~1.4Mb / sec in the 16 player example.
Some of my options are:-
Option 1 will help the general case, and definitely should be done, but it won’t help the worst case where every rigidbody happens to be a separate construction. The second two options aren’t particularly appealing, but may be a necessity. Option 4 would be a lot of work to implement, and has a big impact on game design because it is completely open to cheating and only really makes sense for co-operative play.
I need to do some tests with similar games such as Garry’s Mod (based on the source engine, which I know is using basically the same networking model as I am right now), to see how I stack up in comparison, bandwidth-wise. Regardless I think for now I’m going to stick with the current server-authoritative model, and assume a small number of players. Maybe in the future if this game takes off and the effort of implementing an authority switching model for co-operative play makes sense, I’ll do that, but that would be a way off I think.
Level building – A new approach
A few weeks ago I had a major rethink about how I wanted to create the levels that you explore and build constructions in. Originally I had planned to have pre-made terrains, that were carefully crafted with obstacles to overcome, and set locations where things were placed. I came to the realisation that this was going to be far too much work for me to take on, and would result in limited replayablity. So I decided to sacrifice the crafted set pieces and move to a procedural approach.
Procedural terrain generation
Over the last couple of weeks I’ve implemented a basic procedural terrain generator, that always generates an island (giving a natural boundary to the playable area). It generates a height map by taking a cone shape with fractal turbulence applied to form the basis of the island, then modulating it with fractal ridge noise to give the mountains and rocky ridges. Then, based on elevation and surface slope, an alpha map is generated (this is used to blend between the various terrain textures, sand, dirt, rock etc.) These maps are then plugged into a Unity terrain for rendering. I’ve also added some water, using a modified version of the Unity water shader, which provides a nice visual boundary to the edge of the island. You can see the results so far in the images above.
There is still more to do to improve the height map generation, namely I need to ensure there are more relatively level areas for the player to build constructions on, and also it would be nice to break up some of the more obvious ridge lines (by adding more noise perhaps).
Same goes for the alpha map generation, I need to add more terrain texture types for variety and to break up the often noticeable texture tiling. Also, I want to procedurally place rocks, vegetation and trees to add more interest to the environment.
Final thoughts
In addition to the terrain itself, I’m thinking of trying a procedural / emergent approach for other aspects of the gameplay. Perhaps the things you might encounter as you explore the island…
On that mysterious note, I’ll sign off and hopefully update soon with some gameplay news. In the meantime, check out the new terrains in the web-player build at the usual link: https://dl.dropboxusercontent.com/u/157530041/WebPlayer.html.
New part behaviour controls
It has been a while since my last update, too long in fact, so there are quite a few things to talk about! First off, I have improved player control over “part behaviours”, in particular this applies to the electric motor. As before, you hover over a motor and hit use to switch it on or off. However, unlike before it won’t immediately start running when switched on. Instead, it is activated by your directional controls (i.e. WASD), when shift is held down. To configure these controls, you hold shift+use while hovering over a motor to bring up a config screen (see the first image above), this lets you map either the vertical or horizontal directional controls (i.e. either W/S or A/D) to drive the motor. The upshot of all this is that you can for example build a car with one motor driving the wheels (mapped to directional – vertical), a second motor moving the steering (mapped to directional – horizontal), and then (while holding down shift) drive it around with WASD. You don’t necessarily have to be in or on the vehicle to drive it, it behaves more like a sort of remote control.
Seats, gears and lights
I have also added some new parts to build with. First up, a new seat part that you can attach to your constructions, when you hover over it and press use, you “sit” in the seat. You’re locked into position, but can still mouse-look (see second image above). This is very handy for vehicles that you want to drive around in without falling off! To escape the clutches of your seat, just hover over it, hit use again and you’ll return to normal control. Also, I’ve added a new gear part type – bevel gears. These let you transfer drive through 90 degrees (as an example, see the drive-shaft and axle setup in the last picture above). Finally, I’ve added some new light parts, and a few other bits and bobs.
That’s it for this update, the next one will be coming very soon!
New menu look and feel
Recently I have completely overhauled the menu flow, and re-skinned it (still placeholder art for now), it should be much nicer to use now. I’ve also started adding additional stuff, such as the options screen (currently only graphics options are functional). You can check it out in the web build at the usual link.
Next up – new game modes
The most exciting benefit of these menu improvements is that it makes it easier to start hooking in new game modes. Currently there’s only the basic open sandbox mode, but soon I will be experimenting with other game modes that build on top of the core construction game-play. More news on this soon hopefully!
Construction cloning
Pressing ‘C’ when a part is highlighted will now clone the whole construction it belongs to, if the required parts are available in your inventory (and so removing those parts from the inventory). This should make it easier to build constructions that can be made up of several duplicate elements.
Save / load for inventory and player location
If you run the game from the usual link, you’ll find it now has save game support for your inventory and player location!
The same multi-player limitations still apply (you can only save / load from the server machine, and it only saves the inventory & location for the server player). I still need to figure out a robust design for how saving client player data should work.
Parts inventory – images added
The inventory screen now has a preview image of each part. I still need to re-scale the view based on part size, as small parts are a little difficult to make out, but I think this can wait until a fine tuning / refinement pass later on.
Next up, I’ll add save game support for the inventory, once that’s done the basic inventory system will be just about wrapped up.
Parts inventory
The game has been updated with a new parts inventory system. Hold ‘Q’ when in game to bring up the inventory screen. You can then click on parts in the inventory to add them into the world, ready to be used for construction. Any part in the world that isn’t part of a construction can be added to your inventory by running / walking over it.
Right now each part in the inventory screen just has a text descriptor, hopefully I’ll soon be adding a preview image for each part so you can more easily tell what it is, watch this space!
Now that you can save progress in the game, it somehow feels more worthwhile to build more stuff! Here’s a rickety shed, with an assortment of machines…
At some point I’ll be adding the ability to rigidly attach blocks to the ground, for the purposes of constructing buildings (right now, they just rest on the surface and can still be nudged around by physics).
