みんなでまもって騎士：たまには技術的な話でも
いつもゲームの中身の話が多いので、たまには技術的な話でもしてみようと思います。
とはいっても、中身はほぼ一人で作ってるので、それほど技術的に優れたことはしていません。
キャラが多くて驚く方も多いようですが、特に大したことはしていません。
３Dのゲームとは違って２Dのゲームは毎フレーム頂点数が変わってしまうため、
一つずつ描画依頼を出すとすぐに重くなってしまいます。
そこで、あらかじめ一つにまとめることで描画周りは最適化をしました。
とはいえ、根本的には30フレーム/秒にしたことが一番効果があったと思います。
前作のまもって騎士では60フレーム/秒だったのですが、
本作は画面数や敵の数が何倍にもなっています。
見えない敵は処理を省きたいところですが、
マルチプレイ前提なのでホストにとって画面外でも、
クライアントにとっては違うときもありますので、省くわけにもいきません…。
また、３DSの液晶画面で、しかも画面変化の小さい２Dゲームでは、
60フレーム/秒はそれほど恩恵は得られません。
まもって騎士はキャラもエフェクトも多いので、それなりに効果はあるものの
死守するほどの意義は薄いので早々に見切りをつけて30フレーム/秒でやりたいことが実現できる環境を作りました。
とはいってもやっぱり60フレーム/秒は魅力的なんですよね…。
たまに60フレームモードで動作させたりしてました。
実はシングルプレイならほとんどのシーンで60フレーム/秒で動作しているんです。
マルチプレイになるとさすがにちょくちょく落ちてしまうんですけどね…。
そう思うと３DSのマシンパワーはあなどれないですね。
CPU負荷の話でいうと、このゲームは画面がグリッド状になっていて、
モンスターはグリッドに沿って移動しています。
移動中はほとんどの敵が周囲を見ていないため、数は多くても負荷が軽減されます。
これは通信の負荷にも好影響を与えています。
話しは変わって、キャラが水などに浸かった時に体が半分隠れるのですが、
実はこれが結構大変なんですよ。
ご存知の方も多いと思いますが、ファミコンでは８ｘ８ドットが絵(スプライト)の単位となっています。
小さいキャラはこれを、縦２つｘ横２つの４枚を正方形に並べて16ｘ16ドットのキャラクターを表現するわけです。
そして、下２つを描画しないことで水没などの表現をしていました。
時代は過ぎて現代の２Dゲームではこうした８ｘ８ドットの制限もなく、
一つのキャラクターを何枚もの絵を組み合わせて表現することができるようになりました。
単純に表現の幅が広がったことも大事ですが、作業コストにも影響しています。
まもって騎士では頭部と体、武器などが別に描かれていて、
スプライトエディターという専用のツールでアニメーションを作っています。
バラバラに作ることで、キャラの量産作業をシンプルにでき、管理も楽になります。
話を戻して、水没の表現をするためには、一定ラインより下の絵を非表示にしないといけません。
ですが、何枚もの絵を組み合わせている以上、どの絵を非表示にすれば
水没感がでるかはプログラム側からは判断できません。
そこで、水に入ったキャラを描画するときに、全体を斜めにして地面に突き刺すことで水没感を出しました。
画面上から見ると絵が斜めになっているとはわかりませんが、横から見ると足元の頂点が地面を突き抜けています。
正確にいうとキャラの足元にいくに従って地面（画面奥）に向かって引き延ばすような処理になります。
この表現は昔っぽくて気に入ってます。
もう一つ面白い処理にラスタースクロールがあります。
オープニングでロゴがうねうねしてるアレです。
本物のラスタースクロールは画面の走査線に合わせて変化を付けていくのですが、
今の時代ならもっと違う方法で実現できます。
ていうか今の時代だとできないかもしれませんね…。
で、普通なら、描画結果を弄った方が楽と思うんでしょう。
ですが、私はデザイナ出身でツールでできることはツールでデータを用意した方が楽だったりします。
下手に新しいことに挑戦するより、手元の知識の応用で実現しちゃったわけです。
まずスプライトエディタで縦１ピクセル幅の横長データを128枚に作りました。
この１ピクセル相当のポリゴンを画面に敷き詰めるとロゴになります。
（プログラマから見ると開いた口が塞がらないようなやり方かと思います…）
あとはそれぞれのスプライトにサイン波で位置を変えてやればラスタースクロールの完成です。
リザルト絵の某タツノコ的スキャニメーション風表現もこれの応用です。
特別なプログラムを描く必要もなく、処理を稼ぐ必要もない場面でしたので、
案外シンプルに実装できたと思います。
[karu_gamo]
とはいっても、中身はほぼ一人で作ってるので、それほど技術的に優れたことはしていません。
キャラが多くて驚く方も多いようですが、特に大したことはしていません。
３Dのゲームとは違って２Dのゲームは毎フレーム頂点数が変わってしまうため、
一つずつ描画依頼を出すとすぐに重くなってしまいます。
そこで、あらかじめ一つにまとめることで描画周りは最適化をしました。
とはいえ、根本的には30フレーム/秒にしたことが一番効果があったと思います。
前作のまもって騎士では60フレーム/秒だったのですが、
本作は画面数や敵の数が何倍にもなっています。
見えない敵は処理を省きたいところですが、
マルチプレイ前提なのでホストにとって画面外でも、
クライアントにとっては違うときもありますので、省くわけにもいきません…。
また、３DSの液晶画面で、しかも画面変化の小さい２Dゲームでは、
60フレーム/秒はそれほど恩恵は得られません。
まもって騎士はキャラもエフェクトも多いので、それなりに効果はあるものの
死守するほどの意義は薄いので早々に見切りをつけて30フレーム/秒でやりたいことが実現できる環境を作りました。
とはいってもやっぱり60フレーム/秒は魅力的なんですよね…。
たまに60フレームモードで動作させたりしてました。
実はシングルプレイならほとんどのシーンで60フレーム/秒で動作しているんです。
マルチプレイになるとさすがにちょくちょく落ちてしまうんですけどね…。
そう思うと３DSのマシンパワーはあなどれないですね。
CPU負荷の話でいうと、このゲームは画面がグリッド状になっていて、
モンスターはグリッドに沿って移動しています。
移動中はほとんどの敵が周囲を見ていないため、数は多くても負荷が軽減されます。
これは通信の負荷にも好影響を与えています。
話しは変わって、キャラが水などに浸かった時に体が半分隠れるのですが、
実はこれが結構大変なんですよ。
ご存知の方も多いと思いますが、ファミコンでは８ｘ８ドットが絵(スプライト)の単位となっています。
小さいキャラはこれを、縦２つｘ横２つの４枚を正方形に並べて16ｘ16ドットのキャラクターを表現するわけです。
そして、下２つを描画しないことで水没などの表現をしていました。
時代は過ぎて現代の２Dゲームではこうした８ｘ８ドットの制限もなく、
一つのキャラクターを何枚もの絵を組み合わせて表現することができるようになりました。
単純に表現の幅が広がったことも大事ですが、作業コストにも影響しています。
まもって騎士では頭部と体、武器などが別に描かれていて、
スプライトエディターという専用のツールでアニメーションを作っています。
バラバラに作ることで、キャラの量産作業をシンプルにでき、管理も楽になります。
話を戻して、水没の表現をするためには、一定ラインより下の絵を非表示にしないといけません。
ですが、何枚もの絵を組み合わせている以上、どの絵を非表示にすれば
水没感がでるかはプログラム側からは判断できません。
そこで、水に入ったキャラを描画するときに、全体を斜めにして地面に突き刺すことで水没感を出しました。
画面上から見ると絵が斜めになっているとはわかりませんが、横から見ると足元の頂点が地面を突き抜けています。
正確にいうとキャラの足元にいくに従って地面（画面奥）に向かって引き延ばすような処理になります。
この表現は昔っぽくて気に入ってます。
もう一つ面白い処理にラスタースクロールがあります。
オープニングでロゴがうねうねしてるアレです。
本物のラスタースクロールは画面の走査線に合わせて変化を付けていくのですが、
今の時代ならもっと違う方法で実現できます。
ていうか今の時代だとできないかもしれませんね…。
で、普通なら、描画結果を弄った方が楽と思うんでしょう。
ですが、私はデザイナ出身でツールでできることはツールでデータを用意した方が楽だったりします。
下手に新しいことに挑戦するより、手元の知識の応用で実現しちゃったわけです。
まずスプライトエディタで縦１ピクセル幅の横長データを128枚に作りました。
この１ピクセル相当のポリゴンを画面に敷き詰めるとロゴになります。
（プログラマから見ると開いた口が塞がらないようなやり方かと思います…）
あとはそれぞれのスプライトにサイン波で位置を変えてやればラスタースクロールの完成です。
リザルト絵の某タツノコ的スキャニメーション風表現もこれの応用です。
特別なプログラムを描く必要もなく、処理を稼ぐ必要もない場面でしたので、
案外シンプルに実装できたと思います。
[karu_gamo]
