1

「超連射「超連射68K 68K 開発日記」開発日記」- - 弾幕世代以前の 弾幕世代以前の 2D STG 2D STG のこと のこと --

by ファミベのよっしん2010/02/20

2

自己紹介自己紹介

● ファミベのよっしん（吉田弘一）● STG 大好きです

※ただし 2D に限る

● 80～90年代、趣味の一環として STG を作成● 雑誌にプログラムを投稿、同人ソフト販売

● 2000年代 SCE 在籍● タイトル向け社内ライブラリ制作

3

8080年代につくったもの年代につくったもの

↓当時のメインマシン、ファミリーベーシック V3

4

9090年代につくったもの年代につくったもの

5

9090年代前半期の 年代前半期の STG STG ととそれを取り巻く状況それを取り巻く状況

6

当時のゲーセン＝ゲーマー交流の場当時のゲーセン＝ゲーマー交流の場

● インターネットは無い時代● 情報伝達速度は今ほど早くは無い

● 「コミュニケーションノート」という雑記帳があった● 馴れ合い、罵り合い、絵師の落書き etc...● 今で言う掲示板

● ノートを軸に常連客コミュニティが形成される

7

熾烈なハイスコア競争が展開される熾烈なハイスコア競争が展開される

● 雑誌が全国のゲーセンのハイスコアを集計● 毎月全国TOPプレイヤを決定する仕組み

● 攻略法研究の遠方ゲーセン訪問が流行● 「遠征」という

● 他店の常連が遠征に来ると、スパられないよう（＝スパイされないようという意）ダンボール箱を被ってプレイする者が出現する

● エスカレートするスコア競争● スコアをめぐり、リアル抗争に発展する例も珍しくない

8

当時ゲーセンで稼動していた当時ゲーセンで稼動していたSTGSTG● STGはまだまだ花形ジャンル

● スーパープレイと言えば STG。スーパープレイは希少

● STG＝指鍛錬● シューター曰く「STG に萌え要素など、公私混同も甚だしいわ」

● 今で言う弾幕ものはまだない● 弾幕は高次周回でのみ見られる現象だった

9

当時の当時のSTGSTGデザインの傾向デザインの傾向

● 張り付き撃ち速攻の美学● 敵の隙をつき懐にもぐり込む→張り付き撃ち（手連射）→瞬殺

● スピード狂推奨● 自機速度を MAX に上げ、張り付いたり安全地帯に入ったり

※一方、弾幕世代は弾避けに専念できるデザイン● 弾避けに専念していても、敵にダメージを与え続けられる

● オート連射機能。敵の耐久力＝残り時間になってしまう傾向

● 張り付き要素との両立は各タイトル工夫されているようです

10

9090年代半ばは 年代半ばは STG STG 苦難の時期苦難の時期

● 進化の方向性を模索するが糸口が見えない● 行き過ぎたマニア化をどう是正するか

● 3D 表現に移行しなければならないというプレッシャー

● インカム効率（売上げ）で対戦格闘ゲームに及ばず● 対戦＝どんなに上手いプレイヤでも必ずどっちかが死ぬ

● 格闘ゲームは数分で1コイン、一方 STG は数十分で1コイン

● STGに強いメーカーの撤退が相次ぐ● 東亜プラン倒産、旧アイレム一時撤退

11

一方、ホビーパソコンの動き一方、ホビーパソコンの動き

● 草の根 BBS の普及● 草の根BBS=当時のネット環境に構築された掲示板

● ユーザー同士で活発に技術情報交換

● 個人でも市販クオリティのソフトが作成可能に● フリーソフトで制作環境が一式揃った

● 当時それは画期的なことだった

● ホビーのゲームプログラミング加速

12

X68K X68K ユーザーは ユーザーは STG STG を作りまくったを作りまくった

● アーケード仕様の STG を好むユーザーが多い● X68Kには移植版 グラディウスI が標準添付されていた

● それを目的に購入した人が多い。つまりシューターホイホイ

● 「無いなら作るの X68K 魂」がスローガン● とにかく何か作らないといけない気運、異様なテンション

● コミケの X68K 枠は STG で溢れ返る結果に● STGメーカーの撤退に連動。無いなら作ればいい

13

ここで動画デモ

14

超連射超連射68K 68K の制作についての制作について

15

開発時系列開発時系列

● 1993 年ごろ● X68K の基礎ライブラリ整備

● 1995 年● 超連射68K バージョン 0.10 コミケ（C47だったと思う）で販売

● 1998 年● 超連射68K バージョン 1.00 完成

● 2001 年● Windows 移植版作成、フリーソフト化

16

開発体制開発体制

● プログラムとドット絵● 私（よっしん）が一人で兼任

