Devtober Day 9: Introducing The Honor Sagas

Since my last update, I’ve spent my focus on two significant tasks: developing the concept of this game that I had noodling in my head, and doing some housekeeping on my engine that sounded fun… but wasn’t in the end.

The Honor Sagas

I’ve posted quite a bit of information on the game’s page, so I won’t repeat it all here. I’ve been incredibly excited about the concept I’ve had for this game for a while, and after spending the last few days making important decisions, I’m even more excited. There is more to the name than I want to reveal right now, mostly because some of the ideas are too fresh for me to want to commit to.

Updates to my game engine

I really liked building Kludgine atop rgx. It simplified a lot of the difficult aspects of interacting with wgpu. During the last few months of development, I found myself using less of rgx’s built-in features and rubbing up against places that made me wish I could change various aspects of rgx. The other pending issue I knew I cared about was that I wanted to stay up-to-date with wgpu.

wgpu is under heavy development, and they are actively working on supporting deploying to the browser. I’m purposely designing my game to work at least in some capacity in a browser, although you will be able to download a client for the best experience. I had attempted to update rgx a couple of months ago. But, some significant changes made me unsure of how best to expose it with rgx’s author’s original intention. Daunted by the complexity, I abandoned the approach at the time.

During my battles mentioned in the last devlog, I had encountered a setting I wanted to change inside of rgx. I had the subsequent idea that because I was using so little of rgx, I could gut out just the pieces I was using and try to upgrade that codebase.

I succeeded, but it was a really tough day. The next rest of this section in the devlog is primarily for Rust developers. Skip ahead if you aren’t familiar with lifetimes and ownership. The primary reason for this was a small change to the APIs for how buffers were passed into various functions. In wgpu 0.4, you’d pass a reference to the buffer itself in, and the way the lifetimes were managed, the value didn’t need to stay in scope until the end of the render pass. In wgpu 0.5, BufferSlice was introduced. It has its own lifetime, and now each buffer that was referenced must stay in scope until the render pass is dropped. It additionally required a lot of me banging my head against the desk, trying to understand the lifetime semantics involved. Take a look at line 155 in gpu_batch.rs for an example of the final solution.

The trickiest part of trying to understand the lifetimes is that there were some solutions of lifetime rules that compiled but were too restrictive. That led to me thinking I was good until I got to updating Kludgine and started running into new lifetime issues.

Finally, I had to refactor a significant chunk of how my rendering pass worked due to the new lifetime requirements. Because I try to cache many structures between frames, I needed to create a structure that contained all data structures loaded into the gpu before I began the render pass. The render pass then can take as many immutable borrows as it needs from the cache.

In the end, I have a new crate that is on wgpu 0.6. Unfortunately, I feel a little sad that I jumped off of rgx. It’s a great little library, and it helped me get to where I’m at today. I don’t see my crate as a replacement at all – it doesn’t even have a built-in pipeline! It really just has become the abstraction to wgpu for Kludgine. But, if anyone else likes the idea, I have many ideas on how to genericize a few aspects further.

What’s next?

I’m going to start designing my database layer for storing and syncing map data. I have an idea to allow me to edit the maps in the game directly, and one of the first steps is getting my maps storing in Postgres. Once I have persistent storage, I can start working on getting a server deployed. I’ll definitely be posting another devlog before then!

As before, when I haven’t had enough energy to post a full blown devlog, I’ve provided a few updates on my twitter.

Have a wonderful weekend!