EF-12の後継「EFX(プロジェクトコード)開発の記録をここに記す。月単位で日記を増やしていこう

本日までの現状

EFXは本日(2016/6/25)時点からスタートしたわけではなくもっと以前から下回りの開発が進んでいる。以下は現在までの概要

2014年

業務で動いていた別案件の為の、EF-12世代対応の新しいエフェクトエディタ開発。

パーティクル系エフェクトの要素はこのエディタで概ね網羅していている。EF-12世代といってもトレンドの技術はだいたい実装されている。

もしかするとライブラリの改修に伴い若干の修正が必要になるかもしれないが基本これでEFXに持ち込める。EF-12ではエフェクトエディタと呼べるものがなかったので開発環境としては大きく前進。

2015年2月

・モデルをツール上で編集、保存できるエディタ(マテリアルエディタ)の制作開始。担当はM君。基本ライブラリを作ってるプログラマだ。

EF-12ではMAYAなどのDCCツール用にカスタムのCGFXシェーダーを作りツール上でゲームの見栄えを再現していたが、これだといくつか問題があった

1.ツールの種類と各バージョン用のシェーダープラグインが必要(バージョンは互換性次第)。
2.AutodeskがあるバージョンからこっそりCOLLADAへのカスタムパラメータ出力を出来ないようにしてしまった

2.が特に深刻で、COLLADAのコミュニティ上で1年以上粘ったが『AutodeskはCOLLADAを殺しにきている』という結論しか得られなかった。

こういった外部要因に開発環境が左右されるのはできるだけ避けたい。そこでエディタには以下の大きな要件を定義した

1.FBXに対応させる
2.ただしモデルについては基本的なパラメータ(メッシュ、ウエイト、UV)しか取得せず、調整項目はエディタ上で出来るようにする

言うのは簡単だが作るのは容易ではなかった。FBXはとにかく汚いフォーマットなのだ(プログラマなら言っている意味がわかってもらえるだろう)。扱いにくいことこの上ない。なのでだいたいの会社ではAutodeskが提供しているSDKをそのまま使わざるを得ないのだが、ウチの場合はIKスプラインをそのまま実機でも再生したいというこだわりがあるのと、そこがブラックボックスだとまた迷惑を被る可能性があるので独自解析をすることにした

(これがまた難儀するわけだが)

2015年9月

・マテリアルエディタほぼ完成。独自解析する都合でバイナリは困るのでASCIIフォーマットのみの対応。FBXの構造はおおむねXMLでツールの種類やFBXのバージョンによってそれぞれ中身が違うのを調べて吸収できるようにする。

・Scale Factorのパラメータがちょっと謎。FBX vierwerだとScale Factorは見ていない(というか、ツール内で再変換かかっているように思われる)ようだが、EFXでは過去資産に最適なデシメートルを基準スケールと決定

—-
マテリアルエディタ制作中にモーションリソースも以下の大幅な仕様変更をした。

1.向きの変更
今までZマイナス方向が前だったのをZプラス前に180度変更したのだ。これはルートを回転させれば直るような単純な話ではない。それをやってしまうとプログラムが向きを管理する時に面倒になる。よって全てのモーション(とりあえず汎用モーション約600)をネイティブにZプラスが前になるように移し替えた。これだけで約3カ月

2.IK→FKに変更
IKはインバースキネマティックスのことだ。この辺は理解できる人が読んでいるものとして割愛するので各自検索してほしい。

ちなみにライブラリの機能としてはFKもIKも対応していたし新ライブラリでも対応している。変更したのは「公式キャラが全てFKモーションになっている」という部分。

IKだと①一般ユーザーがIK用の(少々難解な)スケルトン構造を理解できず独自骨が作れない ②手足の長さや肩幅などを変えたキャラを作るとIKで再生結果が変わってくる(部位によっては変更が反映されない) の2点がEF-12で問題になっていた。FKであれば肩幅を変えてもずれた肩の位置を始点に角度で姿勢を決定するのでキャラモデルの自由度が高い。またスケルトンの説明が非常にシンプルだ。

IKFK

