> I fear for what happens when Gabe Newell retires and the MBA cancer fully infects Valve.
They are making SteamOS compatible with other hardware, if you want to build a steam machine of your own. Also their contributions to Wine and Fex will enable other Linux gaming platforms that are not SteamOS to have the same compatibility layer.
I love the idea. How do you stay competitive with the search results of, let's say, DDG? have you considered enabling an API for subscribers? Or selling an enterprise tier subsctription that comes with API?
For all the bad rap that AI gets in game development, stories like this should be heard more. I occasionally get tendinitis and I can't code for the entire day like when I was young. I get some relief dictating to the AI when I need to rest my hands. I can imagine it's a much bigger help for someone who is struggling with worse.
Awesome game! Small suggestion, for each paragraph that is in your description, you can add a small gif-style webm video. It's kind of expected now for Steam games, and specially because it's such a unique game it would make an easier introduction to the concept. Looking forward to play it :D
I've seen it worse: A team of employees have an entry level engineering job, and work as a bridge between support and the "core" engineering team. They just talk to customers when an issue is escalated, and maybe it will submit a hotfix PR but when the issue must be escalated further the instructions are to send it to the higher-ranked team who will make it part of the next sprint.
At every all-hands meetings, core team gets to present, gets to showcase the new features, gets celebrated for "going the extra mile" for customers.
But the real extra mile, is the patience, empathy and thoughtful communication (which is a rare talent, really) of the entry level engineers, who are also humble and nice to be around with, being the only ones who contribute positively to the company culture, as opposed to the ego-tripping 10x engineers.
Management thinks they are absolutely replaceable. Even more, when the concept of "AI agent" appeared on their radars, they were the first people who they thought they're gonna replace.
But the real reason to replace them is to please investors who don't wanna be behind the AI-efficiency-hype. They can't be promoted to a core team, because where's the efficiency in that?
I love this idea! I totally see it in the classroom or being played by someone who's trying to learn how to make an OS (which is on my personal bucket list)
What I didn't like, is the tutorial is separate from the game. It would be awesome imo, if there's a tutorial stage where the game is explained hands-on (maybe pausing the game with explainers, until I start to get how to play) Otherwise I have to memorise the instructions before trying the game.
I also asked claude to give me a 1-paragraph summary of how our stack works. Anyway, if you have more questions i'm happy to answer e-mail (check my profile)
Robotic text below:
The whole thing is TypeScript end-to-end, run by Deno, which acts as the glue. In the browser, there are just two pieces communicating over a native WebSocket: a React front end bundled by Vite—Deno runs Vite for the development server and hot reload—and a Deno back end that owns the simulation.
The simulation runs on a tick loop, with each tick representing roughly one in-game day and taking about one second of wall-clock time. The client sends small command events such as `newBuilding` and `bulldoze`. The server processes each tick and broadcasts all resulting state changes in a single batched frame. This makes the client essentially a renderer of authoritative server state, with a full resynchronization whenever it reconnects.
Under the hood, the simulation distributes heavy workloads—including demographics, taxes, and housing markets—across Web Workers. These workers coordinate through a shared SQLite database used as a cross-thread bus, allowing the game to simulate tens of thousands of citizens.
The 3D layer uses Three.js with WebGPU, a WebGL2 fallback, TSL shaders, and batched draw calls. It runs imperatively in its own `requestAnimationFrame` loop inside one large component, deliberately avoiding React Three Fiber. React manages only the 2D HUD and menus layered on top, keeping the performance-critical rendering loop entirely outside React’s reconciliation process.
The key point for prototyping is that the browser application—the client plus a local server connected over WebSocket—is the entire game. The desktop builds are simply thin native shells around the exact same application. On macOS, the shell uses Tauri with Rust and the operating system’s WKWebView. On Windows and Linux, it uses Electron with bundled Chromium.
Each shell launches the server, compiled into a single self-contained binary using `deno compile`, as a sidecar process. It then finds an available localhost port and points its webview at the bundled client. This means the game can be built and iterated entirely in the browser, with native packaging added only at the end.
For Linux, it was an ABI nightmare, the Steam sandbox is based on Debian 11, and glibc/GTK/webkit can't be reliably static-linked to a modern version that Tauri wants. We also ship a stand-alone version in itch.io that doesn't have the limitations of the sandbox but it was a friction point for many players having to figure out how to meet the dependencies.
For Windows, it was a bit less dramatic, but WebView2 is controlled by Windows Update in Windows 10, Some players have it, some players don't. And requiring windows 11 and up is a very unpopular choice. Maybe could have been solved by vendoring it but also not super clean.
I look forward to give it a try again, when Steamworks Linux runtime 4.0 comes around, and less people are still using Windows 10.
I am the freaky outlier that's actually excited about this.
My city builder game, Microlandia[1], runs on Deno. The game's graphics and UI is a Three.js/React app, but the guts of the game are in a "sidecar" process that is a `deno compile` typescript executable.
On Mac, there's a Tauri shell that runs both client and server, and for Linux and Windows we use Electron, (Tauri proved to be quite problematic except when in macOS)
Why on earth did I choose this cursed stack instead of a "proper" game engine? Well,
Turns out developing the simulation in typescript with a performant sqlite driver hot reloads very fast and with a light code editor and my browser open on a second window I see the stuff updating live as I make it.
Deno has a good VSCode extension with test helpers and a fast language server. WebGPU is good enough for me to write any cool shader I can think of and I don't miss any capability of a game engine.
More importantly, not using Unity/Unreal brought back to me the joy of game development that I had lost due to and horrendous UI-driven workflow that takes me back to Macromedia Flash (yes, I am that old). Oh, and the licensing.
And I know I could switch to Bun with small changes in code but Deno has never got in my way. Maybe it's because I avoid using libraries at all costs (and don't need much).
Also, Typescript/React is such an amazing language for building a complex tycoon/simulation type of game that deals with a lot of data and displays it. Anyone who's worked on Unity knows it's the dark ages for UI over there.
I'm unsure if i'll port the game to Deno Desktop anytime soon but if I start a game again I will use this stack again, as my game engine, this time without Electron or Tauri.
They could. But they rather get their "wisdom" from Steve Jobs trivia romanticizing the grind and being an asshole.
Like Elon Musk, who once wrote in a company-wide email in 2018: "Walk out of a meeting or drop off a call as soon as it is obvious you aren't adding value"
Is someone here using a Claude product that's not code? I'm puzzled about the amount of products they put out. I know a lot of people using Claude but we're all using the terminal-based code. Even for non-engineering stuff it suits great (tax documents, 3D modeling with blender through MCP, academic research, etc.)
I loved your game. I'm wondering about the decision of making the game with a registration on your website instead of a more traditional approach of having a standalone game. The friction point for me was having to register to save progress. I would gladly pay in Steam or itch.io for a game that i can download and play locally.
I'm guessing the decision is about making a online leaderboard?
Unhoused people do exist, and they vote for you so it's in there. Also shelters with real costs based on good data. Modeling slums is actually quite hard. There were unhoused camping sites in the early access version but I was unhappy with how it turned out and retired the feature back to the drawing board.
I want it to come back because it's in the spirit of the game not to hide the "ugly" aspects of city life.
There is gentrification in the way that landlords discriminate low income renters and NIMBYs have political power over you (in the form of the 'disagreement aura')
There's no rules against building single family homes in a city center, but the effect is what you would expect: non optimal tax revenue as you could zone it for something that's worth a lot more.
Regarding the unit economics for finance sector, you are right, the calculations are way too simple, and I'm not entirely happy with it, so I'm looking to improve it, but it does need to be a sweet spot between 1. realistic enough to be educatioal and 2. simple enough you can use it as a gameplay mechanic.
Before the end of the year there will be mod support, and I will pay special attention to making sure that modders can swap the economic formulas for more sophisticated models.