ノスタルジア：ボンネットの下のタンキキでのうわさ

私たちの多くは、ゲーム業界のd明期のタンキキ、マリオ、その他の不朽の名作で育ちました。 テレビ画面で友だちと一緒に何日も過ごし、グローブのようなジョイスティックを変えた日々を思い出すのはいいことです。 しかし、時間は止まらず、一部の利益は他の利益に取って代わられます。 ただし、古き良きおもちゃへの愛が消えないこともあります。

私はそのような人々に自分自身を尊重し、古いゲームへの私の関心はリバースエンジニアリングに向けられ、それが私をロバにしたIT領域へと導いた。



有名なバトルシティゲーム（一般人の場合は「タンキキ」）で有名な任天堂エンターテイメントシステム（略してNES）の中国のクローン「デンディ」はロシアでよく知られています。 かつて、この情報は私にはかなり興味をそそられたようでした-あなたにも同じように見えることを願っています。

背景

数年前、私はさまざまなグラフィックライブラリを勉強しながら、タンキキの正確なクローンを書くという目標を設定しました。 その瞬間、私の友人の一人が元のゲームのコードを変更してかなり興味深いリメイクを作成していたので、私は彼と相談することにしました（ところで、記事の準備と相談に感謝します）。 それから、いくつかの機能が実装されたメソッドを見つけました。 だから、私は長年、この知識を一般の人々と共有することに決めました。結局、これはgamedevストーリーの一部であり、クラシックの愛好家と現代のゲームの開発者の両方にとって興味深いかもしれません。



ゲームを逆コンパイルする彼の努力に対して、 Grieverというニックネームの人物に特別な感謝を申し上げます。 まず第一に、彼が受け取った情報源のおかげで、そのような詳細に本質を掘り下げることが可能になりました。

レベルカード

Battle Cityのマップは、タイル（8x8ピクセルのブロック）で構成されています。 画面に表示される背景全体がマップです。仮に、ライフカウンターを使用しても相互作用できますが、実際にはこれはもちろん失敗します。



ただし、シリアル化された形式では、レベルはよりコンパクトに保存されます。このため、タイルは2x2タイルのブロックに配置されます。 合計で16種類のブロックがあり、以下の表にリストされています。 マップの主要部分（13x14ブロック）のみが格納され、その上で戦車が走行します。静的な壁とサポート情報を保持することは意味がありません。 1つのブロックを書き込むには4ビットが使用されるため、カード全体で91バイトかかります。

ブロックする	コード	ブロックする	コード	ブロックする	コード	ブロックする	コード
	0		1		2		3
	4		5		6		7
	8		9		A		B
	C		D		E		F

ブロックとは異なり、タイル自体の種類ははるかに多く、つまり256個です。 キャラクタージェネレーターの1ページとまったく同じ大きさ-各タイルが0〜255のインデックスに対応するビデオメモリセクション。タイルは、レベル環境を作成し、敵の戦車数、ライフなどの情報を表示するために使用されます。 ただし、レベル要素では直接22個のみが使用されます。そのうち6個はリストされたブロックを形成するためのもので、残りの15個はレンガブロックの追加のタイルです。



マップが8x8ピクセルタイルで構成されている場合、4x4ピクセルブリックミニブロックをどのように破壊しますか？ 実際には、実際にはこのサイズの「レンガ」はなく、代わりに16種類の通常のタイルがあります（各状態に1つずつ）。 つまり 4x4ブロックにヒットすると、実際にはタイル全体が置き換えられ、発射物がヒットした場所に応じて、レンガ自体が異なる状態になります。











したがって、ところで、レンガブロックの一部を破壊するとき、タンクは空いているスペースに入ることができません-結局、タイル自体は破壊されませんでした。



マップ上のリスポーンポイントとイーグルポイントの位置は固定されており、オブジェクトは外観の場所に関係なくその場所に表示されます。 これは、組み込みのレベルエディタでこれらの領域が「壁で囲まれている」場合に発生します。



誰かがマッピングに興味がある場合、これらの目的のために、ゲームの画像を直接操作する優れたエディターQuarrelがあります。

乱数生成

