After careful consideration I’m not thrilled to write this today. CryeCSS LLC is not shutting down but the operations are going to be greatly reduced so that I can focus on my career, family, and a longer term vision for how CryeCSS LLC will accomplish the massive goal that is D20Kit, the tabletop RPG engine.

I know this blog has been dwindling in posts over the years but I think that is part because I don’t have enough polished stories to publish. I’m a scientist and experiment with software day in and day out. Measuring and attempting to discover how data can be modeled, transformed, stored, and transferred in efficient ways.

The Changes

With this announcement there will be some changes. The blog content will be moved to my portfolio under a legacy blog as they are really more my personal blog posts over the years than official company blog posts.

Depending on time available and whether or not I’m able to publish blog articles I will be publishing them under my portfolio. This should help remove confusion as to who is writing these posts and help set the tone of what type of articles they are.

The corporate website will still be a hub for official ongoing activities, announcements, and launch information. However you will get a much better alpha/beta content on my personal blog where I think the very casual nature of my writing makes sense. How I write professionally differs from my scratch-pad notes and taking note of my thought process as I resolve problems.

The Mission

I have been trying to make D20Kit a full product since I first started on Synk. It has grown immensely in scope and complexity in a way that is an unfortunate byproduct of the domain. Tabletop game engines are notorously simple to comprehend, but can be complex on the state you want to maintain.

Depending on granularity you could decide whether to save disturbed debris (i.e. casting fireball in a small room), building decay, NPC actions, players invoking historical events, etc. The list of things that could influence a game world should have the possibility of being replicated. It’s ultimately up to the DM/GM.

I believe pulling back and focusing on the application at an experimental level will result in a more thoroughly designed and tested ecosystem. While the blocky “style” in some demo images can look rough it’s about defining the functionality first and adding coats of polish. As once you have a working solution it becomes much easier to tweak it through A/B changes.

Reliability

Anyone who has maintained a software engineering role at a company can attest that reliability is normally one of the least important aspects of the final solution. It needs to get the job done, sure, but more importantly the velocity of those solutions matter. The industry theory around this seems to be that if you increase the velocity of everyone you can get more attempts in. Statistically the more shots you make the better your chances. Except in practice software engineers don’t operate independently and the software that is built is highly dependent. Which means the surface level statistical analysis breaks down immediately. If all of your attempts fail, then you have poor software reliability and your customers feel how little you care. It does not matter if you do care.

This is an undeniable fact. The more attempts you enable yourself to make, the more attempts you are able to make. Do you know how many people I’ve talked to that “want more” instead of what is already built “to fucking work”? Velocity is diametrically opposed from design and intent. It’s important to balance the two, as too much focus on reliability can slow down development and vice versa.

For CryeCSS, LLC and D20Kit I have a personal gripe on the industrial standard on reliability. In alpha software you can get away with the destruction of user content and it’s “part of what you sign up for.” For D20Kit to be tenable it needs to be self sustaining. A self sustaining game service or game engine needs to be reliable such that any consumer, the developer or players, feel that their money is well spent. I want D20Kit to be the reflexive and automatic choice for planning, running, or building tabletop roleplay adventures. That comes from being ruthless on providing an experience that is both reliable and enjoyable to the developer and the users who enjoy the games told within the engine. This is a non-trivial problem.

Game state, story elements, and the like are not ordinary “state” that is easily recoverable or inconsequential with a data integrity issue. They are the core of the game and must be protected at all costs. Backups can get you pretty far and in tabletop games there is generally a “begin” and “end” times that are really strong signals for a backup. However the state is not likely to be corrupted when you’re not playing. The same as you don’t expect the savefiles on disk to be corrupted if you haven’t opened the game in months. You expect it to “just work”. When your state is dynamically defined by your consuming developer you must provide concrete and reliable primitives. Otherwise they’re wasting their time building in a sandbox filled with water.

The “Just Works” Mindset

I believe this mindset is driven from a couple of factors. Firstly, it’s a cultural shift from the traditional software development mindset, which often prioritizes speed and flexibility over reliability. Secondly, it’s a reflection of the changing expectations of users and the consumers, who increasingly demand seamless, uninterrupted, and consistent experiences.

My belief after attempting to build this tool for a decade is that flexibility and reliability are something that can be targeted in a design and that software design is applicable to all application verticals. It requires you to spend a fraction of the time to understand the long-tail solution that enables more flexibility in the domain of your business. Solve data transformation problems and not infrastructure problems.

“Immutable” infrastructure is a fancy way to say data-driven infrastructure. Borg and later Kubernetes have shown the power of declarative state and reconciliation. This paradigm is what underpins D20Kit and I believe when it’s ready I want it to be a magical experience. The dream is that you should be able to find D20Kit and within an hour be able to run your campaign online or in person and not feel burdened.

Empty Promises

Nearly every old blog post made a claim that I’m not giving up and X, Y, or Z will return. While they remain true to me, I’ve learned that it’s important to be realistic about what can be achieved and to focus on delivering value to users. I’m committed to continuing to work on D20Kit and to delivering a reliable and flexible tool that meets the needs of tabletop gamers. I hope the next post can convince you that this is a viable and realistic goal and that I can earn your support.

Until next time,

-Chris