はじめに

最近、古典的なゲームに関する物語はGDCで好評を博しましたが、開発用のツールに関する物語はほとんどありませんでした。 このシリーズの記事では、ゲーム開発ツールの歴史で重要な役割を果たした人々にインタビューすることで、このギャップを埋めようとします。

シリーズの最初の2つのパートでは、 John Romero（TEd Editorについて）およびTim Sweeney（Unreal Editorについて ）と話しました。

3番目の記事を書いたとき、 クリス・ノルデンが Deus Exと呼ばれるFPS / RPGハイブリッド用に開発したツールについて話すことができて光栄でした 。 GDC 2018でサンフランシスコのクリスとおしゃべりしました。

イオンストームの前：起源と見るガラス

David Lightbone：Ion StormでDeus Exを始めたきっかけは何ですか？

Chris Norden：1994年、オースティンでOriginプログラマーとして働きました。 私が最初に支払ったプロジェクトは、 Jane's Combat SimulationsによるJane's Combat Simulations AD-64D Longbowでした。 もともとはチョッパーアサルトと呼ばれるアーケードゲームでした。 アンディ・ホリスと一緒に、私は2年間それに取り組みました。



ゲームのリリース後、私が最後にやりたいことは、別の軍事シミュレーターを実行することです。軍事的なものすべてが絶対に好きではないからです。 時々、私はOriginで働いていたWarren Spectorと話をしました。 彼はプロットロールプレイングゲームが本当に好きでした。 「自分もこれらのゲームが好きです。そのようなものに取り組みたいです！」

1996年、ウォーレンはオリジンを辞任し、オースティンのルッキンググラススタジオの責任者になりました。 このスタジオは、 Links 386 ProなどのMacゲーム用のポートを作成しました。 彼女はまた、ブリティッシュオープンチャンピオンシップゴルフと呼ばれる彼女自身のゴルフゲームを開発中です。

OriginはまだUltima Onlineを開発していました。 彼女はMultimaと呼ばれ、Ultima VIIエンジンを使用したようです。 Originを終了して、Looking GlassのWarrenに参加するまで、彼と少し実験をしました。

[著者注：ルッキンググラスのメインスタジオは、ボストン近郊のマサチューセッツ州ケンブリッジにありました]

ウォーレンはデザインドキュメントを作成し、しばらくの間、AIR（Austin Internet Role-Playingから）という略語でロールプレイングゲームに取り組みました。 3Dアクセラレータが登場し始めたばかりだったので、3Dで何かをしたかったのです。 Voodoo 1のプロトタイプを入手し、GLideで小さなエンジンを作成しました。

ルッキンググラスのケンブリッジオフィスと提携しました。 全英オープンのリリース後、 ダークエンジンと呼ばれる泥棒エンジンでマークルブランとダグチャーチを支援しました。

経済的およびその他の理由により、Looking Glassはその時点ではあまり気分が良くありませんでした。 会社には素晴らしいゲームがありましたが、売り上げは低かったです。 そのため、約1年後、オースティンのオフィスを閉鎖することが決定されました。

[著者のメモ：クリスはゲームについて絶対に正しい-ウルティマアンダーワールド、システムショック、テラノヴァは批評家に非常に好評で、1990年代の最高のゲームの一部でした]

オフィスが閉鎖されたとき、私たちはほとんどいませんでした：ウォーレン、私、アル・ヤルソ、ハーベイ・スミス、スティーブ・パワーズ。 私たちは皆、このロールプレイングゲームに取り組みたいと思っていました。 オフィスが閉鎖された後、私たちは新しい会社を設立して何かをすることができることを期待して、約6ヶ月間お互いを保持しました。 非常に優れたデザインドキュメントがあり、それを出版社に「販売」し、さまざまな人々とコミュニケーションを取り始めました。 連絡した出版社のことすら覚えていません。 これらの人々の1人はジョン・ロメロとトム・ホールであり、エイドスと一緒に、ダラスにイオン・ストームと呼ばれる新しいスタジオを作るために働きました。


Idの最初の数年からジョンを知っていました。 1991年、ダラスで、MTVはWolfenstein 3Dに特化した巨大な船のパーティーを開きました。 2つのVR Virtuality Arcade Machineマシンがありました。 当時、私は子供で、「神、これは世界で一番クールなものだ！」と思っていました。ジョンが「私は金持ちすぎて何も心配することはない」というスタイルで住んでいた当時、ジョンに会いました。

ジョンは素晴らしい人物です。私はモンキーストーンゲームズで彼と協力し、ゲームボーイアドバンスのゲーム開発を手伝いましたが、それは別の話です。

[著者のメモ：ゲームはHyperspace Delivery Boyと呼ばれていました。 Gameboy Advanceについては、 Majescoが公開することになっていたが、最後の時点で会社はリリースを拒否した。]

