StrikForge 10일차 - 오늘 한 일

넥서스 관리 구조 재확인

SFGameMode와 SFGameState 사이의 넥서스 전달 구조를 다시 확인했다.

SFGameMode가 넥서스 생성
→ RegisterNexus()로 SFGameState에 전달
→ SFGameState가 TeamIndex 기준으로 포인터 저장
→ 다른 시스템이 GetNexus()로 조회

GetNexus()는 넥서스를 직접 생성하거나 검색하는 함수가 아니라, 이미 RegisterNexus()로 저장된 넥서스 포인터를 반환하는 Getter라는 점을 정리했다.

하위 건물 티어 제한 여부 확인

현재 코드를 확인한 결과, 넥서스 포인터를 저장하고 조회하는 기능까지만 구현되어 있으며 하위 건물의 업그레이드를 제한하는 기능은 아직 연결되지 않은 것을 확인했다.

현재 완료된 부분:

• 넥서스 전용 생성
• 팀별 넥서스 포인터 등록
• 팀 번호를 이용한 넥서스 조회
• 넥서스 포인터 제거 함수 준비

아직 필요한 부분:

• 넥서스 현재 티어 Getter
• SFGameState::GetNexusTierLevel()
• SFGameState::CanUpgradeBuildingTier()
• SFBaseBuilding::UpgradeBuilding()에서 제한 함수 호출

티어 인덱스 기준 확인

현재 건물 코드는 배열 인덱스 기준으로 티어를 관리한다.

CurrentTier 0 = 게임상 1티어
CurrentTier 1 = 게임상 2티어
CurrentTier 2 = 게임상 3티어

반면 UI와 RequiredTier는 1부터 시작하는 게임 티어를 사용한다.

따라서 내부 인덱스와 게임 티어를 그대로 비교하면 넥서스가 1티어인 상태에서 1티어 하위 건물의 최초 건설까지 막힐 수 있다는 문제를 발견했다.

최초 건설과 업그레이드 규칙 정리

건물의 최초 건설과 기존 건물의 업그레이드를 구분해 검사해야 한다.

최초 건설

건물 RequiredTier
<=
Nexus 게임 티어

예시:

Nexus 1티어
+ RequiredTier 1 건물
= 건설 가능

하위 건물 업그레이드

하위 건물의 다음 게임 티어
<=
Nexus 게임 티어

예시:

Nexus 1티어
+ 하위 건물을 1티어에서 2티어로 업그레이드
= 업그레이드 불가능

Nexus 2티어
+ 하위 건물을 1티어에서 2티어로 업그레이드
= 업그레이드 가능

티어 기준 결정

혼동을 방지하기 위해 다음 기준으로 관리하기로 정리했다.

배열 접근 및 내부 데이터
= 0부터 시작하는 TierIndex

게임 규칙, UI 표시, RequiredTier 비교
= 1부터 시작하는 TierLevel

게임 티어를 얻을 때는 다음 변환이 필요하다.

TierLevel = TierIndex + 1;

향후 작업

1. 건물 담당자에게 현재 티어 Getter 요청
2. SFGameState에 넥서스 게임 티어 조회 함수 추가
3. 최초 건설 가능 여부 검사 함수 추가
4. 하위 건물 업그레이드 가능 여부 검사 함수 추가
5. 넥서스 자체 업그레이드는 하위 건물 제한 대상에서 제외
6. 건물 생성 및 업그레이드 코드에서 GameState 검사 함수 호출
7. 넥서스 1·2·3티어별 하위 건물 건설 및 업그레이드 테스트

오늘은 넥서스 포인터 관리 구조를 재확인하고, 핵심 건물 티어보다 하위 건물이 먼저 올라가지 않도록 하기 위한 제한 규칙과 티어 인덱스 변환 기준을 정리했다.