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.
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.
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.
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.
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.
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.
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.
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!
> 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.
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.
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.
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.
>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.
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.
Readit News
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!
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...
The sooner Tauri grows Electron/Chrome bundling capabilities, the better.
Chunky and predictable beats confusion, errors, and inconsistencies.
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.
https://ebitengine.org/en/documents/webassembly.html
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...
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.
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 :)
https://github.com/lesmana/webrtc-without-signaling-server
Anyway, this seems like a fun project and a neat use of Deno. I didn't know about the compile feature.
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.
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'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 Comment
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.
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.