I’ve already got a good bit of time logged on this project (that seems to be a habit of mine). This is a zig minesweeper clone with a couple features tacked onto it. If you’ve ever played creamsweeper on the DiamondFire minecraft server, this is basically that but a native application.
I’ve finally made a bit of progress on the play state! I have not had much time these past two weeks to work on this project, so I haven’t completed much. I did spend more than 7 hours working on this (I would ballpark it around 10-11 hours), as I did some work without any wifi or service.
I refactored a bunch of types to accept a central Manager struct. For example:
pub const Server = struct {
pub fn doSomething(this: *Server) void {
// stuff
}
};
Was changed to:
pub fn ManagedServer(comptime Manager: type) type {
return struct {
const Server = @This();
manager: *Manager,
pub fn doSomething(this: *Server) void {
// stuff
this.manager.onDoSomething(this);
}
};
}
Goodness these codeblocks are annoying to write here. I should probably write them in my editor and not in this blog-writer.
Anyway, this lets me achieve my goal of having an event system similar to the way minestom handles it. The above code isn’t perfectly representative of what I do, as I first check that the Manager type has an onDoSomething function before calling it.
I have (kind of) completely finished the packet side of setting up a player once they enter the play state. This does NOT include a nice api for worlds and such. Chunk packets must be sent by hand. On the bright side, the tick loop finally has code to execute: client keep-alive packets (both sending and recieving). The server sends a keep-alive packet every 280 ticks. If the client does not pong the packet within 400 ticks, it gets kicked.
Next I should probably finish up the World struct and make interfacing with it bearable. This will require me to also use the block data report (from the vanilla minecraft server jar) to generate block definitions. I also need to start tracking player data and do some testing with multiple clients.
This post isn’t much, but I’ve tried my best to explain the little bit (that feels like a ton) of work I did. I wasn’t sure what to make the attached image be, so I decided to make it a screenshot of a funny bug I discovered while trying to decide what to make the screenshot be. I had forgotten to set the variable that indicated when the last keep-alive packet had been sent, so the client would receive one each tick.
I started this project before I knew another hackclub event was ongoing, so I have a few hours to be logged with this devlog. This is also my first time participating in a hackclub event, so I am very excited.
mc-zig (name to be changed), upon completion, will be a zig library that can be used to create Minecraft: Java Edition version 1.21.10 servers without the overhead of vanilla behavior, as developing a mod or plugin for fabric or spigot and the like. If you’ve ever heard of the Minestom java library, mc-zig will be similar to it.
My belief at the beginning of any project is to get something working. The code can always be changed later. With this philosophy in mind, I have so far gotten the client through the handshake, login, and configuration states. I wouldn’t consider myself proud of the systems I’ve laid out for myself, but it works, so I can’t complain. The image attached shows what the client does once it gets bored of waiting for chunks to be sent.
Next, I need to send chunks to the client, respond to keep-alives, and handle basic server-bound play packets. I also should probably write a proper readme.
