BGEでは、AnimetedTextureが標準実装されており、UPBGEでもそうなっていますが、これはタイルを使った画像をアニメーション処理することができる機能になっています。
のようにUVEDITORで画像を読み込むと、ゲームプロパティに項目に
■ アニメ
■ タイル
というものがあります。アニメは、何フレーム目からそれが行われて、何フレーム目で終わるかの設定と速度の指定が可能で、タイルについては、スプライト処理のゲームのタイルの概念と同じです。つまり、スプライトを使ったゲームのアニメーション処理が可能になっています。
この時に、X軸やY軸を固定できるのでその列の方向だけでアニメーションを完結させることが可能です。
こうした処理は
■ WOLF RPG EDITOR
https://www.silversecond.com/WolfRPGEditor/
のようなゲームエンジンがそうした仕様になっています。RPGツクールもそうですが、基本的にキャラの動きはタイルで制御してあり、
のようなチップを用意してそれを動かすことになります。ウディタでは、
のような生成ツールもありますが、320x240のオブジェクトのほうが自由度が高く、子供と大人の双方が使えるので、そうした点でキャラを複数用意しやすく戦闘時のドット絵までそろっているという利点があります。その為、とりあえず、機能を理解するために作ってみるという状態だと処理も軽いので320x240の解像度でゲームを作ることになります。
とりあえず、このゲームエンジンは1280x720まで対応しているので、タイルやチップのサイズを企画に合わせて、素材の生成をすることになりますが、このチップやタイルと同じようなことがBlenderのBGEでも利用できます。つまり、音がSEを合わせるような条件でいい場合やゲーム内で何か動きのあるものが表示されているだけだと、こうしたタイルで動かすという選択肢があります。
スプライトを使ったゲームですが、特定の範囲でタイルを指定して作成していくのですが、タイル自体が配列なので、そこに何を配置するかを決めてマップを作ります、その為、先ほどのチップとは別に
のようなマップを作るタイルが存在しており、
のような戦闘シーンで使用するグラフィックは個別に用意されています。当然、エフェクト類も全く別の素材ですから
■ マップ
■ キャラ
■ 戦闘シーンのキャラの絵
■ 会話などで登場させるウインドウの横の画像
■ コモンで追加して表示させることが可能な立ち絵
などは全く別の管理と表示方法になります。つまり、この条件だと、
【 マップの構造 】
タイルのXYの並びなので特定の範囲を配列で考えることが
できる。
タイルサイズでマップそのものの解像度の設定が可能
【 タイルの構造 】
単一の画像にタイルの範囲をしていしておき、その基軸とな
る【０】の部分の 【 ( X , Y ) - ( X1 , Y1 ) 】の座標さえ決ま
っていれば、タイルの幅と高さ分だけ移動すれば、
■ X+1
■ Y+1
が可能になるため、そのタイル座標を配列で管理すれば、X
とYの数値でタイルの位置が指定できる
ようになります。また、1枚数のタイルで対応するのでマップで用意するレイヤーで使用する画像は既に読み込まれたものを使用することになるため、その都度読み込みが発生しないため、速度敵の軽くできるという利点があります。
以前、【 BGEは現在のシーンと上下にシーンを配置できる 】と書きましたが、ウディタも
のような三層構造になっており、三層で構築されたマップ上にイベントを配置する作りになっています。
のような画面構成になっていますが、NPCは全てイベントです。
のようにイベントとして管理されているのですが、
のような形で、配置したイベントとその挙動が表示されます。
以前、ウディタは開発言語の知識が必要ないと書きましたが、それと同時に【 アルゴリズムなどは考える必要がある 】とも書きましたが、制御系については、コモンと言う物を用います。サンプルゲームには既に顧問が実装されているわけですが、
のような挙動をインタプリタ言語のような感じで記述順に実行させていくことになります。
つまり、IF分やSELECTCASEやFORなどの命令文をダイアログ上で指定するような仕様になっているので、それをどう処理するのか？については、自分で考えて実装することになります。
とりあえず、設定についてはそうなっており、
【 オブジェクト単位で挙動指定がされておりプレイヤーのアク
ションや常時何かしらの処理が存在しており、特定のイベン
トで処理が発生するような作り 】
になっています。つまり、【 プログラミング言語は存在しないが、コモンと言う独自の記述を用いた制御を実装する必要がある 】と言う作りになっています。条件分岐や繰り返した複数の選択肢がある場合にどれを選ぶか？というのは何かしらの処理を実装することになるので、そうした処理用の言語やロジックやノードなどの機構が必要になるのは当然ですから、実装された制御用の実装機能についての学習は必要になります。
とりあえず、
のようにイベントを配置すると作成/編集が可能になるので、マップ上に任意のイベントを配置できるのですが、
のようにチップを指定することで、
のようにキャラを配置できます。また、
のようにイベントを設定して、テストプレイを行うと
のように機能します。こうした感じでプレイヤーのアクションに対してのリアクションを用意したり、空間に何かしらのイベントを配置することも可能になりますが、チップの非表示の場合だとそのポイントになり、その範囲を広く指定することでその範囲で何かしらのイベントを指定することも可能です。また、
のような感じで音についても、メモリーに先読みロードなども可能になっているので、処理を軽くする選択肢が複数存在しています。
スプライト処理のゲームを使う場合も3DCGのゲームと同様に
■ フレームレートの概念
■ 秒数（ミリ秒単位の処理）
■ フレームの取り扱い
と言うのは存在します。3DCGだとアクションでそれを使いますが、スプライト処理の場合、NPCの挙動をランダムではなく意図的に動かす場合に使用します。
動く物を作る場合、【 秒間にどれだけ書き換えが発生するのか？ 】というのは動画と同じように存在しますから、当然のようにフレームレートの概念は出てきます。当然、制作時に意図したフレームレートで動かなければ書くついてしまったり動かずに紙芝居のような状態になってしまいますから、実機での挙動を見る場合に、適正なフレームレートが出ている事も重要になってきます。秒数ですが、これも1/1000秒の単位での指定が可能になっているので、これで音ズレを回避するように鳴らしたり、タイミングをずらすなどの調整が可能になりますが、音と同様にチップのアニメーションやキャラの挙動のタイミングなどもフレーム単位で調整をすることになります。
これは、3DCGAを作る場合に、タイムライン上でどのタイミングで動くのが最適かを指定する時に、その挙動の発生タイミングをフレームで指定するのと同じで、その条件でどのタイミングで動くのか？を指定する場合にはフレームで 【 間 】 を作ることになります。完全に停止して入力待ちに出来る場合は別ですが、一連の動きだと秒数指定で止めるか、フレーム単位で調整するかになりますが、音や挙動の制御については、【 自動処理で動く物が存在する 】のでその挙動を指定する場合に、間やズレのない状態（や演出で意図的にズラす）を作ることになりますからそう言った制御が発生します。
3Dのゲームエンジンでもスプライト処理の2Dのゲームやノベルゲームのような物を作ることが可能ですが、その理由は、
【 平面の処理は板ポリゴン＋AnimatedTextureの処理 】
になり、ノベルゲームの場合だと、キャラの製作方法とドライバーとリグの構成が通常の物と少し異なる状態になるだけだからです。
文字の表示がラベルでテキスト表示だと、文字列を読み込んでそれを変数に代入して表示段階で一文つづ読み込んで表示をさせていくと一気に文字が表示されるのではなく、徐々に文字が表示されるような仕様に出来る（のですが、ボタンを押すと全表示などを追加することになるので、結果的に、それをすべて表示する選択も用意しておいて、入力で全表示とカーソル表示をさせることになりますが。。。）のですが、何で表示させているのか？で内容が違ってきますし、どういった表示を行うと軽くなるのか？も作りによって変わってきます。
ゲームの場合、
■ キャラの挙動
■ MOBの挙動
■ マップの生成
などが必要になりますが、【 ゲームシステム 】がないとどうにもならないので、その制作と必要な機能の実装の作業は何を使ったと居ても発生します。その時に、【 ソフトで用意されている制御系の機能の学習 】は常に発生します。
BlenderのBGEを用いた場合、動画はPythonで実行できるのですが、その仕様は2.4xの時代から存在しており、カメラの映像を反映できる仕様から【 Mirro.py 】なども存在しています。また、【 カメラの視点 】と言う特性があるので、【 焦点距離を長くしてスコープの先にカメラオブジェクトをつけておくと、スコープの視点をカメラの切り替えで表現できる 】と言う面白い機能もあります。ビデオテクスチャーについては、そう言った機能があるので、結構自由度が高いのですが、この機能を使うと、【 ゲーム中で動画を用いることができる 】ので、ノベルゲームのような作りにした場合、動画を再生できます。
また、キャラを動かす場合、
■ セルルックなシェーダーでモデルを表示してフレーム内に
表示して動かす
■ 2Dのモデルを作って、シェイプキーとリグで動かす
と言う選択肢があります。とりあえず、セルルックの場合だと、ノードを使ってマテリアルを複数ミックスシェーダーで混ぜてカラーランプで色を作ると影の色とハイライトの色と中間色を指定できるので、そこに影の部分の別のマテリアルとハイライト用の別のマテリアルでコントロールすると、さらに調整できます。
平面の立ち絵の挙動だと、平面的なボーンの回転で関節の制御ができるのですが、これとは別に、以前紹介したように
【 シェイプキーはドライバーで制御できる 】
のでフェイシャルアニメもドライバーでコントロールできます。その為、画像の表示と階層のコントロールで処理をする作るだと、文字のコントロールが大変になる（少し不思議が話ですが、BGEでロジックエディタだけで作るとそうなります。）ような気がしますが、画像の表示についてはそれほど大変な物ではないので【 変数の制御 】をどうするかを考えることになります。
あと、データのセーブはPythonを用いてGlobalDict（Pythonでは辞書ファイルを作成できるので辞書を参照して変数の読み書きが可能になります。）を読み書きして制御できますが、古いスクリプトをそのまま使うと、【 大文字の表記なので3.x系ではエラーになる場合がある 】ので、仕様に合わせた状態に記述を書き換えて使う必要があります。と言うよりも、2.7x系の記述だと、ライブラリの読み込みから大文字なので、3.ｘを使うと、フツーにライブラリを読み込む部分でエラーになるのでコピペをするだけだとフツーに詰みます。
その為仕様に合った状態で使う必要がありますが、そうした機能を用いたゲーム制作も可能です。ただし、【 当たり前に使おうと思うとPythonが必要になる 】のですが、Blenderではカーソルを当てると
【 どういう記述で呼び出せるか表示される 】
ので、その対応の記述を指定してその数値を変数化して制御すれば、数値変動でそのコントロールが可能になります。
多くのゲームエンジンがそうですが、【 制御は何かしらの開発言語を用いる 】事になりますが、BGEもそう言った仕様になっています。
ただし、セーブ機能や動画機能などを考えない場合だと、ロジックエディタだけで動く物が作れてしまうので、そうした点では面白い仕様になっています。
とりあえず、ゲームエンジンの場合、UnrealEngineやUnityやCryEgineのように市販のゲームで使用されている物やXenkoのような最新の技術を実装したOSSのゲームエンジンでも当然のように2Dのゲームやノベルゲームを作ることは可能ですが、流石に、吉里吉里Zやティラノビルダーのような軽差にはなりませんし、ゲームの容量も結構大きくなってしまうので、用途によってゲームエンジンを使い分けることになります。
今回は主にウディタに触れましたが、一部なっ強では強制終了することがありますが、このゲームエンジンでは、24bitのオーディオにも対応しているので、SEやセリフやBGMを24bitのWAVを用いることが可能です。基本的に
【 タイルチップ：マップの構成要素 】
横8チップの制限あり
（800x600以上だと40ピクセルｘ40ピクセルが1チップ）
（＊）基本的に縦は制限がないものの、320x240だと
4000ピクセル以上で不具合が出る
【 オートチップ：マップ上のアニメーション 】
縦5チップの制限あり
（800x600以上だと40ピクセルｘ40ピクセルが1チップ）
横方向は１～∞ですが、画像サイズが大きくなると
重くなるので注意が必要です。
【 キャラチップ・入力待ちポーズ画像・選択肢カーソル画像 】
解像度指定なし
（＊）65535x65535が上限のようです。
■ キャラチップ
横にアニメが再生される。
3パターンや5パターンが選択可能で、
T.PNGだと製紙用のポーズを1つ画像として追加でき
TX.PNGと指定すると、停止時のアニメーションを追
加できる
■ 入力待ちポーズ画像・選択肢カーソル画像
縦にアニメーションが再生される。
【 選択肢用ウインドウ画像 】
3の倍数であればサイズの制限はない
と言う仕様になっています。
その為、サイズの大きなキャラクターを用意して動かす事も可能です。ただし、マップを構成するタイルには、幅の制約が存在します。
■ Appendix
配列とタイルの関係ですが、
の場合、横方向で
【 1 → 2 → 3 → 3 → 2 → 1 】
の順でリピートされます。つまり、+1を最大まで行い、最大数になった場合に-1を行い、最小値だと+1のループに戻る仕様です。これが中割りを１つにするか2つにするかの違いになります。5コマだと、歩行の片足を出すモーションに中割りを入れることが可能になり、3コマだとただの画像の入れ替えになります。
この場合、3つでモーションが構成されていますから、画像は
【 1 → 2 → 3 → 3 → 2 → 1 】
でシフトするのですが、この処理はプログラミング言語を用いてコードで記述する場合だと、任意の変数を用意してその数値変動になります。
この状態で考えると、モーションの画像は12ほどありますが、
■ 移動の方向
■ モーション
と言う組み合わせになっています。つまり、
■ 縦軸 ： 移動の方向
■ 横軸 ： モーション
の配列になっており、先ほどの数値変動は横軸のみの変動と言う事になります。タイル画像をメモリーに読み込んだ場合、それはすべて表示できる状態になっていますが、これを特定の範囲のみで表示することも可能ですがこの場合、始点( X , Y )と対角の終点( X1 , Y1 )を選択すると、
■ 左上 ： （ X , Y ）
■ 右上 ： （ X1 , Y ）
■ 左下 ： （ X , Y1 ）
■ 右下 ： （ X1 , Y1 ）
長方形を形成する4つの頂点の座標を得ることができます。そして、タイルの移動幅というのは、
■ X方向 ： XとX1にX1の初期値を加算すると次のタイルになる
■ Y方向 ： YとY1にY1の初期値を加算すると次のタイルになる
わけです。つまり、画像にインデックスを振るのではなく、初期段階でメモリーに読み込んだ画像ファイルの座標をタイルという区画で切り分けて表示を行うことで処理をしているわけです。この場合、
■ 読み込む画像（PNGなどの画像ファイル）の指定
■ タイルサイズの指定
■ モーション数の指定（タイルのアニメーションで使う枚数の指定）
■ 判定後の読み込むタイルの段の選択
などが必要になります。つまり、この条件で考えると、上記の物は、
■ 向き
■ モーション
で構成された二次元配列と言う事になります。
これとは別に、マップ生成は
のようなタイルを用います。そしてタイルサイズはキャラクターサイズとは異なります。タイルについてはアニメーションをしないものだと、画像の配列なので、
【 パターンを登録した二次元配列 】
になりますが、この時の画像の呼び出しの処理は、キャラチップと同様で 【 画像OOの（X,Y）-(X1,Y1)の範囲 】 で呼び出されています。
その為、【 配列の数値+1 】＝【 タイルの推移+1 】と言う事ですから、X1の初期値をA、Y1の初期値をBとした場合、
配列【 X+1 , Y 】 = タイルル【 X+A , Y 】【 X1+A , Y1 】
配列【 X , Y+1 】 = タイルル【 X , Y+B 】【 X1 , Y1+B 】
と言う形になります。つまり、配列の縦軸と横軸で画像を指定して配置をするので、こういう仕様になります。
通常のプログラミング言語にはレイヤーと言う概念が存在しないので、そうした場合、
【 RGBAの取り扱いと、画像の重なりによる優先度 】
を考える必要があります。とりあえず、RGBAではなく、RGBで考えた場合ですが、こうした条件の場合、動画制作で取り扱う【 クロマ 】の概念を用います。クロマキーというのはグリーンバック （ これは何色でもいいので、すが、基本的には肌の補色を用います。その為、服を系統色から外すとか、ライティングによる影響で背景色の影響を受けないようにする必要がありますが、ブルーやグリーンを用います。ブルーバックを海外で使用する例が少ないのには理由があり、ブルーのコンタクトの人だとブルーバックを使うと目が透けて見えるからです。つまり、爆発シーンを合成で作る場合に、アクターの方にグリーンバックのセットの前に緑のマットを引いて飛んでもらってそのあとに合成すると、爆発シーンで登場人物が飛んで回避するようなシーンが作れますが、この時に、手前に飛んでくるようなシーンだと仮定した場合、目も当然フレームの中に入り、むしろ、こっちに来るので、より表情がしっかりと確認できる状態になります。この時にブルーのコンタクトのアクターの方が主人公で、そのシーンをブルーバックで撮ると、目の色も系統色なので、透けて見えます。つまり、炎が迫るシーンでは、コンタクトまで燃え盛ってしまします。とりあえず、製作サイドは【 そんな”巨人の星かな？”と思うような演出は想定していない 】のでその状態になると弊害しかありませんから、クロマは緑を使うことになります。これと同様に、【 ブルーマンのライブでクロマを行う場合に、ブルーバックを使うとフルで透過してしまう 】とか、【 ピッコロ大魔王のマスクをグリーンバックで行うと、肌が透明になる 】わけです。透明感のある肌ではなく、肌自体が透過して後ろが見えているような状態になるのでやはり問題があります。その為、選択は重要ですが、主にグリーンバックが使用されるのは、コンタクトの色が何色であっても影響がないためです。 ） を使用して撮影を行った場合、後処理で背景の色を選択してその色から閾値分だけ±で明度の差異のあるモノを差し引くと対象外の色彩データが抽出（というか、それに該当しないピクセルが判定外になり、対象の色が選択されるので、該当データを除外してRGBAのアルファチャンネルを0に指定すれば完全な透過が可能になるので別のRGBAのデータを持つピクセルがそのまま維持されます。）されます。これと同じように、【 背景色を決めておく 】とその色を除去した状態使用できるので、クロマの概念をそのまま適応して、
■ 背景色を決めておく
■ 使用する色はその系統色を除外する
■ ドット絵で使用するカラーパレットを用意する
必要があります。その上で、
■ アルファチャンネル適応用のカラー
■ 画像用のカラー
の二種類が生成されます。この場合に、アルファーチャンネルというのは、
【 下側に存在する画像の情報を反映する 】
というものですから、上下のレイヤーの階層構造が必要になります。この場合、階層構造を作る必要があります。その場合、
【 変数の指定による優先度の指定 】
を行うと、階層構造が生成できます。つまり、
【 レイヤー２ 】
【 レイヤー１ 】
と言う構造があったとします。この場合に、ベースとなる画像を指定した場合、通常の指定で問題はありません。と言うのも透過の必要がないからです。
壁紙を用意して何かを上に配置する場合に、四角形に画像の背景が入ると問題が出ますからそうした状態は避けたいと思うのは自然な内容ですが、RGBAの考え方はそうした上に重ねる画像の取り扱いになります。そうなると、クロマ処理においてこの条件は必須となりますが、RGBAが使用できない場合、
■ ピクセル解析
■ 背景カラーの除去
■ 下の画像の反映
の処理が必要になります。RGBの場合、0-255までの条件ですが、仮にRGB(0,0,255)のグリーンバックを想定してみましょう。この場合、ピクセルの構造は二次元配列ですから、解像度のX,Yの座標軸が存在します。これが解像度分だけ存在しているので、
■ 解像度：二次元配列
■ 色情報：三次元配列
になりますが、この時に、解像度の座標データの二次元配列の中に包含された色情報のRGBの三次元配列の特定の配列情報を参照して一致する条件だと透過処理の対象になるわけです。
この時に、上位レイヤーでの処理になるので、素材は、
【 レイヤー２ 】 ： 透過素材
【 レイヤー１ 】 ： 不透過素材
になります。この条件で考えると、
■ 座標（0,0）
【 レイヤー２ 】 ： RGBの色情報
【 レイヤー１ 】 ： RGBの色情報
が格納されているので、最初に透過画像のピクセルの解析を行って、対象のピクセルが透過色の適応がされている場合、同じ座標のレイヤー１の色彩情報を割り当てると、背景が透過したように見えます。
この処理を透過部分だけ行うことになります。同一の解像度の画像を重ねた場合だとそうなりますが、上記のタイルの概念が入ると少し違います。というのも、タイルと言うのは
のような感じで並んだ構造物だからです。マップの構造が解りやすいのでそれを元に考えると、とりあえず。このタイルで構成されたマップ生成の方式では、
■ マップ ： 二次元配列で座標を指定
■ レイヤー ： 変数で階層選択
（これを包含するとマップは三次元配列になる）
■ タイル ： 指定範囲の二次元配列
■ 色情報 ： 三次元配列
になります。つまり先ほどの解析処理に
【 マップ上で座標が一致したレイヤーが異なるタイルの比較 】
になりますから、その上での透過部分の処理の実行になります。
その為、タイルの配置自体はタイルの指定と配列の座標変動で処理できますが、レイヤーの概念が入った条件でRGBAではなくRGBの場合だと、ピクセル解析を行って透過を適応する色を抽出して下層レイヤーの画像のピクセルの色情報を割り当てて表示することになるので、少し処理が複雑になります。
3Dのゲームエンジンでも2Dのような処理ができるというのを書きましたが、
のようなタイルの構成にした場合、BGEでは
■ オブジェクトの発生
■ オブジェクトの変更
が存在しますから、オブジェクト単位で配置する物を変更できるのですが、Pythonスクリプトを用いた場合、【 タイルマップを部分的に指定して使用できる 】のでタイルの割り当てをすることが可能になります。
その為、
の状態で
のようなロジックを組むと
をキー判定で
と
に変更で来たり
のように指定したメッシュ（配列複製をしているので、この状態だと、対象のメッシュのみオブジェクトは発生します。）にオブジェクトを発生させることも可能です。
当然、発生や変更をさせるオブジェクトは別のレイヤーに配置しておく必要がありますが、こうした処理が行えますから、当然のように変数参照で発生するオブジェクトを開けることも当然のように行うことが可能です。つまり、必要なパターンと変数の定義で制御できるので、その場合の変数参照での対象オブジェクトを指定しておけば、タイルの状態で構成できるようなワールドの構成だと変数で配置するオブジェクトの指定が可能になります。
別のゲームエンジンだとアセットで2D製作用のアセットとかありそうですが、軸を一つ減らした状態で処理できるので、立体形状が板ポリゴンに変わり、その重ね方が座標制御になっただけと言う話になります。
3Dのエンジンの場合、目に見えない立体形状（単に非表示にしてるだけ）のコリジョンオブジェクトで接触判定を行うことは可能ですから、平面的な処理で行う座標判定についても、板ポリゴンではなく、コリジョン用のオブジェクトで判定することが可能です。なので、通常は大なっみくすを適応すると倒れてしまう板ポリゴンを直立させることが可能なので、サイドビューのゲームでジャンプを行ってダイナミクスで飛び跳ねるような物も3Dのゲームエンジンだとフツーに作れてしまいます。
基本的に、サイドビューで柔らかい物が動くとカラいだミクスを使う場合、【 固定されている部位とダイナミクスで動く部位 】が必要になりますが、【 動きに関しては、細分化された面で生成できる 】ので、それをキャラの髪の毛やリボンなどを動かすときのような挙動としてリッジドボディーでボーンを制御すると、自然な挙動になりますし、そこにコリジョン判定のあるオブジェクトを追従させると、キャラとの接触判定を用意できます。
つまり、サイドビューの場合
■ キャラ
■ MOＢ
■ 足場
■ 障害物
についてはCUBEのコリジョン判定で立体形状を用いた場合、同じ座標で接触できるように配置されていればそれがそのまま反映されることになります。その為、トップビューのようなダイナミクスがない条件で動くような作りの物だと問題なく接触判定だけで大丈夫ですが、平面の画像でジャンプやダイナミクスを使う場合には、そう言った処理を入れることで、2Dのゲームを作ることができます。
この場合、タイルのアニメーションをAnimatedtextureで行い、枚数が増えた場合にどの程度重たくなるのだろうか？を考えてテクスチャーの枚数やアニメーションの度合いをコントロールすることになりますが、
【 BlenderのAnimetedTextureは16x16まで対応している 】
ので256コマノアニメーションを実装できます。これを読み込みを変えて
■ 16フレーム ｘ 16パターン
で使用することもできますし、
■ 8フレーム x 32パターン
で使用することも可能です。当然、フレーム数は横に一旦流れて次の行を読むので、行で分割した
■ 128フレーム x 2パターン
■ 64フレーム x 4パターン
なども可能です。この場合、どういう挙動にするのか？で中割りの枚数が変わるのですが、実際にキャラの挙動を滑らかにする選択肢は存在しています。Animatedtexttureですが、最大が16x16ですから、タイルを100x100で作ると、1600x1600のテクスチャーを用いることになりますし、200x200のタイルだと3200x3200のテクスチャーを用いることになります。解像度の自由度も存在しますが、あまりにも巨大にすると画像サイズが動画よりも重くなることがあるのでその辺りには注意が必要ですが、基本的に、【 システム上の設計は自分で行う 】のがゲームエンジンですから、こうした使い方をする場合もマシンスペックに合った仕様を考えることになります。