結局、Crystal Toolsってなんなのさ？

[RemingtonSteele]

あちこちのスレッドで「Crystal Toolsが悪い」とか「Crystal Toolsは関係ない」とかの書き込みがあります。
なんか想像だけで語っている感じがして、それ本当なの？的なアンサーだったり質問だったり要望だったり。
結局のところ、Crystal Toolsってなんなんでしょう。教えてわかる人〜( ｣´0｀)｣

（私の妄想＝移動に慣性がついて止まりたいときに止まれない、パッドで８方向にしか移動できないのはCrystal Toolsが原因だと思ってます。共通ライブラリなんぞ使わずに、各ゲームそれぞれの特色があるんだから、面倒でも細かく作り込んで欲しいです。）

[Chaya]

目の前にある箱は何だ

[Kristina_Farron]

Crystal Toolsとは、大雑把というと、「□eの次世代ゲームエンジンおよび周りの開発ツール」であります。
最初はFF13のため開発された。
http://game.watch.impress.co.jp/docs...25/gdc_cry.htm

ゲームエンジンが、現在のゲーム開発者にとってほぼ常識的な基盤です。Unrealなど他人開発したエンジンを直接引用することもありますが、やっぱり規模あるゲーム会社はみんな自前のエンジンを用意したいということです。(基盤が他人に任せるといつか技術的に脱落者になるから嫌です)

[Gilgamesh]

「CrystalToolsが悪い」と言ってる一人です(；´∀｀)

　この「ＣｒｙｓｔａｌＴｏｏｌｓ」ってのは、言うなれば「開発用のミドルウェアプログラム/ハードウェア群」という位置付けがされたシロモノです。
　元々は「ＷｈｉｔｅＥｎｇｉｎｅ」と呼ばれてたものです。

　対応ハードは、ＰＣの他にＰＳ３、Ｘ箱３６０、Wiiとの事（FF13wikiより）

　ちなみに、今の所はFF13,FF14、FFヴェルザス１３の３本にて使用される（使用されている）スクエニ専用の開発ツールです（将来的には、アンリアルエンジンや、CRYエンジン同様に外販も予定してるらしい）

　私が「開発ツールが悪い」という結論に至った原因は､正に「５年もかけて開発したシロモノなのに、何でココまでﾀﾞﾒダメなの？」とさえ思えるほど酷いラグと、もっさり感及び「コピペMAP」、「なんちゃって」シームレス、バカみたいに高い必須スペックなのに、なぜDirectX9.０ｃなのか？にあるのです。

　そして、開発中であれ、そろそろ見えてもいいはずの「PS3版FF14」の画面写真が１枚も公開されていない事も､この結論に至った原因でもあります｡
（「大体こんな感じになりますが、開発中なので､変更されるかもしれませんよ」って感じの画面写真なら､公開してもいいと思いませんか？）

　

[Poice]

(基盤が他人に任せるといつか技術的に脱落者になるから嫌です)

十分脱落してるように見えますが・・・
というか奈落の底でもがいている感じ。どうしてこうなった？

[Moni]

http://game.watch.impress.co.jp/docs...25/gdc_cry.htm

こちらを読む限り、MAYAやphotoshopなどの市販ツールを基にしたグラフィックツール群でしかないように読めます。
FF11とほとんど変わらないポリゴン数でFF14のグラを作っているとどこかで目にしたのでcrystal tools自体はまともに機能してるのではないでしょうか？
プログラムやコピペMAPなどについてはただの設計不足でしょうね。誰の、とは言いませんが。

ところでこれグラフィックにしか言及されていないのですが、ゲームエンジンと言えるのでしょうか？

[Moebius]

ところでこれグラフィックにしか言及されていないのですが、ゲームエンジンと言えるのでしょうか？

