超連射68K 開発日記 -弾幕世代以前の90年代 STG のこと-
- 1. 「超連射68K 開発日記」 - 弾幕世代以前の 2D STG のこと - by ファミベのよっしん 2010/02/20 1
- 2. 自己紹介 ● ファミベのよっしん（吉田弘一） ● STG 大好きです ※ただし 2D に限る ● 80～90年代、趣味の一環として STG を作成 ● 雑誌にプログラムを投稿、同人ソフト販売 ● 2000年代 SCE 在籍 ● タイトル向け社内ライブラリ制作 2
- 4. 90年代につくったもの 4
- 5. 90年代前半期の STG と それを取り巻く状況 5
- 6. 当時のゲーセン＝ゲーマー交流の場 ● インターネットは無い時代 ● 情報伝達速度は今ほど早くは無い ● 「コミュニケーションノート」という雑記帳があった ● 馴れ合い、罵り合い、絵師の落書き etc... ● 今で言う掲示板 ● ノートを軸に常連客コミュニティが形成される 6
- 7. 熾烈なハイスコア競争が展開される ● 雑誌が全国のゲーセンのハイスコアを集計 ● 毎月全国TOPプレイヤを決定する仕組み ● 攻略法研究の遠方ゲーセン訪問が流行 ● 「遠征」という ● 他店の常連が遠征に来ると、スパられないよう（＝スパイされな いようという意）ダンボール箱を被ってプレイする者が出現する ● エスカレートするスコア競争 ● スコアをめぐり、リアル抗争に発展する例も珍しくない 7
- 8. 当時ゲーセンで稼動していたSTG ● STGはまだまだ花形ジャンル ● スーパープレイと言えば STG。スーパープレイは希少 ● STG＝指鍛錬 ● シューター曰く「STG に萌え要素など、公私混同も甚だしいわ」 ● 今で言う弾幕ものはまだない ● 弾幕は高次周回でのみ見られる現象だった 8
- 9. 当時のSTGデザインの傾向 ● 張り付き撃ち速攻の美学 ● 敵の隙をつき懐にもぐり込む→張り付き撃ち（手連射）→瞬殺 ● スピード狂推奨 ● 自機速度を MAX に上げ、張り付いたり安全地帯に入ったり ※一方、弾幕世代は弾避けに専念できるデザイン ● 弾避けに専念していても、敵にダメージを与え続けられる ● オート連射機能。敵の耐久力＝残り時間になってしまう傾向 ● 張り付き要素との両立は各タイトル工夫されているようです 9
- 10. 90年代半ばは STG 苦難の時期 ● 進化の方向性を模索するが糸口が見えない ● 行き過ぎたマニア化をどう是正するか ● 3D 表現に移行しなければならないというプレッシャー ● インカム効率（売上げ）で対戦格闘ゲームに及ばず ● 対戦＝どんなに上手いプレイヤでも必ずどっちかが死ぬ ● 格闘ゲームは数分で1コイン、一方 STG は数十分で1コイン ● STGに強いメーカーの撤退が相次ぐ ● 東亜プラン倒産、旧アイレム一時撤退 10
- 11. 一方、ホビーパソコンの動き ● 草の根 BBS の普及 ● 草の根BBS=当時のネット環境に構築された掲示板 ● ユーザー同士で活発に技術情報交換 ● 個人でも市販クオリティのソフトが作成可能に ● フリーソフトで制作環境が一式揃った ● 当時それは画期的なことだった ● ホビーのゲームプログラミング加速 11
- 12. X68K ユーザーは STG を作りまくった ● アーケード仕様の STG を好むユーザーが多い ● X68Kには移植版 グラディウスI が標準添付されていた ● それを目的に購入した人が多い。つまりシューターホイホイ ● 「無いなら作るの X68K 魂」がスローガン ● とにかく何か作らないといけない気運、異様なテンション ● コミケの X68K 枠は STG で溢れ返る結果に ● STGメーカーの撤退に連動。無いなら作ればいい 12
- 13. ここで动画デモ 13
- 14. 超連射68K の制作について 14
- 15. 開発時系列 ● 1993 年ごろ ● X68K の基礎ライブラリ整備 ● 1995 年 ● 超連射68K バージョン 0.10 コミケ（C47だったと思う）で販売 ● 1998 年 ● 超連射68K バージョン 1.00 完成 ● 2001 年 ● Windows 移植版作成、フリーソフト化 15
- 16. 開発体制 ● プログラムとドット絵 ● 私（よっしん）が一人で兼任 ● BGM ● 柏木るざりん氏 （http://loserkashiwagi.com/） ● 2003 年に「巫女みこナース?愛のテーマ」発表。電波ソング方面 をはじめ幅広く活動中 16
- 17. 当時のコミケ ● 晴海埠頭で開催（C49 まで） ● なぜか毎年晴天に恵まれる。台風が進路を曲げる ● オタクの熱気が作る上昇気流によるものであるという都市伝説も ● 広く作品発表できる唯一の機会 ● インターネットが無い時代、オタクにとっては甲子園のようなもの ● 同人ソフトはまだマイナーな扱いだった ● 新館2Fという劣悪スペースに配置 ● 夏はサウナ状態。館内に熱気で雲ができたという都市伝説あり 17
- 18. コミケ参加が超連射68K制作の推進力 ● 年二回、絶対に動かせない締め切りがやってくる ● 絶妙に妥協できない感じ ● ユーザーからのフィードバックを反映して ver UP ● コミケの度に ver UP（悪く言うと ver UP 商法） ● 頒布価格は 500 円と、低めの設定にしていた ● 完成まで中断できないサイクルに突入 ● 当時、学業が結構忙しく辛かった 18
- 19. 超連射68K の実装技術面について 19
- 20. SHARP X68K はこんなマシン ● CPU ● MC68000 10MHz ● スプライト（ハードウェアによるビットマップ描画） ● 16x16 dot サイズが 1 画面中 128 枚まで表示できる ● 16x16 dot の絵が 256 種まで登録できる ● サウンド ● FM 音源（8チャンネル） ● ADPCM（周波数固定1チャンネル） 20
- 21. 90年代すでにX68Kに陳腐化の兆し ● 夢のマシンのはず、だったのに。。。 ● 後発機も基本スペックを維持するのが SHARP のポリシー ● X68K 成功要因の一つだが、副作用としての陳腐化は不可避 ● スプライト機能の貧弱さが顕著になってきた ● その時、すでに普及帯の家庭用ゲーム機と同等以下 ● プログラムの工夫でカバーしないといけない ● ファミリーベーシックの制約から逃れられたと思ったのも束の間、 再びギリギリコーディングに（とか言いつつ結構楽しんでいた） 21
- 22. スプライトを増やせ！ ● スプライトは走査線が通過した時に表示される ● 表示後、走査線より下に移動すれば、再表示可能 ● これによりスペックの 4 倍の 512 枚表示を実現 走査線が通過した #0 #1 を走査線の #0 #1 に走査線が #0 #1 は表示済み 下に移動する 通過して再表示 22
- 23. スプライト VRAM 不足を解消しろ！ ● 16x16 dot の絵が 256 種しか定義できない ● 狭いが、仮想メモリだと考えれば十分なサイズ ● メインメモリからVRAMへ動的に割り当て開放 ←動作中のスプライトVRAM全体像 たったこれだけの領域しかない 動的割り当てにより狭さを解消 23
- 24. 当時、重い処理と言えば衝突判定 ● 32 vs 32 ごときで 60fps 維持できない /* これしきで CPU 処理時間を 100% 食いつぶす */ for( i=0 ; i<32 ; i++ ){ /* 敵 */ for( j=0 ; j<32 ; j++ ){ /* 自機の弾 */ 衝突判定( i , j ); /* 1024 回実行される */ } } ● スプライトは増えたが沢山のキャラは出せない？ ● それでは意味がないので高速化を考えることにした 24
- 25. 衝突判定の高速化（1） ● 「仮想ビットマップ方式」と当時呼んだ手法を採用 ● 画面をマスで区切ってキャラの居るところにマーク ● マークを見つけたら実際に座標で比較 ● 衝突判定の面積に比例した処理負荷が生じるという欠点あり 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 4 0 衝突の可能性が 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 あるなら厳密に 0 0 2 0 0 0 0 0 0 0 2 0 0 0 0 0 判定を取る 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 8 0 キャラの居る位置にマーク 判定を取る時は、衝突判定 各ビットがキャラ番号に対応 範囲内のマークを調べる 25
- 26. 衝突判定の高速化（2） ● 最終的には以下のような形に落ち着いた ● X軸 Y軸 個別に 1 次元のマスを用意し、論理積で評価する ● X軸評価時点で判定無しと判断可（アーリーアウトによる高速化） ● 負荷は衝突判定の面積でなくサイズに比例（先の手法より高速） 0 1 2 0 0 0 C 0 0 1 2 0 0 0 C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 4 0 4 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 2 0 0 0 0 0 2 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 8 0 8 0 0 0 0 0 0 8 0 X軸 Y軸 対応の1 次元配列にマーク X軸 Y軸 の論理積で衝突検出する 26
- 27. STGを取り巻く状況 90年代後半に起きた変化 27
- 28. 同人ソフトに Windows95 の波が直撃 ● 大半のコード資産が無駄になった ● X68K 的にはエンディアンが逆になったのは非常につらかった ● 当時の Windows はまだゲームが作りづらかった ● DirectX3 が出た頃。初期化だけでコードが1000行以上に ● 高額なコンパイラ、少ない技術資料、GPUの状況も流動的 ● 一時期、同人ゲームがかなり減ってしまった 28
- 29. ゲーセンで起きた変化 ● コミュニケーションノートがその役割を終えていく ● インターネットが普及し、取って代わられていく ● それに連動して、常連コミュニティの世代交代 ● ゲーメスト廃刊、ベーマガのハイスコア集計終了 ● アルカディア誌に引き継がれるが規模は年々縮小の傾向 ● 弾幕系STGというフォーマットが出現 29
- 30. スーパープレイの位置付けが変化 ● YouTube やニコニコ動画で観られるようになった ● 手軽で良い。しかし、本物スーパープレイである保障は無い ● TAS（Tool-Assisted Superplay）の台頭 ● エミュレータ等を駆使して作成したスーパープレイ動画 ● 処理落ち環境でリプレイ採取しただけのお手軽TASも横行 ● 本物スーパープレイのカリスマ性低下 ● STGはスーパープレイのカリスマ性と二人三脚で進化してきた ● 特にTASはそれを根底から揺るがす可能性がある 30
- 32. 某全国TOP神シューター曰く ※シューター＝2D STG を好むゲームプレイヤのこと 「ネットに公開されてるハイスコアは信用ならない」 「仮にリプレイデータがあっても本物か判らない」 「だから今でも競う土俵はネットでなくゲーセン」 「ネットに移行できれば競う相手も増えるのに」 不可能を可能にしてきた彼らだからこそ、偽装「不可能」な リプレイデータもまた存在し得ない＝リプレイを利用してハ イスコアの証明はできない、という解釈になる。 32
- 33. この問題をプログラマの視点で整理 ● 「競う土俵」に求められる特性 ● 明確なレギュレーション（ルール）があり、違反は100%検出可能 ● たとえ違反発生率がゼロでも、違反できる余地がある時点でNG ● シューターにとってネットは競う土俵として不完全 ● ハイスコアが本物であると証明する方法がない ● リプレイ添付でも、精巧な本物プレイっぽいTASの可能性がある ● 技術的な問題にすぎない ● TAS 利用チートを 100% 検出できれば良いのではないか？ 33
- 34. どうすればTASは防止できるか？ ● リプレイデータの改竄防止という方向性ではダメ ● 暗号化しても TAS には勝てない ● 「TAS の弱点＝実プレイ時間」に着目 ● TAS は繰り返しリトライするため実プレイ時間が非常に長い ● 実プレイ時間を計測できれば TAS 利用チートは検出可能 ● 乱数を予測不能にしてやれば良いのでは？ ● 乱数予測系のTAS（例：テトリス電源パターン系）防止のため 34
- 35. 超連射68KでTAS対策を実験してみた ● 従来のランキングサーバー方式をちょっと改良 1)ゲーム開始時、サーバーからゲーム内乱数シードを発行 2)ゲーム終了時、リプレイデータのハッシュ値をサーバーに返す プレイ時間=(2)-(1)。これとハッシュ値をサーバーに保存、公開 ● ハイスコアが TAS 利用でないことを確認する手順 1)プレイヤからリプレイデータを提出してもらう 2)ハッシュ値とプレイ時間がサーバー記録と一致することを確認 ● これだけで大半の TAS が不可能になった 35
- 36. 依然可能なTAS利用チートがある… ● AI 利用 ● 画像解析で自律プレイ（ぷよぷよでは実装例があるらしい） ● 弾幕を避ける AI が作られる可能性はゼロではない ● ゲームを早回しして時間をストック ● 常時 70fps ぐらいでプレイしておき、難所で処理落ちさせる ● さらなる改良案が必要 ● 皆さんも考えてみて下さい 36
- 37. 以上です 37