● BGM● 柏木るざりん氏 （http://loserkashiwagi.com/）● 2003 年に「巫女みこナース・愛のテーマ」発表。電波ソング方面

をはじめ幅広く活動中

17

当時のコミケ当時のコミケ

● 晴海埠頭で開催（C49 まで）● なぜか毎年晴天に恵まれる。台風が進路を曲げる

● オタクの熱気が作る上昇気流によるものであるという都市伝説も

● 広く作品発表できる唯一の機会● インターネットが無い時代、オタクにとっては甲子園のようなもの

● 同人ソフトはまだマイナーな扱いだった● 新館2Fという劣悪スペースに配置

● 夏はサウナ状態。館内に熱気で雲ができたという都市伝説あり

18

コミケ参加が超連射コミケ参加が超連射68K68K制作の推進力制作の推進力

● 年二回、絶対に動かせない締め切りがやってくる● 絶妙に妥協できない感じ

● ユーザーからのフィードバックを反映して ver UP● コミケの度に ver UP（悪く言うと ver UP 商法）

● 頒布価格は 500 円と、低めの設定にしていた

● 完成まで中断できないサイクルに突入● 当時、学業が結構忙しく辛かった

19

超連射超連射68K 68K の実装技術面についての実装技術面について

20

SHARP X68K SHARP X68K はこんなマシンはこんなマシン

● CPU● MC68000 10MHz

● スプライト（ハードウェアによるビットマップ描画）● 16x16 dot サイズが 1 画面中 128 枚まで表示できる

● 16x16 dot の絵が 256 種まで登録できる

● サウンド● FM 音源（8チャンネル）

● ADPCM（周波数固定1チャンネル）

21

9090年代すでに年代すでにX68KX68Kに陳腐化の兆しに陳腐化の兆し

● 夢のマシンのはず、だったのに。。。● 後発機も基本スペックを維持するのが SHARP のポリシー

● X68K 成功要因の一つだが、副作用としての陳腐化は不可避

● スプライト機能の貧弱さが顕著になってきた● その時、すでに普及帯の家庭用ゲーム機と同等以下

● プログラムの工夫でカバーしないといけない● ファミリーベーシックの制約から逃れられたと思ったのも束の間、再びギリギリコーディングに（とか言いつつ結構楽しんでいた）

22

スプライトを増やせ！スプライトを増やせ！

● スプライトは走査線が通過した時に表示される● 表示後、走査線より下に移動すれば、再表示可能

● これによりスペックの 4 倍の 512 枚表示を実現

走査線が通過した#0 #1 は表示済み

#0 #1 を走査線の下に移動する

#0 #1 に走査線が通過して再表示

23

スプライト スプライト VRAM VRAM 不足を解消しろ！不足を解消しろ！

● 16x16 dot の絵が 256 種しか定義できない

● 狭いが、仮想メモリだと考えれば十分なサイズ

● メインメモリからVRAMへ動的に割り当て開放

←動作中のスプライトVRAM全体像

たったこれだけの領域しかない

動的割り当てにより狭さを解消

24

当時、重い処理と言えば衝突判定当時、重い処理と言えば衝突判定

● 32 vs 32 ごときで 60fps 維持できない

● スプライトは増えたが沢山のキャラは出せない？● それでは意味がないので高速化を考えることにした

/* これしきで CPU 処理時間を 100% 食いつぶす */for( i=0 ; i<32 ; i++ ){ /* 敵 */

for( j=0 ; j<32 ; j++ ){ /* 自機の弾 */衝突判定( i , j ); /* 1024 回実行される */

}}

25

衝突判定の高速化（衝突判定の高速化（11））

● 「仮想ビットマップ方式」と当時呼んだ手法を採用● 画面をマスで区切ってキャラの居るところにマーク

● マークを見つけたら実際に座標で比較

● 衝突判定の面積に比例した処理負荷が生じるという欠点あり

0 0 0 0 0 0 0 00 1 0 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 4 00 0 0 0 0 0 0 00 0 2 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 8 0

0 0 0 0 0 0 0 00 1 0 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 4 00 0 0 0 0 0 0 00 0 2 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 8 0

キャラの居る位置にマーク各ビットがキャラ番号に対応

判定を取る時は、衝突判定範囲内のマークを調べる

衝突の可能性があるなら厳密に判定を取る

26

衝突判定の高速化（衝突判定の高速化（22））

● 最終的には以下のような形に落ち着いた● X軸 Y軸 個別に 1 次元のマスを用意し、論理積で評価する

● X軸評価時点で判定無しと判断可（アーリーアウトによる高速化）

● 負荷は衝突判定の面積でなくサイズに比例（先の手法より高速）

01040208

0 1 2 0 0 0 C 0