ランダムな値を生成するタスクは、長い間人類を悩ませてきました。 プログラムで真にランダムな値を取得することは不可能なので、多くの場合、タスクは、ランダムな値の典型的な分布に近い分布を持つ擬似ランダムな値を生成するように削減されました。



完全に決定的な動作をするコンピューターの場合、擬似乱数の生成はさらに困難です。 たとえば、同じボタンを同時に押すことで同じ効果を持つ各起動時に、同じゲームの進行状況を取得します-ゲームプロセスの記録は、その時点で押されたボタンが各フレームに保存され、 。 しかし、私たちにとってこれはそれほど重要ではありません。単一セッション内で可能な限り「ランダムな」値を取得することが重要です。



Battle Cityの状況を検討してください。 ここでは、いくつかの「ランダム」エンティティを使用して擬似ランダム値を生成します。これは、前のランダム値、2番目のカウンター、およびいわゆるバイトです。 ゼロページ-RAMの最初の256バイト。NESプロセッサは、他のプロセッサよりも高速かつ簡単にアドレス指定できます。 そのため、ゼロページに最も頻繁に使用される変数が含まれ、その結果、最も頻繁に変更される変数が含まれ、より均一な分布が保証されます。



その結果、数値の最終値は、プレーヤーが押すボタン、画面上のすべての戦車と弾丸の座標、両方のプレーヤーのポイント数、多くのタイマーの状態（ボーナスタイマーなど）、さらにはサウンドチャネルの状態など、多くの要因の影響を受けます！ もちろん、これは完全なリストではありません。



次の乱数を計算する式自体は非常に単純です。 詳細には触れず、Cでどのように見えるかを示します。

