Hello everyone, this is the second installment of our ongoing devlog series. These news posts will highlight key elements of our development process and decision making towards the upcoming milestone update: 1.0. Much of the focus over the past couple of weeks has been on improving usability with some cool new features and back-end changes.
So, what exactly have we been working on?
New Master Server code
So one of the first things we worked on was a new master server handler. This one has been created from the ground up again using .NET Core for improved stability and efficiency along with cutting dependence on the bloated Unity runtime.
We made it future-proof by using JSON for serialization and deserialization. This will allow us to add new properties without breaking third party API’s relying on the master list (such as the handy BP-ServerList)
Entity Database
Previously, all in-game items, buildings, players, vehicles and their associated parameters, textures, meshes, and audio effects were locked away within inaccessible engine resource files. Now, we’re finally exporting entity data into an external LiteDB database.
This new entity handling will offer API level access to entity fields and methods (in the BrokeProtocol namespace). And another cool thing is that (post 1.0) it can eventually allow easier client-side and server-side modding of new and existing objects and items. We’re re-designing our systems to be as flexible as possible with the API and modding in mind.
End-User License Agreement
Now that the API is nearing, we need to set some base rules about what’s allowed and what’s prohibited. That’s why we created the EULA. The goals were to protect our copyright, but also protect users from aggressive or unethical monetization from servers.
As a game that thrives on 3rd-party community support, we can’t directly control everything. However, we can have a license that protects users against abusive or offensive practices outlined below.
Hosting
Servers may create communities and provide custom content in the form of different mods, settings, rulesets, and gameplay elements. In order to protect players, Servers must not:
- Sell privileges or content for an exorbitant fee
- Charge for anything resembling administrator powers
- Circumvent any anti-piracy measures nor enable access to stolen Intellectual Property
- Undermine or attempt to circumvent any provisions of this license
User-Generated Content
If you’ve bought the Program, you may create or run modifications, maps, plugins, or tools. Mods are welcome but may not be distributed nor hosted on Servers if they are:
- Unoriginal, stolen, or contain a substantial part of copyrightable code or content
- Offensive, racist, homophobic, sexist, slanderous, or otherwise illegal
- Charged for an exorbitant fee
- Provide an unfair advantage to users
The license is still permissive about monetizing your server in a reasonable way to account for server costs. It just protects against abuse that could harm the game and community in the long-run. You will have to agree to this to download the game and once more to host a server.
Console Window
We’ve used BP-ConsoleMonitor since almost always. But this was just a log tail program with no input functionality. coloring, cursor position, etc were all extremely limited due to it being a log tail program in the end just reading output_log.txt or Player.log in newer versions line by line.
So now when you start the server using the Server.bat file it will attach to an existing console window if the parent is a cmd window, if not allocate and attach to the newly created cmd window. This allows the server to close when you press the close button now too, instead of going to task manager.
Because this supports input too now, you can register server console commands using the API as well. There are two already existing: “exit” and “save”. Both are pretty self-explanatory: “exit” is now the preferred exit method as it saves the server as well before safely exiting. Note that when you terminate the process using task manager the process being terminated cannot respond to said action, which results in data loss.
Project Repository Migration
Before we were using BitBucket, but we’ve decided to switch to GitHub. At first, this didn’t work due to the 100MB upload limit at GitHub. Fortunately, Git-LFS exists and after installing that we bypassed that problem.
Since our Issue Tracker and Wiki are on GitHub, it just made sense to migrate there. And GitHub also features more tools and even the possibility to integrate code commits with our Trello roadmap.
API
So now onto the API part. We’ve added a ColorParser so you can use the Minecraft color codes which automatically get parsed to unity RichText. This will be handy for color-coded string because for example:
&6Hello &cWorld&1!
looks a lot better than
<color=#D9A334>Hello</color> <color=#FE3F3F>World</color><color=#0000BE>!</color>
Which is how it looks under the hood.
We also added back function key support so you can now detect when a client presses a function key as well as open or close the function key menu, with your custom text.
Resources can also target specific versions now if you have a resource that targets a very specific version of the game, or if compatibility breaks in a future update.
GunGame Example Resource
Yes, one of the example resources will be a GunGame game mode. For the people who do not know what this is:
You start with a weapon, for example, a pistol and after a set amount of kills using that weapon you get the next weapon in the list. You keep doing this until you get the last weapon and make a kill with it, which results in a game. This is in most cases a knife, but that can easily be changed.
The config file will look something like this.
(This game mode will be released along with the docs and other examples next update.)
General Bug-Fixing and Improvements
As a reminder, we’ve archived our #bugs and #suggestions channels on the Official Discord in favor of our GitHub Issue Tracker. And we’ve been knocking bugs and issues off this list regularly. We’ve cleaned up the unneeded code and improved existing code. Optimization in packet handling, leveraging better libraries, and cleaner connection and authentication handling allows for faster and easier to maintain code on our end and a smoother experience for end-users.
That’s about it, we hope to release another dev log soon(ish) and be sure to follow our development progress on our Trello Roadmap.
Thanks for following along,
@NongBenz and @UserR00T
