だから、多くの仕事と熟考の後、競合他社の経験を分析し、コーヒーカップ（またはビール1杯？）、プロトタイプとイテレーション-小さい機能またはゲーム全体のデザインドキュメントの準備をした後、競合他社の経験を分析した後、おそらく私の前の記事を読んで。 勝利？！ どんなに。



この記事では、ゲームの設計がドキュメントからゲームの実装に至るまでの困難な道、そしてゲームのデザイナー自身の視点から話します。 前の記事のように、タスクはプロセス全体を詳細に表示することではありません。 このテキストは、大規模なチームのゲームデザイナーの経験に興味がある人を対象としています。

ステージ1：受け入れ

ゲームデザイナーがクリエイティブディレクターでもゲーミングディレクションの責任者でもない場合、つまり何らかの形で、主に比較的独立した開発スタジオにいる場合（そうでない場合は出版社の承認が必要な場合が多い）、彼の文書は承認段階を経ます。 それはどこでも異なって動作します。 たとえば、Allodsチームでは、口頭での議論の後、デザインに合わせてメールが（テンプレートに従ってデザインされたテーマとともに）メールに送信されます。 Obsidian Entertainmentでは、クリエイティブディレクターがJIRAを承認します。 ゲームデザイナー、プロデューサー、チームリーダーが参加する「デザインの受け入れ」のための口頭での承認と必須ミーティングがあります。



いずれにせよ、覚えておくべき3つのルールがあります。

1. 「承認」の特定のプロセスが存在する場合は、それに従うことをお勧めします。
2. 優先順位を付ける必要があります。 承認者は多くの場合、検討中の「複雑で物議を醸す」デザインを多数抱えており、スコープ全体をレビューする時間を確保することが常に可能であるとは限りません。 したがって、プロジェクトにとって重要な設計をより頻繁に思い出すべきですが、来年の小さな機能の設計は待つことができます。 しかし、後者について完全に忘れてはいけません。さもないと、まったく気付かない可能性があります。
3. 「彼らが言うように」するだけでなく、批判を建設的に受け入れ、その前提を理解し、問題を体系的に解決します。 多くの場合、初心者のゲームデザイナーは、なぜ間違っているのか、どのように改善するのかを理解する代わりに、「方法を教えて、すべてを計算します」、またはその逆の原則に取り組んでいます-彼らは単に議論への愛から主張しています。 このような行動は、職業やキャリアの成長にはほとんど寄与しません。 設計に誤りがある場合、それが繰り返されないように、なぜ設計されたのかを理解する必要があります。 十分な経験を積んだだけで、もちろん重要な議論がない限り、「ホスト」と議論することはかなり可能です。 最後に、誰もが間違っている可能性があります。

この段階の期間は、状況に応じてゼロ（承認が不要な場合）から数週間かかる場合があります。 一部の企業は、設計の受け入れまたは拒否に対応するための厳しい時間枠を設定しているのは興味深いです。 たとえば、5営業日以内に応答がない場合、設計は受け入れられたとみなされ、作業に移ることができます。 もちろん、このシステムは面白い状況につながりますが、理解できない状況にあるデザインの数は大幅に削減されます。

ステージ2：計画

この段階では、多くの場合、空想の飛行はスプリント、マイルストーン、病気のプログラマー、リソース不足などの残酷な現実に遭遇します。 マネージャーの立場から計画プロセスについて多くの記事や本が書かれており、幸いなことに、通常、単純なゲームデザイナーはそれを完全に理解する必要はなく、必要な場合は経験で十分です。 それにもかかわらず、単純なレベルでさえ、いくつかの極端な事態を回避できるか、少なくともそれらが検出されたときにアラームを発することができるはずです。



