dzdokの書き方

検索エンジンに送信される「dzdokの書き方」というクエリは、西洋の記事の翻訳と、ロシアからのこのトピックに関する著者の反省、またはプロジェクト「Kurochka Ryaba」のデザインの両方を表す多くの回答を与えます。 読者の想像の中で、すべての機能をリストしたゲームのアイデアとゲームプレイを説明する大きな単一のドキュメントが表示されます。 おそらく、読者はかつて、ロシアや西洋の大企業や大規模プロジェクトでゲームデザイナーとして働くためのアイデアを思いつきます...そして、そのようなドキュメントがもう存在しないことを発見します。



大企業に存在するdzdokの書き方について （これらの行の著者は、Obsidian Entertainment、Allods Team、Raven Software、The Workshop、Slightly Mad Studiosのドキュメントを担当し、Higher School of Business Informatics of the Higher School of Economicsのゲームデザインのデザインドキュメントコースを教えています。プロの再訓練プログラムゲームオンラインプロジェクトの管理 ）、およびこの短い記事になります。 もちろん、そこに記述されている誰かにとっては明白に思えるかもしれません。 「dzdokの書き方」という質問への回答を探している人や、大規模な開発会社でゲームデザイナーとしての仕事を得たい人のために設計されています。



プロジェクトドキュメントは、大きなデザインドキュメントではなく、MS Officeファイルのセットではなく、Googleドキュメント内のファイルでもありません。



ほとんどの場合wikiエンジンです。 最も人気のあるのはAtlassian Confluenceですが、通常は「古い」企業で使用される多くのプラグインを備えたMediaWikiや、小さなペットプロジェクトや小さなスタジオ用のDocuWikiもあります。 したがって、大規模プロジェクトのドキュメントを使用する意欲は、プロジェクトで採用されているWikiエンジンを使用して作業する能力から開始する必要があります。 「dzdok」と記述されているものは、通常、Wiki上の3つの個別のドキュメントに置き換えられます。

• コンセプトドキュメントは、ゲームのアイデアの要約です。 Vida「無限のゲームプレイ、壮大な特殊効果、非同期PvPを備えた核ミサイルの発射と迎撃に関するオンラインゲームを用意します！」 ゲームプレイのアイデアと主要コンポーネント（非常に簡単に）、およびいくつかの最も重要なUSP（プレイヤーにアイデアを「販売」し、市場でユニークな「ユニークなセールスポイント」）について説明します。
• ビジョンはすでに、結果として得たいものを説明するより詳細な文書です。 ゲームそのものではなく、最終的なビジネス製品としてのゲーム全体。
• 機能リスト （開発モデルに応じて他のドキュメントにまとめることができます）-機能の簡単な説明、ゲームの構成要素を含むリスト。 たとえば、核ミサイルの組み立て、アーケード傍受、非同期PvP、クランシステム、アチーブメントシステムなど、原則として、ゲームデザインの詳細な説明を含む個々のドキュメントへのリンクがあります（これについては後で詳しく説明します）。 また、各機能は優先度、コスト、開発シーケンスを設定します。

コンセプトドキュメントはシンプルであり、後続のドキュメントの「基盤を築く」ために使用されます。また、新しい従業員、投資家、またはジャーナリストがプロジェクトの本質をすばやく理解できるようにします。



それではVisionに移りましょう 。 このドキュメントは既に大きく、通常次の要素が含まれています。

1. ゲームの簡単な説明 。 ここにあるのは主なアイデアだけでなく、ゲーム全体です。
2. ゲームのジャンル 。
3. 対象読者と市場調査 。
4. 市場に出回っているそのようなゲームの例と彼らに対する態度：彼らは競争相手であるかどうか、観客の交差点があり、アイデアを借りたり、反対したりします。
5. ゲームのUSP（ユニークセリングポイント）は、ゲームを市場で際立たせ、マーケティングを使用してトラフィック/新規プレイヤーを促進するものです。
6. 「成功のための式」 -ゲームのどの要素が最高品質/重要になるか。 革新的なグラフィックス、誠実な物理学などです。 ここでは、USPとは異なり、一意性ではなく、品質が必要です。
7. 要するにゲームプレイコンポーネント 。
8. 遊びの設定とスタイル 。 たとえば、黄色がかった灰色の残忍なサイバーパンク、アニメスタイルの光の壮大なファンタジーですが、芸術の例ではるかに詳細です。
9. 収益化を含むビジネスモデル 。

作成の順序と目的はここでは明らかです。コンセプトドキュメントを作成することにより、ゲームデザイナーは主要なアイデアを定義します。 さらにビジョンで、彼はこのアイデアがどのように、そしてなぜ働くのかを説明します。どの観客に対して、どの要素がプロジェクトを成功させるか、そしてどのようにお金を稼ぐか。 同時に、コンセプトとビジョンを書くことは反復的なプロセスです。 コンセプトを作成したら、提案されたアイデアを（投資家、上司、極端な場合は自分自身に）販売し、アイデアが販売されるまで改善することができます。 Visionを書くことで、ゲームに人気と商業的成功の可能性があるかどうかを評価し、結果に少なくともある程度の自信ができるまでUSP、設定、スタイル、その他の変数を変更して処理できます。



3番目の機能リストドキュメントは、前の2つのドキュメントで説明したコンポーネントゲームの「解析」です。 これは、実際には開発への架け橋です。 そこに記述されていることによると、プロデューサーや他のリーダーは計画を立てたり、マイルストーンやスプリントなどをカウントしたりできますが、このトピックは別の記事に値します。



