New Web Platform

Notes from @AristurtleDev:

This issue is to track work for an official MonoGame.Web paltform.

The main goal is to get a MonoGame game running in the browser. This means developers will be using the same existing MonoGame/XNA APIs they are already familiar with. Anything that is browser specific would stay behind the platform layer instead of becoming something you have to design the game around.

This is not intended to replace KNI and the work that @nkast has done there. KNI does a lot more than provide a path to run MonoGame/XNA project in a browser. However, KNI uses Blazor as a bootstrap for the web host, which is different from the approach we would like to take here, which will be explained below.

Where This Is Going

Before we could start on a web platform, we first needed to implement a new native OpenGL renderer, which is being referenced as the DesktopGL4 platform. Completing that gives us a much better foundation for the web than trying to build on top of the existing managed DesktopGL platform and renderer. On of the things I wanted to avoid was ending up with a separate "web version" of MonoGame that has its own application model. Because developers should expect to be writing a MonoGame game, not adopting a browser specific framework that MonoGame fits inside, we need the browser host to remain as small as reasonably possible.

This is why the web platform work is following the shared native renderer/runtime direction rather than designing around a browser UI framework. Additionally, this means the first version of this is planned to target WebGL2. We evaluated between WebGL2 and WebGPU and ultimately decided that WebGL2 would be the most practical target at this time. It has better browser support as of today, and it also maps naturally onto the native OpenGL renderer work already being done. The priority for our first web platform is compatibility and getting existing MonoGame games running correctly in the browser rather than picking the newest graphics API just because it's newer. WebGPU is something we can look at later as browser support increases, and the rest of the native work here matures, but it is intentionally not in scope for this first implementation.

Additionally, the validation work being done right now is using net8.0 and browser-wasm. This should not be read as the final browser platform being locked to .NET 8. We will keep evaluating .NET WebAssembly improvements as the platform matures.

What Does "build for the web" Look Like?

Right now, I do not think we are far enough along to say it will be as simple as swapping a NuGet package and hitting build. That is the experience we are aiming for, but there are still decisions to make around the final project structure, templates, packaging, and how everything is hosted.

Ideally, targeting the web should just feel the same as just targeting another MonoGame platform. It should not feel like you have to port your game to another framework; existing projects should need as little game specific code changes as we can reasonably manage within the limitations of running in a browser.

---

I'll use this issue to keep track of work. Questions and use cases from the community are welcomed, especially while it is still early enough to help shape what the final platform looks like.

---

Unsupported

While working through the web platform, there are some things that just cannot be supported at the moment but can be in the future. Those are tracked here below

• Gamepad Vibration/Rumble: We are currently using SDL2 + Emscripten for web, which does not provide an API that supports Gamepad vibration. This is implemented in SDL3, but until we can update all platforms to SDL3, this will have to remain unsupported
• Mouse XButton: SDL2 + Emscripten currently only exposes a switch statement check for mouse left, middle, and right clicks. The switch cases do not perform the checks for XButton1 or XButton2. These are implemented in SDL3, but until we can update all platforms to SDl3, this will have to remain unsupported.
• Accelerometer (Mobile): Both iOS and Android require a permission check be done by the browser where the user explicitly grants permission for the page to read the accelerometer data. This cannot be done from a trigger within the game code, it must be done from a DOM element on the page. Due to this, at this time, accelerometer data for mobile is not supported

---