The license makes this a local study project
Spiderbench's LICENSE permits personal, non-commercial local evaluation while restricting redistribution and use in distributed works. Read that before planning a fork for your own game or a public playable mirror. The repository is visible on GitHub, but its code and assets do not carry the reuse permissions a developer normally expects from open-source software. Even the original city components fall under the project's stated restrictions unless you obtain permission.
The 152.4 MB measured checkout is a substantial example to study. Its README describes web-swinging, wall-running, perching, and diving in a procedural Manhattan-style city, with a Three.js rendering pipeline. The author says Claude produced the code and assets under human direction using feedback and reference images. That makes it interesting as an example of a development process. It does not establish how independently an agent could reproduce the result.
What happened when we ran it
Our sandbox installed Spiderbench commit 64d957f in 8 seconds and built it in another 8 seconds on October 14, 2026. Npm added 21 packages, using 60 MB on disk. The lab-node:22 container had 3 CPUs and 8 GB of RAM, ran without elevated privileges, and contained no secrets. Both repository steps completed successfully. The supplied results report no compiler or package-install failure.
Tests were skipped because there was no tests script or target. Our scan found 0 CI workflow files, no Dockerfile, and no tests directory. Npm audit reported 0 known vulnerabilities, including 0 critical, high, moderate, or low findings. Those results describe dependency and build checks. They give no measured frame rate, startup duration, traversal accuracy, or evidence that the game stays responsive during a long session.
The checkout contained 225 files and approximately 53,847 source lines. That gives a reader plenty of implementation to inspect beyond a short graphics example. The absence of an automated gameplay result matters, though: producing browser assets is an earlier milestone than checking how a character moves through a generated city. A developer evaluating the project should keep those outcomes separate rather than treat a passing build as a completed play session.
WebGL2 and the GPU recommendation shape the audience
The README requires Node.js 20.19 or newer on that line, or 22.12 or newer, and a WebGL2-capable browser. It recommends a discrete GPU. The documented rendering stack includes cascaded shadows, screen-space lighting effects, reflections, and temporal anti-aliasing. Those choices explain the interest for a graphics programmer, but they also make an ordinary package-build result a poor guide to how the game will feel on a modest laptop.
Our 8 GB container supplied no graphics benchmark. A suitable personal trial would check the intended browser and machine, then examine traversal and loading behavior with the effects enabled. Controls are available in the game through H, and the README documents a developer menu. That is enough to orient a reader who wants to evaluate the demonstration locally. It supplies no assurance about mobile controls or low-end graphics performance.
Loading feedback received a specific correction
Issue 3 reported a blank startup page while the city and player were being prepared. The associated closed PR 4 describes a loading screen with progress tied to initialization work and visible startup errors. That is a relevant piece of maintenance history because an empty canvas can leave users unsure whether the game has crashed. The issue concerns this game's boot path, rather than a similarly named library or external component.
The lab's 8-second build cannot verify that browser correction. The change description is upstream evidence, and the recorded sandbox steps stopped short of an interactive graphics check. I would inspect startup with a supported browser and confirm that an error is understandable when graphics initialization fails. A loading screen can make waiting legible, but it cannot establish acceptable rendering performance once the city becomes visible.
The activity is recent, and the checks are thin
GitHub recorded a push on October 2, 2026, with 514 stars and 2 open issues and PRs. The listing includes a request for GitHub Actions checks. No latest published release was available. Taken together, the recent push and September issue discussions show ongoing attention around a small project. The missing release tag alone would be a poor reason to call it abandoned, particularly when concrete startup work appears in the history.
Our scan's 0 CI workflows matches the concern raised by that request for automated checks. Another open PR makes security claims about NPC-data handling, but labels its suggestion unverified. That is insufficient evidence to report a confirmed exploitable vulnerability here. The narrower supported conclusion is that the demonstration has little visible automated assurance. Anyone studying it should distinguish working build machinery from verified runtime behavior and from claims made by an automated contributor.
Build your own game on a reusable foundation
The README explicitly frames Spiderbench as an unofficial fan demonstration and prohibits commercial use or redistribution. Three.js is the direct alternative when you want to create your own browser scene, while Babylon.js and Godot offer broader game-building routes. Those projects are foundations rather than equivalent web-swinging games. For Spiderbench itself, keep the goal small: run it privately, inspect how a particular movement or rendering effect is assembled, and leave its restricted assets out of your product.