大企業で働くために3倍になった単純なゲームデザイナーは、上記の3つのドキュメントを作成することはほとんどありませんが、それらを読んで覚えておく必要があります。 ゲームデザイナーのメインタイムは次のレベルに進みます。これは最も意欲的なボリュームです。 これらは、ビジョンと機能リストで説明されている特定の機能のドキュメントです。 たとえば、マウントの設計や、一族の紋章を鎧に適用する設計などです。しかし、もっと野心的なものもあります。キャラクター特性システムの設計や、プレイヤーの基地開発の設計です。



もちろん、このレベルでdzdockを書くことは特定の機能に強く依存します-それは10行のwikiドキュメント、または数十の添付ドキュメント、ゲームテーブルから収集された統計へのリンクと計算のリンクテーブルを含むセクション全体です。



ただし、大企業では次の3つのことを組み合わせる必要があります。

• テンプレート はい、テンプレートと創造性の互換性は難しいように思えますが、プロジェクトに複数のゲームデザイナーがいて、誰もが喜んで書いている場合、プロデューサーとパフォーマーはこの喜びを追加しません。
• 他のドキュメント、機能、およびタスクへのリンク 。 各ディスクは、真空中の単なる球面テキストではありません。 いくつかのグループ（PvP機能など）に属し、他のドキュメントを参照し、タスクのリスト（JIRA / Bugzilla / Trello / GitHub / ...）、準備状況評価、テスターレポートへのリンク、プレイテスト結果を含みます。
• 実際、ファンとゲームプレイ！ dzdokの構造のすべてのレイヤーの背後で、ゲームが面白くてエキサイティングであるという事実を失わないようにすることが重要です。この機能は、ゲーム全体のプラスとして機能し、一般的なアイデアから離れたタスクを実行するだけではありません。

disdockで説明する価値は何ですか？ 機能自体を単に説明することに加えて、他の多くの要素があります。

• 作成者およびステータス （ドラフト、作業、完了、拒否、期限切れ）。 何百ものdzdoksがwikiにあり、何十ものゲームデザイナーが長年働いてきたとき、これらの単純なセクションなしではどのdzdokが関連するかを理解することは困難です。
• 現在のタスク 。 欲しいもの。 たとえば、軍隊が兵舎で訓練している間に、プレイヤーに娯楽を提供します。
• 問題の原因と解決策の必要性 。 重要な点は、その存在が「クールになる」または「競合他社が持つ」機能を節約することです。 後者は多くのゲームデザイナーの悩みの種です。開発されたゲームの要素の多くは不要であり、競合他社がこのUSPを持ち、莫大な収入をもたらしたとしても、機能がクリーンである場合でも、機能はきれいにコピーされます。
• ソリューションの簡単な説明。 あなたが一般的な考え方を受け入れることができるように。
• 拡張されたデザイン 。 実装の詳細な説明。
• 予想されるプレーヤーの動作、通常のセッション。 プレイヤーの立場から「これをどうやってプレイするの？」という質問に答えるために必要です。 これがないと、理にかなっていると思われる機能を簡単に入手できますが、フォーラムのプレイヤーは「それは何ですか？」と書いています。
• ゲーム内の機能の場所および他の機能との通信。 明らかに、機能は他の機能またはゲームの全体的なゲームプレイをサポートおよび補完するものであり、それ自体を繰り返したり抑制したりするものではありません。
• 実装および資産リストのタスク。 機能が機能するために必要なことのリスト：どの機能がコードレベルにあるか、アーティストに何を描画するか、キャラクターのレプリカのテキストをスクリーンライターに書き込む必要があるかどうかなど 時々これはプロデューサーですが、多くの場合ゲームデザイナー自身です。
• 必要な統計。 プレイテストおよびサーバーから収集および分析する情報。 プレイヤーはゲームプレイ機能にどのくらいの時間を費やしますか？ 彼らは乗り物についての特徴で馬や車に乗りますか、彼らは接近戦でサイギやイノシシからシューターを撃ちますか？
• 必要なテスト（+エッジケース）。 QA部門は、機能をチェックするときに特に注意を払う必要がありますか？ QAは自分で作成できますが、多くの場合、ゲームデザイナーのみが「エリキシルを追加するなどのエクスプロイトを持つプレイヤーがトレーディングスキルを1000獲得した場合、購入した商品よりも高価な商品を販売でき、経済全体を損なうでしょう！」 したがって、これは理論的にも不可能であることを確認する必要があります。」
• 展開と運用。 オペレーターのセクション。 パッチノートで機能を説明する方法は？ ゲームの百科事典に彼女に関する記事を投稿する必要がありますか？ プレイヤーから何かを奪い、機能を実行するための報酬を与える必要がありますか？
• 今後の計画。 実際、将来的に機能を改善できるすべてのアイデア。

もちろん、このリストは、機能、雇用主、および設計の作成の緊急度によって異なる場合があります。 それにもかかわらず、必要かつ可能であれば、そのような点を忘れないことをお勧めします。 原則として、dizdokのこれらすべてのポイントの後、ゲームデザイナーは最後のアイテムを待っています...コメント！ ほとんどのWikiエンジンにはこの機能があり、他のゲームデザイナーからプログラマーやテスターまで、多くの同僚がゲームデザインに関する意見を喜んで共有します。







この幸せなメモで、私の短い記事は終わりです。 彼女がおもしろかったと思います。 そして、あなたはコメントに行くことができます！