1. 「超連射68K 開発日記」
- 弾幕世代以前の 2D STG のこと -
by ファミベのよっしん
2010/02/20
1

2. 自己紹介
● ファミベのよっしん（吉田弘一）
● STG 大好きです
※ただし 2D に限る
● 80～90年代、趣味の一環として STG を作成
●
雑誌にプログラムを投稿、同人ソフト販売
● 2000年代 SCE 在籍
●
タイトル向け社内ライブラリ制作
2

3. 80年代につくったもの
↓当時のメインマシン、ファミリーベーシック V3
3

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

31. 90年代に積み残した問題
リプレイデータが本物であることをどう証明するか？
31

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