FKはそれぞれの関節パーツ(デフォーマ)の位置を自分のキャラの体格に合わせて自由に動かしてかまわない(ゲーム仕様上腰までの高さは変えない制限のみ)。nullの固まりなので各種DCCツールへの持ち込みも容易だ。

欠点としては①モーションのファイルサイズが大きくなる②末端にいくほど誤差が大きくなる というのがあるが、メモリ16Gが当たり前の時代なので「ファイルサイズ大きくなってもいいから精度上げなさい」という方針にした。

2015年9~12月

EFX仕様書作成。基本的には『EF-12で足りなかった部分の追加』『EF-12で不具合のあった箇所の修正』という2点をベースに書類にしていく。ゲーム自体はEF-12+αなのでEF-12そのものである部分については記述の必要がなく比較的軽い。それでも4カ月かけているので格闘というジャンルがどれくらい重たいかなんとなく想像できよう。

EFXで特筆すべき新要素を少し挙げておく

・対戦パートとミニクエストパートがあり、ミニクエストでHPとパワーゲージ(的なもの)を消費した状態で対戦がスタートする

・クエストとの兼ね合いもあり技のコマンドは方向キーにできるだけ依存しない。特に必殺技系は「パワーゲージ+ボタン」で全部出せるようにする

・コンテンツとして「ツール」と「ゲーム」を明確に分ける。ツールがEFX(最終的にMod Flameと命名するつもり)であり、ゲーム部分はバンダイナムコのカタログIPに企画提案したゲームとして別途販売する。カスタマイズしたかったらツールを買ってね、ゲームはいわばテンプレートだよ、というコンテンツの関係になる
(余談だがゲームテンプレートは将来的に格闘以外も出していくつもりだ)

—-

2016年2月

・ゲームパートの開発スタート。アサインはメインプログラマ1名(H君)。10名程度の小規模な会社なので2名以上の人員を割くことはできない。専属はH君のみで、あとは仕事が空いてしまった時にアサインするようにして基本業務の稼働率は下げないようにする。どうしても出向の案件が多くなるので機動的なアサインは難しい

2016年3月

・EFXと同じライブラリで作られた社内の別コンテンツをWindows10にもっていったら動かないという事案が発生。DX9.0ランタイムを入れても動かない。これはえらいことだ。なにしろWin10はほとんど強制でシェアを伸ばしており、10に非対応となるとEFXのみならず社内開発ラインにも都合が悪い

かなり重い作業となるのだが止むをえず急きょDX12にライブラリを乗せ換える作業を行うことにした

後日この問題は初期バージョンかつアップグレード版のWin10でしか発生しない問題であることが判明するのだが(MSは死刑だな)、もう仕掛っていて止められないし、DX12対応にすることでグラフィックの品質も向上するはずなのでそのまま続行。正直2名を非生産部門に張り付けてるのは重い…

2016年5月

2D制作環境に「Sprite Studio」が有力候補に

EF-12の開発環境もかなり安価なツールが使用できていたが、それでも「ほとんどの人はMS Officeを持っていない」という事は驚きだった。誰でも自由にカスタマイズできるようにするためには更に安価で質のいいソフトを探す必要があった。

DCC > Blender(MAYA/Maxなども勿論使用可) <FREE! csv > MS Office → CSV Edee <FREE! sound > studio one < FREE! Effect > effect editor < integrated!

ここまでは見えていたが2D/UIだけがAfter Effectsのまま残っており、しかも結構なお値段するので代替ツールを探していたのだがSprite Studioがインディーライセンスなら無料で使え、しかもフォーマットがXMLでゲームに実装しやすいというのを発見、これを採用予定とすることで全要素が無料ツールで完結する予定となった(まだプログラマの実装ができてないのであくまで予定ではある)

体験版をちょっと触ってみたが2Dに特化しているのでAfter Effectsほど難しくもなく、サポートが英語でも充実しているので是非これを使えるようにしていきたい。

next > EFX開発記(2017年6月)

2008 - 2017 © QUAD ARROW Co.,Ltd.
All Right Reserved.