時々、ゲームを開発する際に困難が生じます-技術的な問題が現れ、デザインは理論的にのみ美しく、初期段階で行われた決定は後で困難につながります。 これがこのクラフトの現実です-作成の過程でエラーとset折があります。



しかし、機能やプロジェクトを変更したり、完全に放棄する必要があることを認識したくない場合はどうでしょうか？



人が自分の労働の結果に執着するのは自然なことです。 本を書くとき、これは「愛する人を殺す」と呼ばれます-私たちは愛で発明された不要な文章やフレーズを取り除く必要がありますが、それは冗長であるか、プロットを妨害することが判明しました。



そして、ゲームの開発においても、野心的で、アイドルで、利己的なものをすべてカットすることを学ばなければなりません。 これが行われない場合...そして、我々が見るように、問題はプロジェクトに沿って引きずられ、会社にとって悲惨な財政状況さえもたらすかもしれません。 これは、自分の間違いを認めることにより多くの追加労力を投資する必要がある場合に特に当てはまります。



エコノミストは、これを沈没コストの間違いまたはコンコードエラー（コンコード超音速旅客機の開発を記念して）と呼んでいます。 これは不合理な強化であり、彼は仕事に多くのお金/時間/エネルギーを投資したようであり、その停止は資源の無駄になります。 ただし、実際には、継続の決定は、以前の費用とは一切関係ありません。 最も重要なことは、余分な努力が報われるかどうかを理解することです。



私たちは、数十人の開発者に、彼らが取り組んだプロジェクトで取り返しのつかない損失エラーの経験について話すように頼みました。 ここに彼らが共有したかった物語があります。 それらはすべて、各開発者が継続的に費用便益分析を実行し、不快な結論が出た場合に決定的なアクションを実行する必要があるという重要なリマインダーとして機能します。

木の後ろに森が見えない

CloudGate Studiosの共同設立者であるSteve Bowlerは、 NBA Ballers：Phenomを開発する際にゲーム内にあるべきではない機能を有効にする試みを思い出します。 スティーブは当時ミッドウェイでアニメーターとして働いていました。



「当時、オープンワールドは新しく非常に人気のある「チップ」になりました」と彼は回想します。 「 Grand Theft Auto IIIがリリースされたばかりで、誰もがオープンワールドゲームを思いつきました。」



Ballersの最初の部分はかなり簡単でした-ストーリーカットシーンで接続された、それぞれ独自の環境にある1対1のストリートバスケットボールゲーム。 ボウラーは、続編は新しいゲームモードといくつかの追加でお金を稼ぐためのランスループロジェクトになるはずだったと言います。



しかし、同社は代わりに、これまでオープンワールドを作成したことがなかったチームに、NBAの認可を受けたストリートバスケットボールゲームでそれらを実装することを強制することにしました。





NBA Ballers：Phenom



「開発プロセスのすべてのステップは失敗でした。 たとえば、駆動システムをセットアップするとすぐに、NBAが介入し、NBAはファミリーブランドであるため、プレイヤーは道路上の誰にも押し付けてはならないと言いました。 最初は不要だったカーステアリング機能を放棄する代わりに、チームはNPCが道路から飛び降りることを学ぶために余分な時間を費やしました。



「開発者はオープンワールドを作成するために多くの時間を費やしましたが、最終的に会社がgaveめてアイソメトリックになりました。 今、彼はあなたが行くことができるメニューのように見えました」とボウラーは言います。 「そしてその後も、彼は不思議に思えた。 そして、全体として、それを実装するために最初に努力する価値はありませんでした。」

失業のエキサイティングな大惨事

Interplayの創設者の1人であるRebecca Heinemannは、彼女が参加した、または見た沈没費用に関する悪夢の物語を少なくとも共有できると語った。 しかし、彼女は最も愛する二人に話すことにしました。



「InterplayのStonekeepでは、数時間の実写ビデオが録画されました。 撮影は屋外で行われました」と彼女は思い出します。



しかし、日中の太陽の動きについては誰も考えていませんでした。その理由は、シーンからシーンへ移動するときに影が急激にジャンプしたためです。 「開発者は数日でスケジュールを修正できると考えていましたが、すべてのレコーディングをフレームごとに修正するには75人のアーティストが1年以上かかりました。」









ストーンキープ



十数年後、レベッカは、パブリッシャーの介入がメダルオブオナー：エアボーンの技術面を管理する際に友人のマークDoctermannに干渉する様子を遠くから見ました。



「このゲームはRitual Quake IIIエンジンで開発されましたが、EAは会社を買収し、その製品にエンジンを使用したかったため、チームはRenderwareエンジンに置き換える必要がありました」とハイネマンは説明します。



