남작게돈 추가
남작게돈 그래픽 추가
List<MinionAttack> myMinions = enemyField.GetComponentsInChildren<MinionAttack>()
.Where(m => m.canAttack && m.damage > 0).ToList();
끈데 공격할떄마다 리스트 가져올수밖에 없나:왜냐하면 이전턴에는 있엇지만, 다음턴에 죽을수있으니간? 근데 아니면 유니티에서 playerfield로 연결하도록 해서 하면 자식들 가져올수있는데 그렇게 하면, 무ㅝ가 더 성능면에서 나은거지
공격할 때마다 리스트를 가져오지 않는다"의 진짜 의미<잠깐만 근데 그러면, 이렇게 될수도 있지않나, 적 ai입장에서 하수인 a,b,c(내 하수인) 적은 a1,b1,c1인데 a가 a1쳐서 죽임, 근데, 공격할떄마다 갱신 아니니깐, b입잡에서는 a1살아있다고 생각함<공격<오류,
끄냥 공격할떄마다 갱신해야겟는데
- 적 하수인 A1이 플레이어의 '도발(Taunt)' 하수인 A를 죽였습니다.
- 이제 필드에 도발 하수인이 없으므로, 적 하수인 B1은 명치(Hero)를 칠 수 있어야 합니다.
- 하지만 명단을 갱신하지 않으면 B1은 이미 죽은 A를 찾거나, 여전히 도발이 있다고 착각할 수 있죠.
따라서, "공격 주체(Attacker)"는 루프 밖에서 한 번만 가져오고, "공격 대상(Targets)"은 루프 안에서 매번 갱신하도록 코드를 수정
현재 이득교환잘하는데 문제는 이득교환을 할때는 화살표가 그 대상 하수인으로 가야하는데 (적 입장에서는 플레이어 하수인으로 화살표가 가야하는데 화살표가 항상 플레이어 영웅쪽으로 가있음)
AI가 선택한 실제 타겟(bestTarget)이 누구인지 **MinionAttack**이 알 수 있도록 변수를 하나 추가하고, 그 변수를 따라가도록 수정하
어떻게 스크립트간 정보를 교환하는가
- Update 함수: 이 하수인이 1초에 60번(프레임마다) 자기 메모장을 확인해서, 타겟이 적혀 있으면 그쪽으로 화살표를 돌리는 '감시자'입니다.
-
attacker.aiTarget = targetObj; // 하수인의 메모장(변수)에 타겟을 씀 attacker.ToggleAttackArrow(true); // "자, 이제 화살표 켜고 메모장 봐!"- 이 순간, attacker라는 변수가 가리키고 있는 그 하수인 오브젝트의 메모리(RAM) 공간에 타겟 오브젝트의 주소값이 딱 저장됩니다.
- 하수인의 감시 (MinionAttack.Update):
- 유니티는 매 프레임마다 모든 활성화된 오브젝트의 Update를 실행합니다.
- Update는 실행될 때마다 if (isTargeting ...) 조건을 체크합니다.
- ToggleAttackArrow(true)가 실행된 바로 다음 프레임부터 Update는 isTargeting이 true임을 확인하고 로직을 실행합니다.
- 이때 targetPos를 결정하기 위해 aiTarget 변수를 들여다보는데, 방금 전 지휘관이 적어놓은 targetObj가 거기 들어있으니 즉시 그 위치를 향해 화살표를 그리게 되는 것입니다.
update함수:알아서 호출해주니깐
네, "고유한 저장 공간"이라는 표현이 프로그래밍 개념이라 조금 생소하실 수 있습니다. 아주 단순하게 풀어서 설명해 드릴게요.
"변수(Variable) = 메모리(RAM)에 잡힌 이름 있는 칸" 이라고 생각하시면 됩니다.
1. "인스턴스(Instance)"가 핵심입니다
유니티 필드에 하수인이 3마리(A, B, C) 있다고 가정해 봅시다.
- 세 하수인 모두 MinionAttack 스크립트를 가지고 있습니다. (이건 설계도입니다.)
- 하지만 실제 게임 속 하수인 A, B, C는 각각 별개의 물체입니다. (이것이 인스턴스입니다.)
이때 public GameObject aiTarget;이라는 변수를 선언하면, 유니티는 하수인 하나당 aiTarget이라는 이름의 빈 칸을 메모리에 하나씩 만들어 줍니다.
- 하수인 A의 칸 (aiTarget)
- 하수인 B의 칸 (aiTarget)
- 하수인 C의 칸 (aiTarget)
2. 어떻게 전달되는가? (참조의 원리)
EnemyAttackAI가 attacker.aiTarget = targetObj;라고 코드를 실행할 때의 과정입니다.
- 누구인지 찾음: attacker는 지금 공격 명령을 받은 **특정한 하수인(예: 하수인 A)**을 가리킵니다.
- 칸에 써넣음: 지휘관(EnemyAttackAI)은 하수인 A가 가진 고유한 aiTarget 칸에 가서 targetObj라는 주소를 적어 넣습니다.
- 동시에 일어남: 하수인 A의 Update는 1초에 60번씩 자기가 가진 그 칸을 들여다봅니다. "누가 여기 타겟을 적어놨나?"
- 발견: 지휘관이 적어놓은 타겟을 발견하고 그쪽으로 화살표를 그립니다.
이때 하수인 B나 C의 aiTarget 칸은 여전히 비어(null) 있습니다. 그래서 A가 공격한다고 B나 C의 화살표가 같이 움직이지 않는 것입니다.
3. 유니티 인스펙터와 상관관계
유니티 인스펙터 창에서 변수 옆에 하수인을 드래그해서 넣는 것과, 코드(aiTarget = targetObj)로 넣는 것은 정확히 똑같은 작업입니다.
- 인스펙터: 사람이 마우스로 그 "메모리 칸"에 값을 넣는 것.
- 코드: 프로그램이 실행 중에 그 "메모리 칸"에 값을 넣는 것.
결국 변수란 그 오브젝트가 기억하고 있어야 할 정보를 담는 전용 보관함이며, EnemyAttackAI가 그 보관함에 정보를 넣어주기 때문에 Update가 그걸 보고 반응할 수 있는 것입니다.
**"전달"**이라는 단어 때문에 어디론가 쏴주는 느낌이 들 수 있지만, 실제로는 **"공용 게시판(변수)에 적어두고, 다른 쪽에서 그걸 읽는 방식"**이라고 이해하시면 완벽합니다!
현재 EnemyAI.cs의 로직은 손패 리스트를 앞에서부터 검사하다가 처음 만나는 낼 수 있는 카드를 바로 내버립니다. 이를 낼 수 있는 후보들을 먼저 다 찾은 뒤 그중 하나를 랜덤하게 뽑는 방식으로 수정하면 됩니다.
적 ai같은 비용 카드 두개있으면 어떻게 처리하지
3코 하수인, 종류 다른거 2개
무조건 정리(자기 명치 데미지 고려해서)
- Lethal: 이번 턴에 끝낼 수 있으면 하수인 상황 무시하고 명치만 봅니다.
- Survival: 내 체력이 위험수위(5 이하)이거나, 필드에 깔린 플레이어 데미지가 내 체력보다 높으면 "정리 우선" 모드로 들어갑니다.
- Normal: 평소에는 이득 교환(내가 안 죽는 선에서 잡기)을 시도하고, 안 되면 명치를 칩니다.
- 정렬 로직 (OrderByDescending):
생존 모드일 때는 플레이어의 하수인 중 **가장 공격력이 강한 놈(위험한 놈)**부터 차례대로 리스트에서 뽑아서 공격 타겟으로 정합니다.
"내가 다음 턴에 죽을 것인가"를 판단하는 가장 기본적이고 확실한 기준은 **플레이어 필드에 떠 있는 하수인들의 공격력 합계(Visible Lethal)**입니다.
// [보강] 플레이어 영웅의 공격력까지 포함 (영웅이 무기를 들었을 수도 있으므로)
혹은 나중에 영웅능력 추가한다면
이건 너무 복잡한듯ㄱ
1. '안전 마진(Safety Margin)' 도입
하스스톤 같은 게임에서 플레이어는 항상 손패에 변수(주문, 돌진 하수인, 버프 등)를 가지고 있습니다. 따라서 AI는 **"현재 필드 데미지 + 알파"**를 계산해야 합니다.
- 논리: 내 체력 <= (필드 데미지 + 여유분 3~5)
- 이렇게 설정하면 체력이 10이고 필드 딜이 9일 때, 여유분(예: 4)을 더한 13보다 내 체력이 낮으므로 AI는 **"위험하다"**고 판단하고 하수인을 정리하기 시작합니다.
2. '턴 소요(Turn Clock)' 개념
"내가 몇 턴 뒤에 죽는가?"를 계산하는 방식입니다.
- 상황: 내 체력 10, 필드 딜 9.
- 판단: 한 턴만 더 맞으면 거의 죽음(1턴 클락).
- 전략: 내가 다음 턴에 상대를 죽일 수 있는 상황이 아니라면, 무조건 적 하수인을 하나라도 줄여서 이 '턴 소요'를 늘려야 합니다. (적어도 2~3턴은 버틸 수 있게 필드를 깎아야 함)
3. '하수인 가치'에 따른 유연한 대응 (하이브리드 전략)
무조건 "명치냐 정리냐" 두 이분법으로 나누지 말고, 하수인의 공격력에 따라 우선순위를 정하는 것입니다.
- 위험 대상 제거: 적 필드에 공격력 5짜리 큰 하수인이 있다면, 내 체력이 10일 때 이놈은 무조건 잡아야 합니다. (체력의 절반을 깎으니까요)
- 작은 놈 무시: 반면 공격력 1짜리 하수인은 지금 당장 내 생존에 큰 지장이 없으므로 무시하고 적 영웅을 공격합니다.
- 기준: "적 하수인의 공격력이 내 현재 체력의 30% 이상인가?" 같은 기준을 세우면, 내 피가 적을수록 더 적극적으로 정리하게 됩니다.
4. '역전 가능성' 판단 (공격이 최선의 방어)
내 피가 10이고 적 필드 딜이 9라 위험하더라도, 만약 이번 턴에 적 영웅의 피를 1이나 2로 만들 수 있다면?
- 이때는 정리보다 공격이 낫습니다. 왜냐하면 내가 정리를 하느라 힘을 다 쓰면 다음 턴에도 계속 밀리지만, 적 피를 1로 만들면 오히려 적이 죽지 않으려고 내 하수인을 정리하게 강제할 수 있기 때문입니다.
(특히 4번같은건, 좀..)
왜 hp + 5가 아니라 damage + 5인가요? (논리 설명)
사실 수학적으로는 hp - 5 <= damage나 hp <= damage + 5나 결과는 같습니다. 하지만 코드 가독성 면에서는 후자가 더 이해하기 쉽습니다.
지속 효과(턴 종료 시 발동 등)를 가진 하수인을 구현하고, AI가 이를 똑똑하게 판단하게 만드는 방법을 단계별로 설명해 드릴게요.
1. 하수인은 어떻게 생성되고 있나? (현재 구조 복습)
현재 코드를 보면 다음과 같은 흐름으로 생성됩니다:
- 데이터: Card (ScriptableObject)에 이름, 공격력, 체력, **List<Effect> effects**가 들어있음.
- 생성: CardDrawer가 Card_Template 프리팹을 Instantiate(복제)함.
- 연결: 생성된 프리팹의 CardDisplay에 Card 데이터를 넣어줌.
즉, 새로운 스크립트를 매번 만들 필요가 없습니다. 똑같은 프리팹을 쓰되, Card 데이터 안에 어떤 Effect가 들어있느냐에 따라 능력이 결정되는 구조입니다.
2. 지속 능력 하수인 구현 방법
A. Card.cs 수정 (태그 및 위협도 추가)
AI가 이 하수인을 먼저 잡아야 할지 말지 결정하기 위해 threatLevel(위협도)이라는 개념을 넣는 것이 좋습니다.
public enum ThreatLevel { Low, Medium, High } // AI가 판단할 우선순위
public class Card : ScriptableObject
{
// ... 기존 변수들 ...
public List<Effect> effects;
public bool isEndOfTurnEffect; // 턴 종료 효과 여부
public ThreatLevel threatLevel; // AI를 위한 태그
}B. 효과 실행 (TurnManager.cs)
턴이 끝날 때 필드를 조사해서 효과를 가진 하수인들을 찾아 실행시켜야 합니다.
// TurnManager.cs 의 ToggleTurnButton 함수 내부 (턴을 바꾸기 직전)
void ExecuteEndOfTurnEffects(bool isPlayerTurn)
{
// 현재 턴인 사람의 필드를 찾음
Transform field = isPlayerTurn ? playerField : EnemyAI.Instance.enemyFieldParent;
foreach (Transform child in field)
{
CardDisplay cd = child.GetComponent<CardDisplay>();
if (cd != null && cd.cardData.isEndOfTurnEffect)
{
foreach (Effect effect in cd.cardData.effects)
{
effect.Execute(); // 여기서 남작게돈 효과 등이 발동!
}
}
}
}3. AI의 판단: "이놈은 무조건 잡아야 하나?"
질문하신 것처럼 3코 5/5(나쁜 효과)와 남작게돈(좋은 효과)을 구분하려면 **threatLevel**을 활용하면 됩니다.
EnemyAttackAI.cs 수정 (타겟팅 우선순위)
GetBestTradeTarget 함수에서 하수인의 위협도를 체크하도록 보강합니다.
private GameObject GetBestTradeTarget(MinionAttack attacker, List<MinionAttack> targets, bool isSurvival)
{
if (targets == null || targets.Count == 0) return null;
// 1순위: 위협도가 High인 하수인 (남작 게돈 등)
var highThreat = targets.FirstOrDefault(t => t.GetComponent<CardDisplay>().cardData.threatLevel == ThreatLevel.High);
if (highThreat != null) return highThreat.gameObject;
// 2순위: 이득 교환 (Value Trade)
// ... 기존 로직 ...
// 3순위: 위협도가 Low인 하수인 (3코 5/5 나쁜 효과 하수인)
// 이런 애들은 위협도가 Low이므로, AI가 굳이 먼저 잡으려 하지 않고 명치를 치게 됩니다.
}4. 지속 하수인 만드는 법 (에디터 작업)
- Effect 에셋 생성: DamageAllEffect(모든 캐릭터 피해) 같은 스크립트를 만들고, 프로젝트 창에서 오른쪽 클릭 -> Create로 에셋 파일을 만듭니다.
- Card 에셋 생성:
- 남작 게돈: isEndOfTurnEffect 체크, threatLevel을 High로 설정, effects 리스트에 DamageAllEffect 에셋을 넣음.
- 나쁜 5/5 하수인: isEndOfTurnEffect 체크, threatLevel을 Low로 설정, effects 리스트에 DamageSelfHeroEffect 에셋을 넣음.
요약
- 인터페이스 vs 태그?: 현재 구조가 Effect (ScriptableObject) 기반이므로, **태그(ThreatLevel)**와 **불 값(isEndOfTurnEffect)**을 Card에 추가하는 것이 가장 깔끔합니다.
- 생성?: 기존과 똑같이 CardDrawer가 생성합니다. 능력은 데이터(Card)에 이미 들어있습니다.
- AI 판단?: 하수인 데이터에 적힌 ThreatLevel을 보고 "High면 무조건 정리, Low면 무시" 하도록 로직만 한 줄 추가하면 됩니다.
이렇게 하면 하수인마다 개별 스크립트를 짤 필요 없이, 에디터에서 Card 데이터만 설정해주는 것으로 다양한 지속 능력 하수인을 무한히 만들 수 있습니다!
! 현재처럼 하나의 List<Effect>에 모든 효과를 다 몰아넣으면 말씀하신 대로 **"전투의 함성(낼 때 발동)"**과 **"턴 종료 효과"**를 구분할 수 없게 됩니다.
네, 정확한 지적입니다! 현재처럼 하나의 List<Effect>에 모든 효과를 다 몰아넣으면 말씀하신 대로 **"전투의 함성(낼 때 발동)"**과 **"턴 종료 효과"**를 구분할 수 없게 됩니다.
가장 깔끔하고 확장성이 좋은 방법은 리스트를 용도별로 나누는 것입니다. 하스스톤 같은 게임에서도 내부적으로는 효과가 발동되는 '타이밍'이 철저히 분리되어 있습니다.
1. Card.cs 수정 (리스트 분리)
하나의 리스트 대신, 발동 타이밍에 맞는 리스트들을 만듭니다.
public class Card : ScriptableObject
{
// ... 기존 변수들 ...
[Header("Effects (Timing)")]
public List<Effect> battlecryEffects; // 내자마자 발동
public List<Effect> endOfTurnEffects; // 매 턴 종료 시 발동
public List<Effect> deathrattleEffects; // 죽을 때 발동 (나중에 추가 대비)
public ThreatLevel threatLevel; // AI 판단용
}2. 발동 시점별 코드 수정
A. 카드를 낼 때 (전투의 함성)
CardDraggable.cs에서 카드를 낼 때 실행하는 부분을 수정합니다.
// CardDraggable.cs 내 OnEndDrag 부분
if (cd.cardData.battlecryEffects != null)
{
foreach (Effect effect in cd.cardData.battlecryEffects)
effect.Execute(); // 여기서 '전투의 함성'만 실행됨
}B. 턴이 끝날 때 (지속 효과)
TurnManager.cs에서 턴을 넘기기 직전에 실행합니다.
// TurnManager.cs
public void ToggleTurnButton()
{
// 턴을 바꾸기 전에 현재 필드의 턴 종료 효과 실행
TriggerEndOfTurnEffects(isPlayerTurn);
isPlayerTurn = !isPlayerTurn;
// ... 이후 기존 턴 전환 로직 ...
}
private void TriggerEndOfTurnEffects(bool isPlayer)
{
// 1. 현재 턴인 사람의 필드를 찾음
Transform field = isPlayer ? playerField : EnemyAI.Instance.enemyFieldParent;
// 2. 필드의 모든 하수인을 검사
foreach (Transform child in field)
{
CardDisplay cd = child.GetComponent<CardDisplay>();
if (cd != null && cd.cardData.endOfTurnEffects != null && cd.cardData.endOfTurnEffects.Count > 0)
{
// 3. 해당 하수인의 '턴 종료 리스트'만 순회하며 실행
foreach (Effect effect in cd.cardData.endOfTurnEffects)
{
effect.Execute();
}
}
}
}3. 왜 이 방식이 좋은가요?
- 실수 방지: 인스펙터 창에서 효과를 넣을 때 "이건 턴 종료 효과니까 endOfTurnEffects 칸에 넣어야지" 하고 명확하게 구분할 수 있습니다.
- 유연성: 한 카드가 전투의 함성도 있고 턴 종료 효과도 있을 때 (예: 내자마자 1딜 주고, 매 턴 끝날 때마다 1딜 주는 카드) 아주 쉽게 구현됩니다.
- 성능: 모든 효과를 다 돌면서 "너는 턴 종료 효과니?"라고 물어볼 필요 없이, 필요한 리스트만 바로 돌리면 됩니다.
4. 지속 효과 판단 (AI 부분 다시 확인)
이렇게 리스트를 나누면 AI 로직도 더 명확해집니다.
// EnemyAttackAI.cs 에서 타겟팅 시
private GameObject GetBestTradeTarget(...)
{
// "턴 종료 효과 리스트가 비어있지 않은 적" 중에서 위협적인 놈을 찾음
var priorityTarget = targets.FirstOrDefault(t =>
t.GetComponent<CardDisplay>().cardData.endOfTurnEffects.Count > 0 &&
t.GetComponent<CardDisplay>().cardData.threatLevel == ThreatLevel.High);
if (priorityTarget != null) return priorityTarget.gameObject;
// ...
}요약
- Card 스크립터블 오브젝트 안에 **battlecryEffects**와 endOfTurnEffects 리스트를 따로 만드세요.
- 카드를 낼 때는 battlecry 리스트를, 턴이 끝날 때는 endOfTurn 리스트만 돌리면 됩니다.
- 이렇게 분리하면 코드가 꼬일 일이 없고 하스스톤의 메커니즘을 거의 완벽하게 따라갈 수 있습니다.
- 복잡한 수치 대신 Enum 사용: GoodLastingAbility(남작 게돈 등 좋은 효과), BadLastingAbility(패널티 하수인)로 구분.
- 랜덤 타겟팅: 우선순위가 같은 타겟이 여러 개라면 그중 하나를 랜덤으로 선택.
- 일반 처리 병행: 지속 능력이 없더라도 나보다 공격력이 높거나 이득 교환이 가능하면 잡아야 함.
- 역발상: BadLastingAbility를 가진 적 하수인은 AI 입장에서 굳이 먼저 잡을 필요가 없음 (내버려 두는 게 이득).
TriggerEndOfTurnEffects(isPlayerTurn);는 이름 그대로 "턴이 끝날 때" 호출되는 함수입니다.
ToggleTurnButton()이 실행되자마자, 즉 **"턴 종료 버튼을 누른 직후"**에 가장 먼저 실행됩니다.
"턴 시작" 효과를 만들고 싶다면?
"턴 시작 시 발동(At the start of your turn)" 효과를 만들고 싶다면, isPlayerTurn = !isPlayerTurn; 이후에 호출해야 합니다.
자바와 C#의 아주 중요한 차이점을 짚어주셨습니다! 자바를 하셨다면 충분히 당황하실 수 있는 부분입니다. 결론부터 말씀드리면 C#은 클래스 바깥(네임스페이스 안)에 Enum이나 다른 클래스를 선언하는 것이 가능하고, 실제로 권장되는 방식입니다.
이해를 돕기 위해 차이점을 설명해 드릴게요.
1. 자바 vs C# 구조 비교
- 자바 (Java): 모든 것이 반드시 클래스 내부에 있어야 하거나, 별도의 .java 파일로 존재해야 합니다.
- C#: 하나의 파일(.cs) 안에 여러 개의 클래스, 여러 개의 Enum, 여러 개의 구조체를 클래스 바깥에 나열할 수 있습니다.
2. 왜 클래스 바깥에 두나요? (범위 문제)
Card.cs 파일이 다음과 같은 구조라고 가정해 봅시다.
방식 A: 클래스 바깥에 선언 (전역적 사용)
// Card.cs 파일
public enum LastingAbilityStatus { None, Good, Bad } // 클래스 밖!
public class Card : ScriptableObject {
public LastingAbilityStatus status;
}
// 다른 파일 (EnemyAttackAI.cs)에서 부를 때:
LastingAbilityStatus.Good; // 바로 사용 가능! (마치 자바의 별도 파일인 것 처럼)방식 B: 클래스 안쪽에 선언 (중첩된 타입)
// Card.cs 파일
public class Card : ScriptableObject {
public enum LastingAbilityStatus { None, Good, Bad } // 클래스 안!
public LastingAbilityStatus status;
}
// 다른 파일 (EnemyAttackAI.cs)에서 부를 때:
Card.LastingAbilityStatus.Good; // 반드시 Card.을 붙여야 함3. "이 스크립트는 클래스가 없나요?"
아닙니다! 클래스는 당연히 있습니다. 단지 파일 하나에 'Enum 정의'와 '클래스 정의'가 공존하는 것입니다.
C# 컴파일러는 이 파일을 읽을 때 다음과 같이 인식합니다:
- "오, LastingAbilityStatus라는 타입이 새로 생겼군." (전역 공간에 등록)
- "오, Card라는 클래스도 있군." (전역 공간에 등록)
요약하자면:
- 자바에서는 Enum을 별도의 .java 파일로 빼거나 클래스 안에 넣어야 하지만, C#은 관련 있는 Enum을 메인 클래스 파일의 상단(클래스 밖)에 선언하는 것이 일반적입니다.
- 이렇게 하면 다른 스크립트에서 Card.을 일일이 붙이지 않고도 LastingAbilityStatus를 바로 쓸 수 있어 코드가 훨씬 간결해집니다.
- 자바의 관점에서는 **"파일 이름은 Card.cs이지만, 그 안에 Enum 파일과 Class 파일이 합쳐져 있다"**고 생각하시면 이해가 빠르실 겁니다!
따라서 Card.cs 맨 위에 클래스 괄호 { } 바깥에 Enum을 두시면, 현재 발생한 에러(The name... does not exist)가 바로 해결됩니다.
남작 게돈처럼 **"턴 종료 시 모든 캐릭터에게 피해"**를 주는 하수인을 만들려면, 단순히 텍스트만 적는 게 아니라 실제 로직이 담긴 Effect 스크립트를 새로 작성해야 합니다.
나중에 효과가 수십 개가 되었을 때 "이 효과가 어떤 하수인 거였지?" 하고 찾는 것이 어려울 수 있습니다. 하수인 이름으로 스크립트를 관리하는 것도 아주 좋은 방법입니다.
스크립트 붙이는게 아니라, 생성할때부터 다르네
지금 상황은 "공격 기술(Method)"만 만드시고 "공격자(Object/Class)"를 아직 안 만드신 상태입니다.
두 번째 사진의 **남작 게돈(Baron Geddon Effect)**은 하수인이 아니라, 그 하수인이 사용하는 '능력(효과)' 데이터일 뿐입니다. 그래서 체력이나 공격력 칸이 없는 것이 정상입니다.
이걸로만은 부족함
그래픽 스크립트랑,
로직적인 스크립트랑 연결방법
"모든 효과가 끝날 때까지 기다리는 시퀀스(Sequence) 시스템"
손패의 카드들까지 불을 붙이네,
필드에 있는 얘들만 불붙이도록
이건 카드 클릭하면 확대되로고햇으니깐 그런거고
스크립트 컴포넌트가 꺼져 있는지 확인 (Component Enabled)
인스펙터 창에서 아래로 내려가 BaronGeddonGraphic (Script) 항목을 보세요.
- 문제: 스크립트 이름 바로 왼쪽에 있는 작은 체크박스가 꺼져 있으면, 물체는 살아있어도 그 안의 스크립트 파일만 "잠든 상태"가 됩니다.
- 해결: 이 체크박스를 체크(ON) 상태로 만드세요.
BaronGeddonEffect.cs 수정
애니메이션이 2초 동안 나오기 때문에, 턴 매니저에게 **"2초 동안 기다려!"**라고 알려줘야 턴이 중간에 끊기지 않습니다.
// BaronGeddonEffect.cs 의 Execute 함수 마지막 부분
public override IEnumerator Execute()
{
// ... 데미지 및 그래픽 생성 로직 ...
// [수정] 애니메이션이 2초 동안 나오므로 2초를 기다려줍니다.
yield return new WaitForSeconds(2.0f);
}음, 이렇게 하면 턴종료 많아져도 괜찮나
남작게돈 3개냈을때,
먼저 낸 남작게돈이 먼저 발동하는가
ㄴㄴ
1. 발동 순서: "먼저 낸 순서"가 아니라 "왼쪽부터"
현재 TurnManager의 코드는 필드(playerField)라는 부모 오브젝트의 자식들을 하나씩 검사하는 방식입니다.
- 유니티의 UI 구조상, 하수인이 필드에 배치된 **인덱스(시각적인 왼쪽 -> 오른쪽 순서)**대로 효과가 나갑니다.
- 따라서 먼저 낸 카드라도 오른쪽에 배치되어 있다면 나중에 발동하게 됩니다.
2. 중간에 죽으면 발동 안 하는 이유
이것은 현재 TriggerEndOfTurnEffectsCoroutine의 루프 방식 때문입니다.
- 실시간 검사: 루프가 돌아가면서 "지금 필드에 있는 하수인들 하나씩 나와서 효과 써!"라고 명령합니다.
- 파괴와 삭제: 첫 번째 게돈이 불을 뿜어서 두 번째 게돈의 체력이 0이 되면, TakeDamage 함수 내부의 Destroy(gameObject)가 실행되어 두 번째 게돈은 필드에서 즉시 사라집니다.
- 루프 건너뜀: 시스템이 다음 하수인을 찾으러 갔을 때, 두 번째 게돈은 이미 파괴되어 리스트에 없으므로 효과를 발동할 기회조차 얻지 못하고 넘어가게 됩니다.
'개발 > 하스스톤+전장' 카테고리의 다른 글
| 하스+전장) 도발,죽음의 메아리 추가 (1) | 2026.02.25 |
|---|---|
| 하스+전장)26.02.15 (0) | 2026.02.15 |
| 유니티에서 대상 찾을때 (1) | 2026.02.12 |
| 하스+전장) 26.02.12 (0) | 2026.02.12 |
| 하스+전장) 하수인 공격하면 돌격하도록/영웅 피0이하 게임 승리/소리추가 (0) | 2026.01.28 |