Story on kimoto

当時は合法なソフトウェアの開発

Mon, 01 Jan 0001 00:00:00 +0000

高校生の頃、当時はまだ合法だったソフトを作って、ネットで公開していた。いまの言葉で言えば、たぶん"作ってはいけない側"のものだ。でも当時は、法律がそこに追いついていなかっただけで、違法ではなかった。自分でも際どいものを作っている自覚はあったけれど、“ふつうの無害なソフト"を作っているつもりはなく、“いまはまだ合法なソフトウェア"を作っている、という感覚だった。

なんでそんなものを、高校生が一人で作れたのか。たぶん、当時の自分に「ライブラリを使ったら負け」という、妙に強い美学があったからだと思う。出来合いの関数を呼んで済ませるのは負け。仕様書を原典で読んで、一段下から自分で組んでこそ本物だ――という信条で、われながら頑固だった。

仕様を読んで、下から組む

その頃書いていたものは、たいてい生の Windows API と、プロトコルの仕様書だけでできていた。コンパイラこそ Visual C++ 6.0 だが、中身は実質 C++ ではなく、素の C だった。C++ の便利な機能に頼らないどころか、標準ライブラリのお世話にもほとんどならない。文字列を入れておくバッファすら、std::string のようなものは使わず、malloc で自分で確保して、自分で解放していた。本当に、ライブラリというものをほとんど使っていなかった。そういう小さなプログラムを九十本近く、合わせて四千行ほど書いていた。

たとえば DNS。名前を引くのにライブラリを使わず、RFC1035 を見ながら問い合わせパケットをバイト列から自分で組み立てて、UDP で投げていた。メールもそうで、SMTP(RFC821)を生のソケットで直接喋る自作メーラーを書いた。しかも凝ったことに、宛先のメールサーバーを自作の DNS リゾルバで MX レコードから自力で引いて、途中のリレーサーバーを介さず相手のサーバーへ直接配送する、というところまでやっていた。ISO-2022-JP のような当時のメールの文字コードも、変換処理を自分で書いて通していた。

画面まわりも同じだ。MFC のような分厚いフレームワークには乗らず、Windows SDK を直に叩いた。ウィンドウを出すのも、メッセージループを回すのも、生の Win32 API で書く。ときには Win32 のもっと深いところ——他のプロセスに自分の DLL を送り込んで、そのプログラムの内側でコードを動かす、DLL インジェクションのようなことまで、API を直に叩いて自作した。OS が用意した仕組みの、想定された使い方の一歩外側に手を伸ばすのが、とにかく面白かった。

メールの MIME も、multipart/mixed を自分で組み立てて、本文に添付ファイルを付けられるところまで作った。whois クライアントも、掲示板や日記の CGI（こちらは Perl）も、ぜんぶ自前だった。

いま思えば効率は最悪だ。既製のライブラリなら数行で済むことを、何十行も書いて再発明していた。でも、そうやって一段下を触っているうちに、パケットの中身も、文字コードの都合も、OS が裏で何をしているのかも、手が覚えていった。「使う」だけでは絶対に手に入らない解像度が、そこにあった。

小さく、削ぎ落として作る

冒頭のあのソフトも、その延長だった。作るときは、とにかく小さくすることにこだわった。余計なランタイムを積まず、標準ライブラリにもなるべく頼らず、実行ファイルを圧縮して、フロッピー1枚に余裕で収まるサイズにした。「ライブラリを使ったら負け」の裏返しで、「余計なものを積んだら負け」でもあったのだと思う。

そうして削ぎ落として作った小さなソフトを、誰でも落とせる形でネットに公開していた。当時は、そういうものを作って世に出すこと自体が、できることだった。

二十年後、検体になっていた