Doctermannはその年にコンソールに切り替えたと説明し、RenderwareはEAにRenderware 4.0がNext Genのツールと機能を提供できると確信しました。 問題は、まだ何も準備ができていないことであり、プロセス全体が費やされた壮大で長引く大惨事に変わりました。



レンダーウェアエンジンを使用して約16か月後、開発者はついにあきらめてアンリアル3に切り替えました。彼らはゲームを完成させるのに1年もかかりませんでした。









名誉勲章：空Air

決してあきらめない

開発者The Banner Saga Stoicはひどいミスを犯し、2回はサンクコストのtrapに陥りました-初めてコンソールにポーティングするときと、その後キャンセルされたVitaのポートを作成するときです。 スタジオの共同所有者でテクニカルディレクターであるジョンワトソンは、彼の間違いを認めています。彼は、港湾開発会社がいらいらするいくつかの締め切りにもかかわらず、「ほぼ終了」しているので、我慢しなければならないと考えました。



この問題の全容は、1年間のプロジェクト作業の後、ゲームを台無しにした会社が廃業したときに明らかになりました。 ワトソンは、コンソール上のポートの障害は約10万ドルの費用がかかり、別の会社がポートの開発を開始したときに作業の一部が使用されたが、これらの100kは間違いなく大きな利益を費やすことができると言います。



Vitaのポートの設計では、すべてがより複雑でした。 当初は、2015年1月に最初の会社が開発する予定でしたが、5月に会社が倒産したとき、プロジェクトは宙に舞いました。



「この危機とコンソールでの移植プロジェクトの再開後、新会社は急いでVitaの移植に取り組むことはありませんでした」とWatson氏は言います。 「開発者は、 The Banner Sagaはパフォーマンスの点で大きなリスクであり、GUIに大幅な変更が必要であると感じていました。 彼らは、開発には費用と時間がかかりすぎると信じていました。 したがって、このポートへの酸素を遮断することにしました。 しかし、その後、ソニーは別の港湾開発会社にそれを引き受けるよう指示しました。」



1年以上にわたって、この3番目のチームであるCode Mysticsは、独自のゲームエンジンの複雑さに苦労しました（ポートがプレイ可能な状態になるまでテストできませんでした）。 彼らがなんとかゲームを立ち上げることができたとき、Vitaのハードウェアの恐ろしい速度により、Stoic、Sony、Code Mystics、およびVita Versus Evil向けゲームのパブリッシャーは、プロジェクトを終了するという相互決定を迫られました。 彼らは皆、ゲームを機能させたいと思っていましたが、ワトソン氏によると、「それはただ起こるように運命づけられていなかっただけです」。









バナーサガ

アラームに気付かない

経験豊富なプログラマーのグレンダ・アダムスは、2000年代初頭にゲームをMacに移植するという辛抱強いプロジェクトを思い出します。 ゲームEA Need for Speed：Porscheを移植しました。作業の最初から多くの悪い兆候がありました。 EAは、ゲームのポート部分をポート会社Aspyrに転送することを拒否しました。



「利用可能なすべてのコードを移植することに同意した後、EAは私たちのプログラマに紹介し、見えない部分のMacライブラリを作成する必要がありました」とアダムズは説明します。



ほぼ1年間、チームはコードの大部分（EAによって閉じられた部分と、それと相互作用するシステム）をデバッグする機能なしで作業を試みました。



「時間が経つにつれて、何もうまくいかないことに気付き、作業を中断しましたが、そのような決定は苦痛のようでした」とアダムズは続けます。 「そして、必要以上に長く延期しました。 実際、私たちが直面している障害を見つけたらすぐにプロジェクトを中止する価値がありました。」



「しかし、最初は楽観的でした。なぜなら、ポーティングの観点から、私たちはEAゲームのトップに取り組み、それを機能させることができたからです。」









ニードフォースピード：ポルシェアンリーシュド



パズルクエスト、ウォーロードバトルクライ、 ジェムズオブウォーデザイナーのスティーブフォクナーも、開発者とパブリッシャーのコラボレーションの最初の段階ですべての「レッドフラッグ」が無視されたときに似たようなストーリーを持っています。 Foknerは、プロジェクトの途中でスタジオが期限に間に合わず、支払いを遅らせたと出版社がどのように述べたかを思い出します。



「私たちは次の支払いに到達しようとして、自分のお金を使い始めました」と彼は回想します。 投資は将来の収入に対する投資のように思えたので、合理的な決定だと思いました。 ただし、1か月後、プロジェクトの一部を再送信した後、出版社は半分だけを支払い、補償としてより高い割合の控除を提供しました。



