ゲームデザインのドキュメントの種類 [閉まっている]

ゲームデザインのドキュメントを保存および配布するために、どのような種類のサポート/形式を使用していますか？ウィキ？Docファイル？リポジトリ内のファイル？共有フォルダ？Google Doc？

それぞれについて長所と短所を入力してください。

私が本当に必要なのはオンラインのテキストエディターだけなので、Googleドキュメントを使用しています。私はオンラインで比較的簡単に共同作業を行うことができ、自分のコンピューターがクラッシュした場合でも私の情報がそこで安全であることを知っています。

注目に値するもう1つのオプションは、Dropboxの使用です。そこにWord文書をドロップすると、すぐにバージョン管理を行うコラボレーション環境が実現します。

Wiki

長所：

• オフサイトなどから常にWeb経由でアクセス可能な最新バージョン
• かなり使いやすい（MediaWikiのようなフォーマットのために難破した人を避ければ）
• 自動インデックス作成、検索、簡単な分類
• 変更を人に帰属させ、変更に対する責任を持たせるのが簡単
• リンクをサポートし、詳細を簡単かつ効率的に取り除くことができます
• 内部のバグレポートやその他の通信から直接Wikiページにリンクできるため、バグの検証が非常に簡単になります
• 通常組み込まれているバージョン履歴とリビジョン管理

短所：

• 変更が非常に簡単な場合があります（*下記を参照）。
• 個別に編集すると、ページが同期しなくなる可能性があります（たとえば、「グローバル検索と置換」は通常行われません）
• ページは孤立したり、置き換えられたりして、後でコーダーの潜在的な地雷原として残されます。（「これを実装しないというのはどういう意味ですか？それはまだデザインwikiにあります！」）
• 適切なパッケージを入手しない限り、構文は少し難解になる可能性があります
• ホスティングを手配するか、無料でオンラインで利用できるものを受け入れる必要があります
• 文書の明確な経路がない-どのようにそれを「すべて」読むか？
• 印刷が難しい。ワンクリックですべて印刷できますか？会議に持ち込むために、特定の機能に関連するすべてのものを簡単に印刷できますか？基になるドキュメントを不明瞭にすることなく、デジタルバージョンに簡単に注釈を付けることができますか？

（*私たちは1つのプロジェクトにwikiを使用しました。デザイナーは、サインオフしてコード化するために送信された機能であっても、その一部に参加して「改善」するように常に誘惑されました。その後、QAが機能をテストするときに、多くの場合、デザインは実際にコーディングされたものとは異なる何かを示唆し、最初に何が起こったか、つまりデザインまたはコードの変更を見つけるのにかなりのイライラする作業が必要になるため、悪夢になります。）

テキストファイル

現在のプロジェクトでは、プロジェクトの "Docs"フォルダーにある単純なプレーンテキストファイルを使用しており、コードの横のリポジトリに保存されています。

長所：

• ドキュメントは実際の作業の近くに保管されるため、簡単に見つけることができます。
• シンプルなフォーマットは、ドキュメントの保守が簡単かつ迅速であることを意味します。
• また、単純な形式であるため、サーバーのクラッシュやファイルの破損などが原因でドキュメントが失われるリスクがほとんどありません。
• セットアップ時間は最小限に抑えられているため、単一の開発者や小さな（2〜3人の）チームにとっては、これは素晴らしいスタートです。
• バージョン管理を使用すると、変更が追跡され、多くの場合、ドキュメントの変更をコードの変更に直接リンクできます。
• テキストと同じくらい簡単に操作できるため、検索、編集などはコマンドラインツールで実行できます。

短所：

• 数人のユーザーとドキュメントが簡単に同期されなくなります。
• リンクがないため、1つのグロテスクな大きさのドキュメントを使用するか、いくつかの小さくても接続されていないドキュメントを使用します。
• 制限された書式設定と公開オプション（Markdownなどによる変換は簡単に行えます）
• テキストと同じように簡単に操作できるため、検索や高度な編集などを行う唯一の方法は、コマンドラインツールを使用することです。

これは、あらゆる種類のチーム作業に依存したいものではありませんが、作業を正しく行うためのリポジトリ内のテキストファイルの能力は、単一の開発者にとって過小評価されるべきではありません。現在、私は一般的な設計を含む概要/マスタープランナーの一種として1つのドキュメント、ゲームが必要とする特定の事項のToDoリストとして機能する2番目のドキュメント、緩いバグ追跡としての3番目のドキュメント、および必要に応じて「機能x」について詳しく説明します。

マルチユーザーに対応していないドキュメント形式/エディター（MS Word、Open Office Writerなど）を使用しないでください。ドキュメントを編集できるのは1人だけであり、ソース管理を使用していても、古いバージョンでの作業を開始するのは簡単であり、それを保存することで、他のユーザーが最後にバージョンを更新してから行ったすべてのことを基本的に破棄しますドキュメントの。

共有フォルダは、最悪のソリューションであり、共同で作業することになっているあらゆる種類の資産を完全に排除します。他の誰かが現在そのファイルで作業していると確信することはできません。また、変更の追跡機能がなく、災害（人為的ミス、人間の愚かさ、または人間の怠慢）が発生した場合に、以前のバージョンに戻すことはできません。

できればWikiを使用することをお勧めしますが、ユーザーフレンドリーで、本当にWYSIWYGです。私はConfluenceを個人的に誓います。Confluenceは、より大きなゲーム開発スタジオでも使用されており、最大10人のユーザーと無制限の視聴者に対してわずか10ドルです。

他のほとんどのWiki（MediaWiki、TikiWikiなど）には、学習曲線が急であったり、技術者以外の人が実際に使用できないことさえあるという欠点があります。彼らはそれを学ぶことができなかったというわけではありませんが、基本的にHTMLのようなコードを書くことを要求するドキュメントシステムの使用を（正しく）受け入れません。これは私の不満です：WikiはWYSIWYGだと言っていますが、あなたが書いているテキストに構文を挿入するだけです。それはWYSIWYGではありません！

Wikiを使用する際のガイドラインは、すべての見出しを別のページに置くことです。これにより、ドキュメントを多くの扱いやすい部分に分割できます。Confluenceには、これらのすべてのサブページを1つのサイトまたはドキュメントに集約して、たとえばPDFにエクスポートできる機能があります。

One Noteは良いオプションだと思います。これはWikiのようなものですが、豊富なテキスト編集サポートがたくさんあります。Officeに付属する標準のデスクトップクライアントに加えて、Office LiveスイートにはWebベースのバージョンがあります。正直なところ、無料のWebベースのバージョンでほとんどのニーズに十分対応できると思います。Skydriveと組み合わせると、ライブドキュメントで共同作業を行うための非常に優れたシステムが得られます。

私のオープンソースプロジェクトの1つでは、ドキュメント（およびメディア）を格納するために（息をのむ）SharePointを使用しています。ユーザーと権限の管理は非常に簡単で、完全なバージョン履歴をサポートしています。約4年前からSharePointサイトを使用してきたため、現在はより優れたオプションがある可能性があります。しかし、それは私たちにとってかなりうまくいきました。これはサードパーティによってホストされており（月額約20ドル）、初期設定の後、実質的にメンテナンスは行われていません。ドキュメントライブラリと画像ライブラリをサポートすることに加えて、SharePointはWikiをサポートしていますが、より一般的なWikiエンジンに対してどれだけうまく対応できるかはわかりません。