Host your Quest games anywhere

The past and future of running Quest text adventure games on websites

A server in my kitchen

Quest was one of the first text adventure systems to let you play games in a web browser, back in 2007. Prior to this, the only way to play a Quest game was to download the desktop version on a Windows PC.

I’d forgotten how novel that was at the time - Parchment, an online player initially for Inform games but since expanded to other systems, came out in 2008, so before then players of games made with other systems also had to download some interpreter software.

That first version of the Quest online player was pretty clunky. The server was an old computer whirring away in my kitchen, where the noise wouldn’t disturb me watching TV or sleeping. This ran some server software I’d created in VB6. Quest was a VB6 application at the time, and my server version of it removed the graphical front-end, and accepted socket connections which then spawned a separate process for each game. In the browser, some basic HTML and JavaScript used a little Flash app to create a direct socket connection, as there was no way of doing anything like that in JavaScript at the time.

A dynamic DNS service then routed players’ connections to my home server, and they could play games that had been uploaded to the Quest Games Archive (the precursor to textadventures.co.uk) in their browser.

It was a pile of hacks, but it worked, and it enabled people to play Quest games in their web browsers without having to download or install any software.

A proper application

Over time, things got more robust. In 2009, the old PC was replaced by a VPS, so the online player was no longer reliant on my home internet connection. In 2011, the big Quest 5.0 rewrite brought along the first version of WebPlayer - a “proper” ASP.NET application.

This ticked along for a long time, though occasionally it would get overloaded, or need rebooting for updates etc. This was unfortunate because it meant that sometimes players wouldn’t be able to connect, or they’d get kicked out mid-game, or it could just generally be slow. It was also expensive to run, because it relied on the Windows-only .NET Framework, which meant paying the extra cost of a Windows server.

That finally changed in 2025, with the work for Quest Viva. This migrated the Quest code to the latest cross-platform .NET version. I rewrote WebPlayer using Blazor, which I was then able to deploy to a much cheaper Linux VPS. This has proved to be much faster and more reliable.

The problem with threads

But that was always a stepping stone, because the real prize was to be able to take advantage of the recent .NET support for compiling to WASM. This would mean games wouldn’t need a server at all.

It wasn’t quite as simple as “just compile to WASM” though, because of one big problem - threading.

Although .NET WASM does now have some support for threads, there are a bunch of caveats. Most significantly for the Quest code, you can’t pause a thread. Quest relied on this to suspend script execution when waiting for user input, for example.

Thread pausing was always a not-great aspect of how Quest worked. It’s generally not recommended for software that runs on a server (there’s an overhead to spinning up threads, and you can encounter limits to how many you can create). Back in 2011 when I started work on converting Quest games to JavaScript so they could run as phone apps, thread pausing also revealed itself as a problem as there was no way to do that in JavaScript. It meant deprecating a bunch of “blocking” Quest scripts, and replacing them with “callback” versions instead - we couldn’t pause execution, so we needed to have scripts finish running, and have authors pass in a new script as a parameter which would then run after the user had given their input.

The proper way to handle pausing for user input is async/await - I’ll forgive myself for not implementing this in WebPlayer in 2011, as it didn’t exist in C# until 2012, nor JavaScript until 2017. This gives us the ability to effectively do the same thing as “suspend script execution”, without needing to block a thread. It lets the Quest script runner code look like it pauses, but underneath the compiler does the hard work of turning that into the necessary callbacks.

That required a bunch of refactoring of the Quest code, and there was a knock-on effect - if a function like GetInput() needs to await some user input, then our expression engine needs to be able to handle async functions. Quest 5 used an open source library called Flee to parse expressions, but this doesn’t support async/await. So there was some prerequisite work to switch to NCalc instead, which led to a bunch of work to customise its expression language to be 100% compatible with Flee expressions. That required plugging in a custom NCalc parser and adding a huge number of unit tests - definitely something that Quest was lacking before.

The NCalc work and the async/await work were all merged to Quest Viva’s main branch in recent weeks, and the current server-based WebPlayer is now using them. I’ve been keeping an eye on the error logs, and I’ve fixed a few small issues - I can now feel pretty confident that things are working correctly with the new code, but there’s always the chance that something is broken, so let me know if a game isn’t working correctly.

WASM

With that work done, I’ve been able to compile Quest’s C# back-end to WASM, and we have a new WasmPlayer project, which sits alongside the existing WebPlayer.

WasmPlayer is simply a bunch of static files that a web browser can open. By doing so, it can run any Quest game locally - no server connection needed.

It finally means any Quest game for any version of Quest (even right back to Quest 1.0 from 1998) can be hosted on any website, and be played by anybody in a web browser.

WebPlayer will stick around in the Quest Viva code - it’s a little easier for local development, and if you want to host a Quest game on a server without giving players access to the game file itself, this will be a good option for you (some people have used Quest games as part of treasure hunts for example, where you don’t want players being able to inspect the game code).

But for most people, and for textadventures.co.uk itself, WasmPlayer is the way forward. It means I won’t have to run a game server at all - I can host WasmPlayer simply in Cloudflare Pages or on any other static host.

It also gives much more flexibility to game authors. Up until now, the simplest way to give other people access to your game was to upload it to my website - but now you can host it yourself. Cloudflare Pages, Netlify, itch.io - you can host a playable Quest game anywhere now. No servers to maintain, no disconnections to worry about, no slow-downs under load - once the browser has downloaded the game, it can run it entirely offline, and players can save and load their progress on their own devices.

Try it out

For more information, see the announcement post. For self-hosting instructions, see the documentation.