私たちはロメロとトムホールと話をしました。「ウォーレン、あなたはクールだ、このゲームを作ろう！」 ウォーレンは答えました。 ダラスに移動しません。 カリフォルニアに移動しません。 どこにも移動しません。 スタジオはオースティンに置いておきます。 ですから、私たちは完全に自立したままです。 すべてを完全に制御できます。 あなたは私にお金をくれます、そしてすべてが大丈夫です。」 彼らは答えました：「わかりました、私たちに合っています。 解決しました。」

[著者のメモ：明らかに、これは交渉を単純化しすぎたバージョンですが、何が起こったのかを知ることができます]

ウォーレンは当時、トラブルシューティングゲーム用の優れたデザインドキュメントを持っていましたが、これは徐々にDeus Exのデザインドキュメントに変わりました。

そこで、6人でスタジオIon Storm Austinを設立しました。 当時、私はテクニカルディレクター、IT部門の責任者、「Homo Arom」、セキュリティサービス、および主要なエンジニアでした。 これらすべてを行うのに十分な人員がいませんでした。 そのため、迅速にインタビューを実施し、スタッフを採用する必要がありました。

チームは小さかった。 私たちには、スコット・マーティンとアル・ヤルソという3人のエンジニアがいました。 シェルドン・パコッティは脚本家として雇われました。 それぞれ3人ずつの2つの設計チームがありました。 1つはロバートホワイト、2つ目はハーベイが率いました。 ジェイ・リーが率いる6人のアーティストがいるようです。

ああ、アンリアルの彼の音楽の大ファンだったので、アレックスブランドンも雇いました。 今、私たちは素晴らしい友達です。 私たちは高校の友達だったので、私は彼を将来の妻に紹介しました。 彼は素晴らしい男です。優れたミュージシャンであり、技術的な詳細に精通しています。

その後、管理者を雇いました。それだけです。 そして、2年半の間、地獄のような仕事に直面しました！ [笑い]

UnrealエンジンとQuakeエンジンの選択

JL：それで、Ion Stormの残りの部分はQuakeエンジンで動作しましたが、アンリアルを選択しました。 この決定に至った経緯を説明できますか？

KN：Quakeエンジンをいくら尊重しても、その時点ではサポートが提供されないことはわかっていました。 私たちは何でもできるようにしたい非常に具体的なゲームを作成しました。 Quakeはシューティングゲームであり、それ以上のものではありませんでした。 FPS以外のことをしようとすると、多くの作業が必要になり、Idからサポートを受けられませんでした。 彼らは単にCDにコードを焼き付け、それを開発者に渡して、そのままにしておきました。

JL：ティムスウィーニーとのインタビューで、彼は当時のQuakeエンジンのライセンスモデルを「25万ドルのXcopy操作」と呼びました。

KN：はい、絶対に正しいです！ 私は同意します、エンジンは驚くべきものでした。 当時、彼は革命を起こしましたが、3人のエンジニアのチームがエンジンを書き換えることはできず、独自のエンジンを書くこともできないことを知っていました。 時間が足りません。

かつて、Amiga、C64、PCデモシーンの大ファンでした。 アンリアルと呼ばれるビデオゲームを見始めて、「ああ、なんてこった、RGBライティングとフル3Dがあるのか​​。 エンジンはMMX、SSE、および3DNowを使用します。 彼はとてもクールに見えます！」しかし、私たちは彼に関する詳細な情報を見つけることができなかったので、カナダのロンドンにあるDigital Extremesへの旅行を計画しました。 私たちはティムと彼のチームと会い、エンジンのすべての機能を見せてくれました。 また、私は現在ソニーと仕事をしているカルロ・フォーゲルサンと会いました。彼はプレイステーション部門にいます。 彼はGalaxy Audio Engineを書きました。ほとんどすべてがアセンブリ言語で、超ハードコアな男です。 エンジンには、火と呼ばれるパーティクルシステムがありました。 これらはすべてエンジン内にありました。 「みんな、私はあなたのアプローチが好きだ」と思った。


当時、彼らはこれまで誰もやったことのない超便利なツールの作成に注力しました。 Quakeツールは優れていましたが、技術に詳しくないユーザーにはあまりフレンドリーではないようでした。 エンジニアリングスキルのないデザイナーがいて、これらのプログラムの使用方法を把握する必要がありました。

そこで、私たちは次のことを決定しました。「これらの人には優れたツールがあり、誰もが私たちを大いに助けてくれます。80年代にハードコアなものを書いた古い学校の人がたくさんいます。 そして、ライセンスはどのように配置されますか？「彼らは答えました：「私たちはこれをこれまでやったことがありません。 当時、彼らはライセンスモデルの作り方を理解していなかったと思います。 「ウォーレンスペクターがいます。彼はあなたのエンジンでゲームを作りたいと思っています。」 彼らがこれを聞いたとき、彼らは本当に私たちと一緒に働きたいと思ったことが明らかになりました。