「開発期間を数か月間短縮しましょう」と、ゲームデザイナーはこれらの言葉を「肉屋」-リソースの不足やテストの必要性などに直面するマネージャーやプロデューサーからよく耳にします。 ここでのルールは簡単です。あなたはそれらに備える必要があります。 計画段階の前でも、機能/ゲームのどのコンポーネントが非常に必要であるかを理解（またはより適切に文書化）する必要があり、絶対に必要な場合にのみ遮断する必要があり、どのコンポーネントを完全に犠牲にすることができます。 多くの場合、これを理解するには、少なくとも一部の開発コストの最低限のアイデアが必要です。平均的な重要性の一部は重要性の低いものと同じくらい多くのコストがかかることもあり、そのような状況では多くの場合10の部分が1つを上回るためです。



同様に、どの部品が本当に必要かを理解する必要があります（部品なしで始めてはいけないため）。そして、困難な状況でこの理解を維持することができます。 正式な論理の観点から、パートAがなければ機能が客観的に機能しない場合、「そうでなければ締め切りを破る」または「このチームにはもっと重要なタスクがある」としても、機能が存在しないと機能しません。 もちろん、実際には、多くの「肉屋」（特に開発チームに関する外部の肉屋）がいる場合、機能を完全に防御することは常に可能というわけではありませんが、これは有効で効果的なオプションを取得する試みをキャンセルしません。 さらに、このような「カットオフ」（フィッシュカット）は、有害というよりも必要かつ有用なプロセスであることがよくあります。











もう一つの議論があります：「高すぎる、安くなりましょう。」 もちろん、ゲームデザインの場合、コスト削減は必ずしも品質の低下を意味するわけではありません（この場合、すべてが良好です-別の反復により、同じ結果をより効率的に得ることができました）が、多くの場合、一部を削除する代わりに、保存されたもののボリュームが削減される「カットオフ」の別のオプションです しかし、ここでのルールは本質的に同じです。



「機能を10段階に分けましょう」



「カットオフ」に代わるものは、多くの場合「分離」です。最初は、プレーヤーに機能の基本的な部分が与えられ、しばらくしてから高度な機能などが提供されます。 このアプローチは非常に合理的です。これは、計画の一般的な利便性とプレイヤーにゲームを提供するための初期の条件に加えて、「ライブ」テストの時間と開発コースを時間通りに変更する機会があるためです。 しかし、間違いを犯すのは簡単です。



ゲームデザイナーやプロデューサーとは異なり、プログラマーは2か月でエンジンの機能を約束するため、プレイヤーは城の壁をまだ建設できないという事実を考えません。 代わりに、彼はフォーラムに次のように書いています。「なぜこれらのロックを導入したのですか？ 彼はちょうどそれを構築しましたが、壁を構築することはできません...何人かの学童が来て、すべてを破壊しました。 お金を返せ！」 パーツに適切に分割することで、プレイヤーは各ステージで興味深いゲームプレイを提供し、次のゲームを楽しみにしています。 何が間違っているのか-それはその後の各段階で不完全さと失望に悩まされるだけで、「彼らは今は一年もそれをすることができませんでした」などのコメントがあります。



機能クリープ （ https://en.wikipedia.org/wiki/Feature_creep）-はい、この段階で存在します！



驚いたことに、「アーティストのための無料のリソースがあり、これ以上占有することはない」または同様の「リソース」がある場合に、大きな機能の状況が発生することがあります。 理由は開発価格に直接関連しない場合があります。たとえば、「これはクールな機能です。マーケティング担当者に伝えて、見栄えを良くするためにここに追加する必要があります！」または「このメカニズムでは、ネクロマンサーからアンデッドを収集します！」



これは有利になることもあれば、有害になることもあります。 主なことは、機能の整合性を維持し、有用な機能で補完することであり、featurekapを使用せずに、プロジェクトにメリットがない場合は多大な努力を必要とします。 覚えておいてください：機能は近いです！



関係と因果関係の違反



