이제 구체적인 전략적 상태들, 스킬들 만들기 시작합니다!

클로드와의 베이스 상태관련 마지막 대화 입니다

->

Priority 체크는 어차피 쓰일때 이벤트 매개변수로 넣는거보니 있을게 확실하니까 괜찮을것 같구 오토섭스크라이브이벤트쪽에서 카테고리만 체크해주면 될듯 나머지도 처리했고 DueRoutine 만들어서 yield return ProcessEventRoutines(OnDue); 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 시리즈들) 구독하는건 바람지하지 않다. 그부분을 가장 많이 짚어주셨었네요.

그밖에는 사람대 사람입장에서 그리고 말해야한다?, 기획 과외 느낌나는 게임 플로우 그림 그리는것도 했고, 스킬에서 하는게 너무 많다(현재 플레이어/NPC 일 경우 나누고, 클릭 타겟 선택과 스킬실행까지) 스킬은 그냥 실행만 하는 방향도 있다. 추상화의 범주를 크게 잡았다는 말씀도 해주셨고(예를들면 아무때나 넣고 우선순위 카테고리를 이용해서 자동정렬하게 하는게 아니라 더 세세하게 나눠서 맞춤형으로 하는게 범주를 작게 잡는거에 해당하는 것 같습니다. <- 저는 이건 그냥 기존 방식이 더 마음에 들 더라구요)

개요 설명부분은 시나리오를 바탕으로 필요할것 같은 것들을 떠올리는 제 생각의 추적흐름? 그런것들이 어쩌면 큰 도움이 될수도 있다고 생각해서 그대로 두도록 하겠습니다. 추적방향과 크리티컬한 루틴들 분해 배치는 괜찮았던 것 같고 다만 그 함수들이 이벤트호출 함수였던것이;; 크리처 자신이 가진 상태의 함수들은 이벤트 구독시킨 다음, 구독함수들 실행이 아닌 자기 상태것들이니 업다운으로 정렬하여 바로 호출한다. <- 이부분 바로잡아서 봐주시면 되겠습니다.

이어지는 수업부터는 저 부분 문제거리 없게 진행하도록 하겠습니다!

여유있을때 한번씩 도와드릴 수 있습니다.

개요 1,2에 해당하는 내용을 실력있는 프로그래머 분에게 긴 시간 설명드리고 피드백 받고 하였는데(다시 한 번 감사드립니다) 당장 대상 중급이상으로 고치라고 말씀을...

하여 심화쪽도 수강신청 하기 전 판단하실 수 있게 미리보기를 좀 열어야 할 것 같습니다.

본인이 중급 이상이다 혹은 도전정신이 강하다하는 분이시라면

그분도 좋은 평가를 해주셨으니 오히려 더 좋아 하실 수도 있지 않을까 하네요.

공용 그리 어렵지 않은 주제들도 꾸준히 많이 업데이트 될 것입니다.

반응형 상태들을 위한 설계, 구현 시작합니다.(중간 중간 공용 보통 내용들도 진행합니다 #심화# <- 이거 붙는것들만)

언제 구독시켜도 정해둔 순서대로 동작시킬 수 있는 IEnumerator 이벤트를 이용합니다.

(사실 전수업들까지 하던일들과 똑같은데) 더한 IEnumerator들을 우선순위와, 카테고리로 묶고 정렬하여 Consecutive, Parellel하게 해서 쓰는 방식입니다.

다만 초기에 이벤트 구독해지 해지 패턴 적응하기가 좀 걸릴것같은

저 상태들 도전 해보고 싶지 않으시나요? 저들이 구현되면 만드실 택틱스 게임에 상당한 전략성을 추가하실 수 있을 겁니다.

저것들+ 여러분들이 이제 충분히 비슷한것들 구현,추가가 가능해질것이기에,

시스템 변경? 발전(일관성 있는 맥락이라고 생각합니다) 이후부턴 추가거든요.

+저걸 다 따라오고 나면 IEnumerator 이벤트를 이제 웬만한 다른 프로젝트들에도 신나게 적용시킬수

있게 되실 수 있을 것 같습니다.

 파트1,2도 이벤트의 IEnumerator화 이벤트를 완벽히 시간제어 하긴 하지만(구독순서대로)<- 이것도 정말 좋아요. 게다가 쉽죠.

하지만 이건 구독순서에 의존하지 않고 알아서 미리 정해둔 순서대로 + 같은 범주는 동시에 진행도 시키고 한 차원 더 위의 것입니다!

🎯 Func<IEnumerator> 우선순위 시스템의 진정한 혁신

📊 기존 시스템 vs 개선된 시스템

💡 기존 시스템의 구조와 한계

기존: 구독 순서 의존 방식

csharp

public event Func<IEnumerator> OnDamageEvent;

// 구독하는 순서가 실행 순서를 결정
OnDamageEvent += ProcessDamage;      // 1번째 실행
OnDamageEvent += PlayAnimation;      // 2번째 실행  
OnDamageEvent += CheckDeath;         // 3번째 실행

// 실행
yield return this.ConsecutiveAll(OnDamageEvent.GetInvocationList()
    .Cast<Func<IEnumerator>>()
    .Select(handler => handler()));

문제점:

• 구독 순서에 따라 실행 순서 결정

• 코드 위치나 초기화 순서에 의존

• 복잡한 상호작용에서 순서 제어 어려움

• 동적 구독 시 예측 불가능한 실행 순서

•  

🚀 개선된 시스템의 혁신성

💎 커스텀 어트리뷰트 기반 우선순위 제어

혁신: 선언적 우선순위 관리

csharp

public event Func<IEnumerator> 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내용이 주 목적일 수도 있기에

고민을 했었는데요. 문의결과

기존 수강생 분들은 자료를 다운로드 받았거나 수강많이 하신 분들도 원하시면

우측 아래 문의하기를 눌러서 요청하시면 인프런 담당자분께서 처리해주시겠다고 하네요.

기존 구매자분들 대상이고,

새 구매자 분들은 유료강의에셋 다운로드 목적이 있을수 있기에 제외하겠습니다.