ハクソク

世界を動かす技術を、日本語で。

Show HN: 安全なRustに移植されたQuake、ブラウザでプレイ可能

2026年10月9日原文(quake-srp.pages.dev)

概要

QUAKE·SRP は、 ゲームエンジン の一種であり、 ユーザーインターフェース が特徴 クリックやキー操作で 起動・メニュー表示 が可能 フルスクリーン や サウンド切替 などの設定項目 マウスキャプチャ や キー割り当て のサポート ソースコード や 解説 へのアクセスも提供

QUAKE·SRPの基本操作

  • QUAKE·SRP fetching engine ：QUAKE·SRPエンジンの読み込み開始
  • クリック または Enterキー ：ゲームのスタート
  • 任意のキー ：メニュー画面の表示
  • マウスクリック ：マウス操作のキャプチャ開始

設定項目

  • game fullscreen ：全画面モードへの切替
  • sound off ：サウンドのオン/オフ切替
  • keys ：キー割り当ての確認や変更
  • source ：ソースコードへのリンク
  • explainer ：操作説明やゲームの解説文書

ユーザーインターフェースの特徴

  • シンプルな操作性 を重視した設計
  • クリックやキー操作 のみで主要機能にアクセス可能
  • 初心者でも直感的に利用可能 なインターフェース

サポート機能

  • ゲーム進行中のフルスクリーン切替
  • サウンド設定の即時反映
  • キー設定やマウスキャプチャ による操作カスタマイズ
  • 公式ソースや解説文書 へのワンクリックアクセス

利用シーン

  • QUAKEシリーズ のファンによるプレイ体験
  • ゲームエンジンの学習や研究 用途
  • ユーザーインターフェース設計の参考資料

Hackerたちの意見

コードはここにあるよ - https://github.com/terrapapagalli1516/quake-srp （SRPは「スロップラストポート」の略だよ。）「巨人の肩の上に立つ」っていう表現がぴったりだと思う。ブラウザのレンダリング、WASM、Rust、LLMの交差点みたいなもんだね。俺にとっては、AIが何ができるかのデモというよりも、LLMが最後の瞬間に登場して勝利を収めるために、過去数十年の人間の努力が必要だったっていうのを見せるものだよ。確かにLLMがCからRustにポートしたけど、それがうまく機能するために必要なものを考えてみて。これは本当にすごいことで、AIだけでは成し遂げられなかったんだ。

└

Rustへのポートは余計だったかもね、Cから直接wasmに行けたはず。でもそうすると「Rust Rust Rust」って言えなくなるし…。

1996年にクエイクをプレイして、Netscape Navigator 2.0で新しいJavaScriptのマウスオーバー画像効果を試してた時に、こんな電話のウェブブラウザができるなんて想像もできなかったよ。

└

わぁ、それはかなり非現実的な感じだね。2001年からインターネットを使ってて、2006年から2008年にウェブ開発者になったんだけど（その時にJSを知った）、それでもこれには感心してるし、楽しいよ（特にコードが人間によって書かれてないってのが）。30年後にJSとQuakeが新しいものとしてここにあるのを見るのは、ちょっとクレイジーだね。

なんてこった、著者は「証明」[0]のビジュアルディフハーネスまで提供してくれた…それがオリジナルのゲームをピクセル単位で再現してるって。俺たちの新しいスーパーパワーの素晴らしいデモの上に、さらに素晴らしいトッピングが乗った感じだね。コンピュータに、俺たちがどうやってやるか説明できることをやらせるけど、自分では（多分）やる時間を取らないっていう。 [0] https://github.com/terrapapagalli1516/quake-srp/tree/main/or...

└

正直言って、これはLLMが登場する前から一般的に使われてた技術だと思ってたんだけど？自分でもかなり使ってるけど、Dolphinの広範なビジュアルCIシステムに触発されたんだよね。

└

そうだね、面白いね。これと同じことが、銀行のバックエンドとか、ウォール街の専用ソフトウェア、アマゾンの物流や配送システムに適用されるまで、どれくらいかかるんだろう？現代の人間社会にとって非常に重要なシステムを逆エンジニアリングして、スプーフィングする状況が数週間、数日、数時間で来るかもしれない気がする。

└

お二人が言ったことに付け加えますね。僕は実際のブラウザでライブサイトに対してピクセルチェックを行っていて、最初の頃はフルページのスクリーンショットをやめました。スクロールバーやレイジーロードされた画像、フォントのタイミングでピクセルが変わるのが毎回のように起こるからです。僕がやってるのは、小さな安定した領域を一つずつ、コンポーネントやフローごとに比較して、ピクセルごとに少しの許容範囲を設けることです。それに、ビジュアルチェックの前にDOMレベルのアサーションを置いておくので、何かが失敗した時には、二つの画像を比較する前に構造的に何が変わったかが分かります。ゲームのポートに関しては本当に難しいですね。レンダラーがピクセルを決めるので、テストが決めるわけじゃない。でも、領域のアイデアは応用できます。ビューポートを固定して、安定している部分だけを比較するんです。

└

ビジュアルディフハーネスは、多くのビジュアルバグを取り除くのに役立ったんじゃないかな。LLMにピクセルが完全に一致するまで続けるように指示すればいいんだ。

└

ピクセルデータを使うのは珍しいかもしれないけど、リプレイ機能のあるゲームをポートする人は、実装を比較するのに簡単な方法だと気づくはずだよ。

└

gbaevalからインスパイアを受けてるんじゃないかな。両方に「オラクル」や他の類似点があるし。 https://gbaeval.com/

└

この魔法のスーパーパワーがビジネスオーナーの手に渡ったら、どんな力になるか想像してみて…。

Hacker Newsで議論の続きを見る