Warcraftの作成（パート1）

はじめに（翻訳者から）

私のお気に入りのゲームの1つがWarcraft IIであることがわかりました 。

このゲームがどこかで言及されたり、誰かがそれを覚えているたびに、私は通常とても幸せです。 もちろん、 Warcraft IIの前は、 Warcraftだけでした。



そして最近、面白いことが起こりました-ブリザードの起源に立っていた人の一人であるパトリック・ワイアットと、ウォークラフトの開発を始めた人は、当時の一連の思い出を始めました。 以下で読むことをお勧めする最初の記事は、Warcraft開発の開始に関するものです。 アイデアの出所について。 彼らがマルチプレイヤーを夢見ている間に、オフィスで組織されたネットワークについて。 EMSおよびDOSでのプログラミングの美学の複雑さについて。 プロジェクトチームなどについて。



私は悲しいかな、DOS開発の専門家ではないので、読者が技術的な詳細に関連する翻訳の不正確さを指摘してくれたら、喜んですぐに訂正します。



これはもちろん、その他の不正確さ、タイプミス、句読点および文体に適用されます。

---

昔、PCゲームがDOSオペレーティングシステムで書かれた時代の初めに、Warcraftと呼ばれるゲームの開発を始めました。

私はプロジェクトをリードし始めています！

私は、PC用のいくつかのゲーム、Mac用のいくつかのゲーム、スーパー任天堂とセガジェネシス用の7つのコンソールゲームを開発しましたが、後輩の開発者でした。 それ以外の場合、ゲームは一般的に移植され、ゼロから開発されたわけではありません。 移植とは、あるプラットフォームから別のプラットフォームにゲームを転送するプロセスです。 たとえば、Amiga用のゲームを作成し、コードを書き直し、デザインを再描画し、他の必要な詳細を変更すると、ゲームは任天堂で実行されます。



新しいプロジェクトでの私の役割には、2種類の作業が関係していました。 まず、プロデューサーとして開発チームをリードする-ゲーム業界では、プロジェクトマネージャー、デザイナー、エバンジェリスト、シェパードキャットと呼ばれます。 2番目：Lead Developerのポジションの要求に応じて、ほとんどのゲームコードを記述します。 そして、ちなみに、現在のように200人以上ではなく、10人または20人の開発者がゲームの開発に接続した場合はそれほど難しくありませんでした。

ウォークラフトのルーツ

当時私が働いていた新興企業では、 Silicon＆Synapseと呼ばれていましたが、熱狂的な開発方法に敬意を表してBlizzardに名前が変更されました-空き時間に、開発者は多くの素晴らしいゲームをプレイしました。 そして、この永遠のゲームプレイのおかげで、 Warcraftが生まれたきっかけが生まれました。



私たちは、 Westwood Studiosが開発したDune 2と呼ばれるゲームによってWarcraftを作成することに触発されました。 デューン2は、おそらく最初の最新のリアルタイム戦略（RTS）でした。 スクロールマップ、リアルタイムのユニットの作成およびユニットの制御。 ユニット間の個別の戦闘で。 基本的に、このゲームは、特定のスケールとグラフィックスの品質を除いて、 Starcraft 2などの最新のRTSとほとんど変わりません。



このゲームの前身はDune 1でした。これも上記の要素を組み合わせた非常に価値のあるゲームですが、クエストゲームに組み込まれています。 Dune 2は、前のゲームで提案されたすべてのモードから1つのモードに焦点を合わせました。 プレイヤーは、リソースの収集、基地の建設、リソースの収集、軍隊の形成、そして最終的に敵の探索と征服をリアルタイムで制御したキャラクターを表しました。



私は、他のBlizzardの従業員と同様に、当時Dune 2のゲームに完全に座っていました。 昼休みや仕事の後、それを演奏しました。 3つのレースのそれぞれでプレイし、それぞれの長所と短所を特定し、その後、ゲームスタイル、戦略、戦術について議論しました。



しかし、プレイが非常にクールだったという事実にもかかわらず、私は修正することを示唆する多くの明らかな欠陥に苦しみました（いいえ、彼らはそれを要求しさえしました！）。 最も明らかな間違いの1つは、友​​人と私がDuneをコンピューターとしか対戦できないという考えでした。 このゲームスタイルがマルチプレイヤーに理想的であることは明らかでした。 各プレイヤーが他のすべてのプレイヤーが移動するまで待たなければならないターンベースのゲームとは異なり、リアルタイムゲームでは、すべてのプレイヤーが同時に行動できるため、時間のかかる戦略的な決定ではなく、スピードと決定的な戦術的な動きに集中できます計画中。