面白いのはここからだ。何年も――というより十数年、二十年という単位で経ってから――そのソフトが、**査読付きのセキュリティ研究の"検体”**として使われていたことを知った。当時は「いまはまだ合法」として配っていたものが、時代が進み、法も検知技術も追いついて、「検知すべき対象」の側に回り、それを見つけ出す手法の実験台のひとつに選ばれていた。作った本人が何も知らないうちに、自分の書いたコードが、どこかの研究室で走らされていた。

それを、いまのマシンが消した

ふと、あれはどんなソフトだったっけ、と思った。細かい作りは、もう覚えていない。二十年も前に、高校生の自分が書いたものだ。懐かしくなって、いまも残っているその配布ページから、自分で自分のソフトを落としてみた。

開く暇もなかった。ダウンロードが終わった瞬間、いまの OS が、それをマルウェアとして検知して、目の前で強制的に削除した。止める間もない。ただ「削除しました」という通知だけが残った。当時は合法として配っていた自分の作品を、二十年後の自分のマシンが、危険物として問答無用で拭き消していく。手を伸ばした過去が、現在の側から、静かに、しかし容赦なく消された――そういう感触だった。

手元のファイルは、それで消えた。二十年前、あんなに苦労して組み上げたものが、いまのマシンにはただ一瞬だった。

それでも、不思議と嫌な気はしなかった。消えたのは実行ファイルだけで、あれを作った日々——ライブラリを使わず、下から一つずつ積み上げて、やっと動いたときのあの感覚は、消えずに残っている。あれを動かすのにどれだけ夜を溶かしたか、初めてちゃんと動いた瞬間にどれだけ興奮したか。その苦労と達成感だけは消せない。

L4D2 マップ・MOD 配布記

Mon, 01 Jan 0001 00:00:00 +0000

Left 4 Dead 2(L4D2)は Valve のゾンビ協力 FPS。対戦モードでは生存者4人と特殊感染者4人に分かれて戦い、特殊感染者への対処スキルが勝敗を分ける。ただ、突進してくる Charger(体当たりで突っ込んでくる特殊感染者)を近接武器のヘッドショット一発で確殺するような一瞬の技術は、実戦の失敗の中でしか磨けない。それなら練習環境ごと自作すればいい、と練習マップ3部作と HUD MOD 群を作って配布していた。

練習マップ3部作(2010年頃)

Charger 近接 HS 練習マップ — Charger を近接武器のヘッドショットで一発確殺する練習をするマップ。ひたすら Charger が湧いて突進してくる。BOT の Charger は突進中の被ダメージが減る仕様で近接 HS 一撃死が再現できないため、spawn した瞬間に自動でダメージを与えて擬似的に成立させた。net_fakelag で実戦のラグまで再現できる
Witch 処理練習マップ — Witch(刺激すると襲いかかる特殊感染者)の処理だけを延々と反復する
Jockey 練習マップ — Jockey(生存者に飛び乗って操作を奪う特殊感染者)の bhop(連続ジャンプで加速する移動技)と strafe ジャンプを練習する

遊ぶ側の不満は HUD MOD で解決した。残弾警告(Large Ammo HUD)、キルログ拡大(Large Damage Log)、味方ヘルスの数値表示、コンパクトな ClearHUD、観戦者用 HUD——いずれも GameBanana(旧 FPSBANANA)で配布した(配布物一覧)。当時の日記には配布側の実感も残っている:

HomePageのリストに、Jockey Training乗せるの忘れてたので追加した。あれなぜかめっちゃ人気なんだよな、よくわからん

調べて、直す(2010年)

マップと MOD の裏には、ゲームを分解して調べた蓄積がある。調査メモは当時から公開していた:

2年前のメモが答え合わせされる

2012年10月のアップデートで、ハシゴを高速でのぼるテクニックが突然できなくなり、Steam の公式フォーラム(SPUF)にスレッドが立つ騒ぎになった。原因は cvar(ゲームの設定値)の joystick がデフォルトで 1 になったこと——そして「joystick 1 だと高速のぼりができなくなる」という現象自体は、その2年前に自分で見つけて wiki の詳解Left4Dead2に書き残していたものだった。Valve の開発者が「コントローラーを使っていないのに移動が変わるのは意図していない」と認めて翌日に修正され、高速のぼりが Valve 公認のテクニックであることも確定した(2012年10月19日〜20日)。

