UDN
Search public documentation:

ScaleformWorkflowJP
English Translation
中国翻译
한국어

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

UE3 ホーム > ユーザーインターフェイスと HUD > 「Scaleform GFx」 > 「Scaleform GFx」のワークフロー

「Scaleform GFx」のワークフロー


workflow.jpg

計画 (planning)


あるタスクがどのくらいの時間を要するかを試算することは、開発をにおいて非常に難しいことです。「Scaleform」が混合されたもの (Flash) の中に新たなツールセットを導入したため、これがいっそう難しくなりました。覚えておいていただきたいことは、UI アーティストで、すでに Flash についての知識をもっているか慣れているのでなければ、UI 作成プロセスが開始されたときに相当苦労が重なるでしょう。たとえば、「Gears of War 3」の場合、Flash サイドでシーンを完成させるのに 2 週間近くもかかる場合がありました。ただし、開発プロセスの終わりごろには、アーティストたちがほぼ 2 日間でシーンを量産することができるようになりました。原因は、Flash について学ばなければならなかったためです。また、「Scaleform」や「Unreal Engine 3」とともに使用するためにシーンをセットアップする最もよい方法について学習するプロセスもたどりました。このような学習プロセスが終わった後は、非常にスムーズで迅速に作業が進みました。

スクリプト処理サイドでは、「Scaleform」の UI を作成することは、概してかなり平凡なことです。大きな学習曲線というものはありませんでした。ただし、Flash サイドでアーティストがシーンを作り出す速度によっては、スクリプト処理がすぐにパイプラインにおけるボトルネックとなります。

設計 (design)


作成開始の前に、しっかりとした設計をすること! UI を完成したものの役に立たず、最初から作り直したり、全体的に改変したりするのは時間の無駄です。これは、当初からはっきりとした方向性や設計がなかったために起こります。プロセスの終了間際のささいなイテレーションであれば、工数や苦労の点で、最初から再設計することに比べるとコストはそれほど大きくありません。

ラフを作る (rough in)


初めてシーンをいくつか作る場合は、見栄えのしないバージョンでシーンを自分自身で実際に作ってみるのがよいでしょう。ラフによるクラスを作成し、適切なバッグ化 (ネスト化) を用いてクリップをムービーに追加し、単純なラフによるアニメーションを追加していきます。このようにして、スクリプトが機能するのに必要となるやり方でレイアウトすることができるようになります。テストシーンのために行うにしても、非常によい練習となります。Flash のデバッグは、実際にやってみることからしか学ぶことができない黒魔術です。単純なことでさえ失敗することがあるということを経験することが、これを学ぶための最善の方法です。

具現化 (flesh out)


ラフのシーンが作成され、機能するようになったら、アーティストが加わり、シーンにタッチを加えて洗練させます。起点となるシーンがすでにセットアップされているため、アーティストは、適切にシーンの階層を理解することができ、それによって、いくつかのことがらを機能させることができるようになるとともに、後にそれを利用して最初から独自のシーンを作成することができるようになります。このことは、開発プロセスにおいてボトルネックとなるスクリプト作成者にとって時間の節約となります。このプロセスにおいて、アーティストは必ずや、いくつかのものを壊します。(このことは、外見を作り出し、求められている設計を体験をするのに間違いなく必要となります)。スクリプト作成者サイドにおいて、このことは、通常、些細な修正を意味します。やがて、アーティストは物事を壊す原因とその回避法を学びます。同時に、スクリプト作成者の方も、どのような変更がどんな方法で物事を壊すことにつながるのかを学ぶことになり、それを基にして問題の所在を診断することができるようになります。

イタレート (iterate)


要件の変更、設計の変更、システムの変更。変更は、ゲーム開発において必要悪です。イタレートが必要となるので、それに備えなければなりません。できれば、当初にしっかりとした設計について合意がなされ、変更が最小限で済むようにしたいものです。ただし、いつもそうなるとは限りません。完全に再設計し、シーン全体をスクラップにすることもあります。しかし、目標は、プレイヤーがよりよい体験をすることにあるのですから、そうする価値はあります。

仕上げ (polish)


うまく機能するようになり、見栄えもよくなると、アニメーションやグラフィックなどが適切なものとなるように仕上げに入ることになります。ただし、ご注意を! できあがったものを駄目にしてしまうことは、とても簡単です。変更することによって問題が生じる可能性がありますが、今行おうとしている変更は、それに見合うだけのものでしょうか? もしそうであれば、変更しましょう。そうでないのであれば、そのままにしておきましょう!

テスト、テスト、テスト


何度もテストしましょう。「GFx Player」でテストしましょう。さらに、ゲーム内であらゆることをテストしましょう。「GFx Player」によって、シーンの外見と動作がどのようなものであるのかがよく分かりますが、本物にかなうものはありません。非常に些細な変更であっても、全く無関係に見えることがらを駄目にしてしまうことがあります。テストの間隔が長くなれば、それだけ問題の原因となった変更を突き止めることが難しくなります。

疑わしい場合は、テストしましょう。