hckrnws
If this requires installing WebView2 on Windows, then I'd recommend against this approach. I did something similar myself (to avoid distributing a bloated Electron build), but, since the WebView2 installer sets its window title to "Microsoft Edge Update", I got a lot of negative feedback from a few very vocal Steam users who thought my game was trying to re-install Microsoft Edge--a browser they had meticulously removed all traces of. I think one Steam user even called my (free and open source) game "malware", just because of that window title (which only appeared on first run, when the WebView2 installer ran).
I'm sorry to say that if I had to do it again, I'd use Electron, despite the bloat. I bet Electron would also make distributing a Linux build easier, too. (WebView2 didn't work fullscreen on Proton when I last tested.)
Sorry to be a downer! Obviously, I originally loved this approach since I did something similar--it just didn't end up paying off. No one noticed that the download was ~100 MB lighter--but they sure noticed a brief flash of "Microsoft Edge" on their screen!
Impeller renderer is about 100 KB [0]. You still need to add things like text layouting library and image codecs to that size. A few MB in total I guess, but much less than a full web engine.
While Flutter could be used to draw UI to texture, Impeller could also be used by other UI frameworks. Recently, Avalonia team experimented with replacing Skia and a Flutter developer asked, if they are interested in using Impeller and even offered some help [1].
This would probably be suitable, as a more lightweight alternative to WebView, for integrating into game engines.
[0] https://chromium.googlesource.com/external/github.com/flutte...
[1] https://www.reddit.com/r/dotnet/comments/1nv3snm/comment/nh7...
Even if you don't opt for gpu compositing, you can be 8x more performant than skia by writing something yourself. Skia is optimized for portability, not necessarily performance.
I wonder if Tauri is subject to this.
The sooner Tauri grows Electron/Chrome bundling capabilities, the better.
Chunky and predictable beats confusion, errors, and inconsistencies.
By that logic, every website should bundle their own web browser. They don't. Browsers are consistent enough, especially when you limit your web browsers to only those that OSes provide as web view components.
Bundling your dependencies is in fact something applications like to do though. The question becomes whether your browser/runtime is the layer you stop including deps or the os native apis which that browser is built on top is. When you get to physical products the OS is absolutely part of the dependencies you want to control and deploy, even if it largely exists to run a single application.
Safari and Edge scare the user about pointer lock control, which makes it annoying/impossible to build nice 3D games or visualizations in Tauri. Every on click event is met with a huge, scary browser-native alert. Chrome doesn't do that.
That's just one of dozens of browser inconsistencies we've recently dealt with. It's just the most egregious.
Safari and Edge aren't that interesting, since Tauri uses the OS's native web view, not Safari or Edge. Are you saying that the web view also scares the user about pointer lock control?
Yes. The OS's native web view uses the same rendering/JS engines as the OS's preferred browser choice. This is why native web views are inconsistent, and in this case, crippled.
By that logic, every app that utilizes Python scripting should bundle their own Python runtime.
And they do.
Python is neither backwards nor forwards compatible. The web is very stable.
And most people don't have a Python runtime installed. Almost everyone has an OS with a web view component already installed.
You don't need to bundle that much, when you have tooling to retrieve reproducible dependencies and build the whole thing in reproducible ways.
This shouldn't be a problem with Windows 11 anymore? AFAIK, the "evergreen" version of WebView2 is installed by default.
It might even be better than that. It sounds like Microsoft pushed WebView2 to (at least some) Windows 10 computers (N.B. Steam says 32% of users are still on Windows 10).
Of course, the docs still say:
> Even if your app uses the Evergreen distribution mode, we recommend that you distribute the WebView2 Runtime, to cover edge cases where the Runtime wasn't already installed.
https://learn.microsoft.com/en-us/microsoft-edge/webview2/co...
I wish we knew how prevalent that situation was. Not sure what the failure mode would be. But it sure would be nice to be able to assume that a modern WebView always exists on Windows! That certainly wasn't the case back when I made my decision circa 2022.
It was added in 22H2 Windows 10.
Out of curiosity how do you feel about wasm? Reason I am asking is I've been doing something like this but using Go and phaserjs. I've found the experience pretty awesome and my main target was the web so didn't think beyond that. My choice was based on comfort with Go and a big frustration with the react eco system (also low expertise there).
I started out really hyped for Deno, but I feel like in most cases Bun or WASM end up being better options. WASM is a great option because it has real security unlike Deno, it's a bit more involved to work with but that project setup cost gets amortized over the life of a big project, so the main downside is build chain speed, but Go is pretty good there.
Yeah build speed was actually quite good (I am sure rust-wasm has better over all performance but I am not that advanced yet). Two things I still am not able to get a feel for is:
a. load time - the Go wasm bundles can be large (TinyGo should help) but even with 25mb -> 5mb - that 5mb feels like big especially on a mobile download (i think?). But this is one off so I can suck it up.
b. This feels like a big one. I am only doing turn based games so may not be a big issue but it feels like the wasm <-> browser ser/deser can be a killer. Thank fully I am not doing high (or even medium) FPS games so will deal with that later :D
> b
I investigated wasm as a scripting engine (not a compile target, which is a orettt great use case for wasm) and the thing that killed it for me was how difficult it was to do zero-copy host-wasm memory sharing. Wasm is designed to be sandboxed and breaking those guarantees is hard. The problems I hit were: 1. Many languages (AssemblyScript, Grain) expect to own the entire linear memory, so even with WASM shared memory, it isn’t safe to actually use it unless you jump through hoops (eg use AssemblyScript GC functions to allocate and pin memory for host use), 2. WASM multi memory promises to solve this by letting you attach additional separate linear memories but neither AssemblyScript nor Grain support it. Additionally the wasmer runtime doesn’t yet support it.
I didn’t investigate whether Rust or Emscripten had either of these issues (I assume not), but they felt like a poor choice for “scripting”. I also didn’t investigate using V8 or other JavaScript engines to run wasm.
I guess the performance depends on how much you have to serialise. The ideal is to work in SharedArrayBuffers directly on linear structures of primitives and avoiding serialisation altogether. I did this for a (JavaScript) particle system where the simulation is in a web worker, that way you can achieve zero copy and it’s fast. But yeah once you have to cross the boundary and convert those or copy data, performance is hurt quite a bit…
Pardon the delay. Love this analysis. I think you were the person who's particle system post that inspired me to give wasm a deeper look (as I was saying mine is just turn based games so not exactly a demanding workload).
My thought was - can I take a language that I am comfortable with and is reasonable fast (both to develop and from perf persepective) and use that as my "logic layer". C and Rust would also have been great but for me C's memory management (Id be lying if I said I am comfortable after being away for over a decade) and battery-light standard library (again not sure what changed in last 10+ years) kept me at Go (Rust learning curve I did not even want to think about).
Back to the performance penalties - I structured it so that payloads are small and all state is kept on the wasm side with just batched messages to update view state. If I ever need to do do high FPS things il have to dig more into SharedArrayBuffers (but felt this was pain to get working). But then Id have reimplement a lot of the libs like phaserjs etc?
I don't think I posted about my particle system, so I don't think I'm the same person.
> But then Id have reimplement a lot of the libs like phaserjs etc?
The way I see it is that you either:
1. Do everything in WASM, using your languages native libraries (eg Emscripten supports SDL and WebGL, for example -- I hear newest wasm version also makes more directly available from browser WASM)
2. Use WASM to offload certain workfloads or simulation, and send data to Javascript and do all rendering in Javascript (using three.js, PIXI.js, or WebGL directly).
If using 2, you either send updates (I made a little toy test engine where I wrote messages to a SharedArrayBuffer that the JS side could read), or you operate directly on primitives in a SharedArrayBuffer (fastest since there's no serialisation needed, but harder to do).
Note for my particle system, I used PIXI.js to render and the webworker to simulate. I had a read index and a write index and the simulation would basically read the particle attributes from the read index and write them to the write index. The read index would be incremented for each particle and the write index only for live particles, meaning that as particles died it auto compacted:
let read_index = 0
let write_index = 0
let numParticles = liveParticles
const view = new DataView(sharedBuffer)
do {
const x = view.getFloat32(read_index + 0)
const y = view.getFloat32(read_index + 4)
const pos = update(x, y) // whatever your update logic actually is
const stillAlive = // ...
if (stillAlive) {
view.setFloat32(write_index + 0, pos.x)
view.setFloat32(write_index + 4, pos.y)
// only advance for live particles
write_index += SIZE_OF_PARTICLE_IN_BYTES
}
read_index += SIZE_OF_PARTICLE_IN_BYTES
} while (--numParticles > 0)
Interesting. Aere you using Ebiten for wasm?
Dang I am not sure why I was downvoted. But to your question I just used a basic MVP pattern where the Go side was pushed events from the browser and the game lib did the validation and called back methods on the browser to update the view state. So the browser side was very stateless for me. This made my testing a lot easier.
MicrosoftEdgeWebview2Setup.exe /silent /install
I'm assume (wrongly?) that installing this dependency is managed by Steam before the first run, not up to them.
One can opt in to the common redistributables (which usually makes sense if the thing you're looking for is covered) or decide to package custom steps into InstallScript files https://partner.steamgames.com/doc/sdk/installscripts. In either approach, Steam will automatically manage the runtime dependency installation for the user before the "Play" button appears.
Thanks for the info. Looks like they're using /silent right there in the example
"Steam customers love a quick and silent install. Add silent or quiet parameters to all run process commands and only add what you absolutely need for the game."
Is there really no way to get around the webview2 installer? Why not package it in your app bundle somehow instead of installing it as an external dependency?
> Is there really no way to get around the webview2 installer?
WebView2 supports both the auto-updating "Evergreen" version and a fixed version[1]:
In the Fixed Version distribution mode, you control the timing of updates to the WebView2 Runtime for your app. You download a specific version of the WebView2 Runtime and then package it with your WebView2 app. The WebView2 Runtime on the client isn't automatically updated.
[1]: https://learn.microsoft.com/en-us/microsoft-edge/webview2/co...
For me personally, I was trying to avoid bundling an entire browser runtime, so I viewed that approach (bundling WebView2's runtime instead of downloading on demand, only if needed) as no better than using Electron. At the time, that also wouldn't have solved my "Linux support" problem, but the blog post author is using webivew (which uses WebKitGTK on Linux), so that might not be relevant to them either. At which point I have nothing relevant to say!
I made an attempt at using WebKitGTK on Linux to build a WebGL game a couple of years ago. I was basing it on some existing code that I had already done a ton of work with to optimize and make cross-browser compatible. Had basically 99% feature parity between Chrome and Firefox.
Lack of standards support in WebKit made it painful to use and even meant losing major features like VR support. WebKit and WebKitGTK were both extremely unstable in their own ways. And I never could figure out a decent debugging scenario setup.
Hah that is so unfortunate when it’s so much nicer not to be using electron.
omg, not the electron, please! How about NW.js?
> But the fast workflow enables me to focus on the insanity that is the foolish endeavor of simulating the world, instead of getting sidetracked on making 3D and UI actually work in Go, or intoxicating my brain with Unity
I'm glad the author found something that works for them. That said, if the author's goal was to publish a game with intention of turning a profit, this attitude can be very counterproductive. It does work out really well in some cases, but more often than not it results in failure. The distribution looks like a bathtub curve - either your concept is so simple that a DIY thing can work (Minecraft) or you have the other thing (Elden Ring).
The most challenging parts of game dev happen in places like photoshop, blender, audacity and blank sheet of paper. Turning the art integration tool into your primary obsession is a fantastic way to slide on all of these other value drivers. For example, populating a game with premade assets from the store is no longer a viable commercial solution when your audience has seen hundreds of prior arrangements of the same.
If the game is a hobby or other not-for-profit venture, then all of the advice in this article is fantastic. I started my game dev journey doing everything in the web as well. It is still a very compelling platform target. The thing that really gets me thinking is that despite my ability to create flawless webGL builds out of unity is the fact that I don't bother anymore. The need kind of went away once it became clear that layers like Proton on Linux would actually cover my ass.
It reminds me of the idea behind Dwarf Fortress, which has been a sleeper hit for 20 years before one of the creators needed money for a cancer treatment; their Steam release earned them a good chunk of money. But for 20 years, it was a not-for-profit labour of love.
> For example, populating a game with premade assets from the store is no longer a viable commercial solution when your audience has seen hundreds of prior arrangements of the same.
Focusing purely on profits (as your comment does), is this really true? Production costs seems really low for those sort of games, and I see countless of them on the Playstation Store even, which does have some barrier to entry, so someone must find it profitable enough to continue churning out those sort of slop games.
But the author of this post seems to not do it for the profits, they have other goals in mind, so not sure it really matters in the end.
> If the game is a hobby or other not-for-profit venture, then all of the advice in this article is fantastic
Good job author for creating a fantastic blog post, I agree with parent :)
This is cool but I don’t understand why they didn’t choose to make it a local first web app since nothing about it seems to require unrestricted local access.
He mentions multip long term iirc
Also possible from a browser with WebRTC:
I don't understand how Deno is the game engine here, isn't it just the runtime for their chosen programming language? Is the CLR the "game engine" for games written in C#?
Anyway, this seems like a fun project and a neat use of Deno. I didn't know about the compile feature.
That was my first objection.
My second objection is that when I see a title of the form "using X as Y" (especially here, where the audience is technical) I expect the article content to be primarily about how X is useful for Y, and about the specific actions taken to make it fit for purpose. But this one seems to be largely about the consideration and rejection of other tools, and then the rest is basically just celebrating the experience of having made it work.
The main thing I learned about the game, outside of the screenshots and basic description, is that it uses a client-server model. Even though there's no clear reason why that would be necessary or even helpful beyond "it's written in TypeScript and that's what TypeScript devs are accustomed to". Certainly I can hardly fathom that any original implementation of SimCity too such an approach.
Not the same but there's this https://github.com/kmamal/gpu
It's SDL + WebGPU + Node. It doesn't give you a webview. It gives you (windows, input, audio, joypads) via SDL and graphics via WebGPU. I'd guess you can run three.js on it.
It's not looking super loved though but it does show a simple idea. Glue SDL and WebGPU (via dawn or wgpu) to pretty much any language and you get an environment to make portable apps.
> I'd guess you can run three.js on it.
I'm a bit out of the loop with three.js. How far along is their WebGPU renderer? Is it close to feature parity with the WebGL renderer?
[dead]
>Once I got into the new development workflow it was clear to me this was a huge win: I can develop using vscode with the Deno extension so the server-portion of the game runs with a full debugger, and with Vite I have a live-updating view of the game right next to my vscode window. Since the game is stateful on every tick I can live reload portions of the code without restarting my current game. Watching your changes go live as you are playtesting is such a heartwarming feeling could not give up now that I’ve tasted it.
IMO This is the key part of the article. Having live reload available shortened the feedback loop drastically.
It makes an even bigger difference for game development than it does for web stuff, due to longer compile times. I hope it becomes commonplace for more more free game engines.
I would rather use the user's installed browser, using Chrome Firefox, Safari as the game engine.
Bun + WebView + WebGPU is my new experiment. Deno also has bindings for glfw but I couldn’t get it to play nice with WebGPU or OpenGL beyond 3.2 profile.
As someone who got into programming because of games, wrote a few game engines, released a few - the concept of being able to use webdev tech (beyond UI stuff) for the core game graphics is just unbelievable.
Obviously you won’t get every ounce of juice from the machine but a lot of games don’t require that AAA touch. I’m glad to see the author’s on the same tract as me. WebGPU is so awesome. My biggest issue with this whole approach is that is super trivial to spit out the gltf models that anyone can use your assets.
Trying to work some old school pkg logic into the mix doesn’t really help either. Barring writing my own binary format, I’d love to see a way to make gltf models secure. Allowable from your site but not loadable from elsewhere or something like that. DRM for the art assets.
Fun game. Great work. I think schools are billed twice, once when you build and then again at the end of the month. Also there may be a bug with "lowest rent". It never seems to change and is higher than the "median rent".
Would also like to see more infrastructure like water and electricity. Any plans to open source parts of this?
Occasionally I’ve been working on this: https://github.com/rune-runtime/rune
The concept is to provide a WASM runtime for games with all the functionality you’d need. Graphics, audio, storage, input, UI, etc.
It’s made in Rust and doesn’t use a browser engine at all.
Haven’t touched it in a little while but the concept is still sound. It’s all the benefits that a mature engine would give you, without the engine. Eventually there would be a package manager where you would be able to find engines built for this runtime.
Upvote for making a great city planning game. This could teach the young generation the importance of good city planning for the economy, the environment and the well-being of people. The architectural uprising is just as much about city planning as beautiful architecture. Human friendly towns is good for business, saves the municipalities money and increases quality of life. Ideally people should be paid to live in cities. Disclaimer, I am the chairman of the Norwegian architectural uprising.
> teach the young generation
Looking at the political situation around the world, I think learning should not stop at a certain age. I'm pretty sure even the "older" generation can learn from this. People that grew up with SimCity are now in their forties and fifties, and some never quit gaming at all.
> Ideally people should be paid to live in cities.
Just make it actually cheaper than the suburbs and you'll have more people.
...who in turn will create demand driving prices up.
I'm 100% with you on this, as I spent close to an hour in traffic yesterday driving into the city during the afternoon rush hour, but transport is so much cheaper than real estate, that plenty of people are actually stuck outside big cities.
This game is to Sim City what My Summer Car is to Need For Speed. That's delightful!
Pretty cool! While I was at Recurse I took a stab at building a library like webview client mentioned in the post. https://github.com/zephraph/webview. Deno was my first target. I really enjoy deno's tooling overall, it's nice to be able to just import a server script as a URL and limit its permissions.
I'm currently making a tycoon game with React, it's not bad for making some games. I use setInterval for a simple game loop along with a zustand store for the game logic. I'm keeping the game logic and state client-side for now, but I might move it over to a server in the future.
Just a note for those planning to make a simple game or animation in JavaScript: in most cases it's preferrable to use `requestAnimationFrame` instead of `setInterval` or `setTimeout`.
[dead]
It would be great to see a business model behind it too. You had to manufacture all the products in a factory and every product would be breaker down to the very basics. This was my idea for ages but never started to build it...
I saw Dino, which is a web technology, but I was very saddened that after trying to click components in every screenshot, non of them were web based and just screenshots :frowny-face:
Cool article and game! I've been using Tauri for my three-js game so far and it's been great. Glad that there are other good options outside of Electron
Why not make this a web/browser game?
I don't feel like the author explained why such focus on being a downloadable game. Just nostalgia or because they want it included in Steam? With a web ui, why not make this a web game?
I absolutely loved the original SimCity and SC2000. The focus on creation, management, and simulation was always more fun to me than the graphics.
This game looks like so much fun as well and eager to give it a try.
I think that Godot engine would be perfect for this project. Can produce a single executable, super easy 3D, very lightweight, and very extensible. No webview dependencies, 4.4 still supports windows 7.
I don't get why one wouldn't just use webworkers to run the simulation instead, thus making the game fully executable in a web browser.
If deno has some perks during development, there must be a way to replace websocket with some other transport that works with webworkers for "production" builds.
> Is it too simple? Maybe. But Cities Skylines is made using Unity and can make your laptop so hot that doubles as heating for the winter.
How does Microlandia fare against cities skylines? I have played neither, but I’m curious about performance comparisons between fully web sim game against unity one.
Commercial, and pretty good game, CrossCode, was coded in "HTML5", more precisely - JavaScript. And new game from same developers seems to be using same technologies, probably more advanced, as it looks amazing, with some 3D-ish effects.
The author is so close to using Tauri that he’s starting to taste metal.
awesome! I have wanted to do something like this since the deno compile feature came out - great to see someone pulled it off, and last i checked the binaries were significantly less bulky than electron.
Crafted by Rajat
Source Code