A HeavenX Developer's thoughts on Modding:

When I was growing up and first got a GameCube, one of the first games I played to death was TimeSplitters.

It had a map maker, and my brothers and I would stay up way too late building levels and then immediately playing them. That loop of creating, sharing, and playing hooked me early.

Later I sank a ton of time into Unreal Tournament 2003.

I didn’t make custom maps or game modes for it, but I loved jumping into other people’s work.
There was this one map that was basically a giant bedroom, and you were action figure sized weaving around the bed frame and bathroom door.
Stuff like that massively extended the game’s life for me and showed how much creativity a community can bring.

More recently, in a game I helped make called MyFloppy, I built a UGC system where players could draw items like furniture, posters or just whatever they wanted and use them to decorate their Floppy’s room.
Players could even submit those items to a global store so others could place them in their rooms.
Watching people fill their spaces with community-made art was a reminder of why I like building systems that allow players to contribute to the experiences of others.

That through-line is why I wanted HeavenX to be moddable from the beginning.
I want to support the whole spectrum: folks who just want to play, folks who want to tinker locally, and folks who want to tell completely different stories for their own communities.

The architectural choices we’ve made: client profiles, a real-time asset pipeline, and eventually an SDK and self-hostable servers, are all in service of that.

-Hunter

Server + Client Profile System

It’s been powering HeavenX since playtest #2, but we’ve been expanding it to support a real-time content pipeline for the entirety of HeavenX and (eventually) fully offline play and modding.

Why a real-time asset pipeline?

• Fast fixes without a patch. Core game assets are versioned and served from the HeavenX Game Services (HXGS) backend. Clients can pull versions and integrity hashes, then request the exact asset payloads they need.
• We use the same approach for all content types, which keeps the service transport in the HeavenX client compact and consistent.
• Fair leaderboards. Submissions include structured session and loadouts, on the server we normalize timing and compute placements. This lets us audit or cross-check entries, while ensuring that all players submitting scores are using the same set of cards.
• Add content post-launch without pushing builds. Because HeavenX assets are portable (more below), we can provide new content after release and clients fetch only what changed.

Eventual “client profiles” (offline, modding, and self-hosting)

We’re in the process of designing a client profile system where settings control where the HeavenX client loads its data and which features are enabled. Currently we are planning to support:

• Local (Built-In): Uses the assets that ship with the game. No online features.
• Local (Modded): Loads assets from disk. No online features. We’ll release our HeavenX SDK after launch so you can author custom cards, maps, story content, etc with the same DTOs our tools use.
• Server (Official): Default profile. Streams official assets from our ZHI server.
• Server (Modded): Further out: we’ll release the HeavenX server so communities can self-host and stream their own content to anyone who connects.

Why this is cool: different players want different experiences... out-of-the-box offline play, local tinkering, or fully custom storylines streamed from a community server... and we want to enable all of those experiences so we are putting in the work to make it happen.

On Stop Killing Games

HeavenX's server architecture was intentional from day one.
We’re building for both offline and online, and for both local and server-side modding.
HeavenX will always be playable.

Where the server stack is today:

• Telemetry (SGTA): In place. We capture anonymous performance metrics so we can spot spikes, regressions, and platform issues without personally identifying information.
• HeavenX Game Services (HXGS): In place. HXGS handles HeavenX client auth, assets, users, leaderboards, more. It sits behind a reverse proxy, and the services are orchestrated in Docker Swarm so we can scale replicas under load as needed.
• Story system asset support: In active development (actors, quests, translations, globals). We’re ~80% through the backend work, more on that once the schema stabilizes and we have it all working correctly.
• Everything runs behind an NGINX reverse proxy with the game services isolated appropriately. We ship Postman collections for all APIs, and the stack is portable to other VPS/dedicated hosts because it’s containerized.

How this compares to what other games do:

Plenty of games pick one lane: always-online live service, or a purely local moddable sandbox.
We’re deliberately doing both:

• Live service layer for quick balance/content updates (no client patches).
• Offline-first profiles so HeavenX remains playable forever.
• Local modding with an SDK using the same DTOs (data transfer objects – you can think of them as assets like "cards") and editor flows we use internally, so creating content won’t feel like a second-class experience.
• Self-hosted servers (post-launch) so communities can run their own canon, cadence, and game rules.

This hybrid is harder to build, but it pays off in longevity, fairness, and content velocity.

The SDK approach (and why modding won’t be second-class):

• Every Unity asset we stream is represented as a DTO (portable data, again think of a 'thing' in the game like a 'card').
• Our internal editor tools are built around those DTOs to author, validate, hash, and publish.
• After launch, we’ll ship an SDK that exposes the same DTOs + pipelines, so the content-creation experience is identical to ours.
• Because the server code will also be released, you’ll be free to build your own editors if you prefer a different workflow.

What’s next from here:

• Finish the story system server backend (actors/quests/translations/globals).
• Wire up client profiles in the launcher/settings UI (likely in December/January).
• Author and document the SDK and self-hostable server (code + Docker image) after release. We’ll take the time to clean, document, and support it properly. In the short term we’re 100% focused on shipping HeavenX.

If you’re the kind of player that doesn't want to mess with mods and just play through the vanilla experience, tinker, or run your own unofficial campaign that can be streamed to other players, we’re building HeavenX with you in mind.

In Other News

Work continues on writing shaders for the office; there's a lot that goes into making a CRT monitor look good.
Just focusing on one aspect—simulating pixels on the screen—is more involved than you might think.
Depending on what angle you look at the monitor, the strength of the pixel effect, the size of the pixels, etc., you can end up with nasty moiré patterns.
Masking out the colors lowers the brightness of the image which needs to be compensated for both in the texture and the shader.
Then the difference between your own monitor's resolution and the in-game monitor introduces problems that would take several more paragraphs to explain.

UI/UX Throwback: "RightNow"

The in-game "RightNow" application (a corporate-issued task tracking tool the player will use to complete tasks within HeavenX) takes its design inspiration from the aesthetics and UI/UX conventions of late-90s enterprise software.
As part of ZHI's broader design philosophy, every tool within the desktop interface is deliberately period accurate, drawing from the visual and functional cues of vintage productivity suites like Lotus 1-2-3 and Freelance Graphics.

Hypothetical: What if you lived 10 years longer but every time you shit it got all over your hands (There is no way to get around it...) would you take this deal?
If you read this part, answer in the comments below.

All other applications are being thought through in the same way.
Currently, there are planned (and in some cases already functional) versions of messaging software (Slack / Teams), email, and rudimentary web browsing tools that emulate the design constraints of early corporate software.
Each tool is built to serve functional roles in the player's experience of the game like surfing intranet pages, uncovering hidden lore, parsing internal memos, or chatting with other Neo-Frontiersmen via “Shout!”.

Thanks for reading