正直なところ、ライセンス契約の詳細を覚えていません。 ティムはおそらく覚えています。 支払った金額は覚えていませんが、あまり考えていません。」

JL：当時のIDがQuakeにどの程度リクエストしていたのでしょうか？

KN：少ないと思う！ そしてそれは別のプラスでした。 彼らのエンジンは比較的新しいものでしたが、私たちは最初のライセンシーではありませんでした。 最初の1つは、Wheel of TimeとKlingon Honor Guardです。

[著者注： ティムスウィーニーとアンリアルエディターについてのインタビューでアンリアルエンジンのライセンス履歴について詳しく読むことができます]

したがって、私たちはそれを選択することにしました。 開発者はソースコードを提供し、次のように述べました。「できるだけ早くサポートします。」 私たちはいつも対面で話しました。 質問がある場合は、電子メールを送信しました。テクニカルサポートシステムはありませんでした。

彼らがこれをやったことがないので、私たちは多くの問題を抱えていました。 私たちは彼らに多くのコードと質問を送り、長い連絡を取り、更新を受け取りました。 しかし、私はそれが正しい決断だったと信じています。 Quakeを選択した場合、ゲームの作成ははるかに困難になると思います。

さらに、Unreal Tech Advisory Groupのメンバーになりました。 私たちは最初の技術会議のアイデアを思いつきました。そこではライセンシーになったすべての会社の長（当時は4人でした）が集まり、エンジンを改善する方法について議論し、不便な点についてTimをscり、アルコールや食べ物で整理しました。通常。 私はまだこれらすべての人々と連絡を取り合っています。

JL：Unreal Tech Advisory Groupの他のメンバーと何か共有しましたか？

KN：主にUnreal Editorの改善点を共有したと思います。 エンジンは素晴らしかったが、彼にはまだ長い道のりがあった。 その後、さらに多くのデザイナーやアーティストを雇うことができたとき、彼らは作業プロセスを改善するための提案も始めました。 それらを自分で実装するか、Unrealチームに送信するか、Unrealチームに私たちよりも早くできるかどうか尋ねました。

メインエディタに多くの変更を加えましたが、そのほとんどはゲームにのみ関連していました。 いくつかの改善点を共有しましたが、他のほとんどの開発者はまったく異なるゲームに関与していました。

私は、その種のシステムとしては初めてだと思うシステムをたくさん書かなければなりませんでした。 少なくとも私はそれらを見たことがない。 たとえば、アニメーションミキシングシステム。 本質的にこれは、モーフターゲットまたはブレンドシェイプが今日呼ばれているものです。 当時、ゲームでこれをしている人はいません。 すでにどこかで実装されているかもしれませんが、インターネットが広く使用される前は、情報を共有することは非常に困難でした。

JL：Unreal Editorに加えた変更について話してもらえますか？

KN：何らかの理由で当時はエディターになかったシステムの1つは、カメラスプラインの視覚化です。

UnrealEdの最初のバージョンでは、カメラをドラッグしてそのパスのポイントを設定する必要がありました。 この場合、ポイントを表示することはできましたが、カメラ間のパスを決定するポイント間の接続は表示できませんでした。


JL：ポイントツーポイントゲームのようなものですが、数字はありません！

KN：その通り！ スプラインにはブレークポイントがあり、設計者はパスがどのように見えるかを常に把握できませんでした。 彼らは、カメラがどのように移動するかを非常に正確に知りたいと思っていました。 そこで私はこのシステムを追加しましたが、彼らはそれを気に入りました。

とても簡単でした。 コードの単純さを意味します。各主要な制御点に座標軸を描画し、次に制御点を描画して実際にどこに行ったかを確認します。 それは設計者を本当に助け、そのようなシステムを作ることは非常に簡単でした。 なぜ追加しなければならないのかわかりません。 ティムは彼女が本当に必要だとは思っていなかったと思います。

DL：これは面白いです。Unrealの最初のデモを一般に思い出すと、人々が最初に目にしたのは城の周りを飛んでいるカメラでした。つまり、Epicはカメラパスを作成しなかったようです。


KN：その理由は、レベルデザイナーの多くが超技術者で、頭の中でそのようなことをシミュレートするのに慣れていたからだと思います。 しかし、ビデオゲーム業界は徐々に成熟したため、さまざまなレベルの経験を持つ人々のためのツールを作成する必要がありました。 すべてのデザイナーがエンジニアであったわけではなく、今日ではさらにそうです！ これはルールではなく例外でした。 したがって、ツールは便利でシンプルになっているはずです。

ところで、ポーンが恐竜の頭で示されている理由はまだわかりません。