2010年の夏を .dem から掘り起こす

Thu, 09 Jul 2026 00:00:00 +0000

16年前の L4D2 対抗戦の demo 185本を AI が解析し、固有文字列から全プレイヤーの座標まで開いた記録

タイムアタックと記録

Mon, 01 Jan 0001 00:00:00 +0000

FPS の中でも、bhop(バニーホップ) という移動テクニックに一時期のめり込んでいた。ジャンプを連打しながら空中で視点と入力を合わせると加速し続ける、Source Engine 特有の挙動で、それを突き詰めるための Kreedz Climbing(KZ) という MOD がある。地形を登ったり bhop でコースを駆け抜けたりしてタイムを競う、タイムアタックの世界。ここでの記録と、そこから派生した bhop まわりの作りものをまとめる。

Kreedz Climbing の記録

当時の日本記録(jp best)をいくつか持っていた。* が jp best、(tie) が同記録:

kz_date2: 03:02 *jp best
kz_bhop_cartooncastle: 00:35 *jp best
kz_bhop_shrubhop: 02:24 *jp best
kz_bhop_tiles: 01:18 *jp best
kz_bhop_ocean: 00:37 *jp best
kz_bhop_arctic: 00:24 *jp best (tie)
kz_bhop_backalley: 00:22 jp best (tie)
kz_bhop_kashgar: 00:24 *jp best (tie)

日記に残っている「実績まとめ」より:

JP Best(4つ): kz_date2, kz_bhop_cartooncastle, kz_bhop_shrubhop, kz_bhop_tiles JP Best同記録(3つ): kz_bhop_arctic, kz_bhop_backalley, kz_bhop_kashgar そろそろkz界はフラグムービー作ったあとに去ろうと思っている

peercast.in

Mon, 01 Jan 0001 00:00:00 +0000

PeerCast は 2002年生まれの P2P 映像配信ソフト。専用クライアントを入れてポートを開放しないと視聴できない、敷居の高さごと愛されてきた配信文化圏だった。peercast.in は 2012年に作った、その PeerCast の配信をブラウザだけでサムネイル一覧・検索・視聴できるようにするサイト。「インストールしないと何をやっているかすら見えない」せいで失われているリスナーを取り戻し、PeerCast の間口を広げるのが狙いだった。

実装は nginx reverse proxy + Sinatra + 自作のしたらば掲示板クローラー。配信ごとのコメントをリアルタイム表示する「Peercast Stream」機能は Server-Sent Events(サーバーから一方向にデータを流し続ける仕組み)で作っていた(詳しくは後述の内部の仕組み)。

どんな画面だったか

サイトの実物は残っていないが、公開10日目(2012年3月15日)のトップページの HTML が Wayback Machine に丸ごと残っていた。そこから当時の画面を再現したのがこれ:

2012年3月15日のトップページの再現。アーカイブされていた当時の HTML に同時期の Twitter Bootstrap 2.0 を当てたもので、配信者名はぼかし、未アーカイブのサムネイル画像はプレースホルダにしてある。「現在のPeercast総人口は、1220人です」「現在41件配信中」も当時の実データ

トップページは配信中チャンネルをリスナー数順に並べたリアルタイムランキングで、各行にサムネイル・配信時間・「再生する」リンク・掲示板リンクが付く。配信中チャンネルの全文検索と過去の全データからの検索、AutoPagerize 対応もあった(2012年3月13日)。ランキングは最高リスナー数・平均リスナー数・配信時間の3種類で、「客観的な指標をもとに新たな配信者さんを見つけることができる」ことを狙っていた(2012年3月15日)。

