後半パート未完成（完成予定なし）【Unity】ターン制タクティクスゲーム制作 ＋ 独創的で簡単かつ洗練されたゲームアーキテクチャの作り方。コンテンツ機能を追加しながら拡張性や再利用性などを実証中。
カリキュラムに記載されている後半パートが進行していない未完成の講義です。プロトタイプと応用部分の核心的な内容は含まれています。（詳細な事情は告知にて） ---------------------------------------- ターン制タクティクスゲームを実装する方法 Part1,2 -> 基本機能、基本戦闘ループ（骨組みに該当） 活用できるアセットが増え、アップデートしたい内容も多くなったため、 「素早いプロトタイプ作成」と考えていただければ幸いです。 これら2つのパートの内容から、アップデートされた（または予定の）内容をどのような方法で実装するのか、おおよそ推測することも可能です。 ---------------------------------------------------------- アップデート -> part 1,2で作成したものをベースに応用・拡張 cf -> 該当ジャンルのゲーム開発に役立つ内容 + α
･
修正済み
別の専門家との講義内容フィードバック後に把握した問題点について
しばらく前にニュースでさまざまな複雑な戦略的反応型の状態のために
優先順位、カテゴリを使ったIEnumeratorイベントを利用して解決すると言われました。
まず謝罪を申し上げるべきだと思います。申し訳ありません。
私がその時の言葉にもエラーがあり、アップロードした概要でもあまり望ましくない方法を提示しましたね。
今日また別の方と遅い昼食から午後まで該当内容関連のフィードバックを行いましたが。
おかげで私が提示した解決策？解決策というより、それを適用する方法？に問題があったことを確認できました。
優先順位、カテゴリを使ったIEnumeratorを利用して解決するのが正しい。
イベントを使用するコンテキストとクリーチャーからアップダウン（トップダウン、クリーチャーが自分が持っている状態の関数を直接呼び出す）
時を区別しなければならないことが明確でした。方法がなければ知らなくても、あればクリーチャーでのアップダウン（トップダウン）が当然正しい。自分が持っている状態の関数がクリーチャーのイベント（OnBefore、OnAfter、On / Attack、Damage、Deathシリーズ）を購読することは望ましくありません。その部分を一番たくさんくれてくれましたね。
他には人対人の立場でそして言わなければならない？抽象化のカテゴリーを大きくとったという言葉もしてくれて（例えば、いつでも入れて優先順位カテゴリーを利用して自動整列させるのではなく、より細かく分けてオーダーメイドにするのがカテゴリーを小さくとるのに該当するようです。
概要説明部分は、シナリオに基づいて必要なものを思い出す私の考えの追跡フローですか？そんなことが多分大きな助けになるかもしれないと思ってそのままにしておきましょう。トレース方向とクリティカルなルーチンの分解配置は大丈夫だったようですが、その関数はイベント呼び出し関数でした。クリーチャー自身が持っている状態の関数はイベントを購読してから、購読関数の実行ではなく自己状態のものであるため、アップダウンでソートしてすぐに呼び出す。 <-この部分を正して見てください。
続く授業からはあの部分問題通りに進めるようにします！