JL ：（笑）はい、ティムと私はこれをインタビューで議論しました！ ところで、あなたがした技術的な決定を後悔しましたか？

KN：UnrealScriptを使いすぎました。 これは間違いの1つでした。 UnrealScriptは非常に柔軟でしたが、遅すぎました。 UnrealScriptよりもネイティブCでより多くを書く必要がありました。

真北と偽のグリッチ

[著者のメモ：インタビューのこの段階で、Deus Ex Editor（UnrealEdのバージョン）とDeus Ex SDKのドキュメントを開きました]

JL：Deus Ex SDKインストーラーには、Robert White、Sheldon Pacotti、Al Yarusso、およびScott Martinがスポンサーしているように見えるドキュメントファイルがいくつかあるDocsフォルダーがあります。 これらの人々が誰であり、彼らが何に取り組んだかを教えてもらえますか？

KN：Alは対話エディターに関与していました。 スコットはAIに取り組みました。 私がやった... すべて 。 [笑]とりわけ、私はアシスタントディレクターでリードプログラマーでした。 しかし、プロジェクト全体で最初から最後まで3人のエンジニアしかいなかったため、私たちはすべてを少しやりました。


クリス・ノルデン（左下）、エル・ヤルソ（クリスの右上、時計を手に）、ロバート・ホワイト（中央列、中央のやや右、サングラス着用）、シェルドン・パコッティ（右下）、スコット・マーティン（2回目）行、右端、サングラスも）

DL：「Unrealは垂直階段をネイティブでサポートしていませんが、Deus Exに追加されています。」というエディターのドキュメントのセクションがあります。 これについて詳しく教えてください。

KN：階段は面白い話です。なぜなら、私たちはレベル全体を動き回らなければならなかったからです。その当時の一人称シューティングゲームでは、この目的のために、伝統的に傾斜階段と滑らかな上り坂が使用されていました。

ウォーレンの法令の1つ（設計が法律であるためです！）プレイヤーは、どんな方法でもミッションを完了することができるべきだと言いました。 ゲームの重要なアイデアは、望むなら、発射することなく、全体を実行できるということでした。 実際、私たちはあまり成功しませんでした。数回撮影する必要があるゾーンがいくつかありますが、私たちは非常に近かったです。

DL：開発者は続編で成功したと思います。

KN：はい、おそらく。

そのため、プレーヤーはゲーム全体を経験し、発砲することはなかったはずです。 さらに、彼は射撃以外の何もせずにゲーム全体を経験することができました。 プレイヤーはゲーム全体を通り抜けることができ、敵に検出されることはありませんでした。 完全に異なる方法でそれを通過することが可能でした。

JL：垂直階段の欠如は、アンリアルテックアドバイザリーグループミーティングでティムと話し合ったトピックの1つでしたか？

KN：答えるには、「Fuck you、Tim！」というスクリプトコードを見つけて調べる必要があります[笑]。これは怒ったときに私たちがやったことです。後でこれを覚えておくためにコメントを書き留めました。

垂直ラダーのサポートを追加する方法について考え始めたとき、最初に「ジオメトリを作成しましょう。次に、プレイヤーが同期アニメーションでバーをつかむことができるように、トリッキーな物理的トリックを行うことができます」と考えました。 しかし、私たちが決めた後-まあ、これはすべて地獄であり、複雑すぎます。

JL：[笑]

KN：デザイナーがこの仕組みを作成することを要求したため、これを非常に迅速に行わなければなりませんでした。

したがって、結果として、私は地獄のようなハックに行かなければなりませんでした。 エンジンには「テクスチャグループ」という概念がありました。 本質的に、それは特定のタイプのテクスチャに割り当てられた文字列ラベルであり、それらをソートしやすくします。 コードでリクエストできます。 そこで私たちは考えました：「なぜアーティストは登れるようにテクスチャを作らないのですか？」 その後、単にそれらをテクスチャグループに追加し、レイキャストを実行してそれらを認識し、いくつかの制限を加えて、プレーヤーを彼の動きの方向に固定しました。 これはうまく機能しましたが、常に完璧とは限りませんでした。プレイヤーがテクスチャの最上部に登ったとき、ビームはもはや放射されず、プレイヤーをプラットフォームに押し上げる必要があったためです。 つまり、ソリューションは不完全ですが、結果として機能しました。 安くて簡単なハックでした。

今日の読者は、「エンジンに階段がなかったのはなぜですか？ しかし、当時は何もありませんでした。 これらは単なるBSPフラグメントであり、静的メッシュはありませんでした。そのようなものはありませんでした。


JL：UnrealEdには非常にクールな螺旋階段ジェネレーターがありました（笑）が、垂直階段はありませんでした。

