とにかく画面スクロールと座標の管理が難しいです。
一般的にアクションゲームのメイン画面にはX座標とY座標があり、それぞれの座標位置を線基準で指定して、オブジェクトやBG（背景）を配置していきます。
オブジェクトの移動や画面スクロールなどは、座標値を変化させる事で実現していくようになり、その座標計算処理が一般的にゲームの内部処理になります。
プレイヤーがコントローラーで入力した情報を元にして、オブジェクトの座標を更新してゲームは成り立っています。
つまりゲームのCoreな部分ですね。
この話は前にもしたような記憶があります・・・。
画面スクロールとオブジェクトの位置関係を保持する座標値は、ローカル座標と呼ばれるものとそれに対してグローバル座標と呼ばれるものがあり、時にグローバル座標なしでローカル座標とページ位置だけで実現しているゲームもあります。
今回私が制作しているものは、グローバル座標を指標にして、それを使ってローカル座標を算出し、相対的なページ位置を算出してアクションゲームのBGを動かしています。
その情報を元に、BGとアバター（このゲームにおいてはロックマンの事）との接触判定などを行っています。
ファミコンのゲームは一般的に画面サイズがx:256/y:240(偶に224)なので、そのサイズの画面単位でローカル座標が算出されます。
例）[GLOBAL] x:500/y:450 → [local] x:244/y:194
その後、例えばスタート地点の部屋から右に部屋がある場合は、X座標が256 <= x && x <= 512となったりします。
途中でワープする演出などがある場合は例外ですが、基本的には全部同じ領域にページを展開したインデックスを持っており、それにアクセスしてページを描画する仕組みです。
グローバル座標がx:500/y:450の場合だと、
・1ページ辺りの最大X座標 256、最大Y座標 240
・x:500 は 256 より大きいため、500 – 256 で 244、右のページへ移動
・244 は 256 より小さいため、該当ページに到達したとする
・y:450 は 240 より大きいため、450 – 240 で 210、下のページへ移動
・210 は 240 より小さいため、該当ページに到達したとする
このようにして画面スクロールを実現しています。
こうしてみるとシンプルなように見えますが、コード化するとかなり複雑怪奇になります。
その辺りがゲーム開発が敷居が高いと言われる所以なのかな～と思ったり思わなかったり。
まぁいずれにせよ、ゲームを実現する手段は多種多様でやり方は人それぞれと言ったところでしょう。
一番難しかったのは固定ページスクロールです。
仕組みというよりは、ロジックが難しいイメージです。
画面スクロール自体は隣接有無でチェックしながら進むのですが、問題はそこではなく・・・
固定スクロールの場合、
スクロールを開始する地点が対面の端部分に到達した時であり、
それまでは画面を固定しておく必要がありました。
その場合は、隣接部屋があるがスクロールさせないという概念を既存の仕組みに取り入れる必要があり、それがあまりにも分岐を余分に呼び起こす要因となってしまいました。
そこでAIに片づけてもらったのですが、やはり管理クラスの保守（というか維持？）は大変ですね。
設計の大切さがよく分かる工程でした(笑)
そんなわけでなんとか実装自体はできたので、これからリファクタリングをするのですが如何せんクラスが増えていくのがなんかちょっと違和感というか慣れませんね(´･ω･`;
私がもともとC言語などの手続き型に慣れきっていた人間だったので、その慣習がまだ体に残っているんでしょうか。
そんなわけで今回のエントリーはここまでです(・∀・)
次回は「ロックバスター」の実装を進めていきたいと思います。
どこまで行けるか分からないけど、今年も頑張ろう。
コメント