Browser Capabilities Check

WebGPU is a graphics API that allows low-level access to hardware, comparable to Vulkan, DirectX 12, and Metal.

Game programmers may link directly against browser WebGPU implementations like Google Dawn or gfx-rs/wgpu to allow them to use all the same graphics developer tools that a native game developer has while working on their games and game engines.

WebGL 2 is a graphics API that follows the OpenGL ES 3 standard, loosely in line with OpenGL 4.1 or so.

WebGL 2 supports most features necessary to build rich 3D environments, and may serve as a reasonable fallback to WebGPU.

WebGL 1 is a graphics API that follows the OpenGL ES 2 standard, loosely in line with OpenGL 3.3 or so.

The vast majority of devices that support WebGL 1 now support WebGL 2, so WebGL 1 is mostly only useful as a legacy fallback API. It is missing many features useful in modern graphics programming, but can still be used to make great 3D games.

WebAssembly is a binary code format that offers a few really neat features:

• Efficient numeric formats (u32, i32, etc)
• Linear memory layout for cache-friendly code
• LLVM compile target, leveraging decades of low-level compiler optimizations

Web Workers are JavaScript files that execute in a thread separate from the main thread.

This device and browser supports up to 1 threads

Multithreading under the default WebWorker API requires asynchronous message passing, which is generally useless for traditional game programming.

Certain loading-screen operations can still be improved significantly (e.g. unpacking compressed asset files), but run-time CPU utilization is difficult under that model.

SharedArrayBuffer allows JavaScript (and by extension WebAssembly) to use a more traditional memory-shared model.

Unfortunately, two nasty security bugs caused SharedArrayBuffer to be globally withdrawn, and only slowly re-introduced under certain circumstances.

Support for traditional pthread-style threading in a WASM application.

This can be accomplished via WebWorkers and SharedArrayBuffers, or natively as a WebAssembly feature.

Widely available two-directional networking protocol based on upgraded HTTP connections.

Technically allows for multi-player games in the browser, but is subject to frequent lag spikes and less optimal round-trip times due to being built on top of TCP.

WebRTC allows for real-time communication in the browser - typically voice and video calls.

WebRTC is built on the SCTP protocol, which can be configured to behave like UDP (unordered, unreliable) in order to have low-latency networking that isn't subject to the lag spikes of WebSockets.

Unfortunately, WebRTC is built to be a strongly peer-to-peer protocol, and configuring it for traditional game client/server communication is a difficult engineering problem.

WebRTC may also support binary streams without video/audio encoding, which can be used for arbitrary game data.

Many game programmers have suggested WebRTC as a potential mechanism for browser game networking, but very few (if any!) have actually succeeded (as of 2023).

WebAudio allows for advanced audio programming - 3D spatial audio, Doppler effects, in-game processing of audio (e.g. gain nodes)

Audio programming is a largely solved problem in both game development and web development, existing game audio solutions work well on the web.

Browsers generally don't expose access to arbitrary USB devices, but game pads (console controllers, joysticks, etc.) are common enough to have a special web API.

Games will often lock the mouse to the screen, especially for first-person perspective with mouse movement.

Web applications have a few caveats in order to use it, but support is generally good enough for game programmers to work with.

Web applications may choose to make a video or game surface fullscreen at the user's request.