KN：ええ、そうです... BSPに穴が開いたので、私たちはそれを使用してデザイナーをscったようです。 近くに何もなければ、階段はきれいに見えました。 ただし、BSPで角スライスを作成し始めるとすぐに、BSPに小さな穴を開けることができますが、穴自体は見えません。 この機能は多くの痛みを引き起こし、その使用を禁止しました。 彼女は良さそうに見えたが、壊れていた...

DL：ドキュメントには、マップに関する情報（たとえば、マルチユーザーかどうか）、マップの作成者の名前、ミッションが完了した場所、ミッション番号などを含むDeusExLevelInfoというクラスも記載されています。 しかし、TrueNorthについてお聞きしたいと思います。

KN：[笑] BAMタイプのUnreal：Binary Angle Measurementエンジンでした！

JL：これらのクレイジーな数字は何ですか？！

KN：当時、浮動小数点演算は非常に高価でした。 鉄は弱かったが、十分な記憶がなかった。 360度は8ビットの数値ではなく、255単位の精度、つまり1単位あたり約1.4度で十分ではありません。 ティムはオリエンテーションに16ビットの数値を使用し、これにより精度が向上しました。

プログラマーにとって、これらの数字はすべて非常に簡単です。 これらは2度で問題ありません。すべてを頭の中で計算できます。 しかし、デザイナーとアーティストは問題を抱えていました。 そのため、開発者がそれらを覚えやすくするために、簡単な単純化を考え出しました。

[編集者と作業している間、クリスはデコレーションクラスに参加しました]



KN：デコレーションも大きなクラスでした。 対話できるすべてのメッシュは装飾です。 つまり、ゲーム内のほとんどすべてです！

JL：ドキュメントの装飾セクションでは、「以下にリストされていないフィールドの一部を変更すると、エディターがクラッシュする可能性があることを警告しています。」 なぜこれが起こったのか覚えていませんか？

KN：[笑]正直、覚えてない。 デコレーションは非常に大きなクラスであり、エンジンと奇妙な方法で相互作用する非常に多くのEpic機能があったため、特定のフィールドが予期しない動作を引き起こす理由を技術的な微妙さを理解していないデザイナーに説明するのではなく、彼らは「それを使わないでください。さもないとエディターがクラッシュします。」

JL：[笑]

KN：恐ろしい戦術のようなものです。 プログラマーの会議で、私たちは、これがBSPチェーンの損傷につながることをユーザーに説明する方法を疑問に思いました。 エディターがクラッシュすることを伝えましょう。

コードをもう一度調査する必要がありますが、あまりにも深く詐欺されているユーザーを怖がらせるために、一部の場所で意図的な失敗を隠しているという罪さえあるようです。

JL：続けましょう。 ParticleGeneratorセクションには、「主な機能の1つは、トリガーとunTriggersを使用してオンとオフを切り替えることができることです。」 つまり、使用したアンリアルエンジンのバージョンでは、パーティクルをオンまたはオフにすることは不可能でしたか？

KN：当時は違います。 パーティクルシステムを挿入した場合、常に存在し、オフにはなりませんでした。 これは奇妙な見落としだと私には思えます。

そうでなければ、Unrealパーティクルシステムは最高でした。 ほとんどはアセンブラーで書かれています。 それは手続き型であり、他のすべてと比較して非常によく書かれています。 デザイナーは彼女を愛していました。 実際、あまりにも多くの。 フレームレート全体を殺すことが可能でしたが、彼らは夢中になり、ますます透明なレイヤーを追加しました。

当時、ハードウェアレンダリングはまだ普及していませんでしたが、ソフトウェアレンダリングをサポートする必要がありました。 Timは素晴らしいプログラミングスキルを持ち、優れたソフトウェアレンダラーを作成しました。彼は素晴らしかったです。

[ゲーム内のさまざまなオブジェクトを見ると、[プロパティ]パネルに異常な名前のカテゴリがあることに気付きました]

JL：この匂いの特性は何ですか？

KN：動物は痕跡を取るために嗅覚が必要でした。 実際、犬は臭気ノードを追跡できます。 私が正しく覚えていて、レベルを移動すると、プレイヤーは特定の期間有効だった匂いノードを残すことができます。したがって、犬が彼の匂いを嗅ぐことができるように、それを作りました。

DL：つまり、箱の後ろに隠れると、人々はあなたを見つけることができませんが、犬は見つけることができます

。しかし、結局彼は切り取られたようです。グラフィカルなフィードバックがなかったため、この概念をプレーヤーに説明することは困難でした。



[ゲーム内で最も象徴的なオブジェクトの1つであるイントロレベルを開きます。この部屋には、巨大な手の像が回転するグローブを持った大きな恐ろしい部屋があります。ゲームのオープニングビデオで彼女 を見せてくれます。]

