実際に図を使用してゲームをモデル化しますか？[閉まっている]

私はほとんどUMLを意味しますが、機能するメソッドは実行可能です。だから-あなたは実際にUML /他の図や異なる方法でゲームをモデリングしていますか？私は大学でUMLを使用したモデリングについてのテーマを持っていましたが、実際のメリットよりも努力のように思えましたが、それは巨大な複雑なITシステムを作成したことがないからだと思います。だから、それは価値があり、通常はどのタイプのダイアグラム/メソッドが最適ですか？

*もちろん、多くの場合、具体的な問題を解決するために具体的なツールを選択する必要がありますが、いくつかのパターンがあるかもしれません。

編集： 1つの重要なことを忘れていました- ものを実装する前または後に図を作成しますか 私が意味するのは、人が通常心を変える何かを設計して実装するか、予期しない何かが出てきて、時には大きなものを変更しなければならないときです。すでに複雑な図でそれらを行うことは、コード自体と同じように絶望的です。

私は私たちの周りのすべてが、ダイアグラムを介して何らかの形で表現できると思うのが好きです。たとえそれが、特定のオブジェクトの状態の間の遷移を時系列で表す単なる線形図であったとしても（生物のように、誕生から死まで多くの状態を経て）。図を使用して、実際の実装に関する考えやアイデアをまとめます。私はかなり即興演奏します。

したがって、私の図はほとんどの場合非常に高いレベルであり、マインドマップのように感じます。

いくつか例を挙げると、これは実際にはインタラクティブオブジェクトが基本型であるゲームのクラス継承マップ（カットされたもの）です。

これはスパイクトラップのFSM（有限状態機械）ダイアグラムです（踏み込んでスパイクが地面から現れる素晴らしいトラップ）。

これは私が最近描いたハンドブックダイアグラム（この方法で名前が付けられることが多いため、頻繁にダイアグラムに戻ることを意図しているため）。ゲームのコンポーネントの概要を示し、必要なものとそうでないものをすぐに確認できるため、必要なアセットの収集にも役立ちます。大きなプロジェクトではかなり大きくなるので、小さなプロジェクトではこれらをお勧めします。しかし、それらをさらに広げることができるので、それは物事を修正するかもしれません。

下位レベルに行くとき、それは通常、アーキテクチャの最も複雑な側面を計画する必要があるためであり、通常はそこでUMLを扱います。ただし、完全にクリーンで正しいUMLの出力に集中することはありません。UML規約で最も気に入っているものを採用し、それを素晴らしいマインドマップ風のUMLに変えました。それは単純であり、私のために仕事をしますが、明白な理由のために、実際のUMLが期待される環境ではそれを使いません。

下位レベルに行かなければならない別の状況は、実際のアルゴリズムを説明する必要がある場合です。フローダイアグラムと呼ぶものを使います。これは、ホワイトボックステストで使用される図に触発された形式です。

私が今描いたスパイクトラップのサンプルは次のようになります。

これは通常、ダイアグラムと実際のアルゴリズム実装の間の最終層です。必要に応じて、フロー図をさらに詳細に実行し（追加の実行命令を使用）、複雑さを推定または推定し、正確なテストケースを作成します。また、擬似コードよりもダイアグラムを好みます。

ゲーム開発とは関係ありませんが、マルチスクリーンアプリの画面、ユーザーが各画面でトリガーできる機能、画面間の関係を説明するのに適した形式もあります。私は通常、実際の開発を開始する前にこれらを構築し、開発プロセス全体でマップのように機能します。クライアント向けの場合、画面図はさらに便利です！これは、プロジェクトの最初から最初までのすべてを検討し、必要なすべての機能を考慮するのに役立ちます。したがって、正確なコストと時間の見積もりを提供することは非常に貴重です。

ええ、私は間違いなくすべてのものを図式化します。アイデアがあれば、そのための図を描くことができます。少なくとも非常に広い図をバックアップせずにプロジェクトを何らかの形で開始すると、足が不自由になります。

私は確かに-構造的および行動的-私の経験則では、図を作るコストが私が1ヶ月後に何を考えていたのかを思い出そうとするよりも少ないとき、または私に明確に説明する必要があるときに図を作ることです他の開発者

継承階層が十分に複雑になったときのクラス図

