Discover the potential of WebGL with the infinite, procedurally-generated scenery of this casual driving game.
Slow Roads is a casual driving game with an emphasis on endlessly procedurally generated scenery, allhosted in the browser as a WebGL application. For many, such an intensiveexperience might seem out of place in the limited context of the browser—and indeed, redressing that attitude has been one of mygoals with this project. In this article I'll be breaking down some of the techniques I used to navigate the performance hurdle inmy mission to highlight the oft-overlooked potential of 3D in the web.
3D development in the browser
After releasing Slow Roads, I saw a recurring comment in the feedback: "I didn't know this was possible in the browser". Ifyou share this sentiment, you're certainly not a minority; according to the 2022 State of JSsurvey, some 80% of developers have yet to experiment with WebGL. To me, it feels something of a shame that so much potentialmight be missed, especially when it comes to browser-based gaming. With Slow Roads I hope to bring WebGL further into the limelight,and perhaps reduce the number of developers who balk at the phrase "high-performance JavaScript game engine".
WebGL may seem mysterious and complex for many, but in recent years its development ecosystems have greatly matured into highlycapable and convenient tools and libraries. It's now easier than ever for front-end developers to incorporate 3D UX into theirwork, even without prior experience in computer graphics. Three.js, the leading WebGL library, servesas the foundation for many expansions, including react-three-fiber which brings 3D components into the React framework. Thereare now also comprehensive web-based game editors such as Babylon.js or PlayCanvaswhich offer a familiar interface and integrated toolchains.
Despite the remarkable utility of these libraries, however, ambitious projects are eventually bound by technical limitations. Skepticsto the idea of browser-based gaming might highlight that JavaScript is single-threaded and resource-constrained. But navigatingthese limitations unlocks the hidden value: no other platform offers the same instant accessibility and mass compatibilityenabled by the browser. Users on any browser-capable system can begin playing in one click, with no need to install applicationsand no need to sign in to services. Not to mention that developers enjoy the elegant convenience of having robust front-end frameworksavailable for building UI, or handling networking for multiplayer modes. These values, in my opinion, are what make the browser such anexcellent platform for both players and developers alike—and, as demonstrated by Slow Roads, the technical limitations might often bereducible to a design problem.
Achieving smooth performance in Slow Roads
Since the core elements of Slow Roads involve high-speed motion and expensive scenery generation, the need for smooth performanceunderlined my every design decision. My main strategy was to start with a pared-down gameplay design that allowed for contextualshort-cuts to be taken within the engine's architecture. On the downside this means trading off some nice-to-have features in thepursuit of minimalism, but results in a bespoke, hyper-optimized system that plays nicely across different browsers and devices.
Here follows a breakdown of the key components that keep Slow Roads lean.
Shaping the environment engine around the gameplay
As the key component of the game, the environment generation engine is unavoidably expensive, justifiably taking the greatestproportion of the budgets for memory and compute. The trick used here is in scheduling and distributing the heavy computation overa period of time, so as not to interrupt the framerate with performance spikes.
The environment is composed of tiles of geometry, differing in size and resolution (categorized as "levels of detail" or LoDs)depending on how close they will appear to the camera. In typical games with a free-roaming camera, different LoDs must be constantlyloaded and unloaded to detail the player's surroundings wherever they may choose to go. This can be an expensive and wasteful operation,especially when the environment itself is dynamically generated. Fortunately, this convention can be entirely subverted in Slow Roadsthanks to the contextual expectation that the user should stay on the road. Instead, high-detail geometry can be reserved for the narrowcorridor directly flanking the route.
The midline of the road itself is generated far ahead of the player's arrival, allowing for accurate prediction of exactlywhen and where the environment detail will be needed. The result is a lean system that can proactively schedule expensive work,generating just the minimum needed at each point in time, and with no wasted effort on details that won't be seen. This techniqueis only possible because the road is a single, non-branching path—a good example of making gameplay trade-offs that accommodatearchitectural short-cuts.
Being picky with the laws of physics
Second to the computational demand of the environment engine is the physics simulation. Slow Roads uses a custom, minimal physics engine which takes every short-cut available.
The major saving here is to avoid simulating too many objects in the first place—leaning into the minimal, zen context bydiscounting things like dynamic collisions and destructible objects. The assumption that the vehicle will stay on the roadmeans that collisions with off-road objects can reasonably be ignored. Additionally, the encoding of the road as a sparsemidline enables elegant tricks for fast collision detection with the road surface and guard rails, all based on a distancecheck to the road's center. Off-road driving then becomes more expensive, but this is another example of a fair trade-offsuited to the context of the gameplay.
Managing the memory footprint
As another browser-restrained resource, it's important to manage memory with care—despite the fact JavaScript isgarbage-collected. It can be easy to overlook, but declaring even small amounts of new memory within a game loop can snowballinto significant issues when running at 60Hz. Besides eating up the user's resources in a context where they're likely multitasking,large garbage collections can take several frames to complete, causing noticeable stutters. To avoid this, loop memory can bepre-allocated in class variables at initialisation and recycled in each frame.
It's also highly important that heavier data structures, such as geometries and their associated data buffers, are managed economically. In an infinitely-generated game like Slow Roads, most of the geometry exists on a sort of treadmill - once an old piece falls behind into the distance, its data structures can be stored and recycled again for an upcoming piece of the world, a design pattern known as object pooling.
These practices help to prioritize lean execution, with the sacrifice of some code simplicity. In high-performance contexts it'simportant to be mindful of how convenience features sometimes borrow from the client for the benefit of the developer. For example, methodslike Object.keys() or Array.map() are incredibly handy, but it's easy to overlook that each creates a new array for their returnvalue. Understanding the inner workings of such black-boxes can help to tighten up your code and avoid sneaky performance hits.
Reducing load time with procedurally-generated assets
While runtime performance should be the primary concern for game developers, the usual axioms concerning initial web page load time stillhold true. Users may be more forgiving when knowingly accessing heavy content, but long load times can still be detrimental to the experience,if not user retention. Games often require large assets in the form of textures, sounds, and 3D models, and at a minimum these should be carefullycompressed wherever detail can be spared.
Alternatively, procedurally generating assets on the client can avoid lengthy transfers in the first place. This is a huge benefit for users on slow connections,and gives the developer more direct control over how their game is constituted—not just for the initial loading step, but also when it comes to adapting levelsof details for different quality settings.
Most of the geometry in Slow Roads is procedurally generated and simplistic, with custom shaders combining multiple textures to bring the detail.The drawback is that these textures can be heavy assets, though there are further opportunities for savings here, with methods such as stochastictexturing able to achieve greater detail from small source textures. And at an extreme level, it's also possible to generate textures entirely on the client with tools such as texgen.js. The same is even true for audio, with the Web Audio API allowing for sound generation with audio nodes.
With the benefit of procedural assets, generating the initial environment takes just 3.2 seconds on average. To best take advantage ofthe small up-front download size, a simple splash screen greets new visitors and postpones the expensive scene initialisation untilafter an affirmative button press. This also acts as a convenient buffer for bounced sessions, minimizing wasted transfer of dynamically-loadedassets.
Taking an agile approach to late optimization
I've always considered the codebase for Slow Roads to be experimental, and as such have taken a fiercely agile approach todevelopment. When working with a complex and rapidly-evolving system architecture, it can be difficult to predict where theimportant bottlenecks may occur. The focus should be on implementing the desired features quickly, rather than cleanly, andthen working backwards to optimize systems where it really counts. The performance profiler in Chrome DevTools is invaluablefor this step, and has helped me to diagnose some major issues with earlier versions of the game. Your time as a developer isvaluable, so be sure you aren't spending time deliberating over problems that may prove insignificant or redundant.
Monitoring the user experience
While implementing all of these tricks, it's important to be sure the game performs as expected in the wild. Accommodatinga range of hardware capabilities is a staple aspect of any game development, but web games can target a much broader spectrumcomprising both top-end desktops and decade-old mobile devices at once. The simplest way to approach this is by offering settingsfor adapting the most likely bottlenecks in your codebase—for both GPU- and CPU-intensive tasks—as revealed by your profiler.
Profiling on your own machine can only cover so much, however, so it's valuable to close the feedback loop with your users insome way. For Slow Roads I run simple analytics which report on performance along with contextual factors such as screen resolution.These analytics are sent to a basic Node backend using socket.io, along with any written feedback the user submits via the in-gameform. In the early days, these analytics caught a lot of important issues that could be mitigated with simple changes to the UX,such as highlighting the settings menu when a consistently low FPS is detected, or warning that a user may need to enable hardwareacceleration if the performance is particularly poor.
The slow roads ahead
Even after taking all of these measures, there remains a significant portion of the player base that needs to play on lowersettings—primarily those using lightweight devices which lack a GPU. While the range of quality settings available leads to afairly even performance distribution, only 52% of players achieve above 55 FPS.
Fortunately, there are still many opportunities for making performance savings. Alongside adding further rendering tricksto reduce GPU demand, I hope to experiment with web workers in parallelising the environment generation in the near term,and may eventually see a need for incorporating WASM or WebGPU into the codebase. Any headroom I'm able to free up will allowfor richer and more diverse environments, which will be the enduring goal for the remainder of the project.
As hobby projects go, Slow Roads has been an overwhelmingly fulfilling way to demonstrate how surprisingly elaborate, performant,and popular browser games can be. If I've been successful in piquing your interest in WebGL, know that technologically SlowRoads is a fairly shallow example of its full capabilities. I strongly encourage readers to explore the Three.js showcase,and those interested in web game development in particular would be welcome to the community at webgamedev.com.