DL：質問があります。床の下にこのジオメトリのミラーは表示されません。他のゲームでは、床の裏に重複したジオメトリを配置することでミラーがシミュレートされました...



KN：いいえ、鏡は本物でした！非常に遅いため、デザイナーにめったに使用しないように依頼しましたが、これらは実際のミラーです。

実際、レーザーコードを書いたとき... [笑]

DL：[笑]あなたが何を得ているかわかります...

KN：...私は実際に鏡をチェックしなければなりませんでした。すべてのデバイスのコードをテストするテストレベルがありました。レーザーポインターコードを書いたとき、反射ミラーディスコボールを作成し、両端にミラーのある部屋を作りました。レーザーポインターを取り出し、ディスコボールに向けると、うまくいきました！

もちろん、すべてのラインをトレースしなければならなかったため、フレームレートはどこよりも低くなりました...

Light Wave：LWO23Dコマンドラインツールをご覧ください

[著者注：LWOはLightwave Objectの略です。これは、フォーマットの3DジオメトリのソフトウェアパッケージですLightwaveの3D会社NewTek社のチームデウスエクスしばらく]としてもテキサス州に位置して、



TackのDeus Ex Labのスクリーンショット

JL：なぜあなたのチームはLightwaveを使用することに決めましたか？

KN：私たちのアーティストは彼をよく知っていました。 したがって、適応する必要がありました。

DL：エクスポーターをコマンドラインツールとして書いた理由について詳しく教えてください。

KN：そのとき、そして今でも、タスクを自動化するための小さなコマンドラインツールを書くことがよくあります。 私は昔ながらのプログラマーであり、不必要な合併症は好きではありません。 私はほとんどC ++が嫌いです。 私はパターンが好きではありません。 時間のかかるものすべてが好きではありません。

コマンドラインツールを作成するときは、Win32バッチファイルを作成し、組み込みのすべてを取り除き、空のファイルから始めて、 int main() 、先に進みます。 これは、問題を引き起こさない迅速でポータブルなソリューションです。

DL：静的メッシュのエクスポートはかなり標準的なプロセスだと思います。 しかし、アニメーションをどのようにエクスポートしたか教えてください。



TackのDeus Ex Labのスクリーンショット

KN：ゲームには骨格アニメーションはありませんでした。 私はそれが実装されている時代の単一のエンジンを知りません。 したがって、すべては頂点の混合によって行われました。 スキニングは当時非常に高価でした。 GPUはありません。CPUですべてを計算する必要があり、何らかの方法で浮動小数点計算を避けました。

Lightwaveの内部で、デザイナーは骨格アニメーションを作成し、そのキーフレームを表示しました。 アニメーションをミックスするには共通の基盤から始める必要があるため、Tポーズを作成する必要がありました。 つまり、適切なミックスでは、アニメーションは基本的にTポーズからのオフセットでした。 混合はエンジンの側面で行われました。

JL：それで、Unrealでは、すべてが同じでしたか？

KN：おそらくはい。 ティムが次のバージョンに骨格アニメーションを追加したとは思わない。

トーキングヘッド：ConvEditとLipsink

[ConvEditフォルダーを開きます]


JL：ConvEditについて教えてください

KN：Alの発案によるもので、Visual Basicで書いています。

JL：当時のUnrealEdと同じです。

はい、当時は、インターフェイスを簡単に実装する機会はあまりありませんでした。 Delphiおよび他のいくつかのUIフレームワークがありました。 それらを使用しなかった場合は、たとえばWin32 API、GDIなど、すべてネイティブに記述する必要がありました。 それは大きな問題でした。

つまり、今日ではかなり原始的なように見えるVisual Basicは、当時非常に優れていました。C＃の前身であるBasicに似た独自のプログラミング言語を備えたシンプルなビジュアルフレームワークです。 彼は私たちに関数のプロトタイプを作成し、ツールを非常に迅速に書くことを許可しました。

[注：Visual Basicがその時代のゲーム開発ツールでどのように使用されたかに興味がある場合は、 アンリアルエディターについてのティムスウィーニーとのインタビューを読んでください]

主にシェルドンが使用していました。 彼はカメラを制御するツール、音を制御するツールを必要としていました。 彼は、誰も使用したことのない映画のようなツールを多数使用したいと考えました。 最初に演壇ズームとは何かを学び、シェルドンとこのゲームに取り組みました。

今日でもこのツールはまだ使用されていると思います。

ところで、シェルドンはトンネル手首症候群（RSI、反復性緊張障害）を患っていたため、アザラシは彼にとって拷問になりました。 彼は、Dragon Dictateの音声転写を使用してDeus Exにほぼ完全に取り組みましたが、当時は今日よりもはるかに悪かったです。 この症候群は非常に強かったため、シェルドンは装具を着用する必要さえありました。




