A shared C# game in the browser

The Web Player executes shared C# gameplay through .NET WebAssembly. A JavaScript shell connects browser loading, input, audio and page lifecycle to the game. The current Arcade build also uses profile-guided ahead-of-time compilation for selected work.

The browser must manage memory, user activation and session transport while preserving the accepted game rules.

A shared game with browser-specific ownership

The desktop and browser projects share explicitly classified player sources. The engine and simulation libraries supply rules; browser adapters handle the canvas, user-activated audio, transport and resource preparation. WPF stays in the Windows editor.

The website admits an account to an available release, supplies its bounded bootstrap, and delivers content matching that release. The browser predicts play locally. The server independently advances the matching simulation from submitted input before accepting progress and completion. A client-provided checksum alone does not grant access or prove a win.

Why room loading needs its own design

Compressed image or sound bytes are only one part of memory use. Decoded textures, audio buffers, temporary decoding work and the WebAssembly heap also consume resources. A fast download is therefore not proof of safe memory use.

The current player bounds retained media, leases active/prepared rooms and retires unused room resources. Hash-checked encoded media can be reused while decoded resources remain tied to their owners. Story presentation has a separate bounded preparation path. Increasing a cache limit is a capacity decision that still requires measurement on the target browser.

Transitions coordinate prepared content and simulation boundaries. A connected room can slide when appropriate; repositioning and cutscene entry have their own visual treatment. The purpose is to preserve a coherent arrival while the correct room, assets and controls become active together.

A direct campaign start

The title defaults to Start Campaign. For a fresh attempt using the same release, the website can hand the new authorized session to the already mounted player after the old owner is drained. Prepared media is reused and the intro opens directly. A changed release must load its matching bootstrap. The absence of an intermediate loading pane does not remove the authorization or release checks.

There is no player-facing saved-game resume. Internal transport and verification records still exist because ordered input, retries and accepted completion need owners. Flight retry is part of the current session.

Honest limits

Compiled code and assets delivered to a browser remain accessible to that browser. Release checks and server verification protect access and accepted state; they do not make client code uncopyable. Browser memory, GPU/audio behavior, startup time and physical-controller behavior require separate evidence from a successful build.

Continue with release engineering, Arcade access, and the game platform.

Implementation evidence: TheGynaraLegend/src/Gynara.Browser, src/Gynara.Game/SharedPlayer.projitems, and DrakimaCore's src/DrakimaCore.Infrastructure/Arcade/PortableArcadeSessionVerifier.cs and PortableArcadeReleaseAdmission.cs.

Further reading: Maintained handbook chapter.