cssQuake: Bringing the Classic 3D Shooter to the Browser

cssQuake is a browser-based port of the original Quake shareware version powered by the PolyCSS renderer. It offers full gameplay of the first episode along with multiplayer capabilities and extensive debug tools. The project is an open-source tribute to id Software's classic FPS, currently in active development at version 0.223.

Key Points

• Uses the PolyCSS renderer to display Quake assets and gameplay within a web browser environment.
• Includes the complete first episode of the Quake shareware version, from the Slipgate Complex to Ziggurat Vertigo.
• Features integrated multiplayer support with customizable frag limits, time limits, and player counts.
• Provides extensive debug and gameplay toggles, including options to disable damage, movement, or attacks for testing purposes.
• The project is open-source and hosted on GitHub, leveraging assets from the original id Software release.

Sentiment

The overall sentiment is strongly positive and amused, with Hacker News broadly agreeing that cssQuake is an impressive technical stunt. The criticism is mostly technical qualification rather than rejection: commenters debate performance, browser behavior, and whether CSS is the right abstraction, but usually while still acknowledging the project as clever and entertaining.

In Agreement

• The project is an impressive constraint-based achievement because it makes a recognizable, playable Quake experience work through browser layout and transforms rather than a normal graphics pipeline.
• Performance issues are understandable because CSS is not designed or optimized as a real-time game renderer, so the unusual implementation is part of the point.
• The demo succeeds as a nostalgia trigger, reminding commenters how enduring Quake is and how much engineering went into the original engine.
• Browser and platform differences matter: several users report smooth results in Firefox or Chrome, suggesting some complaints are tied to particular browser engines rather than the project as a whole.
• Using JavaScript for game logic and CSS for rendering is still interesting, because the notable part is avoiding canvas or WebGL for the visual output.

Opposed

• Some commenters argue that the experience feels slower than the original game did on old hardware, which makes the project feel more like a curiosity than a practical port.
• A few users see CSS as fundamentally the wrong tool for this job and question whether pushing it this far says anything useful about web technology.
• Several practical complaints appear around controls, collision, menu behavior, sound discovery, and browser-specific rendering glitches.
• Some skepticism comes from the wording of CSS-only implications, since JavaScript is still needed for game logic and DOM manipulation.