Freedoom on AWS Lambda Web Functions

This describes running the 1993 Doom engine (doomgeneric) with the Freedoom data inside AWS Lambda Web Functions by compiling the C engine to a 2.7 MB WebAssembly module and loading it from Node.js. The engine is driven by the host: Node provides a virtual 320x200 pixel screen, pushes keyboard events into Doom’s input queue, and advances the clock one tic (1/35 s) at a time so the simulation is deterministic. The server renders frames and streams them as a single long binary HTTP response at about 17.5 fps; key presses are sent as small POSTs. Each game costs roughly 0.15 ms CPU per tic (~0.5% of a vCPU), so one execution environment can host many games. Sending only changed pixels reduces bandwidth (initially ~890 KB/s per player, reduced to ~500 KB/s by sending every second frame); compressed codecs saved another 30-40% but weren’t always browser-compatible.

Because Web Functions spread requests across environments with no session affinity, full memory snapshots are impractical, so state is rebuilt from a DynamoDB-backed input log. The table stores a lease (current owner and heartbeat), the input log, and an inbox for off-owner inputs. Handoffs use a transaction where the owner writes last inputs and the new environment replays the log - replay speed is about 30 ms per minute of play and handoffs occur in roughly 120 ms; owner failures are detected after 2.5 s, risking up to a half-second of input loss. Spectators are supported by replaying the same log. Practical notes: bundle the AWS SDK, use CloudFront with origin access control and IAM auth for custom domains, and deploy via the provided repo; the pattern generalizes to any deterministic app whose state can be rebuilt from an input log.