プログラマー（アーキテクト）からゲームデザイナーへの推奨事項。
エントリー
コンピュータゲームは、映画が劇場に取って代わるのと同じように、将来的に映画産業を変える比較的若い産業です。 ゲームの作成は、映画のように
集合的な作成です。 さらに、コンピューターゲームの作成は、それ自体が実質的にすべてのIT領域を含むため、最も難しいITタスクの1つです。
誰もが
事前準備について聞いたことがありますが、これがどのように起こるかを正確に知っている人はほとんどいません。 そして、開発段階について多くのことが書かれていて、出版段階についてさらに書かれている場合、計画段階についてはほとんど知られていない。 せいぜい、あなたは幸運にも
計画の
結果を知ることができます。 しかし、これらの結果はどのようにして達成されたのでしょうか？ -
暗闇のなぞなぞ 。
このドキュメントは、ソーシャルネットワーク向けのゲーム
Star Arenaを作成した後の「報告」の結果です。 このドキュメントでは、アレキサンダーと私がゲームで一緒に作業する過程で出会った
問題と解決策のリストを合理化しようとしました。 さらに、このドキュメントは、コンピューターゲームワークフローの構築に関する多くの作業の一部です。
私は意図的に他の文書を背後に残しました：他のパフォーマーのためのコンセプト、ビジネスケース、TK。 これにより、1つのトピックに焦点を当て、それを十分な詳細だけでカバーすることができました。
最も重要なこと：
- 最終結果の明確な理解。 （品質管理。）
- 締め切り。
ドキュメントが必要な理由：
- 通信の時間を節約します。 （証言で混乱して、100回語るのではなく、1回書いてください。）
- 完成したプロジェクトがどのようになるかを確認する方法。
- 問題の分析と特定はまだ計画段階です。 （アーキテクチャエラーが発見されるのが早ければ早いほど、修正のコストは安くなります）
- 決定の修正。 （新鮮さの程度がさまざまであるといううわさではなく、正確なデータ。）
- 作業計画。
ドキュメントは何ですか：
- コンセプト（「ゲームはどうですか？」）
- 仕様（何を取得したいですか？）
- 委任事項（これの取り決め-彼について議論する）
- 作業計画（これを行う方法）
TKの議論に関与しているのは誰ですか：
関心のある専門家からのフィードバックが早ければ早いほど、不要な作業が少なくなります。
- ゲームデザイナー（ドキュメントの作成）
- アーキテクト（説明、分解の完全性と詳細の追跡）
- プログラマー（作業量の評価。）
ドキュメント要件：
デザインが
だらしなくなればなるほど
、 一般的に読む人
が少なく
なります。 読者は、彼らにとって
不快な仕事を
避けるために、
信じられないほど機知に富んでいます。 したがって、ドキュメントを
読むのができるだけ
簡単で楽しいものであることを確認することが非常に重要
です 。
- 書式設定 （印刷しやすく、読みやすい/保持しやすい）
- キーフレーズの強調表示。 （ドキュメントを斜めに読むには）
- リストを作成します。 （単色のテキストの代わり）
- 長いリストをグループに分割します。 （グループごとに3つのアイテム）
- 複数回の繰り返し。 （ドキュメント参照を避ける）
- 日付、ページ番号、ページ数、ページネーション。 （読んでいるものを議論するときの正確な参照のため）
- 目次、ドキュメントのリスト、変更履歴。 （ドキュメント/バージョンの検索用）
TKのコンテンツの要件
ドキュメントが満たす必要
がある要件の明確なリストはありません。 したがって、TKの開発は、その満杯に近づくずっと前に中断されます。 その結果、開発の次の段階はTKなしで始まり、TKが途中で追加されるか、開発の結果に基づいて追加されることを期待しています。
- ロシア語。 （ミーム、歪んだ英語の用語、アルバニア語、その他のごみはありません。多くの内部文書も読んでいます。）
- 次のような一般的な言葉はありません：
- 可能なすべてのオプション
- カードはコンピューターによって発明された
- さまざまなオブジェクトの相互作用
- すべてのアクションなどの後
- エンティティ（クラス）のタイプの名前にはすべて次のものが必要です。
- ロシア語の名前（プレーヤー用）
- 英語（コード用）
- 短い説明（転写/ヒント/コメント）
- エンティティには名前を1つだけ含める必要があります。 （「アーマー」が別のページを「アーマー」または「シールド」に変えないように）。
- 提案は、文脈を詳しく調べることなく、読者にとって完全で理解可能なものでなければなりません。 （読者自身が著者の意図を推測することを意味しないでください）
- 測定できるものはすべて測定する必要があります。
- ピクセルおよびバイト単位の画像サイズ
- テーブル内の列とセルの数
- テキストボックスの文字数
- レベルごとの武器の数
- セッション時間など
プログラマーの仕事の結果の主な要件：
これらの重要な要件は暗示されていますが、誰からも決して表明されません。
- 変更するシステムの柔軟性。 （動的要件。）
- 自動エラーデータ収集。 （フィードバック。）
- お客様による簡単な起動と構成。 （結果のデモンストレーション。）
TKを書く最初の段階：
サブジェクト領域の説明、プログラマーが理解できる用語での形式化。
- データベース（メタデータ）
- オブジェクトタイプのリスト
- オブジェクトの特性
- オブジェクト間の通信/依存関係
- ビジネスプロセス（フルゲームサイクル）
- プロセスリスト（作業シナリオ）
- 機能リスト（できること）
- 予想される変更のリスト（可能性のあるもの）
TKを書く第2段階：
すべてのタイプのユーザー（プレーヤーおよび管理者）に対する製品の外観/動作。
- インターフェース（視覚部分）
- 名前付きのゲーム画面のリスト（または要素のグループ）
- 名前とテキストヒントを含む各画面上のアイテムのリスト
- 要素の動作の説明（ウィンク、ツールチップ、ブロック、ポップアップダイアログなど）
- 管理者（管理）
- サーバー（バイタル/システムインジケーター）
- ゲームコンテンツ（販売、クエスト、モンスター、モノ、ショップ、ドロップ、場所など）
- ゲームデータ（プレイヤーによって生成されたコンテンツ）
- 統計とレポート（どの統計を収集する必要がありますか？）
TKを書く第3段階：
どうやってそれをすべてやろうとしているのか。
- 必要な技術研究
- 各テクノロジーの要件のリスト
- 各技術のテスト/デモの説明
- 将来の要件/起こりうる問題のリスト（次は何ですか？）
- ゲームのさまざまな種類のコンテンツ（リソース）の要件のリスト（剣の画像のサイズ、クエストの名前の長さ、特殊効果の種類、ビデオのサイズなど）。
- コンテンツの操作に不可欠なツールのリスト（マップエディター、クエスト管理パネル）。
- タスクの優先順位付け。
- 最初の作業アセンブリの要件（最初のプロトタイプでできること）。
- プロジェクト開発の他の反復とその結果の要件のリスト。 （それを完了するために各段階の終わりに示される必要があるもの）
ドキュメントのサポート
- 最初の段階で書かれたもののほとんどは時代遅れであり、計画の終わりのずっと前に書き直される必要があります。
- 計画の最初の段階の主な原則： セクションのリストを整理し、各セクションの質問のリストを作成します。
- 初期段階で詳細が低いほど良い。 （名前の完全なリストの代わりに、武器の種類の数、詳細なリストの代わりに、レベルごとのクエストの数など）
- ドキュメント内で適切なアイテムを見つけて、他のアイテムに影響を与えることなく変更するのが簡単であればあるほど良いです。 したがって、複雑な文からのグラフィカルなスキームとソリッドテキストを避ける必要があります。 最終報告のために、グラフィックプレゼンテーションと感情的な説明を残します。
- 各計画サイクルの後に、文書の完全性と詳細レベルの均一性を確認してテストします。 （5部屋の家で1つだけが記述されている場合、他の4つを記述するか、1つの部屋の詳細な記述を捨てて、すべての部屋が等しく等しく記述されるようにする必要があります。）
- 不快な質問のリストを作成します。 常に暗いスポットがあり、彼らはそれを認識せずに歩き回り、黙ろうとします。
- エンドユーザーに簡潔な指示を提供します 。 最終的なパフォーマーは、完全なドキュメント、およびボリューム全体での適切な言及の苦痛な検索に直面するべきではありません。
- 習熟の兆候 ：計画の次の各レベルは、より抽象的なレベルの記述の結果を改善しますが、変更しません。 抽象化/詳細のレベルを移動する優れたスキルであり、詳細の適切な説明から計画されたエンティティのリストに移動できます。
カッティングコーナー
すべてのテクノロジーは、作業量とコストを削減するために、ばかげた点まで単純化されます。 化学酵母パン、アルコールワイン、ドキュメントなしの開発。
多くの人は、次の場合に文書化は必要ないと考えています。
- プロジェクトは2〜3か月です。
- 2-3人のチーム。
- 限られた予算。 （彼は常に制限されています）
- ドキュメントの要件はありません。 （それを行う方法を誰も知らない）
- 彼女には役に立たない。 （使用されていないドキュメント）
ただし、覚えておく必要があります。ドキュメントの開発には、すべての努力の40％がかかります。 また、プロジェクト開発が正常に完了する確率を90％で決定します。
最初のステップ
初心者が
最初のプロジェクトとしてクラシックゲームの「クローン」を選択することを強くお勧めします。 このようなゲームでは成功した経験はありませんが、製品開発サイクル全体のビジョンはありません。 それで
ゴールに到達する方法が理解できません。
演習として少なくとも2つの完全なTKを作成せずにゲームの開発を開始しないでください。 これはアルカノイドのTKかもしれません。 しかし、これは、このゲームを
見たこと
がない場合でも
、開発者
が本格的なアルカノイドを
作成できる TORでなければなりません。