理想的な世界では、他のチームが他のチームをブロックしないように機能を計画し、できるだけ早くテストを開始できます。 現実は暗く、恐怖に満ちています。 これはさまざまな種類のマネージャーの特権ですが、ゲームデザイナーも参加して、少なくとも機能の機能の復帰の順序を確認する必要があります。 多くの場合、彼だけがすべての内部接続を完全に理解し、「基礎に機能するまで壁は建設されません！」という警告を発することができるからです。



計画段階で上記およびその他の問題を克服した後、最終的に開発を開始できます。 ここに最初の「フランケンシュタインのしきい値」があります。「安い」、「カットオフ」、「側面からの機能追加」を経た機能を冷静に見て、最後に何が起こったのかを理解する必要があります。 そして、必要に応じて、何かを修正してみてください。 そして、すべての準備が整ったら、計画中に受け入れられたすべての変更の結果に基づいてドキュメントを更新することを忘れないでください。

ステージ3：実装

ゲームデザイナーにとって、ゲームデザインの実装は2つの部分で構成されます-プログラマー、アーティスト、および他の同僚の仕事と、実際にはゲームデザイナー自身の仕事です。 2番目の点は側からは予想外かもしれませんが、多くのロシアの企業や西洋の企業（たとえば、Obsidian Entertainment、Raven Software、The Workshop Entertainment、著者はこの現象を個人的に観察しました）では、ゲームデザイナー自身がすべてのデータをゲームに提供しています：スペルダメージ、予約タンク、アチーブメントの勝利数など。 データに加えて、「オイルで使用済み-追加の損傷に火をつける」タイプのスクリプトも内部ツールで収集されます。 ゲームにデータを持ち込む別のゲームデザイナーがいることもありますが、これはルールというよりは例外です。 地域のゲームデザイナーの専門性が非常に強い欧米の企業でさえ、通常はアイデアを思いついた人が（もちろん、必要に応じてプログラマーの助けを借りて）データを入力します。 小さなチームでもこれは一般的ですが、意外なことに、ゲームデザイナーを「排他的に発明する」ケースを見つけることができます。



大企業では、通常、クリエイティブディレクター（時には彼も！）より低いランクのすべてのゲームデザイナーは、ツールを習得し、リポジトリ、エラー追跡システム、およびその他の技術部分でコミットを処理する必要があります。 これをすべて簡単に説明するのはかなり難しいので、興味がある人は自分でもっと読むか、包括的なプログラム「 インターネットゲームプロジェクトの管理 」の一部である「技術プロジェクト開発の基礎」コースを受講する必要があります 。



同僚、プログラマー、アーティスト、その他の専門家の仕事に関しては、2つの基本的なルールを覚えておく価値があります。

1. タスクがデザインに準拠しているかどうかを確認し、外部からのように読んで、ゲーム全体またはそのデザインについて何も知らないことを想像してください。 多くの場合、技術専門家（優れた専門家を含む）は、ゲーム内の機能の存在、受け入れられている慣行などを認識していない場合があります。 そして、タスクがこれを念頭に置いて策定されていない場合、結果は意図したものとは非常に異なります。
2. パフォーマーの質問「正確に何をすべきか」は適切であり、それらに答えることは迅速かつ正確です。 もちろん、明確化のための質問が多すぎる場合は逆の状況があります。 この場合、問題がどこにあるのかを正確に理解する価値があります-書面の設計、ゲームのビジョンと特定の機能をパフォーマーに伝えること、または特定の従業員の中で？ これを理解することによってのみ、問題を意識的に解決できます。 間違いなくやる価値のないことは、そのような問題を無視するか、自分で解決するようアドバイスすることです。

実装する際には、取得したものをテストし、この問題でQAを支援する必要があります。追加の検証が必要な弱点を指摘し、質問に答える必要があります。 初期テストにより、潜在的な問題を簡単に特定して修正できます。



