YAGNI vs 확장성 설계 — 영원한 밸런스 싸움에 대한 고찰GameFlow FSM을 완성해가는 과정에서 자연스럽게 떠오른 근본적인 의문을 정리한 문서. "지금 만들지 않은 것이, 나중에 만들기 너무 어려워지지는 않을까?"라는 질문에서 시작해, 실전에서 쓸 수 있는 판단 기준까지 정리했다.1. 고민이 시작된 지점GameFlow FSM을 설계하면서, 여러 차례 "지금은 필요 없다"는 결론을 내렸다.LobbyLevel에 EKCLobbyPhaseType 같은 전용 하위 FSM을 만들지 않기로 함 (아직 로비 안에서 규칙이 질적으로 갈리는 지점이 확정되지 않았기 때문)재료 덮개(Preparing/Active)를 별도 State가 아니라 단순 Guard 조건(bIsFarmingOpen)으로 처리하기로 함이 결정..
왜 헷갈리나"레벨 = 맵"이라는 감이 틀린 건 아니지만, 언리얼 내부적으로 Level과 World는 계층이 다른 개념이다. 대부분의 소규모 프로젝트에서는 이 둘이 사실상 1:1로 겹쳐 보여서 구분 없이 써도 문제가 없었을 뿐이다.Level (ULevel) — 맵 데이터 한 뭉치하나의 .umap 파일에 대응하는 액터 데이터 덩어리.배치된 건물, 지형, 조명, 트리거 등 액터들이 들어있는 "내용물" 그 자체.Level 자체는 "지금 실행 중인지, 네트워크에 연결되어 있는지"를 모른다. 그냥 정적인 데이터 뭉치.World (UWorld) — 지금 실행 중인 게임 세션 그 자체지금 이 순간 메모리에 로드되어 실제로 굴러가고 있는 게임 인스턴스.World 안에는 정확히 하나의 Persistent Level + (..
GasRange Logout/PostLogin 설계 — 아키텍처, 판단 근거, 문제 해결, 테스트 기록배경 — 왜 필요했는가GameFlow 빈틈 점검 과정에서, 전투 레벨(AKCGameMode)에 Logout/PostLogin 오버라이드가 전혀 없다는 것을 발견했다. 이로 인해 Playing 상태 도중 플레이어가 이탈해도 GameSystem이 그 사실을 전혀 인지하지 못하는 상태였다. 회의 전 협의를 통해 "인원 부족 시에도 계속 진행"이라는 정책을 확정했고, 추가로 "이탈한 자리는 비워뒀다가 재접속 시 복귀 가능하게 한다"는 요구사항이 정해졌다.아키텍처 — 어떤 구조를 썼는가이미 존재하던 인프라 재사용4번(로비/세션 담당)이 이미 로비→전투 레벨 전환 시 PlayerState 유실을 막기 위해 UKCS..
GameFlow 설계 최종본 및 판단 근거EKCLevelType(최상위) + EKCGamePhaseType(GasRange 하위)로 구성된 계층적 FSM. 오늘 고민했던 순서 그대로, 왜 이 구조에 도달했는지 근거를 남긴다.최종 구조 요약[최상위, 전역] EKCLevelTypeSplashScreen → MainMenu → LoadInLevel(세션생성) → LobbyLevel → Loading → GasRange ↑___________________________설정변경____| | ↓ Ending 종료 ..
KCLevelTransitionSubsystem — 설계, 구현, 검증 완료 기록레벨 전환 시점을 감지해서 GMS로 방송하는 Subsystem. 오늘 처음 만든 Subsystem이며, 전체 판단 과정과 트러블슈팅을 기록한다.1. 왜 필요했는가GameFlow를 검증하는 과정에서, 다음이 코드로 확인됨:KCLoadingViewModel::SetProgress(), KCResultViewModel::SetTeams() 등 "데이터를 채우는 함수"는 이미 존재그러나 그 함수를 "언제" 호출해야 하는지 결정하는 메커니즘, 즉 레벨 전환을 감지하는 코드가 프로젝트 전체에 0곳검증 방법: grep으로 PostLoadMapWithWorld, PreLoadMap 등 레벨 로드 감지 델리게이트 등록 코드, 레벨 전환 관련..
로딩화면 + 에셋 프리로드 시스템 기술 문서범위: Lobby → GasRange 진입 시 에셋 프리로드 및 로딩화면 표시관련 클래스: UKCLoadingScreenSubsystem, UKCLoadingViewModel, UKCLoadingTipDataAsset, UKCAssetManager1. 개요Lobby에서 GasRange로 트래블할 때, 목표 레벨에서 사용할 Item 에셋들을 미리 메모리에 올려두고 그 진행 상황을 로딩화면으로 표시하는 시스템입니다. 레벨 스트리밍과 에셋 프리로드가 병렬로 진행되며, 둘 다 완료된 시점에만 로딩화면이 사라집니다.2. 아키텍처2.1 구성 요소클래스역할UKCLoadingScreenSubsystem프리로드 트리거, 진행 상태 판정, 위젯 표시/제거를 총괄하는 GameIns..
[설계 결정 기록] 왜 UKCLoadingScreenSubsystem인가대상: Lobby → GasRange 진입 시 재료 에셋 프리로드 + 로딩화면 표시결론: 새 UGameInstanceSubsystem(UKCLoadingScreenSubsystem)을 만들어서, 기존에 있던 4개 클래스(KCAssetManager, KCLevelTransitionSubsystem, KCLocalPlayerUISubsystem, KCLobbyPlayerController)를 조율만 하고 자체 로직은 최소화한다.이 문서는 그 결론에 도달하기까지 뒤집힌 전제들과 검증 과정을 순서대로 기록한다. 결론보다 과정이 중요한 이유: 다음에 비슷한 설계 판단을 할 때, 여기서 썼던 검증 방식(기존 코드 재확인 → 전제 재검토 → 외부..
증상Lobby → GasRange 진입 시:호스트(리슨서버): 로딩화면 정상 표시/제거, 인게임 HUD 정상 표시원격 클라이언트: 로딩화면은 정상 표시/제거되지만, 인게임 HUD가 전혀표시되지 않음게임 진행(캐릭터 조작 등) 자체는 클라이언트에서도 정상 작동영상 보기https://github.com/user-attachments/assets/3f7fd323-dba4-447b-902b-be1eea5166d7원인 규명1. 로그와 실제 상태의 불일치 확인SetHUDWidget()이 성공 로그(AddedToScreen=true)를 남기는데도 WidgetReflector로 확인하면 실제 화면 트리에 위젯이 없었습니다. 로그만으로판단하지 않고 Widget Reflector로 직접 확인하면서 원인 조사 방향을잡았습니..