そして、この考えから、ゲームの開発が始まりました。 ゲームの設計を真剣に試みることなく、技術要件を評価することもなく、スケジュールと計画もなく、従業員の予算を計画することもありません。 彼らはナプキンさえも描きませんでした。 私たちは冗談でそれを「ビジネスプランデュジュール」 （フランス語で「1日」）と呼びました。これはその後Blizzardの標準プロセスでした。

開発開始

プロジェクトの唯一の開発者として、設計チームが不在で、この段階でDune 2のアートワークのスクリーンショットを撮り、このゲームのスライスを使用して、少なくとも1人のデザイナーをプロジェクトに接続できるようになるまで開発を進めました。 その後、デザイナーは他の多くのプロジェクトに取り組み、締め切りを迫り、気を散らす時間はありませんでした。それから、気を散らすことは一般に困難でした。



ゲームエンジンを開発する初期の取り組みは、タイルに基づいてスクロール可能なマップのレンダリングを作成することに焦点を合わせていました。 ユニットおよびその他のビットマップをレンダリングするスプライトレンダラー。 ユニットをアニメーション化できるスプライトシーケンサーエンジン。 マウスとキーボードのイベントマネージャーがクリックをキャッチし、最終的にユーザーインターフェイスのコードの強固な基盤を構築して、これらすべてを実際に試すことができるようにしました。 このキットにより、初期のプロトタイプを組み立てることができ、シングルプレイヤーモードで「プレイ」できるようになりましたが、新しいユニットを作成する機能がないため、これを後で実装しました。 このバージョンでは、キーボードからコマンドを入力するだけで、ユニットがマップに表示されました。



毎日、私はエンジンに新しいレベルを自発的に構築しました。 計画されたマイルストーンやプロジェクトの外部要件がないため、次にねじ込む機能を選択できるうらやましい立場にあり、本当にやる気になりました。 それでも、私はゲームの開発を楽しんでおり、当時私が目の前に開いていた未耕作の開発分野には麻薬効果がありました。 今でも、私はゲーム業界で22年間働いていますが、開発に関連する創造的な瞬間が今でも大好きです。

最初のユニークな機能：マルチユニット選択

私が特に誇りに思ったチップの1つは、ユニットの選択です。 Dune 2では、ユーザーは一度に1つのユニットしか選択できませんでした。これにより、戦闘の戦術的編成中にマウスが熱狂的にクリックされました。 ユーザーが複数のユニットを一度に選択して、ゲームオーダーの発行プロセスを高速化し、戦闘を劇的に行えることは明らかであるように見えました。



ゲーム業界で仕事を始める前、しばらくの間、 MacDrawやMacDraftなどの多くのコンピューター支援設計（CAD）アプリケーションを使用していました 。 それらの中で、私は父のビジネスのためにワインセラーのデザインをデザインしました。 したがって、複数のユニットを一度に選択する方法について考え始めたとき、長方形の「クリック＆ドラッグ」選択のメタファーを自動的に思い出しました。



Warcraftは、このUIのメタファーを使用した最初のゲームだと思います。 このアイデアをゲームに導入したばかりのとき、多数のユニットを同時に割り当てて管理することができました。 同時に選択されるゲームキャラクターの数に制限はありませんでした。



一度に100ユニットを選択してマップ上のあるポイントに送信すると、パス検索アルゴリズムの不完全性にすぐに気付きました。このアルゴリズムが登場した瞬間から、ユニットを選択して送信するのに何時間も費やしました。コードを書く代わりに地図をハイキングします。 当時、それは私がプログラムした最もクールな機能でした！



その後、開発プロセス中に、チームのメンバー間でゲームの設計について多くの議論を行った後、ユーザーが一度に選択できるユニットは4つだけにすることを決定しました。 これは、ユーザーに戦闘戦術についてもっと考えさせ、群衆を集めてすぐに戦闘に送り込ませたくないという事実によって説明されました。



後に、 Warcraft IIでは、一度に9ユニットを選択できるようにしました。 ちなみに、 デューン2の精神的後継者であるCommand and Conquerには選択肢の上限はありませんでしたが、これらのデザインアイデアに関する議論は、確かに別の記事に値します。