サムネイルは10分おきに全配信から取得していて、配信ごとの「サムネ一覧」ページで時系列に眺められた。ノンストップで蜘蛛の生活を流し続ける配信(当時すでに100時間超)をこのサムネ一覧で紹介した日記も残っている(2012年3月12日)。

このスクリーンショットの2日後(2012年3月17日)には、配信中の番組をスクリーンショットのタイルで一覧できる「Now!」ページが追加された。「アクセスするごとにランダムに並び変わるので、人間が左上から順番に見てしまうという行動パターンへの対策もバッチリできています」(当時の日記)。その後もサイドバー・最新レス表示・配信者一覧・取得先 YP(配信一覧を持つ元サイト)の追加と、ほぼ日次のペースで機能が増えていった(2012年3月20日〜26日)。

内部の仕組み

当時のソースコードが手元に残っていた。それと日記を突き合わせると、内部構成はこうなっていた:

スタックは nginx + Sinatra(Ruby)+ MySQL。実は Sinatra アプリは2つに分かれていて、peercast.in 本体がランキング・検索・サムネ一覧・Now! を、別アプリの Peercast Stream がコメントのリアルタイム配信を受け持っていた
サムネイルのキャプチャは、サーバー上で常駐させた PeerCast クライアント(localhost:7144)経由で各配信に接続し、ffmpeg で「先頭8秒地点」の1フレームを切り出して、RMagick で縮小・黒背景に合成して軽くぼかす、という流れ。最初の8秒はバッファで映像が乱れがちだったのを避ける工夫で(2012年3月5日)、これを10分ごとに全配信ぶん回していた。並列化には parallel gem、失敗時のリトライには自作の retry-handler を使っている
YP の index.txt(<> 区切りのチャンネル一覧)は、複数の YP を結合してから NG キーワードで配信を除外し、1つのファイルに書き出していた(yp_merger)。パーサは自作ライブラリ集 orelib にあり、のちに自作の csvmapper で書き直す記事も書いた(2012年8月1日)。YP のクロール自体は本体とは別のサーバーで回していた(2012年3月23日)
ランキング(最高リスナー数・平均リスナー数など)は MySQL のビューとして持っていた
8,000 req/sec は nginx のキャッシュチューニングによるもの(2012年3月8日)。動画そのものは配信していない(再生リンクは視聴者手元の PeerCast クライアント localhost:7144 に向く)ので、捌くのは HTML とサムネイル画像だけでよかった
Peercast Stream の SSE は Sinatra の stream :keep_open、nginx 側は proxy_buffering off で流していた(2012年4月20日)

クライアント側のパッチ

そのキャプチャの土台になっていたのが、公開の2週間前(2012年2月21日)に用意した Linux 用 PeerCast クライアントの fork だ。ベースは「PeerCast for Linux(VP パッチ版)」で、README には “VP patch + fixed compile bug” とだけ書いてある。けれど実際に足していた本命は、サーバーで無人常駐させるための自動再起動だった。PeerCast 本体を fork() した子プロセスで動かし、親が waitpid() で見張って、子が落ちたらまた起動しなおす——というスーパーバイザを main.cpp に加えている。10分おきに何日も動き続けるキャプチャ基盤の裏で、クライアントが落ちても勝手に生き返るようにするための改造で、コンパイルを通すための細かい修正(sys/wait.h の include など)も一緒に入っていた。

TF2 Sushi Server 運営記

Mon, 01 Jan 0001 00:00:00 +0000

Team Fortress 2(TF2)は Valve の対戦 FPS。その協力モード MvM(Mann vs. Machine) は、プレイヤー6人でロボット軍団の侵攻を防衛するモードで、公式サーバーのほかに個人が建てる「コミュニティサーバー」で遊ぶ文化があった。

Sushi 鯖は、2012年の夏にそのコミュニティサーバーとして建てた日本向けサーバー群。最初は1部屋だったが、最盛期には MvM 10部屋 + Payload(爆弾カートを押し合う対戦モード)+ Idle という構成になり、累計利用者は最終的に25万人を超えた。これはその運営の記録。

