Reinvisioning Cosmic Verge's Architecture

The other day I wished that I had a website that showed all of the activity on our projects. As I thought about that, I realized that the activity would look sporadic without understanding how it fits into the big picture. So, I began trying to imagine what that visualization would look like, and I started with a graph of the crates and how they are being consumed in the big picture of Cosmic Verge.

Over the course of the last few months, @dAxpeDDa and I have been refining our approach to building a highly available, secure, performant platform for Cosmic Verge. This graph isn’t complete either – it’s just what we have so far.

Our philosophy to development is to build things modularly, lending itself to separating functionality into distinct crates. This adds its own problems – that many more CI setups to maintain and multi-project issue management is not nearly as good as it should be on GitHub. However, we’re doing our best to develop strategies to ensure we’re building a good, solid foundation for ourselves.

The only way for us two to pull off a huge project is to try to construct things to unit test thoroughly and reuse as much as possible across our projects.

Refining our vision

The largest changes in the past few weeks have been the swap in positions of PliantDb and Gooey to being the primary dependencies of Cosmic Verge. This is the “near term” vision for the game. PliantDb will be providing the networking, clustering, and general runtime for the game. Gooey will drive all of the game’s drawing for now. Long term, we hope that the game is successful enough to warrant including some 3d capabilities, in which case another crate would emerge at the same level as Gooey and PliantDb for those portions of the game.

One example of the evolution of our vision is fabruic's role. When we started PliantDb, it was a project that was aiming to solve some storage goals for us. We imagined that Cosmic Verge would be building its own client-server protocol using fabruic, and the servers would have a private protocol as well. At the time, PliantDb was being treated like any other database: an external service to consume.

As I began thinking about the features I wanted to design for PliantDb, I started to see a path to a unified architecture. Instead of building clustering for PliantDb and then building it again for Cosmic Verge, could we flip our viewpoint and have PliantDb take a central role in our design?

Ultimately the arguments that convinced us to pursue it are the same reasons we’re deciding to use Gooey for our game “engine.” Dogfooding these crates through our game will be an ultimate test of the power of those crates.

A case for building a game with Gooey

For Gooey, the argument to embrace it fully only happened over this past week. See, Gooey’s architecture is actually built up of a group of crates as well:

When running a Gooey app on the desktop, it will use gooey-rasterizer, which uses kludgine for its Renderer implementation. This Renderer trait will be the same trait that a hypothetical Canvas widget could expose. The long-story-short: if we target our 2d drawing of Cosmic Verge through this Renderer trait, Cosmic Verge will automatically work wherever Gooey runs.

The biggest benefit is that because Gooey is already ahead of Kludgine in terms of working on the browser, picking this path will get Cosmic Verge onto the browser with this new architecture with fewer headaches. Getting Kludgine working in the browser hasn’t been straightforward. Relatively speaking, it’s straightforward to get a Canvas widget working.

The near-term roadmap

Here’s the high-level sequence of events until we have a version of Cosmic Verge running on this architecture:

  • Implement enough of Gooey to let a user create an account or log in.
  • Research/implement OPAQUE password authentication in PliantDb
  • Add authentication flow to PliantDb
  • Recreate basws-like functionality in PliantDb's Backend trait.
  • Add HTTP-routing layer (most likely with routerify)
  • Add WASM implementation to pliantdb-client.

While I was originally crossing my fingers that I might have Cosmic Verge running in the browser by the end of the year, this list doesn’t feel very daunting. It’s more than a couple of weeks of work, but it’s not much more than a month or so by my SWAG.

I’m looking forward to showing off more of Gooey as it evolves. I’m most likely going to focus on it for another week to get enough built out that @dAxpeDDa can implement a Grid widget for us after he wraps up his TPM and OPAQUE work for Custodian. Once we have enough to show off a moderately interesting demo with [Gooey], it won’t be much longer before getting Cosmic Verge up and running again.