JL：わあ！ 知りませんでした ゲームには多くのダイアログと多数のブランチがありました...

KN：1つのミッションでも大量のデータがあります。

シェルドンは、ゲームと多くのインタラクティブな対話を強力に制御したいと考えていました。 彼はプレーヤーに有意義な選択をしてもらいたかった。 彼とウォーレンは、選択せずにダイアログをクリックする必要がないことを嫌っていました。 彼らはプレイヤーがキャラクターとやり取りし、重要なものを選択することを望んでいたので、ゲームは旗を立て、パッセージ中のキャラクターとのやり取りと行動を覚えていました。

JL：Deus Exの最初のウォークスルーから、アンナナバラのオフィスでのブリーフィングを覚えています。 すべてのビデオゲームでいつものように、私はNPCが対話を完了するまで、あらゆる種類のナンセンスをしてオフィスを走り回りました。 突然、彼女は会話を止め、私に向き直り、「一体何をしているの？」と尋ねました。

KN：[笑]

DL：少しの間、私は凍りついて、「これは本当に起こったのですか？」と自問しました。ゲームに没頭するという点で、私にとってはとても重要な出来事でした。 これが見られる前の単一のゲームはありません。 これは、会話エディタが原因のようです。

KN：ウォーレンの戒めの1つは、「プレーヤーが誰かのオフィスにいて、動物のように振る舞い、物を壊す場合、キャラクターは何かを言わなければなりません！」 彼はプレーヤーを無視すべきではありません。なぜなら、それは非現実的だからです。」

JL：ツールを作成するのが特に難しいと判明したカットシーン関連の側面はありましたか？

KN：私たちはたくさんの対話をしましたが、それらはすべて声をかけられました。 私たちは俳優との対話を録音スタジオで数週間過ごしました。 これは、唇の動きを同期させることについて考える必要があることを意味します（lipsyne）。 「非常に多くのダイアログでリップシンクを作成する方法は？」と思ったのは、結局のところ、フレーズだけでなく、いくつかの言語もありました。

当時、左官に役立つツールはあまりありませんでした。 ほとんどの開発者は前処理を実行しました。ツールでダイアログを実行し、データファイルを表示してから再生しました。 しかし、私は決定しました：「私たちはこれのための時間がありません、そして、あなたが声を再録音しなければならないならば、あなたは再びすべてをやり直す必要があるでしょう。」

だから私は、動的なサウンド分析を使用してこれをリアルタイムで行う何らかの方法がなければならないと考え始めました。 大学で電気工学を学び、誰にも言わずに自分で理解することにしました。

JL：[笑]

KN：「これができるかどうか見て、みんなを驚かせます」と思いました。 繰り返しますが、私は誰も以前にこのようなことをしたことはないと思いますが、今日、このテクニックはどこにでもあります。

当時、私が見たすべての中で、そのようなシステムに最も近いのはHalf-Lifeでした。 開発者はEnvelope Followingテクニックを使用しました。これは文字通り、サウンドの音量に応じて口を開閉します。 システムは機能しましたが、あまりリアルに見えませんでした。

DL：本質的に、それは「顎のけいれん」でした。

KN：はい、正確に、正確に。

Gabe Newellとこのタスクをどのように達成したかを一度話し合ったときのことを覚えています。「ああ、 Envelope Followを使えばそれで十分です。 他のすべては複雑すぎます。」

それから私は家に戻り、数学的計算を推定し始め、それからFFT（ 高速フーリエ変換 ）を実行するシステムを書きました。 繰り返しますが、浮動小数点計算は非常に高価であり、おそらくそれらをシミュレートする整数近似を記述しました。

彼女はリアルタイムで短い音声録音を分析し、主要な周波数成分を抽出し、6〜7つの異なる音素に結び付けました。

ひそかに、アーティストの一人にいくつかのブレンドの形（ブレンドシェイプ）をシミュレートするよう依頼しました。「ああ」、「a」、閉じた唇などが必要でした。 彼は理由を尋ねました、そして、私は彼が単にこれをして、私にデータを与えたと答えました。



高速フーリエ変換（ウィキペディアの画像）およびプレストンブレア音素シリーズ

JL：[笑]このソリューションは、Deus Exで使用したアニメーションの組み合わせに合っているようです。

KN：はい、正確に、完璧です。

それで、彼は私にデータを与え、私は数学的計算を書き、できる限り手作業でフォームを添付しました。 私は真剣な研究をしませんでした。システムはパフォーマンスの点で非常に高価でした。

私は真ん中に巨大な頭を持つテストレベルを作成し、彼女に2、3行を送りました。 ドイツ語、英語、フランス語でフレーズをチェックしましたが、すべてが完全に同期していました。 「くそ、これはすごい！ 本当にうまくいきました！」

