Devlog #3: Modding Capabilities and Cleanup

Hello everyone. We’ve been hard at work preparing our big 1.0 milestone update and we’re keen to update you on our final steps before release. Today marks the 2 year anniversary of our Steam release so what better day to release our 3rd (and likely final 1.0 milestone) devlog. And they say the perfect trilogy doesn’t exist.

We’re marching towards a release over the coming weeks so much work has been put into cleaning up a lot of legacy code and focusing on more advanced modding capabilities like asset bundles, client compiler, syncing mods and more.

Now let’s break down our progress for you:

Asset Bundles

Custom Asset Bundles support is one of the biggest modding changes we’ve implemented. Using the free Unity Engine and a special package provided with Broke Protocol, modders can completely customize game and world objects.

Servers can modify existing or create all new weapons, props, skins, vehicles, and more. Custom meshes, textures, and sounds are supported. And it will all be synced with players joining your server automatically.

We’ll be adding separate Workshop tags and in-game support for the different types of mods players will be making including maps, scripts, and modded asset bundles.

Caching

Aren’t custom assets pretty huge to sync with all players in addition to custom maps? What about server load?

Luckily asset bundles are compressed on exporting (we’ll add a wiki on how to build custom asset bundles properly). Also for example, if you want to just change the damage output or fire rate of the AK47, you don’t need to link the model/audio/texture files and the game will fall back on the default assets without the need to transfer heavy meshes or textures.

But the biggest part of reducing server load is caching. Once you get an asset from the server, it’s cached on your system. Next time you join any server with the same map/asset (by comparing file hashes), it’ll be an instant load without straining the server.

Custom UIs and HTTP Server

CEF (Chromium Embedded Framework) is a rendering engine for web content. It’s basically an embedded browser and an essential part of our custom UI support.

You can make full server-side UIs with it and have it communicate with your C# code in both directions. The web content is overlayed on top of every players HUD and has input support, mouse focus controls, and can interface with the game’s central EventHandler for custom scripting.

All files for CEF will be hosted from a lightweight HTTP server players will connect to. If all this sounds complicated, fear not. Almost all of our solutions from database support to the HTTP server are embedded into our game server itself. So just open port 80 (which can be changed), get your web files in the correct directory, and it should be good to go. No assembly required.

Discord RPC Library Update

Before we were using a pretty big library for Discord RPC. It provides cool updates for friends as to what you’re doing in Broke Protocol but it was heavy and spamming our logs a bit much So we jumped ship to something better.

Note: Joining friends could be implemented some time after 1.0

Now we’re using the official native C++ wrappers for Discord. This has decreased the overhead of the library by at least 30MB with better performance as well.

Client Compiler

The client compiler is basically magic that allows servers to run client-side code on players. Usually reserved for more advanced mods or rendering things that would require too frequent network updates, it’s another tool for modders to leverage.

In order to prevent servers abusing this power, the compiler is sandboxed to cut off any filesystem access and players will have the option to accept or deny compiler access on servers using this functionality. Do note if you disallow this on joining, the server may not work correctly or kick you.

API Decisions

After a lot of discussion we’ve finally decided how we’re going to implement the API framework and foundation. We were going for a wrapper design at first, but that would mean the codebase would grow by at least a factor of 2 since every type would require a wrapper. So our final decision came down to the following:

Use Asset Bundles to modify static fields that define entities (like their firerate, damage output, or max speed) by exporting their properties in an asset bundle.

Change fields we do not wish to be modified to private or internal. We will try to open up as much as possible but to prevent possible bugs some fields will be made private/internal.

Change fields we *do* want to be modified to properties, which then can be used to auto-sync these values with clients to prevent the modder from having to do it themselves.

Cleanup and Organization

A very important part of the API was a global namespace cleanup. Before files were stored in “global::“ which may cause naming conflicts in such a large project and clutters auto-suggestions in our editors as we’re coding. But now we’ve moved away from that and are finally putting our files in their related namespaces. This will make it way easier to find specific types and is way more organized.

Another thing we’ve done which is very small but very helpful was cleaning up the server.bat and start.sh scripts. Someone also informed us a while back that the line breaks in start.sh were windows ones (\r\n) instead of the traditional Unix ones (\n), so we’ve fixed those too.

Legacy Mobile Code

All these advancements mean the Mobile BP version will be deprecated. SteamID, CEF, and client compiler support is either limited, or not supported at all on Android (or iOS for that matter). This decision let’s us clean up a lot of legacy mobile code and make things easier to maintain for our 2-man team.

Other Fixes And Features

Volume sliders

We’ve finally added volume sliders per audio stream to the game! You can now mute the main menu music while keeping the sounds of screaming children in the voice chat at 100%. You’re welcome.

.txt files to .json files

Some existing JSON files had the .txt extension which we’ve now changed to .json. Also, admin_list.txt and ban_list.txt will be replaced by group/role management within the database.

That’s about it, we hope this will be the **final** devlog before the update. We can’t be sure of course but if everything goes according to the plan another devlog shouldn’t be required. Be sure to follow our development progress on our Trello Roadmap.