Major refactoring, new projects

This post will mostly focus on Kludgine, but before we get into the updates to the engine, a quick update on my strategy of developing moving forward:

  • ncog.link will switch back to my original idea of ncog.id – an account management system that I can share between games. The goal would be to put some basic functionality that I could share between games, such as an inventory management system. I plan on keeping this completely open-source.

  • Cosmic Verge, my original game idea, is being resurrected. I am still exploring the design of this game’s mechanics and systems, but what I do know is that it will be an MMO-esque game using a long tick similar to how EVE Online uses a 1-second tick. A longer tick can allow us to consider keeping TCP as an option, instead of UDP. Short ticks are not optimal on TCP for many reasons.

    By keeping TCP an option, it allows the game to use SSL to encrypt its connections. Additionally, by further picking WebSockets specifically, it should be possible to port Cosmic Verge into the browser through WebAssembly once wgpu supports it. It may seem odd to fixate on arguing for WebSockets, but it’s because of the next bullet point…

  • basws is a framework that I wrote this week to stand up an async client and server WebSocket API. I am integrating it into Cosmic Verge and ncog. I’m pretty happy with the current state, and I think once I’m done adding a few more of the ideas I have, it will be almost ready for a 0.1.0 release.

  • async-handle is a very simple crate that makes using Arc<RwLock<T>> slightly nicer. It’s built atop async-rwlock. I find myself wanting to use the Arc<RwLock<T>> type a lot, and in Kludgine, I already exposed KludgineHandle. I decided to take that type and make it a bit more general-purpose and release it in its own crate.

  • rgx-lyon is a new Pipeline for rgx. The rgx 2d shape pipeline is great for simple shape drawing, but for enabling custom polygons, I needed to bring in the big guns with lyon.

  • muse: I haven’t revisited muse yet, but I’m itching to. As part of my decision to resurrect Cosmic Verge, I decided that I will be attempting to tackle the art and music myself. Muse is a fundamental part of my plan of putting music into Cosmic Verge, and also I’m hoping to use it to experiment with some programmatic styles of composition.

As you can see, it’s been a busy couple weeks since the last update – those are just the items unrelated to Kludgine! Let’s get onto the main star of the update.

Kludgine Updates

Better message passing

Message passing is now triggered through the async runtime and no longer is tied to the scene lifecycle. This fixes one of the concerns I had in my Chillscapes Retrospective.

Integrated rgx-lyon

I’m sure you could see this coming… kludgine::shape is now based on rgx-lyon. It has basic primitives in the Shape type, but it also supports full tesselation through the Path type.

Integrated euclid

I apparently have been under a rock since I started Kludgine. euclid is an amazing math library focused on data types commonly used in computer graphics. The commit was an impressive 48 changed files, 621 additions, and 1,549 deletions. I did that refactor over the course of 24 hours in 3 sittings. Each time I sat down, I looked at the next compiler error, resolved it, and moved on.

I’ve spoken on it many times, but as soon as I finished removing all of the errors and warnings from the compiler and clippy, everything in my engine worked the same as it did before. I don’t have a vast array of unit tests. The reason wasn’t that I helped myself by having thorough tests. It was just simply that Rust is that helpful at allowing you to express the true intent of your code, and it checks your steps more thoroughly than more traditional languages.

Added sprite rotation

In starting my stream this morning, I wanted to start working on the game aspect of Cosmic Verge, but I realized one of the first things I wanted to support would require rotating sprites, a feature that rgx doesn’t quite support (there’s a pull request in final stages for it). However, after thinking more about how I would support custom shaders in Kludgine, I decided it would not be a waste of time to implement my own Pipeline for rendering sprites.

In the process of doing this, I also refactored a few other under-the-hood details now that I was taking a more firm grasp on the rendering pipeline. Overall, there are some slight performance gains due to this refactor, but those gains are mostly due to my pipeline fitting my design perfectly, while my design required moving data around to prepare it for rgx.

What’s next?

Now that I have sprite rotation, I’m hoping to start working on getting a very basic game client started up. I’m still spending some time each day developing my design document for Cosmic Verge, but it might be a few weeks before I feel confident in sharing the vision I’m developing.

One aspect I’ve been debating over the last few days is how open I want to be in development? I’ve decided that I’m going to try to keep as much open source as possible. The way the game works, for the most part, will be open-source, but content, behavioral scripts, and assets will only be distributed through Cosmic Verge itself. This is because I want to make sure that I can develop storyline content in private, or that specific details of mechanics can be hidden from users. To me, perfect information is one of the prime enemies of having fun in games these days.

I’m going to try to do better and not let so much work go by without an update next time! In the meantime, I’ve released Kludgine using a prerelease version indicator. This allows the documentation to be published. Not much of Kludgine is documented yet, but I’m starting to feel more confident that I can begin documenting some types without fear of them changing too much in the future. I’m going to be trying to release regular development version updates on crates.io moving forward.

As always, feel free to leave a comment below, join my Discord, or say hi on Twitter.