0 0 0 0 0 0 0 00 1 0 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 4 00 0 0 0 0 0 0 00 0 2 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 8 0

0 0 0 0 0 0 0 00 1 0 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 4 00 0 0 0 0 0 0 00 0 2 0 0 0 0 00 0 0 0 0 0 0 00 0 0 0 0 0 8 0

0 1 2 0 0 0 C 0

01040208

X軸 Y軸 対応の1 次元配列にマーク X軸 Y軸 の論理積で衝突検出する

27

STGSTGを取り巻く状況を取り巻く状況9090年代後半に起きた変化年代後半に起きた変化

28

同人ソフトに 同人ソフトに Windows95 Windows95 の波が直撃の波が直撃

● 大半のコード資産が無駄になった● X68K 的にはエンディアンが逆になったのは非常につらかった

● 当時の Windows はまだゲームが作りづらかった● DirectX3 が出た頃。初期化だけでコードが1000行以上に

● 高額なコンパイラ、少ない技術資料、GPUの状況も流動的

● 一時期、同人ゲームがかなり減ってしまった

29

ゲーセンで起きた変化ゲーセンで起きた変化

● コミュニケーションノートがその役割を終えていく● インターネットが普及し、取って代わられていく

● それに連動して、常連コミュニティの世代交代

● ゲーメスト廃刊、ベーマガのハイスコア集計終了● アルカディア誌に引き継がれるが規模は年々縮小の傾向

● 弾幕系STGというフォーマットが出現

30

スーパープレイの位置付けが変化スーパープレイの位置付けが変化

● YouTube やニコニコ動画で観られるようになった● 手軽で良い。しかし、本物スーパープレイである保障は無い

● TAS（Tool-Assisted Superplay）の台頭● エミュレータ等を駆使して作成したスーパープレイ動画

● 処理落ち環境でリプレイ採取しただけのお手軽TASも横行

● 本物スーパープレイのカリスマ性低下● STGはスーパープレイのカリスマ性と二人三脚で進化してきた

● 特にTASはそれを根底から揺るがす可能性がある

31

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

32

某全国某全国TOPTOP神シューター曰く神シューター曰く※シューター＝※シューター＝2D STG 2D STG を好むゲームプレイヤのことを好むゲームプレイヤのこと

「ネットに公開されてるハイスコアは信用ならない」

「仮にリプレイデータがあっても本物か判らない」

「だから今でも競う土俵はネットでなくゲーセン」

「ネットに移行できれば競う相手も増えるのに」

不可能を可能にしてきた彼らだからこそ、偽装「不可能」なリプレイデータもまた存在し得ない＝リプレイを利用してハイスコアの証明はできない、という解釈になる。

33

この問題をプログラマの視点で整理この問題をプログラマの視点で整理

● 「競う土俵」に求められる特性● 明確なレギュレーション（ルール）があり、違反は100%検出可能

● たとえ違反発生率がゼロでも、違反できる余地がある時点でNG

● シューターにとってネットは競う土俵として不完全● ハイスコアが本物であると証明する方法がない

● リプレイ添付でも、精巧な本物プレイっぽいTASの可能性がある

● 技術的な問題にすぎない● TAS 利用チートを 100% 検出できれば良いのではないか？

34

どうすればどうすればTASTASは防止できるか？は防止できるか？

● リプレイデータの改竄防止という方向性ではダメ● 暗号化しても TAS には勝てない

● 「TAS の弱点＝実プレイ時間」に着目● TAS は繰り返しリトライするため実プレイ時間が非常に長い

● 実プレイ時間を計測できれば TAS 利用チートは検出可能

● 乱数を予測不能にしてやれば良いのでは？● 乱数予測系のTAS（例：テトリス電源パターン系）防止のため

35

超連射超連射68K68KででTASTAS対策を実験してみた対策を実験してみた

● 従来のランキングサーバー方式をちょっと改良

1)ゲーム開始時、サーバーからゲーム内乱数シードを発行

2)ゲーム終了時、リプレイデータのハッシュ値をサーバーに返す

プレイ時間=(2)-(1)。これとハッシュ値をサーバーに保存、公開

● ハイスコアが TAS 利用でないことを確認する手順

1)プレイヤからリプレイデータを提出してもらう

2)ハッシュ値とプレイ時間がサーバー記録と一致することを確認

● これだけで大半の TAS が不可能になった

36

依然可能な依然可能なTASTAS利用チートがある…利用チートがある…

● AI 利用● 画像解析で自律プレイ（ぷよぷよでは実装例があるらしい）

● 弾幕を避ける AI が作られる可能性はゼロではない

● ゲームを早回しして時間をストック● 常時 70fps ぐらいでプレイしておき、難所で処理落ちさせる

● さらなる改良案が必要● 皆さんも考えてみて下さい

37

以上です