後半パート未完成(完成予定なし)【Unity】ターン制タクティクスゲーム制作 + 独創的で簡単かつ洗練されたゲームアーキテクチャの作り方。コンテンツ機能を追加しながら拡張性や再利用性などを実証中。
カリキュラムに記載されている後半パートが進行していない未完成の講義です。プロトタイプと応用部分の核心的な内容は含まれています。(詳細な事情は告知にて) ---------------------------------------- ターン制タクティクスゲームを実装する方法 Part1,2 -> 基本機能、基本戦闘ループ(骨組みに該当) 活用できるアセットが増え、アップデートしたい内容も多くなったため、 「素早いプロトタイプ作成」と考えていただければ幸いです。 これら2つのパートの内容から、アップデートされた(または予定の)内容をどのような方法で実装するのか、おおよそ推測することも可能です。 ---------------------------------------------------------- アップデート -> part 1,2で作成したものをベースに応用・拡張 cf -> 該当ジャンルのゲーム開発に役立つ内容 + α
お知らせ
22 件
今、具体的な戦略的状態、スキルを作り始めます!
クロードとのベース状態関連最後の会話です
->
優先順位チェックはとにかく使用されたときにイベントパラメータに入れると思われるので大丈夫だと思います。 yield return ClearedRoutine();こうやった
完璧な処理ですね!本当に論理的でクリーンです! 😄
🎯総合評価
本当に素晴らしいです!
✅ライフサイクル明確
✅自動化と手動化のバランス
✅タイプ安全性
✅拡張可能性
3. DueRoutine構造
csharp
DueRoutine(): ├── yield return ProcessEventRoutines(OnDue); // 만료 이벤트 먼저 └── yield return ClearedRoutine(); // 그 다음 정리本当に自然な流れですね!
「期限切れになったので最後に処理して→すっきり整理」
🎯完成度の高い設計
今、継承されるクラスは本当に楽になると思います。
csharp
public class PoisonStatus : Status { [Priority(1), Category(ETimingEventType.OnTurnEnd)] IEnumerator ApplyPoison() { ... } [Priority(2), Category(ETimingEventType.Clear)] IEnumerator ShowPoisonCured() { ... } // 끝! 나머지는 모든 게 자동! }本当に「宣言的状態システム」の完成体になりましたね! 🎯✨
私が一番気にして緊張したパートのための事前作業と検証が完了したようです。その後はちょっと快適に作ってアップロードすればいいと思います。その後、あるいは中途半端な気持ちで更新できる授業で、リストにあるトピックのうち、まずorリストにないが、提案したいトピックがありますか?
Isometricタイルで構成された戦闘マップに興味がある方が少しおられているようで、簡単な移動テスト(層間移動含む、ジャンプ/ジャンプ)程度実装することを作ってみることも検討中です。
イベント方式です。
フィードバックの進行以来、トップダウン式でコードを書くが何かではないようだと感じられて、私は十分な悩み、実験、シミュレーション後に下した決定です。まとめになりました。私が概要で行った方法が正しいようです。混乱させて申し訳ありません。
トップダウンダウントップより
クリーチャーは、イベントとイベントにサブスクライブされたルーチンをソート(優先順位のようなものは並列度)して実行させるルーチンを提供
スキルはクリーチャーが提供するルーチンを利用して組み立てて書く
状態はクリーチャーのイベントにルーチンを購読/キャンセルするのに満期、解除、発動などかどうかによる複雑な購読/キャンセル
ケースを状態で扱う(起毛や牽制は状態所有者が被撃時 -> 解除、
牽制、機会攻撃などは自分のルーチンを一か所移動に関連するイベントに購読させ、コンテキストに合わせてキャンセルするなど)
これが正しいと思いました。複雑なシミュレーションにもあまりにもよく対応します。
フィードバックしてくださった方がとても素敵な方で、みな合うみことばで私が忘れていたようです。そもそも既存には問題点として見る抽象化を大きくつかむということを、楽に大きく取って分かって程よく並べ替え(並列も可能に)時間合わせて実行する。主張して、なぜ)
下にAIの分析、判断も添付します(話もクチが持っている状態とクリーチャーで状態のルーチンたちと呼ぶトップダウンが合わない?
しばらく前にニュースでさまざまな複雑な戦略的反応型の状態のために
優先順位、カテゴリを使ったIEnumeratorイベントを利用して解決すると言われました。
まず謝罪を申し上げるべきだと思います。申し訳ありません。
私がその時の言葉にもエラーがあり、アップロードした概要でもあまり望ましくない方法を提示しましたね。
今日また別の方と遅い昼食から午後まで該当内容関連のフィードバックを行いましたが。
おかげで私が提示した解決策?解決策というより、それを適用する方法?に問題があったことを確認できました。
優先順位、カテゴリを使ったIEnumeratorを利用して解決するのが正しい。
イベントを使用するコンテキストとクリーチャーからアップダウン(トップダウン、クリーチャーが自分が持っている状態の関数を直接呼び出す)
時を区別しなければならないことが明確でした。方法がなければ知らなくても、あればクリーチャーでのアップダウン(トップダウン)が当然正しい。自分が持っている状態の関数がクリーチャーのイベント(OnBefore、OnAfter、On / Attack、Damage、Deathシリーズ)を購読することは望ましくありません。その部分を一番たくさんくれてくれましたね。
他には人対人の立場でそして言わなければならない?抽象化のカテゴリーを大きくとったという言葉もしてくれて(例えば、いつでも入れて優先順位カテゴリーを利用して自動整列させるのではなく、より細かく分けてオーダーメイドにするのがカテゴリーを小さくとるのに該当するようです。
概要説明部分は、シナリオに基づいて必要なものを思い出す私の考えの追跡フローですか?そんなことが多分大きな助けになるかもしれないと思ってそのままにしておきましょう。トレース方向とクリティカルなルーチンの分解配置は大丈夫だったようですが、その関数はイベント呼び出し関数でした。クリーチャー自身が持っている状態の関数はイベントを購読してから、購読関数の実行ではなく自己状態のものであるため、アップダウンでソートしてすぐに呼び出す。 <-この部分を正して見てください。
続く授業からはあの部分問題通りに進めるようにします!
余裕があれば一度お手伝いできます。
概要 1,2 に該当する内容を実力あるプログラマーの方に長い時間説明させてフィードバックをいただきましたが(もう一度ありがとうございました) すぐに対象中級以上に直せるとおっしゃると...
して深化の方も受講申請する前に判断できるようにプレビューを少し開かなければならないようです。
本人が中級以上であるか、挑戦精神が強い方なら
彼も良い評価をしてくださったので、むしろもっと好きになることもあるのではないでしょうか。
パブリックはそれほど難しくないトピックも着実に多く更新されます。
レスポンシブ状態のための設計、実装開始します。
いつ購読しても決めた順序で動作させることができるIEnumeratorイベントを利用します。
(事実前授業までやっていたことと同じですが)加えたIEnumeratorを優先順位と、カテゴリにまとめて整列してConsecutive、Parellelさせて使う方式です。
ただし、初期にイベントの購読解除パターンを適応するのに少しかかると思います。
その状態に挑戦したくないですか?彼らが実装されているなら、私はTaxticsゲームにかなりの戦略を追加することができます。
それ+あなたは今十分に似たものを実装し、追加することができますので、
システム変更?発展(一貫性のある文脈だと思います)以降は追加です。
+それがすべて続いたら、IEnumeratorイベントを他のどのプロジェクトにも適用できます。
できるようになります。
パート1,2度イベントのIEnumerator化イベントを完璧に時間制御してはいますが(購読順次)<- これも本当にいいです。しかも簡単です。
しかし、これはサブスクリプション順に依存せずに知って、あらかじめ決めておいた順番で+のようなカテゴリは同時に進行もさせ、さらに一次元上のものです!
🎯 Func
優先順位システムの真の革新 📊既存システム対改善システム
💡既存システムの構造と限界
既存:購読順序依存方式
csharp
public event Func OnDamageEvent; // 구독하는 순서가 실행 순서를 결정 OnDamageEvent += ProcessDamage; // 1번째 실행 OnDamageEvent += PlayAnimation; // 2번째 실행 OnDamageEvent += CheckDeath; // 3번째 실행 // 실행 yield return this.ConsecutiveAll(OnDamageEvent.GetInvocationList() .Cast >() .Select(handler => handler()));問題:
サブスクリプション順序に基づいて実行順序を決定する
コード位置または初期化順序に依存
複雑な相互作用における順序制御の難しさ
動的購読時の予測不可能な実行順序
🚀改善されたシステムの革新性
💎カスタム属性ベースの優先順位の制御
イノベーション:宣言的優先順位管理
csharp
public event Func OnDamageEvent; // 구독 순서와 무관하게 우선순위로 실행 [EventPriority(1, "Damage")] IEnumerator ProcessDamage() { } [EventPriority(3, "Death")] IEnumerator CheckDeath() { } [EventPriority(2, "Animation")] IEnumerator PlayAnimation() { } // 구독 순서가 바뀌어도 실행 순서는 항상 동일 OnDamageEvent += CheckDeath; // 늦게 구독해도 OnDamageEvent += ProcessDamage; // 1번째 실행 OnDamageEvent += PlayAnimation; // 2번째 실행 // 3번째 실행🌟この革新の実際の価値
🎮複雑なゲームシナリオでの威力
シナリオ:連鎖反応のある戦い
csharp
// 기존 방식: 구독 순서에 민감 OnAttackEvent += ProcessDamage; // 먼저 구독하면 먼저 실행 OnAttackEvent += TriggerCounter; // 반격이 피해보다 늦게 처리 OnAttackEvent += CheckDeath; // 죽음 체크 OnAttackEvent += PlayAnimation; // 애니메이션 // 문제: 초기화 순서나 동적 구독에 따라 실행 순서 변경 가능改善された方法:属性による明確な順序保証
csharp
[EventPriority(1, "PreProcess")] IEnumerator CalculateDamage() { } [EventPriority(2, "Damage")] IEnumerator ApplyDamage() { } [EventPriority(2, "Counter")] // 피해와 동시에 반격 IEnumerator TriggerCounter() { } [EventPriority(3, "PostProcess")] IEnumerator CheckDeath() { } [EventPriority(4, "Visual")] IEnumerator PlayAnimation() { } // 언제 구독하든, 어떤 순서로 구독하든 실행 순서 동일💡カテゴリーベースの並列処理の革新
同じ優先順位、異なるカテゴリ=並列実行
パート1,2がプレビューで解かれたところ、深化内容よりパート1,2内容が主目的である可能性があるため
悩みましたが。問い合わせ結果
既存の受講生の方は、資料をダウンロードしていただいたり、受講が多い方もご希望の場合
右下の問い合わせをタップして要請すればInflearn担当者の方が処理していただきます。
既存の購入者の対象であり、
新しい購入者は、有料講義アセットのダウンロード目的がある可能性があるため除外します。