オブジェクトのインスタンス化のようなものが、異なる部分からのフランケンシュタインモンスターの作成に隣接するものになったときのオブジェクト図-キッチンシンクの頂点およびピクセルシェーダーユーザーで、すべての必要なビットがパイプを介してプッシュされることを確認するのに特に役立ちます

一連のオブジェクト間の詳細な相互作用が複雑になる場合のシーケンス図-これは、ほとんど計算されていない下流の場所で以前に計算された情報が必要な複雑なレンダーフローのモデリングに非常に役立ちます

図は、設計を伝達、文書化、支援するための優れた方法であり、設計はソフトウェア開発の最も重要な部分です。UMLには多くの機能がありますが、それらをすべて同時に使用することは意図されておらず、有用な機能のみが使用されます。

新しい都市をナビゲートするとき、標識をたどるだけでなく、実際に立ち止まって地図を見ますか？それが設計とコーディングの目的です。物事がなじみのないとき、問題が複雑なとき、あなたが失われたと感じるとき、それはデザインについて考えるのが最も助けになるときであり、それを後よりも早くする方が良いです。何かを実装する前にデザインを変更する方がはるかに簡単です。

ダイアグラムは、問題を視覚化し、デザインを支援するための優れた方法です。特に視覚的な思想家にとっては（これは私が想像するgamedevのほとんどです）。図に明確にマッピングされると、多くの問題が簡単になり、欠陥が明らかになります。図にあるいくつかの問題：

• 単一のコンポーネントへの接続が多すぎますか？あなたは維持するのが難しい神のオブジェクトを持っているかもしれません
• 相互接続が多すぎますか？おそらく、モジュール性を改善して、アーキテクチャの脆弱性を減らすことができます
• 2つのコンポーネント間の経路が多すぎますか？おそらくあなたは密結合を持っている
• ゲームなどの高性能アプリケーションの場合、ホットパスまたは内部ループに関係するコンポーネントが多すぎますか？これはパフォーマンスに影響する場合があります
• ただし、ほとんどの場合、図には、想定した設計と実際の実装との矛盾が示されます

さらに、図は、技術に詳しくない人やプロジェクトに不慣れな人にデザインを伝え、文書化するのに最適です。また、6か月後にはプロジェクトに実際に不慣れであることを忘れないでください。

UMLの使用方法は、これらの考慮事項に基づいて決定する必要があります。あなた自身のために作図？最も使いやすい表記法を使用してください。他の開発者と協力していますか？API呼び出しの詳細、メッセージの種類、依存関係の方向を含めるようにしてください。アーキテクチャについて議論していますか？ブラックボックスと単純な接続で十分です。とにかく、UML機能の完全なセットを使用する人はいません。さらに、多くの人が理解する標準化された表記法のセットとして非常に便利です。

私自身に関しては、私は常に図を使用しています-個人プロジェクト用の簡単なメモ帳の描画、職場での簡単なUML図。このUMLダイアグラムは、私が複雑すぎると考えているものであり、その作成と保守のコストがその利益を上回るため、私は決して作成しませんが、もちろんYMMVです。

図には2種類あります。正式な図と落書き。

フォーマルダイアグラムについては、他のプログラマと作業しているときに行いますが、単独でプログラミングしている場合はほとんど行いません。

しかし、だからといって頭に浮かんだコードを何でも書いてくれるわけではありません。私の意見では、プログラミング（または実際には人生のあらゆること）で最も重要なことは、最初に考え、後で行うことです。

コーディングは非常に機械的な作業です。入力すると、画面に単語が表示されます。アイデアは、コーディングを開始するまでに、手元の問題をすでに解決しているはずだということです。落書きをすることは、あなたの考えを整理する素晴らしい方法であり、コーディングの部分を正しく行う必要があるという考えを自分で強制することさえできます。落書きは将来の参考のために保存することを意図したものではなく、思考プロセスを簡単に理解できるようにするためのものです。

考えるのに時間がかかりすぎても心配しないでください。思考の90％と10％のコーディングに専念すると、良いバランスが得られると思います。「考えるだけの時間はない、ただやるだけ」で生活する「シニア」プログラマーに会ったことがあります。しかし、彼らが何をしているのかを考える時間よりも早くコードを「完了」と呼んだとしても、彼ら（または後に残された不運な魂）は、正しく構築されるべきものを修正し、パッチを当てるのに無数の時間を費やします最初から。