複数のユニットを同時に制御する能力を除けば、この段階では、 WarcraftはDune 2の簡易バージョンにすぎませんでした。 類似性は非常に下品だったので、 ウォークラフトが デューン2 に触発されたという事実にもかかわらず、それはまだ完全に異なるゲームです。画面の左上隅にミニマップがあり、右下にあります。

同胞団の設立

1994年の初めに、私はプロジェクトにより多くの人をつなげるのに十分な進歩をすでに遂げました。 Ron Millar、Sam Didier、Stu Rose、Bob Fitch、Jesse McReynolds、Mike Morheim、Mickey Nielsenなどが参加しました。 1994年2月に当社がDavidson＆Associatesに買収された後、彼らの多くがゲームの開発を始めました。



丈夫で長い髪のブロンドのロンミラーは、バイキング自身の子孫のようでした。 彼は当初アーティストとして雇われ、 Virgin Gamesの Gameboyプラットフォームの多くのアートワークの著者でしたが、彼の印象的な創造性とデザインの才能は、多くのBlizzardプロジェクトのデザインで非常に重要な役割を果たし、間違いなくこの役割を果たしましたWarcraftの開発。



熊に似た丈夫で背が高く、しゃがむキャラクターであるサム・ディディエは、彼の英雄的なキャラクターを描くという壮大なスタイルで、ブリザードグラフィックスのスタイルを定義します。 彼は16ビットコンソールタイルの描画中にも描画スキルを磨きましたが、すべての会議中や他の自由な瞬間にファンタジースケッチを描きたいという願望は、プロジェクトのアートディレクターとして素晴らしい仕事をすることを示唆しました。



Stu Rose - Blizzardロゴのデザインにつながったのは彼の実例的な背景でしたが、今でも使用しています。 彼はマップの背景タイルを描くことから始め、その後、 Warcraftの全体的なデザインコンセプトで重要な役割を果たしました。 Stuは人間のPeonの声と同じくらいあなたに馴染みがあります。 そして、私は言わなければならない、抑圧された勤勉な労働者がどのように話すべきかについての彼のアイデアは、彼の喜劇の才能を明らかにした。



ボブ・フィッチは、私がWarcraftを始めたその瞬間に、別のプロジェクトの開発者および技術リーダーとして私たちと一緒に働き始めました。 Blizzardの社長であるAllen Edhamは、クロスワード、学者、ボーグルなどのゲームを含む「 ゲームピープルプレイ 」という単語ゲームを書くタスクをボブに与えました。 ボブは非常に熱意に欠けていたため、プロジェクトは何ヶ月もほとんど進行しませんでした。 Warcraftが上り坂になったとき、ボブは私に夢中になり、彼の熱意は私たちのゲームが飛躍的に前進するのを助けました。



カリフォルニア工科大学を卒業したジェシーは、ローカルネットワーク（LAN）でゲームをプレイできるように、IPXプロトコル用のネットワークドライバーの作成に取り組み始めました。 Blizzardの 2人の共同設立者の1人であるMike Morheimは、後に難しいタスクの解決に貢献しました。「ミックスモード」で動作するモデムのドライバーを作成しました。 結局のところ、 Warcraftは保護モードで動作するDOSゲームであり、モデムドライバは、DOSと80386チップのアーキテクチャの両方に関連するトリックでのみ保護モードとリアルモードから同時に呼び出すことができました。システムは機能しました。 マイクはオフィスに座ってモニターを見つめ、同期データに対処するために診断データを殺到させました。 最終的に、モデム部分のコードは装甲貫通になりました。これは、以前使用した基本的な方法を考えると、当時の重要な成果でした。

アートオブウォークラフト

アラン・エダムは、ブランド認知を通じて販売を拡大しようとするウォーハンマー宇宙のライセンスを取得したいと考えていました。 Warhammerは、 Warcraftデザイナーの強力なインスピレーションでした。 しかし、いくつかの理由で、このベンチャーを放棄しました。 ビジネスレベルで有利な条件に同意することは難しく、チームの仕事に干渉しないように、私たち自身で宇宙の創造を制御したいという熱望があまりにも熱心でした（もちろん私ももちろん）。 さらに、ライセンスの下での作業はすでにかなり悪い経験がありました.DCコミックスと「デス・アンド・リターン・オブ・スーパーマン」および「 ジャスティス・リーグ・タスク・フォース 」を行いました。この経験を新しいゲームで繰り返したいとは言えません。