ウォーレンを見つけて、彼に言った、「私はあなたに何かクールなものを見せたい」。 彼はst然としたようです。 [笑]彼は私に尋ねました：「一体何だ、これをゲームに入れることができますか？ すごい！」

その結果、このシステムを使用したゲームをリリースしましたが、パフォーマンスのために大幅に削減する必要があり、そのために視覚的な品質が低下しました。 しかし、私の最初のテストレベルは素晴らしかったです。 私は今でもこれが最初のリアルタイムリップシンクシステムだと思います。 以前にこれをやった人はいません。

おそらく特許を取得する価値があったのでしょう。 しかし、私はそれが悪質な行為だと思うので、ソフトウェア特許を信じません...

また、このシステムをAnacronoxで使用したいダラスのアートディレクターの1人との大きな議論もありました。 彼女は私たちのゲームの前に出てくるべきだった。 「共有してもかまいませんが、Deus Exが登場する最初のゲームになりたいです。」 彼は言った：「いいえ、あなたは私たちにそれを与えなければなりません！」彼はホールで私たちに実際に叫んだ。 「いいえ、私はすべきではありません」と答え、ウォーレンは私を支えました。 最初にゲームをリリースしたので、これはとにかく重要ではありませんでした。 実際、私たちはそれを手放したくなかったので、結果として、彼らは独自にシステムの独自のバージョンを実装したと思います。 利己的だったかもしれませんが、この機能を実証できるように、最初に卒業してほしかったです。

Ion Stormが制作した他のすべてはダラスで開発されました： Dominion：Storm Over Gift 3 、 Daikatana 、 Anacronox-すべてはダラスで行われました。 Deus ExのみがAustinで作成され、私たちのチームだけがいて、他の人はいませんでした。 私たちはバブルにあり、ダラスのオフィスからはまったく孤立しており、これは意図的に行われました。 私たちは束をいじりたくはありませんでした...私は率直になり、彼らのすべてのゴミを束ねます。 この分離は完全に意図的であり、私たちにとって非常に重要です。 私たちのチームと彼らのチームはテクノロジーを交換せず、実際の連絡先も交換しませんでした。

おわりに

DL：要約すると、この記事を読んでいるツール開発者にアドバイスをいただければ、何と言いますか？

KN：顧客の話を聞いてください。 ツールを真空で書かないでください。 エンジニアとして、「この方法でこのツールを使用できます。この方法が最も効果的であるため、このように記述します。」

しかし、ほとんどいつもあなたは間違っています。 デザイナーとアーティストのワークフローは非常に異なるため、デザイナーとアーティストの話を聞く必要があります。 それらは他とは完全に異なる働きをします。 このツールはあなたが使用することはありません。ほとんどの場合、彼らのためです。

DL：一緒に働いたチームでそのようなメンタリティに出会ったことはありますか？ そして、これにどのように対処しましたか？

KN：プログラマーに伝える必要があるのは、「ユーザーにこの問題があると思うのはなぜですか？ 問題はコードにあると思いますか？ それとも、画面の構造に問題があるのでしょうか？ フォントが小さすぎませんか？ 間違ったボタンの色？ おそらく、あなたは非標準的なことをしているのでしょうか？」

なぜなら、プロフェッショナルなデザインのほとんどのツールを見ると、通常はかなり一貫しているからです。 物事の仕組みに関する設計ガイドがあります。

クリエイティブチームはこれらのツールを使用できる必要があります。 ドキュメントを読む必要があるということではありません。 理想的な世界では、すべてが明白なはずです。

今日はUX / UIデザイナーがいますが、当時は何もなかったので、ユーザーからのフィードバックを得ながら、自分でインターフェイスデザインを作成する必要がありました。

そのため、ユーザーの隣に座って、ツールの使用方法を確認してください。 Lightwaveでの動作を確認しました。 ツールの最初のバージョンを書いたとき、私たちは何をすべきかを促さずに近くに座って、それらを見て、「これに問題がありました」または「それを見つけるためにメニューに登らなければならない」などのメモを作成しましたホットキーにする価値があります。」 それらを見て、学び、適応するだけです。

つまり、デザイナーのワークフローについて本当に考える必要があります。 不要な動きを最小限に抑え、メニューのクロールを最小限に抑え、ホットキーを追加する必要があります。 ワークフローを高速化するため、すべての機能のキーボードショートカットを積極的に推進しました。 ツールを学習する過程で、ホットキーを使用して作業を大幅に加速します。メニューを登る必要はありません。

エンジニアのための古典的なtrapに陥る必要はありません。「よく知っています。楽器を書き留めました。どのように機能するかを知っています。 使用できない場合、あなたはただのバカです。」 これは、ツールを開発するときに起こりうる最悪の事態です。

JL：素晴らしいアドバイス。 クリス、どうもありがとう！