uint8 seed = 0; uint8 index = 0; uint8 rand() { seed = (seed << 3) - seed + secondsCounter + zeroPage[++index]; return seed; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードからわかるように、0〜255の範囲の擬似乱数値をいつでも受け取ることができます。さらに、その分布は、不滅のゲームプレイからわかるように、非常に適切です。

ボーナス

ゲームには、ヘルメット、ウォッチ、スペード、スター、手ren弾、戦車、銃の7種類のボーナスがあります。 同時に、後者は元のゲームではまったく使用されていませんが、海賊版の修正で見つけることができます-そこで、即座に最大のアップグレードを行います。 撮影した3つの星に相当します（一部のバリエーションでは、「森」を破壊することもできます）。 残りのボーナスのアクションは、誰もが知っていると思います。 ただし、念のために申し上げます。時計は敵を凍結させ、シャベルは本部の周りに鎧を作り、星は戦車の力を増加させ、手destroy弾は画面上のすべての敵を破壊し（ポイントは与えられません）、戦車は命の数を増やします。







ところで、銃を持った海賊版では、別のボーナスがあります-あなたが水の中を移動できる船です。 また、一部の変更では、対戦相手がボーナスを受け取ることができ、これによりゲームのバランスが根本的に変わります。 そのような変更のコレクション全体もあり、バージョンはさまざまな同様の些細な点で異なっていました。



どうやら、当初はゲームに8つのボーナスを含める予定でしたが、最終的には6つのボーナスがありました。 ただし、ボーナスが表示されると、8を法とするランダムな値（0から7）が取得されます。これは、ボーナステーブルのインデックスであり、ゲームに含まれていないボーナスの場所は星と手g弾によって再び占有されます。 その結果、それらの損失の確率は1/4であり、残りのボーナスの確率は1/8に等しくなります。



ボーナスウォッチとヘルメットは10秒間有効です（プレイヤーがリスポーンすると、ヘルメットはリスポーンの時間を含めて3秒間持続します）、ボーナススペードは20秒です。



ボーナスキャリア自体-点滅するタンク-敵の格納庫に17、10、または3つのタンクが残っている場合に表示されます。 つまり 4、11、18という番号のタンクはボーナスタンクです。



ゲームの標準による秒は通常より少し長く続くことに言及する価値があります：コンソールのNTSCバージョンは60フレーム/秒のスクリーンリフレッシュレートを持ち、秒を追跡する最も簡単な方法は、60を法とするフレームカウンターがゼロの場合、各フレームの秒数を増やすことです。 ただし、計算を簡素化し、オーバーフローの結果としてフレームカウンターをリセットしてもこの方法では計算に影響しないため、この数値は64​​（0x40）に丸められました-このモジュールで数値を取得するには、0x3Fで論理乗算を行うだけで十分です。 ゲームの秒は1.06実秒ですが、これはフレーム数で測定される期間には適用されません。



ゲームに精通しているすべての人に知られている興味深い事実：行動を止める前に、本部周辺の防御が「点滅」し始め、レンガまたは装甲フェンスに変わります（これはボーナスの最後の4秒間に起こります）。 この場合、本社周辺の保護が部分的または完全に破壊された場合でも、点滅するたびに、レンガの壁全体に完全に戻るまで復元されます。

相手の知性

もちろん、戦車のAIは戦術的な分析器ではありませんが、いくつかのロジックはまだ計算されています。



まず、ゲームには動的な複雑さがあります。 複雑さの指標として、敵のリスポーン間の遅延の値が使用されます。これは、プレイヤーのレベルと数に依存します-これらの値が高いほど、リスポーンが速くなります。 特定のレベル（ゼロからの番号付け）のフレームでのリスポーン時間とプレイヤー数は、次の公式を使用して計算できます： 190 - level * 4 - (player_count - 1) * 20



。 秒単位で時間を取得するには、結果に60を掛けるだけです。



戦車の動作には3つの期間があります。最初にランダムに動き、次にプレイヤーを追いかけ、最後に本部を攻撃し始めます。 最初の2つの期間の期間は同じで、8つのリスポーン期間に等しくなります。 つまり、リスポーン時間を8で割ると、秒単位で期間が得られます（または、8倍するとフレーム単位で同じ時間が得られます）。たとえば、最初のレベルと1人のプレーヤーの場合は23秒になります。 3番目の期間は、秒カウンタがゼロにリセットされる（256に達する）まで続き、期間のサイクルは再開しません。



この敵の戦術はすべてコマンドシステムに基づいており、8バイトが割り当てられています。プレイヤーの戦車に2つ、敵の戦車に6つです。 このバイトの上位4ビットはコマンドに使用され、残りの下位4ビットは引数に使用されます（通常、これは移動の方向です）。 結果は16個のコマンドで、それぞれにハンドラーがあります。 ハンドラーは、動きを処理した後、各タンクのフレームごとに1回呼び出されます。



既存のコマンドを表面的に検討します。

• 0-NOP（タンクなし）
• 1..7-タンク爆発の処理（アニメーションフレームのコマンドで）
• 8-ステータスの処理（氷上でのスライドなど）
• 9-方向を変える
• A-タイルの境界線の交差を確認する
• B-本社に移動
• C-2番目のプレイヤーの戦車に移動する
• D-最初のプレイヤーの戦車に移動する
• E..F-管理チームを復活させる

方向を変更する機能があります。これは、行動の最初の期間で呼び出されたときに、戦車の方向をランダムに変更します.2番目の期間では、偶数の戦車に最初のプレイヤーに移動するコマンドを与え、奇数の戦車には-2番目に、そして3番目に本部に向かって移動するコマンドを与えます。



敵の戦車がタイルの境界を越えるとき（両方の座標が8の倍数になるとき）、この関数が戦車に対して呼び出される確率は1/16です。 戦車の座標が8の倍数でない場合、または方向転換機能が呼び出されず、これで戦車が障害物にぶつかった場合、1/4の確率で次のことが起こります。少なくとも1つの座標が倍数でない場合、戦車は反対方向に方向を変えます8、それ以外の場合、タンクは方向転換コマンドを与えられます。



方向変更コマンドが実行されると、何か他のことが起こります：確率1/2で、上記の関数が呼び出されます。そうでなければ、等しい確率で、リストから前または次の方向が取られます：上、左、下、右（つまり、タンクが回転します時計回りまたは反時計回り）。



このようなすべてのロジックは、このような擬似コードの形で想像できます。

 void changeDirection(Tank tank) { // period duration in seconds, respawn time in frames const int periodDuration = respawnTime / 8; if (time() < periodDuration) { // first period tank.setRandomDirection(); tank.setCommand(cmdCheckTileReach); } else if (time() < periodDuration * 2) { // second period if ((firstPlayer.isAlive && tank.number % 2 == 0) || !secondPlayer.isAlive) { tank.setCommand(cmdMoveToFirstPlayer); } else { tank.setCommand(cmdMoveToSecondPlayer); } } else { // third period tank.setCommand(cmdMoveToEagle); } } void onCheckTileReachCommand(Tank tank) { if (!tank.isPlayer && tank.x % 8 == 0 && tank.y % 8 == 0 && rand() % 16 == 0) { changeDirection(tank); } else if (!tank.isPlayer && frontTile.isBarrier && rand() % 4 == 0) { if (tank.x % 8 != 0 || tank.y % 8 != 0) { tank.invertDirection(); } else { tank.setCommand(cmdChangeDirection); } } } void onChangeDirectionCommand(Tank tank) { if (rand() % 2 == 0) { changeDirection(tank); } else if (rand() % 2 == 0) { tank.rotateClockwise(); } else { tank.rotateAnticlockwise(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タンクが障害物または壁に接すると興味深い状況が発生します。この場合、タンクが回転しなくても、座標の1つは常に8の倍数であり、その前にタイル障害物があるため、回転の確率が数倍増加するためです。 したがって、戦車は実際には定位置に留まりません。たとえ角やニッチになったとしても、すぐにそこから移動します。



敵の射撃の状況も同様に興味深いものです。 単独では、それらは戦車とは完全に分離して発生します。各敵には1つの弾丸があり、各フレームのショットによって、この弾丸を発射するかどうかが決定されます。 弾丸がすでに飛行中の場合、ショットは発生しません。そうでない場合、戦車が発砲する確率は1/32です。 この場合、弾丸は中央の戦車の正面にあり、戦車の方向を継承します。



デモンストレーションモードでのプレイヤーの戦車の動作について、いくつかの言葉を言う価値があります。 ここではすべてが単純です。画面にボーナスがある場合、戦車はそれらに気を配ります（弾丸が彼らが遭遇する障害を越えて飛ぶと、彼らは道に沿って立ち往生することができます）。 そうでなければ、彼らは単に最初に利用可能な戦車を追いかけ、もし何も残っていなければ、彼らは静止します。 砲弾は敵の戦車と同じルールに従って発射されます。 デモモードでの単独の発射は効果がありません。

衝突処理

衝突計算は、常にかなり要求の厳しい作業であり、NESのようなプロセッサにとって重要な場合があります。 タンクと「額」の実装との相互作用の計算を誤ると、タンクの各ペアを比較する必要があります。これは、数が少ないにも関わらず、クロック速度が1.76 MHzのプロセッサにとってはかなり高価な手順です。 しかし、マップ上の戦車に加えて、解放されたシェルも移動することを忘れないでください。 そのため、開発者はかなり興味深いトリックを行いました。



事実は、各タンクがその下に目に見えない壁を「描く」ということです。 したがって、タンクとレベル要素との衝突検出の段階で、タンク間の衝突検出が発生します。特定の座標に障害物があるかどうかを判断するのに十分です。 副作用があります：多くの人は、タンクを前方に移動するタンクに「ドライブ」しようとすると、タンクがある程度の距離を移動するまでプレイヤーの動きがブロックされることに気づきました-その瞬間、次のタイルに移動し、そこに新しいものを「描画」壁と古い「消去」。











砲弾が戦車に命中しても同じ効果が見られます。 視覚的には、接触はタンクのスプライトの境界から異なる距離（内側と外側の両方）で発生します-0から7ピクセルまで。 しかし、戦車がそれらの下に壁を描く場合、弾丸はそうではありません。 さらに、シェル間の衝突の計算には、ほとんどのフレーム時間がかかります！ 特別な場合には、それでも十分ではない場合があり、これらの操作はすべて次のフレームに転送され、現在の操作は変更されません。 つまり はい、タンチキには遅れがあります。



あるプレイヤーのシェルが別のプレイヤーにヒットした場合、2番目のプレイヤーは192フレームのモーションコントロールを失います。 3秒間ゲームします。 しかし、デモンストレーションモードでは、これは起こりません。



発射物には、衝突がチェックされる2つのポイントがあることに注意してください。 それらは弾丸の鼻の側面にあり、実際には2つの衝突を同時に処理できます（そうでなければ、少なくとも1つを検出した後、発射物が消えます）。 これは、たとえば、レンガブロックの中心を狙った場合に発生します。ストリップ全体が破壊されます。



もう1つの興味深い点は、低速の弾丸（速度が少し遅い）がすべてのフレームではなく、フレーム全体で処理されることです。 理論的には、ゲームが奇数フレームごとにスローダウンし、プロセッサがそのような弾丸の衝突の処理に到達する時間がなく、それを延期する状況が発生する可能性があります。 しかし、次のフレームでは、彼はそれをまったく処理する必要はありません！ このような状況の組み合わせにより、ゲームの速度が大幅に低下した場合、一部の緊急事態では低速の弾丸が壁を通り抜けて飛ぶことがあります。

ムーブメント

ゲームの速度は、座標を変更するときにスキップされるフレームの数によって決まります。 そのため、たとえば、プレーヤーの座標は、ゲームの最速の敵である4つのうち3フレームごとに変化します。



同じことがシェルにも当てはまります。シェルには2つのタイプがあります。1フレームあたり4ピクセルの速度で飛行する高速と、1フレームあたり2ピクセルの速度を持つ低速です。

タンク	速度、ピクセル/フレーム	発射体タイプ	タンク	速度、ピクセル/フレーム	発射体タイプ
	3/4	遅い		2/4	遅い
	3/4	クイック		4/4	遅い
	3/4	クイック		2/4	クイック
	3/4	クイック		2/4	遅い

衝突は移動中にも処理する必要があるため、フレーム全体に可能な限り均等に分散して計算を最適化することが適切です。 最も単純なアプローチでは、すべての敵の動きを偶数フレームで処理し、奇数フレームでは高速装甲兵員輸送車の動きのみを処理すれば十分です。 しかし、その後、奇数フレームが過負荷になる可能性があり、ゲームは単に遅れます。



実際、負荷はかなり巧妙に分散されます。 フレーム番号とタンク番号の間で「XOR」が作成され、その結果のみパリティ/奇数がチェックされます。 その結果、偶数フレームでは低速タンクの半分が処理され、奇数フレームではもう一方が処理されることがわかります。



氷上での滑走に関するいくつかの情報。 ここではすべてが簡単です：プレイヤーが氷の上で方向ボタンを放した後、タンクはさらに28フレーム（つまり21ピクセルが通過する）の間、または氷を離れるまで自力で動きます。 この期間中、追跡されたトラックの状態は変化せず、乗り物の音は失われません。また、氷上で方向ボタンを押すと、この瞬間のスリップタイマーがゼロの場合、特徴的な音が再生されます。

イースターエッグ

イースターエッグは当時の多くのゲームで見られますが 、バトルシティを迂回しませんでした。



タイトル画面で建設モードを選択した場合、7回（START、STARTを押して）入出してから、2番目のボタンAを8回押して最初のジョイスティックの下ボタンを押し、次に最初のジョイスティックを押して右に押します2番目のボタンBで12回、最後に最初のジョイスティックでSTARTボタンを押すと、悲劇的なラブストーリーが表示されます。







さらに、ゲームでは未使用のデータを見つけることができます-開発者の名前（大久保良一、武文武道、小澤淳子）および象形文字は、ラブストーリーの主人公の名前と通りの名前（おそらく彼または彼の恋人が住んでいた）を意味します。







おそらく、ここの詳細には触れません。これは、上記のリンクで詳細に説明されているためです。

エピローグ

結論として、ゲームを作成する前は、ある意味、今よりも優れた芸術でした。 これは途方もないスキルです-ハードウェアの制限内に収まり、同時に良いゲームを作成します。 これは、本質的に同じ目標を追求する、想像するのが難しい傑作を作成するデモシーンに似ています。



現在、これらはすべて過去のものであり、実際に実装する方法について考えることはできません。 私の意見では、これはゲーム開発プロセスに入るためのしきい値を大幅に低下させ、徐々にではあるが確実にアートよりも通常のビジネスに変わります。 おそらく、私はこの点であまりにも美的です。