多くの場合、企業では、少なくとも最年少ではないゲームデザイナーも彼らによって発明された一種の「機能所有者」になり、開発の監督が奨励されます。 たとえば、ゲームデザイナーは自分のデザインのためにタスク実行者に行き、ステータスを要求し、現在の優先順位を見つけ、自分の機能に従ってタスク内でそれらを自由に変更することさえできます（たとえば、「新しいボスの能力のコードで最初にサポートしてテストする、そしてそれから戦利品でバグを修正します ''）。 したがって、ゲームデザイナーは彼の機能の小さなプロデューサーになります。

ステージ4：結果の分析

その結果、機能が作成され、テストされ、プレーヤーに提供される準備が整う日が来る。 ただし、この段階では、ゲームデザイナーにとってさらにいくつかのタスクがあります。視聴者へのプレゼンテーションプロセス（パッチノート、「開発中」の記事、ゲームプレビューなど）を確認し、収集された統計に従って動作を監視する。 一部の機能は、ゲームの開始前に一度行われ、その後実質的に変更されません。 しかし、「ゲームクラスのバランス」、「ゲーム内経済」、「社会活動」などの概念を含む多くは、プロジェクトの全期間にわたって何度も変わる可能性があります。 彼らにとっては、正しい決定を下すために、統計とプレイヤーのレビューを操作できる必要があります。

ゲームデザイナーができること

読者は一種の矛盾を見ることができます：ゲームデザイナーがツールキットを使用して技術的に作業し、プロデューサーとしての優先順位を理解し、QAとして潜在的な問題を見つけ、プレイヤーの気分を認識し、統計を理解できるようにする必要がある場合、これらをどのように組み合わせることができますか？ そして同時に、実際、デザインを書くのですか？











ここに、ゲームデザイナーの2番目に重要なスキルがあります（ゲームを発明する能力の後）-開発のすべての参加者になることを同時に試みるのではなく、状況を正しく理解し、それを管理し、彼の能力を最大限に引き出し、問題を修正します。



プレイヤーが理解するのが非常に難しいメカニズムで、単純化できないものですか？ コミュニティマネージャーが彼女についての記事を書くのを助ける価値があります。



フィッチがテストするのは難しいですか？ QA部門を支援する価値があります。



開発シーケンスとそれらを使用せずに機能を実行する機能の両方の点で、複雑な関係を持つ多くのコンポーネントがありますか？ パフォーマーの間でこれらのコンポーネントの優先順位に従うことは価値があります。

特定の時点での複雑なフィーチャであっても、問題のある方向が2つ以上あることはめったにありません。すべてが単独で発生する力を分散させなければ、フィーチャを準備状態にするのにそれほど時間はかかりません。



私たちはまた、「彼らが望んでいるようにさせて、すべてをクールに考え、何かがうまく行かなければ彼らが責任を負う」という心理的な誘惑に対処できなければなりません。 はい、デザインの実装に干渉しないことが心理的に便利な場合があります。次に、「すべてが私のデザインのように行われなかったため、期限が切れました-すべてが悪いことは驚くことではありません」が...これは通常、長期的には機能しません



もちろん、小さなドリームチームのチームでは、パフォーマーが一目ですべてを理解し、期限が切れない（または自由に動く）ことが起こり、QAがすべてのバランスの問題を見つけ、パッチノートにエラーがないことを主張します-あなたはそれを行うことができます！ ただし、ここでは「夢」という言葉が重要であり、ロシアと西洋の両方の大企業では、厳しい現実に直面する必要があります。 しかし、「ドリームチーム」に一度でも、上記の開発スキルは遅かれ早かれ役に立ちます。 結局のところ、ラオツが書いたように、「空の下では、すべては一時的にしか起こりません。」



結論として、簡単な観察結果を追加します。最初はゲームデザイナーの実際の作業は複雑に見えますが、すべてが正しく行われていれば（これは前の記事とこの記事で初期レベルで説明されています）、すべての困難が克服されます。 主なことは彼らを恐れることではありません。