先日、
にて
をに触れたのでこのツールについて書こうかなと思います。このツールは、
のような感じで2Dのゲームを作れるゲームエンジンで、最初から用意されているゲームを遊んでイベントを体験した後にどういった構造になっているのかをコモンを見て理解が出来るようになっています。
新規にゲームを作ることもできるのですが、テンプレートに当てはめてゲームを作るようフレームワークではなく、ゲームシステム自体をコモンを使って作れる仕様になっています。また、コミニュティーには様々なコモンが用意されているので、作りたい仕様のものをコモンを使って構築することも出来ますが、負荷が高くなりますが、このツールを使った3Dの表現をしたゲームもあります。
基本的にはスプライト処理になりますが、当初のバージョンではSD解像度でしたが、現在は3になっており720p対応になるなど高解像度のゲームが作れるようになっているようです。公式YouTubeチャンネルには、
1
のようにアップデートの情報も掲載されていますが、無償版については、この多機能なツールが無料で使用できます。
機能が多い有償版もありますが、コーディングではなく 【 処理の流れの実装 】 で組み立てていく形になっているので、プログラミング源との知識のない人でも処理の実装が出来る仕様になっています。
作者の方はスモーキングウルフさんですが、この方が無償で提供されていたツールのバージョンアップ版で、今年の7月にもバージョンアップが行われています。これからはこのツールは、ウディタと言う名称でこのツールの表記を統一することにします。
ウディタの流れ
ウディタでは、サンプルゲームと制作ツールがセットになっているのですが、最初にサンプルゲームを遊んで見ると色々bな要素が用意されているので、シンプルがRPGを作る上での機能が用意されています。
これは、初代からそうなんですが、サンプルゲームでは、MOBのエンカウントについてもコモンが用意されており、
■ ランダムエンカウント
■ シンボルエンカウント
が存在します。ランダムエンカウントは 【 補数制御 】 なので、完全に数的処理と数値の選出の処理になっているのですが、シンボルエンカウントは座標制御になるので、タイル上の座標での出来事での制御になります。
プログラミング言語を使って位置から作る場合、この座標制御の処理の塊を用意してそれを呼び出して使うような状態になりますが、ウディタでは、【 マップ以外のもの 】 については、 【 イベント 】 と言う形で制御されています。
なので、画面内には、
■ マップ
■ イベント
という2つのもので構成されています。マップはイベントを実装するもので貼りませんから、タイルを敷き詰めることになりま菅、これにも階層が存在しており、地面と建物では階層が異なるので、こうしたものは階層を分けて管理できるようになっています。
構造としては、この 【 マップ 】 と 【 イベント 】 の２つで構成されており、NPCやキャラクターについては、イベントでの制御をする様な仕様になっています。
こうした機能も 【 どんな処理をすればいいのか？ 】 は解りにくいので、最初にお手本を見てどんな事が出来るのかを知る事が大事ですが、サンプルゲームでは、
■ フラグ
■ 仲間のパーティーへの追加
■ ショップ
■ ダンジョンの階層
■ シンボルエンカウント
ゲーム制作をする場合
商用ではなく、学習目的だと非商用だと利用可能な素材を使えばそのままゲームで利用できますが、商用利用だとライセンスに引っかからないものを使うか制作することになります。
ゲームエンジンを使うバイアに共通していることとしては、 【 対応コーディックを使う 】 ことになるので、使用できるコーディックの素材を用意することになりますが、制作をする場合には
■ 素材のモニタリングをする環境
■ 素材自体を作る環境
が必要になります。なので、どう言ったものを使うのかで用意する環境も違ってきます。
ソフトウェアの機能や作るものの機能の実装をする場合だと、用意された素材を使って作ることになるのですが、作る仕様に合わせた素材の制作環境も用意しておく必要があります。
個人でゲームを作る場合だと、サラウンドのマスタリングの必要がない場合だと、DTMのようにステレオのマスタリングが出来る環境はあったほうがいいように思います。ゲームの場合、そのゲームエンジンがどういった色を扱えるのかでも変わってきますが、現在のように10bitの色深度だとsRGBという訳ではなさそうなので、もっと広い色空間が使用されていると思うのですが、8bitの色深度の場合だと、色空間はsRGBとかREC.709辺りが使用されているので、グラフィックの場合だとsRGB（AdobeのRGC.709のガンマがsRGBと同じで、コレとは別にマスモニ用など３種類あるのでREC.709は複雑な仕様になっています。映像を作る際にはマスミニに合わせるといいようですが、行為った特殊な事例も存在します。）を使う事になるので、sRGBの色が正確に出る環境を用意することになります。この辺りは、10bitになるとそれに準拠した環境を揃えることになるので、毛好コストがかかる話になりますが、sRGBのハードウェアレベルのサポートはIGPでも行われているので、表示をする際のカバー率がどの程度あるのか？の話になってきます。この辺りは、PCMを使う際の量子化ビット数とサンプリング周波数で音質が違ってくる（のと、調整幅が違ってきます。）のと同じですが、表示や音を突き詰めるとそういったハードウェアレベルのことまで考える必要がでてきます。
ソフトウェアについて
ゲームも映像と同じで、時間軸での推移を指定したfps数で画面を書き換えながら表示を行う仕様になっていますから、この時の
■ 表示
■ 音声
を構成する素材を作る必要があります。ウディタの場合、 【 スプライト処理 】 ですから、スプライト処理しか出来ない時代のハードウェアの技術体系の 【 疑似３D 】 もできるはずなんですが、基本的にはラスターグラフィックを使った制御になります。この素材を何で作るのか？になりますが、ゲームの構造によって用意するものも違ってきます。
音や音楽を作る場合だと、波形編集ソフトやDAWを用意することになりますが、現在は、
■ Cakewalk by BandLab
のように登録が必要ですが、WINDOWSで販売されていたSONARのフルバージョンを無償でしよ出来るようになっています。
音については、DavinciResolveにバンドルされているDAWのFialightが多機能なので、音の加工だとコレを使うだけでも大丈夫だったりします。なので、
■ Cakewalk by BandLab
■ DavinciResolve
を組み合わせておくと、動画の制作も含めて作業が出来る環境を構築できます。この状態で音の部分は殆ど完結しているのですが、ボーカル音源などはないので、そういった音源系を使用する場合は別途揃える必要があります。
登録をしないで使用できるOSSのツールだと、
■ Aucdacity
■ LMMS
などもありますが、MIDIシーケンサーでCCの部分を作っておいて、LMMS側で調整することも出来るので、
■ MuseScore
■ Domino
などを使ってSMFファイルを作る方法もあります。波形編集ソフトやDAWでは、素材を加工して音を作ることが出来るのですが、DAWだとシンセをトラックにアサインしてしようすることになりますが、この時の制御は音階になります。
波形編集ソフトだと波形とノイズを出力できるのでこの状態を作って加工することになりますが、こうしたツールは定数化した状態で波形を完結させることになります。コレに対し、DAWではオーディオに対してもオートメーションが適応できるので、エフェクトの状態を維持して後で再編集をすることが出来ます。なので、どちらがいいというわけではありませんが、ソフトの特性が存在するので、それを踏まえた使い方をする必要があります。
グラフィックについては、【 Blenderを入れておくとほとんどのことが出来る 】 ので個人が趣味でゲームエンジンを触る場合だと、Blenderだけで完結しそうな雰囲気もあります。このツールは、
■ モデリング
■ キャラクターオブジェクトのセットアップ
■ シーン構築
■ CGAのシーンのレンダリング
■ コンポジットノードでの質感調整
■ テクスチャなどの素材制作
■ CGA素材のトラック編集
■ コンポジション
などが行えます。また、グリースペンシルが使用できるので、2Dの手書きアニメーションを作ってレンダリングをして書き出すことが出来ます。このように
■ 実写
■ 3DCGA
■ 手書きアニメーション
が作れるので、かなり自由度の高い制作が行えるようになっています。ウディタで使用するのはラスターグラフィックになりますが、レンダリング結果を使用できるので、素材を作ってレンダリングをすることで目的の素材を用意することが出来ます。
OSSのグラフィックツールだと
■ GIMP
■ Krita
もあるので、ラスターグラフィックの素材制作を行う環境は複数存在sマスが、こうしたツールを使う場合には、グリッド表示をオンにして間隔を１ピクセルにしてするとドット絵の作業を行うことができるようになります。半島名の表現を使用しない場合だとブラシは鉛筆などにして不透明度を100%にしてドットを打つしておくことになります。
タイルサイズは便宜上、偶数にすることになるので円を作る場合だとセンターが撮れません。なので、1ドット分だけ遊びを作るて奇数でドットを作ると形を取りやすくなります。
偶数のシンメトリーの場合だとセンターを決めてミラーリングで作れるのですが、こうした処理も範囲選択と反転複製だけで行えるので作業を効率的に行うことも出来ます。ドット絵だと
■ EDGE
などもありますが、作業がしやすいツールを選ぶと意図した素材を用意することが出来ます。エフェクト系だと
■ Prominence
ように数値の指定をするだけで意図したエフェクトを作れるものもありますが、作業に必要なツールも同時に用意しておくことになります。この場合、
■ キャラのモーションのタイル
■ マップのタイル
■ エフェクトのモーション
■ 立ち絵やモンスターなどのグラフィック
■ 効果やUIで使用する素材
■ SE
■ ボイス（ボイス有りのゲームの場合）
■ BGM
のような素材を用意することになりますが、この素材もゲームの作りで用意する者の仕様が変わってきます。ただし、素材自体を作るソフトは共通しているので、自作の素材を使う場合には素材を作れる環境も別途用意しておく必要があります。
ことはじめ
ウディタでゲームを作る場合もプログラミング言語と同じで 【 機能を覚える 】 ことからスタートするので、最初は、サプルゲームでいようされている素材とサンプルゲームの解像度のように 【 低負荷で動いてくれる状態 】 からスタートすることになります。
その状態で、システム乗り会をすることから始めることになりますが、サンプルゲームはRPGなので、当然のようにものすごい数のデータが用意されています。ウディタでは、最初から使用できる素材の数が膨大に用意されていますが、この素材やデータはデータベースで管理されています。なので、このデータベースを使用することで管理をしていく作りになっています。
ゲームの場合、
■ 表示
■ 音声
野用や出力部分とは別に
■ 操作
■ 自動処理（MOBの動き）
のようなものも存在しています。そのため、プレイヤーに見える処理と見えていない処理が存在するわけですが、プログラミング言語で物を作る作業は料理や工作と同じで 【 材料を揃えて処理をする 】 必要があるので、それぞれに個別の担当先が当てて同時進行（実際にはスケジュールで動いています。）で動作している状態だと、それぞれの処理に必要な材料を用意しておく必要があります。それが画像や音声などの素材であったり、数値のデータになりますが、こうしたデータが関連付けされており、管理できる構造になっています。
ゲームを作る場合にはこうした状態を作る必要がありますが、ウディタでは、
■ データ ： テキスト
■ 素 材 ： 音声や画像（バイナリ）
■ デ ー タ ： 参照するもの
■ シーケンス ： 処理の内容
は別のものになっていますから、
■ データベース
■ コモンウインドウ
も別の場所で管理されています。
基本的には、
■ 素材（音声や画像）
■ 処理
■ データ
■ 実際に表示するものの指定
が個別に用意されており、これを使って状態を作ることになりますが、
■ キャラクターのパーソナルデータ
■ MOBのパーソナルデータ
■ アイテムのデータ
■ 魔法の効果や種類
などは一つのレコードにまとめて管理したほうがいいので、管理方法は違うとしても一次元配列の状態で存在しており、条件抽出でデータ参照が出来たほうが扱いやすいので、こうしたデータはまとまった状態で存在し、インデックスで管理されています。
これが、データベースの基本構造になりますが、このデータで管理したものと立ち絵や画像の紐付けによってよbに出した数値に対して画像を適応できる容易なリマす。この場合、バイナリとデータは別物ですから、個別に管理しておいて、呼び出すための紐付けをすることで、インデックスで画像とデータの双方を呼び出すことができるようになります。これが、商品画像と詳細情報を紐付けしたデータベースでのデータの管理になりますが、管理方法としてはゲームの立ち絵やセリフのウインドウのアイコンの呼び出しも全く同じ方法になります。こうした管理方法が行われているのと、ファイルの構造自体が異なるので、データとバイナリが個別に管理してある為、マルチメディアファイルとデータファイルの管理画面も独立した状態になっているわけです。
これは、【 組み合わせて使用する素材の状態を作るための作業 】 になりますが、戦闘システムや会話システムで使用するものとフィールドマップで使用するものでは 【 動いているアプリケーションが異なる 】 ので、管理するものも違ってきます。
このフィールド移動中の状態では、
■ 地形
■ 建物や樹木
■ 上モノ
■ キャラクターやNPC（イベント）
を配置することになります。この場合、この構成要素となるタイルを配置することになるので、
■ マップのタイル
■ キャラなどのタイル
を用意することになります。この作業はレイアウトなので、整数座標に指定した画像の範囲を割り当てていく作業になりますが、この状態だと 【 静止画が完成してしまう 】 ので、画面内を動けるようにする必要があります。この時に使用するのがイベントになります。なので、フィールドでは、
■ マップ
■ イベント
で構成されているわけですが、
■ 素材
■ 処理
を配置することで、画面内での城太鳳を作ることになります。マップの切り替えもイベントになりますから、相違した処理についてもコモンで記述した処理を実装することになります。
ここまでが、
■ 戦闘システム
■ 会話システム
■ フィイルド移動中の状態
このように 【 目的によって管理が別れている 】 のですが、ゲームエンジンを使う場合には、最初に何をするものが用意されているのかを理解してからスタートすることになりますが、その上で機能を追加したり仕組みを作る方法を考えることになります。
最初は拡張から試してみる
折角ドラクエタイプのサンプルゲームが実装されているので、この中に実装されているコモンを使ってコレよりもボリュームのあるゲームを作って理解を深めるとドラクエタイプの仕組みのゲームを作る事が出来ます。
最も簡単な拡張方法は 【 マップの拡大 】 になりますが、この作業は地形を作る作業なので、レベルデザインになります。
ゲームを作り際にはマップを作る必要がありますが、この時に条件にあった地形を作る必要がでてくるのでその状態をタイルを並べて作っていくことになります。このときにもサンプルゲームのタイルを使っても問題がないのですが、ただマップを広げるだけでもレベルデザインが少し難しいと感じるかもしれません。
自作をする場合だと、タイルからすべて作ることになりますが、マップのデザインも意外と綺麗にまとまらないことがあるので、意外と難しい作業になるかもしれません。
マップの拡張とは別に、マップの追加もできるのですが、この仕組みもサンプルゲームに実装されているので同じコモンを使うこｔが出来ます。
新規に広いマップを作ってそこを移動するようなことも出来ますし、マップ内の座標の変化を追加してマップを広く見せることも出来ます。マップを増やして移動できるようにすると異なるワールドの実装などにも使用できるのですが、こうした処理もマップの追加とレベルデザインで基本部分を作るとその状態を作ることが出来ます。
この状態で、広いワールドが作れますが、この場所にはイベントが存在しないので、イベントを配置することになります。この時にサンプルゲームに用意されているイベントを参照して違う構造にして使用すると異なるイベントを発生させることが出来ます。
ツールの機能を理解する場合には、最初に素材部分はそのまま使用することにして、機能部分を使っていくことで理解を深めることが出来るのですが、ウディタの場合、サンプルゲームという教材があるので、
■ レベルデザイン
■ イベントの実装
の方法やどういった事が出来るのか？を確認しながら作用をしていくと、コモンの取り扱いとマップの管理などの方法を覚えることが出来ます。
NPCと動き
NPCの動きもコモンなので、マップを見てみるとイベントを配置するレイヤーにNPC用のイベントが配置されています。ここで、動作やイベントが用意されているのですが、会話の返答なども定数で指定されたものが実装されています。
これが、ゲーム内で登場するキャラの動作になりますが、表示、非表示が可能なので、プレイヤーを非表示にして操作不能にしておけプレイヤーにの移動のイベントを回避できるので、 【 NPCが動くイベント 】 などを実装できます。また、操作を受け付けない状態で、プレイヤーキャラやNPCが話を進めるようなシーンを実装する場合だと、コモンでそのキャラ（プレイヤーではなく、別のNPCにタイルを当てはめてイベントで制御する）に脚本通りに動いてもらうことで話の中で展開するシーンを実装することも出来ます。
そのため、イベントについては
■ フィールド内の動き
■ 脚本に基づいて動き
が存在しますが、この２つをコモンで制御することが出来るようになっています。この時のイベントも独立したマップで配置するものを決めておけばいいのですが、その次のシーンでマップの状態をどうするのか？を考えて置く必要がありますが、この時のプレイヤーやMOBの位置もイベントのレイヤーでのイベントの配置で指定することになります。
フラグ
ゲームの場合、条件をクリ化しないと先に進めないような仕組みが用意されていますが、この仕組みはRPGでなくても実装されています。ファミコン時代のロードランナーでも 【 全ての金塊を取った後に脱出用のはしごが出る 】 と言う処理が実装されていますが、これもフラグによる制御になります。つまり、数値が決まっていてその数値のカウントでフラグを制御すれば同じ状態を作れますが、RPGの場合だと、条件をクリアしないと先に進めなかったり、イベントが進まない仕様になっていますが、こうした仕掛けを作る際に 【 条件分岐 】 を使います。つまり、条件を満たしていないので先に進めないと言う状態になっているので、その条件をつくて実装することになります。ウディタでは、この処理もコモンで指定できるので、別の世界に移動するための条件や、ストーリーが進むための条件などを用意しておいて、その条件がイベントのクリアという仕組みにしておくことで、ストーリーの進行上では回避できない矯正イベントを実装することができるようになります。
当然、クリア後にそのイベントが何度も発生すると困るので、フラグのスチの変化で挙動が変わる仕組みも作る必要があります。
サンプルゲームにもフラグは用意されているので、そういった処理の実装方法もコモンを見て学習できるようになっていますが、ゲームを作る上での必要な要素が色々と詰まっています。
環境とベンチマーク
に書かれていますが、単体で使用する画像の上限は2048x2048pixとなっているようです。チップツールは別のようですが、素材置き買うに合わせて作業を進めることになります。