「その瞬間、私は何が起こっていたのかを理解し、それをただ乗り越えたに違いありませんでした」とフォクナーは言います。 今、彼はこれが出版社の莫大な金銭的問題を証明する明確なシグナルであると理解しています。 「しかし、私は若くて素朴でした」とスティーブは言います。 「したがって、私は決めました-私たちは目標を達成します！」



「次の6か月間、支払いはますます少なくなりましたが、私たちはそれらを待ち続けました。 締め切りに失敗したというメッセージはますます奇妙で気難しいものになりましたが、私たちはそれらに対処しました。 私たちは労働者を解雇し、給料を削減しましたが、開発段階を実行し続けました。その時までに、出版社自身よりも多くのお金をプロジェクトに費やしていたからです！」



さらに悪いことに、絶え間ない要求と経済的ストレスに疲れた開発者は、自分のゲームをするのを止めました。 「おなじみのトピックを新たに見ると、このゲームは誰も興味を持たないフランケンシュタインのモンスターに変わりました」とフォクナーは言います。 「しかし、私たちはそれに気づかなかった。」



支払いが完全に停止した場合でも、会社はさらに6か月間ゲームの開発を続け、その後、Foknerはプロジェクトをキャンセルしました。 「当社のスタジオは破壊され、3人の従業員が残った」と彼は回想する。 「非常に重要な教訓を受けて、なんとか生き残り、回復することができました。」



インディースタジオは、未検出または無視されたアラームを混同することもあります。 ボクセルエージェントクリエイティブディレクターのサイモンジョセリンは、 Toy Maniaパズルでこれを実現しました。 彼のスタジオは、Facebookでこのプロジェクトをゲームとして開発するのに6か月を費やしました。最初はサイモンだけがチームに参加し、その後アーティストとプログラマーが彼に加わりました。 警告信号は、ソフトプレイの段階でゲームプレイがバラバラになったということでしたが、Jocelynはさらに6か月間作業を続けることにしました。



彼らはデータを収集し、それを使用してゲームとその印象（マーケティング資料、さまざまなブラウザーでの作業の品質など）を改善しようとしましたが、データが警告する内容に注意を払っていませんでした-ゲームはまだ動作しませんでした。 これはさらに無駄な努力につながりました-現在、ゲームプレイが変更され、基本的な仕組みがより複雑になり、ユーザーがアクセスしにくくなっています。



「Facebookでの数か月のプレイが失敗した後、モバイルに確実に移行することにしました」とJocelyn氏は言います。 チーム全体がモバイルバージョンの開発に着手し、数か月かけてAndroidユーザー向けに最適化しました。 「もちろん、彼女はモバイルでも失敗しました。」

悪夢を避ける方法

一部の開発者は、サンクコストエラーの影響を回避または削減する方法を見つけることができました。 たとえば、現在のCloudGateスタジオでは、開発者は通常、誰かが解決できない問題に遭遇したときにタスクを変更するとボウラーは言います。 これは、彼らがうまくいかないことについて「非常に正直」になり、彼らのオリエンテーションを失うことを助けます。 Voxel AgentsのJocelynは、彼の本能に従い、紙の上でデザインを作成することを学び、それから初めて、将来の明確なビジョンを持つために安価なプロトタイプを作成しました。 これは悪い費用の悪夢を完全に排除することはできませんが、問題の解決には役立ちます。



Funomenaの共同設立者であり、 ジャーニープロデューサーのロビン・ハニケは、安価なプロトタイプとチーム内のオープンで正直な雰囲気のおかげで回避された悪夢について多くの話をすることができます。 「私の話のほとんどで、すべてが正常に終了しました」と彼女は言います。 「それは長い間、彼らは悪い無駄のように思えただけです。」









旅



thatgamecompanyとFunomenaの両方にとって、救助は小さなチーム規模でした。 そのゲーム会社がJourneyで壁をcうメカニックを頑なに実装しようとしたとき、チームは小さなプロトタイプでアイデアを絶えず繰り返し、メカニックの完全な開発にはすぐには行きませんでした。



その結果、スタジオがこのアイデアを拒否し、スカーフとフラグを備えたシステムに移行したことは、ゲームに利益をもたらしました。 「 ワタムでのクロールとフォールディングの初期のプロトタイプと、 ルナのために開発した物理的および音楽的なフィードバックシステムでも同じことが起こりました」とハニケは言います。



「デザイナーは自分の過ちから実験し、学ぶべきだと思います。 人生は短すぎて悪い考えを保持することはできませんが、革新には勇気と時間がかかり、悪い考えを良いものに変えるのに時間がかかります。