Game init and the basics

The countdown has got sounds, and now something actually happens after it.
The players get teleported to the islands. This also means a team assigning algorthm is in place. It is not perfect, but it should work pretty well, and it has it already accounted for an integration with a party system.
Any unnecesary marker entities get removed and the generators start spawning resources. They also got a title that displays when an item will spawn (for diamonds/emeralds), and the items now don’t stack, so you can clearly see when there is many of them.
Blocks are now protected from destruction, though for now it affects everything including the bed and anything the player places. This will be fixed once I will have other systems required for it in place.
I also have a shopkeepers system work in progress, but time is running out and I didn’t manage to finish them, so they will be in the next blogpost.

Starting the game

After adding a fix to make sure chunks are loaded during validation map editing is mostly finished.
This means we can start working on the actual gameplay.
So, after a bunch of coding, we got an API (and command to invoke it for testing) that creates a new bedwars game, by creating a copy of a map, finding all queue spawnpoints and teleporting players to one of them. The world is automatically managed, and removed after all players leave (because no one wanted to play or the game ended). We also got ourselves a countdown that… counts down to the game start.

Map editing progress

Map editing has got an enitre validation system, which ensures that map setup gets completed, before it can be played.
It makes sure that there are at least two different teams placed on the map, and a place for players waiting for game to start is selected. Those warnings can be checked with new /bw map validate command. The player is also warned when leaving the map if it isn’t ready to be played.

A Snapper Tool has also been added, which can be used to snap entities to block grid centers and edges, allowing for more precise placement of spawnpoints and generators.

The marker entities for spawnpoints have also been added, and all of them got new textures.

Async and assets

I added two new assets: BedwarsTeam and BedwarsMap
The first one defines bedwars teams, letting you assign a colour and a name to each of them.
The second one stores neccesary metadata about bedwars maps, such as the amount of teams it can support. It is automatically created when you create a bedwars map with a command. Getting this to work took a lot of struggle and my time. For some reason trying to save the asset to a file was locking up the entire server.
After a lot of debugging, I realized hytalemodding.dev was wrong, and made me think my code is executing async, while it was executing on the world thread (which caused the problem). I sent a PR to them to correct that, and adjusted my code, which solved the problem. I in the end I heavily reworte the involved code. First I removed the use of CompletableFutures, because they annoyed me. Then I made it use Kotlin coroutines, after learning how to use them, which finally made the code more bearable. I also changed the error handling to use a custom exception to contain a formatted, translatable message.
While not very much productive for the features, this session did a bunch of good things for the code, which should accelerate things in the future.

PS: I made the /bw map list command work by using the new map asset

Bedwars map editing and exit

You can now exit the edited bedwars map, and then return it. This took longer then expected to implement due to some issues with world lifecycle management and teleportation. The code responsible for managing maps also got some better organization.

Why don’t you write it in Kotlin?

A friend said.
I agreed.
I hope he was right.

Kotlin is pretty weird in my opinion, like Java + Python, but it also had to do a bunch of things in its own way, without s clear reason why. But it has null safety without having to write @Nonnull everywhere, and dunks on java getters and setters which are pure boilerplate (and were starting to annoy me). That + a nudge from a friend is enough for me to go for it.
So yeah, I refactored the project into Kotlin and I hope it pays off in the long term.

Note that I deleted some unused files, so the added to removed ratio is off, I didn’t save whole 250 lines just by switching to Kotlin.

Empty world creation

Next up in the works is map management, starting with the ability to create a new empty world. where you will be able to build your bedwars map.

Did you drop a generator?

Or 10 of them?
I fixed the generators disappearing after server restart.
The culprit of it was NetworkId component, which assigns an unique integer id to every entity, and lets the server communicate to the client which entity it is talking about. The problem? They are manual! You need to assign a NetworkId when you spawn an entity (which I did), but you also need to assign one, once the server loads the entity from storage!
After I added an ECS system to do so, a bunch of generators, which were saved, just not visible, showed up.

Configurable generators

The work on item generators continues, and I’m baffled to see that this devlog is representing 9 hours of coding - time passes quickly.
There is however a nice list of changes:

• Generators have been moved from json to code. This means they are no longer running away (see previous devlog). However a new problem emrged - the don’t get saved on server shutdown for some reason, and are gone after restart. I spent over an hour debugging this already, with no success so far.
• The generator is now spawned with /bedwars spawn generator command, instead of using the entity tool, which is a side effect of moving generators to code.
• Custom Hytale asset has been created, which allows for configuring the generators (what items and how often they drop) using the built-in Hytale Asset Editor. The asset also supports generator upgrades, so multiple level can be configured.
• A custom UI and interaction has been made, which allows the user to select which asset to use for the generator, and to activate it for testing.
• The generator stores a reference (id) of the configuration asset it is using, so it will be able to persist that data in map templates.

Is it a bird? Is it a plane? No, it’s an item generator!

And it is flying away!

But it is working, dropping items as it should.
The reason it is flying away is that entities made with json need a movement type, and by default the “Fly” type keeps going forward it seems. I’ll find a fix for it.

On the recording items are also spawning in slightly incorrect location, which is already fixed.

Bedwars command is up

The setup is done, so the development can finally take off, and the devlogs will be actually interesting and more frequent now.
We are starting with a /bedwars command fresh from the oven. The command will be used to manage bedwars maps, and to start a game without using the API.