数字で見る Sushi 鯖

累計利用者数の推移。当時のブログで節目ごとに発表していた実測値を直線でつないだもの:

設立一周年(2013年8月)時点の統計と、確認できる最終値(2016年8月、MOTD アーカイブの Stats ページより):

TF2 マップ制作記

Mon, 01 Jan 0001 00:00:00 +0000

TF2 の協力モード MvM(プレイヤー6人でロボット軍団を迎え撃つモード)用のマップを、自分で運営していた Sushi 鯖で回すために3枚作った——mvm_volcano_a4(溶岩)、mvm_labo_a1(研究所)、mvm_mountain_b3(山を防衛)。マップは Hammer という Source Engine 標準のレベルエディタで作る。ダウンロードは Gaming から。

mvm_mountain と mvm_volcano は、テストプレイにすぐ join してくれる SpaceMomonga さんのアドバイスを受けて作ったマップで、「このときのコミットメントがすごく大きかったですね」と一周年の日記に書いている。

作ってみて分かった大変さ

自作マップのプレイ回数が421回になったときの日記(2013年1月)に、マップ制作の地味な苦労が記録されている:

マップ作るのって意外とまじでめんどくて大変であるというのがよくわかって、たとえばbotの湧きタイミングの調整とか、botがスタックしないように見えない壁をせっせと設置したりとか、処理落ちしないように壁越しに見える必要のない部分にはnoclipっていう壁を設置することで、壁越しのオブジェクトを描画させないようにoptimizeしたりとか。

制作日記「Map作り」

MvM 登場直後の2012年9月から、「Map 作り#N」と題した制作日記を連載していた(#1〜#13)。#11 は mvm_volcano のコンセプトメモで、「RED チームが火山の内部に持っていた秘密基地に、ロボットが爆弾を持って攻め込んでくる」という設定と一緒に、こんな設計判断が書いてある:

溶岩ダメージは即死ではなくて火炎ダメージを数秒間耐えられるようにした。なぜかというと、溶岩エリアに落ちた味方をみてニヤニヤする時間的猶予を残すため。即死しちゃうと、溶岩でもがき苦しむ味方の姿をみることができない。

wave(押し寄せる敵の波)の設計は秒単位で組んでいた。mvm_mountain_b3 の wave7 の設計メモ(2012年9月25日)は「1秒後に buff banner soldier squads が4体 spawn → 2秒後に natascha giant×2(2箇所で)→ …… → 60秒後におそらくクリア」というスポーン表そのものが残っている。

ハマりどころの記録

BOT が落ちる — 曲がり角で左側に落下する BOT が多発。nav mesh を nav_split で分割し、危ない縁に nav_avoid 属性を付けて歩かせない手順を確立した(2012年10月1日)
バランス調整は永遠に終わらない — volcano の a1→a2 だけでも「Respawn Suicide バグを直した」「Engineer が強すぎるので Sentry Buster が湧く専用の場所を追加」「敵が落下死したときに bomb が近くに復活するようにした」(2012年9月30日)
テストを速くする工夫 — tf_mvm_jump_to_wave で任意の wave に飛び、世界の時間を倍速にして特定のラッシュまで早送りする、という検証手順を文書化していた(2012年9月24日)
エンジン側のバグも踏む — 制作中に TF2 本体のバグを何個も発見している。建築者のいない中立セントリーガンが敵を撃とうとするとサーバーごとフリーズする、セントリーガンは水中の敵に反応しない、テレポーター出口に物理オブジェクトがあると出口が壊れる(2012年9月26日)
道具も壊れる — 翌2013年、SteamPipe 化で Hammer Editor が新規マップ作成時にエラーを吐いて起動しなくなり、gameinfo.txt に ToolsAppId を設定して復旧した(2013年7月29日)

未完に終わった構想

作りかけ・構想止まりのマップもいくつかあった(マップ名は伏せる)。