一番いいのは、思考は自由だということです！考えるためにコンピューターに座っている必要はありません。食べたり、通勤したり、運動したりしながらコードについて考えることができます...実際、最高のアイデアは、少なくとも予想しないときに出てくるので、常に心を開いたままにして、あなたが本当に何を知っているときにのみコーディングを開始してください「コーディングします。

ここに私が同意する関連記事があります。

編集：図の実際の形式と種類については、フリースタイルにすることをお勧めします。あらかじめパッケージ化されたツールを使用する代わりに、実際に手書きすることをお勧めします。重要なのは思考プロセスを支援することなので、好きなものを自由に描いてください。セマンティクスは好きなものであり、ダイアグラム間、さらにはダイアグラムの異なる部分間でも異なる場合があります。

事前にパッケージ化されたツールと比べて、フリースタイル/手書き図には3つの主な利点があります。

1. 選択したツールでサポートされている図の種類に従う必要はありません。mapmindsが機能することもあれば、UMLのようなものがうまくいくこともあれば、論理図が機能することもあります。また、完全にカスタム化されたダイアグラムが機能する場合もあり、フリースタイルダイアグラムのすべての柔軟性を提供できるツールはありません（紙に穴を開け、お好みのパッケージで紙の裏側に進み、何が起こるかを確認してください）

2. ツールを使用する代わりに、実際に図を作成するのにより多くの時間を費やします。ツールに関係なく、探している特定の要素を見つけるためにメニューをキーボードで移動したりマウスでマウス移動したりするよりも、ペンと紙の方がダイアグラム作成が常に高速です。

3. 手書きにコンピューターは必要ありません。私はほとんどの場合、複雑なデザインをしていますが、図書館、カフェ、飛行機の中でさえもしています。また、良いアイデアは常に最も適切でない瞬間に浮かび上がるので、書くものと書くものを常に持ち歩くようにしてください。

Game Developers Conference 2013でのデザイン図の話をいくつか指摘する価値があるかもしれません。これらは非常に実用的で実証済みの例であり、長年にわたって多くの会議で発表されてきたようです。

（他の回答は、コードベースの計画、構築、成長、および維持においてデザイン中心のダイアグラムが非常に役立つ理由と方法を実証する見事な仕事を行ったので、私はその側面をそのままにして、これらのリソースが役立つかもしれないと信じます質問にアクセスするすべての人に。）

Joris DormansとErnest Adamsは、Machinationsゲームの設計/バランス図作成システムについて説明しました。（これは、GDC EU 2012からの有料のGDC Vaultビデオです。ドーマンズのwikiのGDC 2013からのサンプルです。）wikiがシステムを説明する方法は次のとおりです。

Machinationsは、理論的なフレームワークであり、ゲームを動的システムとして説明し、その中の閉じたフィードバックループに焦点を当てたインタラクティブで動的なグラフィカルな表現です。意図は、（反復的な）ゲーム構造を方法論的に表現および調査する方法を見つけることです。Machinationsは、ゲームの設計とバランスの直感的で繊細な実践に新しいレンズを提供します。

ノア・ファルスタインは「パズル依存図の難解な芸術」と呼ばれる講演を行いました（有料のGDC Vaultビデオ）。ペイウォールのないリンクはここにはありませんが、さまざまな人々がオンラインで議論したりメモを投稿したりしています。

両方の講演では、これらのダイアグラムをいつ作成し、どのように維持するかについて議論しました。

おそらく、この記事をチェックして、単純な抽象文法を使用してゲームプレイループを説明し、それが設計上の問題を特定するのにどのように役立ち、そのレベルで反復するのがいかに簡単かを確認してください。

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

また、抽象的なテーマを使用して機会、運、準備などを追跡する、ゲームプレイループの経済性に基づいた、このテーマに関する私自身の仕事についても指摘できます。

http://www.stephanebura.com/diagrams/

このアプローチが便利な場合は、Joris DormansのMachinationsをご覧ください。このようなダイアグラムを作成し、シミュレーションを実行するためのツールです。

http://www.jorisdormans.nl/machinations/

彼の全プロセスは彼の本で説明されています。

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/