I have not explored Hytale modding much yet, but I do love it already.
I just registered the commands structure, and look what I get for free - an entire help menu for my command that is automatically generated.

Setting up Hytale modding - the ever changing landscape

So, how long does it take to setup the dependencies and run something that released 2 days ago in a dev environment?
5min? 10min? 15min?

Yes, it is 15 minutes, unless you are also running your IDE inside flatpak, using the kotlin build scripts for the first time, and trying to follow two different templates at once, which happens to be me.
In that case it takes 2 hours.
And then, the next day I find myself deleting all the changes I made, because a gradle plugin got released in the meantime, which does the same job better.

The plugin had few little things missing, so I spent some time working on it, made a PR, and talked a little with the author.
Today I also made another PR, which instantly got closed, becaused I and the author coded the exact same feature in the exact same time. 😆

With all the changes made the gradle plugin has all the features it needs, and thus I present to you:
The smallest, cleanest build.gradle.kts file you have ever seen

Preparing for Hytale

As I am writing this, we are 2 hours apart from Hytale release. This means that the main work will soon be able to take off.

In the time from project start to now, I have made the BedwarsTracker tool (which is also available to try out on github btw.), wrote the code for an item generator, and most importantly spent much time experimenting with json, to get a good hang of what will work well as Hytale Assets for configuring the plugin.
For example teams will be data driven, meaning you can create as many (or few) as you want.

Tracking Hypixel Bedwars generators

I’m creating an exact replica of the Hypixel Bedwars, which means I need to know how fast iron and gold spawns in generators.

I tried to count this by hand but it was very cumbersome and error prone. I also had to sit in the forge which meant so I couldn’t defend the bed. So I created a Minecraft mod, that will do this for me.

Writing the mod

First I tried tracking items being added to the player’s hotbar, and it worked, but I still had to sit in the generator.
So with second attempt I started tracking item entity spawns, which didn’t rely on the player. After implementing that I could play as long as I didn’t go too far away from the forge, because then the items would not spawn client side. The server spawns them back after coming back close, which I also had to account for, to not have duplicated data.

Analyzing the data

The mod generates a CSV file with raw data, that needs to be analyzed. So I
wrote a python script which:

• Removes some noise, by discarding entries that have a very big delay between
  them.
• Merges item spawns that occured in short period of time (because Hypixel spawns each item individually) into one spawn with correct count.
• Groups spawns using HDBSCAN algorithm with hyperparameters tuned for each item type to find different forge speeds (because the speed changes after 30s, and when you upgrade the forge).
• Calculates the average delay for each group and prints it in the console.
• Plots the delay against time.

A discovery

Seeing a chart lead to an interesting discovery:
Did you know that generators are at least 2x faster during the first 30 seconds of the game? I certainly didn’t.

The result

In the end, this yields us the attached charts.
Note: As you can see the algorithm stops working very well after you upgrade the forge, because the data is a bit weird. I might spend some time later to fix that, but for now this is enough.

It works! (kind of)

After much work, we have a working rotary knob that can control the volume of the device it is connected to.
Rust embedded ecosystem is still pretty new, so I wasn’t able to find any library for making a HID device with Bluetooth LE. Instead, I had to manually write out the GATT services. Fortunately, it was easier than I thought, with only two being required for a working device. I also had to drop down to Windows (from my usual Linux) for a moment to generate a HID descriptor using the Waratah tool (https://github.com/microsoft/hidtools).

However, the biggest trouble, which took most of the time assigned to this devlog was getting the bluetooth device to connect and not get disconnected by OS or throw some error and disconnect itself. I spent probably another six hours not counted here, staring at logs, btmon, and searching about bluetooth pairing. So far, I haven’t managed to get a JustWorks pairing to work, and instead settled on a fake pin pairing. The device pretends it is displaying a pin to the user, and letting him confirm it, when actually it just automatically confirms it, and the user also does so on the device he intends to control. I believe the trouble with JustWorks authentication is caused by - guess it - trouble! - the BLE library I am using (pun intended). Another possibility is Linux causing problems or it might even be both.
I’m planning to open an issue on trouble github about this, and maybe the library can get fixed.

This project, while functional now, is also not yet done.
I still need to implement proper pairing data storage, so the device can reconnect after being powered off, I need to connect knob press to mute, and I need to make a physical package for the device, so it is actually usable. The authentication without pin is also something I would love to get working.

The video showcases the knob being used with a phone because it was easier to record, but it works with a pc too obviously.

Knob rotation is fixed!
Now every turn is detected correctly, yay.
The solution?
Even more bit patterns.

Bluetooth stack is up!
This was mostly copy-paste work from the examples folder of trouble, the BT stack by Embassy, with some tweaks and few small things to figure out.
Below you can see a screenshot from the NRF Connect mobile app, which lets you discover and debug Bluetooth devices around, recognising my device.
I also spent some more time messing with the knob, to see how it works, however so far I didn’t manage to fix the every other rotation reporting.
Next comes the hard part which is figuring out how to make Pico appear as a HID device, get accepted by different OS’es (I read windows might have some additional requirements), and how to send keypresses.

The knob is working! (kinda)
I wrote the code to handle the input from the knob, and now it prints into debug log when rotated left or right. However for some reason it detects only every other rotation (you need to rotate it twice in on direction to get a print). This is to be fixed. I’m also considering using interrupts for this (for fun), but the Embassy documentation is pretty lacking, so I will leave this for later.