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.
What’s Been Done?
Managers and Events
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.
Play State Setup
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.
What’s Next?
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.