Qiitaには画像アップロード上限があるんで 古い記事をまとめ直す。
ちらつきの解消については 次のサイトの記事が参考になる。
「SpriteRenderer、とりあえずの隣接ドット対策」Unity / VRゲーム開発日記＠長崎
http://icoc-dev.hatenablog.com/entry/2014/09/29/111645
Unity2Dでタイルマップを敷き詰めてスクロールさせようぜ
前回： http://qiita.com/muzudho1/items/86fedc87b4b9e5731bfb
後ろは だいたい こうなっている。
- 画面 見えているところ
- ステージ カメラが動いてくる。カメラに映ってないところも作っている。Unity では シーン と考える
- 3D空間 何も置いてなくても、えんえんと空間は在る
- ステージデータ 木とかコピーして増やせるんで、コピー元になるのを置いている。Unity では アセット と考える
撮影されてるところ は、コンピューターで計算する対象になるが、映ってないところは計算を省いてくれる。「カリング」でググろう。
じゃあ、Unityの３Ｄ空間に バンバン 山とか 木とかを置いていこう、となるんだが、木を１本１本 作っていては コンピューターの計算対象になる。
木とか コピーで水増しして映しておけばいいケースもある。計算を省こう。「プレファブ」でググろう。
Unityの シーン が、ステージ・データ そのものだ。
じゃあ、上図の ステージデータ って何か？
ゲーム開発受注の案件によっては
- JSON形式にしてステージを送受信したい、
- ステージは 方眼紙（配列）のイメージをしている
といったことがある。
Unityの シーン を直せず いじらず、テキストエディターで編集したい、ということだ。
これを とりあえず ステージデータ と呼ぶことにした。
このように ステージデータを編集するためのツールは マップエディタ
などと呼ばれ、アセットストアに いろいろ売ってるようだ。
調査予算とかないんで、無料で使える Tiled Map Editor で補うことにした。
「Tiled Map Editor」
http://www.mapeditor.org/
容量の面での問題
ステージをタイル形式にして JSON で送るのだから、転送容量は でかくなる。
ステージのデータが テキストで １メガバイトを超えそう……、ということは「気にしなくていい」案件なら このまま進んで問題ない。
気にする場合は 別に対策を取ること。
スクロール機能
ランゲーだと 横に延々と走っていくわけだが、ステージ全部を最初にローディングするというのは 非現実的だ。
ステージの初めの方で すぐに死んでしまうプレイヤーもいるだろう。遊ばな後ろの方のステージを ローディング するのもおかしい。
まずは短いステージでやってみる。
上図の黒い枠を ０プレースホルダ―、１プレースホルダ―、２プレースホルダーと名付けるとする。
画面が上に行ってしまえば、０プレースホルダーを ２プレースホルダーの後ろに移動させるという仕組みだ。
// 多分こんな感じで 上に行く
transform.Translate( 0, 200f, 0 );
プレースホルダーの長さは 設定で伸ばせるようにしておこう。
どれぐらいの大きさが ゲームプレイに影響を与えない通信に収まるのか 設計フェーズでは分からない。
プレースホルダーの中は、左上から ０セル、１セル、２セル…… とする。
そして その場所に セル・ゲーム・オブジェクト を置いておく。
ステージ・データの タイル・データによって、
セルの スプライト画像を貼り換えたり、コライダー（BoxCollider2D）をＯＮ／ＯＦＦ したりすればいいのではないか。
ただ、別々に ３つのプレース・ホルダーが動くプログラムを書くのが難だったので プレース・ホルダー・チェイン という名前の１つのクラス、１つのゲーム・オブジェクトにして 実装してみた。
// スクリプトで コライダーを追加する例
GameObject go = new GameObject("Cell0", typeof(SpriteRenderer), typeof(BoxCollider2D));
BoxCollider2D col = go.GetComponent<BoxCollider2D>();
col.size = new Vector2( 0.4f, 0.4f);
例えば、GameObject のコンストラクタは可変長引数になっていて、コンポーネントを追加していくことができる。