今では想像するのはかなり奇妙ですが、 BlizzardがWarcraftユニバースの知的財産所有者ではなかった可能性がありました。 そうすれば、今日のゲーム業界でこのような自信のある立場にいると想像するのはさらに難しくなります。



Warcraftを開始してから数年後、父がアジア旅行から戻ってきて、戦車に乗ったスケルトンの一団であるWarhammerミニチュアのセットを渡して、次のように言いました。「私は旅行中に、弁護士に伝えて、メーカーに連絡させてください。そうでなければ、彼らはあなたからアイデアを引き出しているように見えます。

ゲーム開発者への障壁

開発の初期段階の興味深い点の1つは、私たちが座ってゲームを開発している間に、ネットワークまたはモデム接続を介してプレイすることはおそらく素晴らしいことでした。 同時に、オフィスにはローカルエリアネットワークがありませんでした。 結局のところ、フロッピーディスクに簡単に収まるコンソールゲームを主に開発する前は、ネットワークは必要なものではないように見えましたが、バックアップを作成するプロセスを簡素化することもありました。



そのため、私が他のアーティストや開発者と積極的に仕事を始めたとき、私たちは通常「歩行者ロカルカ」を使用しました。つまり、実際には、コードまたは設計で実装する必要のあるオフィスからオフィスへの相互変更を含むフロッピーディスクです。



ボブ・フィッチはプロジェクトの2番目の開発者であり、私たちは常にファイルとコードの変更を相互にコピーしました。 時々、統合中にミスを犯し、すでに修正していたバグは再開されました。 私たちはそれらを再び捕らえ、ファイルをコピーして変更を加えたときに、成功したバグ修正の上に何かを上書きしたことを発見しました。



開発が加速しており、「どこで何を編集したかを記憶する」方法以外にバージョン管理のための他のプロセスがなかったため、この状況はますます頻繁に繰り返されました。 私のコンピューターはコードの「マスター」ブランチを保持していて、パッチを追加したため、ある程度幸運だったので、コードの変更はあまり頻繁に失われませんでした。 今日、私たちはこれにバージョン管理システムを使用していますが、そのような人生の喜びさえ想像できませんでした！



多くの開発者、デザイナー、アーティストがプロジェクトに参加し、プロジェクトに取り組んでいると、もちろん簡単になりましたが、基本的には別の大きな障害が見つかりました。 このゲームはもともとDOSで「リアルモード」で開発されたため、メモリは640Kしかなく、オペレーティングシステム用に120K前後しかありません。 その時の地獄のような状況を想像できますか！？！



デザイナーがキャラクター、背景、ユーザーインターフェイスを描き始めるとすぐに、私たちはすべての記憶を食っているという事実にすぐに直面しました。 そして、私たちは代替案を探し始めました。 最初のアイデアは、EMSページメモリ経由のマッピングを使用し、640Kメモリバリアの「上」にゲームデザインを保存することでした。



プログラマーがEMSの記憶について語る物語は、雪の中で登り、裸足で学校に行ったときの老人の物語に似ています。 EMSの話だけがはるかに悪く、これらすべては実際に真実です。



いずれにせよ、幸いなことに、EMSのアイデアはうまくいきませんでした。 しかし、より良い解決策がありました。 Watcomという会社がCコンパイラをリリースしました。これには、DOSモードの「エクステンダー」が含まれており、「保護モード」で記述されたプログラムが32ビットメモリのリニアアドレス、つまりプログラマーにアクセスできます。 32ビット（または64ビットアプリケーション）を書き込んでも問題はありません。 ソースコードを修正してこのモジュールをビルドするのに数日かかりました。その後、再び作業を開始し、より多くのメモリにアクセスできるようにしました。

結論ではない

シリーズの次の記事では、Stu Roseと設計革命について説明します。 最初のマルチプレイヤーWarcraftバトルとマルチプレイヤーをほぼ殺したバグ。 ビル・ローパーがフロッピーディスクにWarcraftを置くことでWarcraftを驚かせた方法。 私たちのゲームに対するWestwood Studioの反応や、ゲームに隠されているその他の詳細については、私とチームの他のメンバーが18年前に開発しました（！）。



続きを読む、第2部→