きっとCGエンジンなんだよ。(´・ω・`)　日産のじゃないよｗ

[Kristina_Farron]

一般的に、ゲームエンジンの構成は以下の機能を含めます：
引用元：Wikipedia

＊グラフィック描画
＊スクリプト処理
＊モーション処理
＊サウンド処理
＊物理演算
＊通信
＊インタフェース

Crystal Toolsについては、08年発表当時ではグラフィックの分野しか言及していないですが、ほかの分野の機能も整備しないとゲームの開発の加速効果が限られていますので、たぶんある程度の機能があると考えられます。

あと、失礼ですが「共通ライブラリなんぞ使わずに、各ゲームそれぞれの特色があるんだから、面倒でも細かく作り込んで欲しい」という要望は、現代におけるゲームデザイン分野ではかなり非現実的な発想であります。マシンそれぞれの特性に合わせてプログラムを一から作るなら開発の時間が非常に長くなって、発売出来る前に、仕様を決める時で予想したターゲットマシンが既に現役ではなくなる可能性が大きいです。

さて、いまのFF14に対して大体の不満は、はたしてゲームエンジンに関係あるのか？

酷いラグと、もっさり感

先週Foxclonさんの返答によれば、ラグについては複合的な要因があります。たとえば「無駄な関数の呼び出しが多い」、これが設計上の思考が間違ってるのでエンジンのせいではない。しかし「一つの機能を完遂するにはどれほどのパケットが必要？」についてはエンジンに関与する可能性があるので、一概とは言えません。

コピペMAP、「なんちゃって」シームレス

前体制の時田中Pはこう仰る：エリアが広いにしたいが、地形データーが多すぎるので、小さいな元素を作って、複数配置させるしかできない。実はFF11もこの手のやり方がありますが、コピペの感じがほとんどない。しかもエンジンの仕事は地図デザインの支援しかすぎないので、この件についてはエンジンのせいではないと思います。

バカみたいに高い必須スペックなのに、なぜDirectX9.0c

エンジンのグラフィック描画機能が大体共通的に中間形式に変換し、それから各種マシン(PS3, 360, PC...)専用の部分によってマシン専用SDKの最終プログラムに変換し、コンパイルする。つまり、Crystal Toolsが出力した結果が場合によってPC用になりPS3用になり、360用もなれます。それぞれのSDKに合わせてカスタマイズの部分もありますが、ディテールのさじ加減くらいの程度になります。
ちなみに、FF14のスペック要求が高いの原因はポリゴン数の上昇やテクスチャの大量増加、およびシェーディング(物体の表面での光と色の変化をシミュレートする演算)の進化であると考えられます。同じくDX9のゲームだとしても、作りによって「画質が粗いけど軽い」「画質がズバ抜きけど重い」になります。SDKの選択には関係ありません。実際、DirectX9.0を使わないと、WindowsXPを使ってる人はFF14遊べなくなる。それは多分社長さんと田中Pが一番見たくないシナリオだろうと思っております。

移動に慣性がついて止まりたいときに止まれない

もしかして「移動操作止めてもちょっと移動する」「キャラが移動中で死んだとき地面で滑るなんで非常にキモい」のこと？それはFF11でもたまに発生しますよ。原因はクライアントの位置情報と鯖の位置がラグによって不整合が出てきて、鯖によってシンクロさせた際が発生するんです。前述のとおりラグが必ずしもエンジンのせいではありませんから断定するにはまだ早いでは。

[REDel]

クリスタルツールがどの程度の実力なのかはまだ未知数ですが、高性能のエンジン例えばUE3とか使ってるから、軽快に動いて凄い見た目のゲームが作れる、と言うわけでもありませんよ。
結局、そのエンジンを使いこなせないと全くダメダメなゲームが出来上がります。
「UE3つかっててこれかよ！」とかいうユーザーの悲鳴を聞いたことはないでしょうか？
エンジンってそんなもんです。

[reiot2000]

以前スクエニでもUnreal Engineを使ってたらしいですけど、実際のところ使い方把握するだけで手一杯で最適化なんてろくにできてなかったみたいですからねぇ。
それなら自前で何とかできるものを作ってしまえ、となったのはわからないでもないです。
むしろPCの場合、メモリやらCPUやらの制限がPS3版と比べて大幅に余裕があるため、開発者側のリソース管理がかなり雑だったんじゃないかとしか思えない状況です。そもそもスクエニってスクエア時代はともかく、スクエアエニックスになってから（というかDirectX世代の）PC用ゲームの開発能力がどの程度あったのかも正直よくわかりませんし。
案外PS3のほうが割り切った設計ができるため、クライアントの出来自体はそっちの方がいいのかもしれない、なんて最近思うようになってたりしてます。