Muji

구현 목적AchievementComponent가 Report를 받으려면 모든 컴포넌트가 직접 Report해야 하거나, AchievementComponent가 각 컴포넌트의 Delegate를 개별적으로 등록해야 했다. 이 방식은 결합도가 높고 확장 시 수정 범위가 커진다. 이를 해결하기 위해 메시지 시스템을 도입해 클래스 간 직접 의존을 제거했다.자료 조사 결과 언리얼 엔진에도 GameplayTag 기반의 메시지 시스템이 라이라 프로젝트에 있는 것을 확인했다. 기본 기능이 아니기도 했고 구현한 경험도 있었기 때문에 간단한 메시지 시스템은 Subscribe-Publish 구조로 충분하다고 판단해 구현했다.요구 사항GameplayTag를 이용해서 Tag 기반의 BroadcastEvent에 따른 구조체를 Bro..

작업 목적업적 시스템을 구현하기 위해 업적 데이터와 판정 구조가 필요했다.이전 프로젝트에서는 Requirement, Condition으로 현재 상태가 모든 조건을 만족하는지 검사했다. 반면 이번 프로젝트에서는 공격 횟수나 피격 횟수처럼 현재 상태뿐만 아니라 과거 이벤트의 발생 이력과 누적 진행도까지 함께 고려해야 했다.이러한 요구를 반영하기 위해 업적 정의, 처리 규칙, 진행 상태를 분리하여 다양한 업적 조건을 유연하게 처리할 수 있는 구조를 목표로 했다.요구 사항특정 조건을 만족하면 업적이 해금되어야 한다.업적은 특정 페이즈 또는 특정 맵에 한해 판정 가능해야 한다.일부 업적은 특정 페이즈 구간 동안 조건을 지속적으로 만족한 상태를 유지하거나 위반 이벤트가 없어야 해금된다.일부 업적은 즉시 해금되지 않..

요약업적 달성 조건의 판단은 게임 로직에서 수행하고 AchievementSubsystem 그 결과를 플랫폼 상태로 동기화하는 책임만 담당하도록 설계햇다. 이를 통해서 게임 규칙과 플랫폼 연동을 분리해 경계의 응집성을 높였고, Steam 의존 구현을 Subsystem 내부에 캡슐화하였다. 현재는 Steam 기준 구현이지만 이후 다른 플랫폼으로 확장 시 Subsystem 내부로 제한할 수 있도록 설계했다. 이번 작업에서는 다음을 구현했다.초기화 시 업적 Query비동기 Write 직렬화업적 설정구현 목적업적 로직을 게임 코드 전반에 두지 않고 수명 주기와 책임이 명확한 단일 시스템으로 관리하는 것이 목적이다.설계GameInstanceSubsystem 채택: 업적은 플레이 세션 전체에서 공통으로 접근되므로 게..

업적 시스템을 구현 중에 Phase에 반응하는 업적이 있어서 Phase 코드를 확인했다. 확인 결과 Phase의 진행 관련 로직이 GameMode, GameState, DroneSeller에 분산되어 있어 책임이 명확하지 않은 상태였다.이에 Phase 관련 로직의 책임을 재정리하고 구조를 개선하기 위해 리팩토링을 진행했다.문제점DorneSeller Class가 Game Rule을 담당하고 있다. Drone Seller가 Monster Spawn, Destination 설정, Phase BGM 재생의 로직을 담당하고 있었다.Phase 관련 로직이 여러 클래스에 분산되어 있다. 처음 Phase BGM 재생은 GameMode, 처음 Phase Monster Spawn은 DroneSeller가 담당하는 등 동일..

모듈기능 별로 파일로 나누는 것을 모듈이라고 한다. 기능 별로 나누어서 유지 보수성을 높히고 응집성을 향상할 수 있으며 구조적으로 분리를 할 수 있다.모듈 이용하기import를 통해서 사용파일 이름을 .py가 없는 것이 모듈의 이름모듈 자체적으로 비공개 네임스페이스를 이용하므로 이름 충돌이 발생하지 않는다.# fibo.pydef fib(n):....def fib2(n):...# other.py# 네임스페이스에 모듈만 추가import fibofibo.fib(100)# 네임스페이스에 직접 함수 추가from fibo import fib, fib2fib(100)# 모든 이름 추가from fibo import *# 다름 이름으로 모듈 추가import fibo as fibfib.fib(50)# 함수를 다른 이름으로..

개요Stove의 심의를 받기 위해서 Stove 빌드를 생성할 필요가 있었다. Stove 빌드를 위해서는 Stove SDK를 연동해야 할 필요가 있다. Steam을 이용하지 않으므로 다른 매치메이킹 방식을 사용해야 했고 이에 따라서 EOS를 사용하기로 결정했다.Stove 연동Stove SDK는 Stove의 다양한 기능을 통해서 Stove에 출시할려는 게임을 위한 SDK이다. 2.0과 3.0 버전이 존재하며 2.0 버전의 경우 플러그인 형식으로 구현이 되어 있고 3.0의 경우는 써드 파티로 구현이 되어 있다. 써드 파티의 경우 플러그인과 외부 라이브러리를 빌드에 포함시키는 방법이라고 한다.사전 준비스토브 빌드를 태스트하기 위해서는 Stove Studio에서 그룹을 신청하고 제품을 등록해야 한다. 다음 사진의..

버그 현상관전 모드 시에 Laser Beam이 보이지 않는 오류문제 원인Laser Beam이 발생하는 위치Abyss Diver 캐릭터는 3인칭 메시와 1인칭 메시를 나누어 가지고 있고 각 클라이언트에 따라서 메시를 출려갛는 구조이다. Anim Notify 시점에 따라서 클라이언트에서 해당되는 메시를 찾고 해당 메시에 이펙트를 생성하는 구조이다.문제 해결1인칭 메시 판별 여부1인칭 메시를 판단하기 위해 IsLocallyControlled를 이용해서 판단하고 있는데 관전 모드의 경우 Possess는 하지 않아서 판단이 불가능하다. Possess 상태는 아니지만 ViewTarget을 통해서 판단하므로 IsLocallyViewed를 통해서 해결할 수 있다.bool UAnimNotifyState_LaserBeam..

문제점 및 원인 분석관전할 때 Spontaneous Actor가 보이지 않는 오류가 발생항상 안 보이는 것은 아니고 잠깐 보였다가 안 보이는 현상이 발생항상 안 보이는 것이 아니므로 네트워크 문제로 판단했음물체의 가시성을 확인하는 것은 연관성(Relevancy)이므로 연관성을 확인하기로 결정로그 분석LogAbyssDiverCharacter: Display: IsNetRelevantFor: BP_UnderwaterCharacter_C_0 / RealViewer: BP_ADPlayerController_C_1 / ViewTarget: BP_UnderwaterCharacter_C_0 / SrcLocation: X=0.000 Y=0.000 Z=0.000 / bIsNetRelevant: TrueLogAbyssDi..

관전 진입 시에 기존 Player UI가 남아 있는 현상이 있었다. 관전 시에는 풀스크린 이펙트와 같은 Player HUD를 비활성화를 해야 한다. UnPossess 상황에서의 Visibility Update는 OnPossessedPawnChanged를 이용하기로 생각하고 있었다.우선은 로그를 확인하기로 했다.OnPossessedPawnChanged 로그[Host]LogAbyssDiverCharacter: Display: [Server] InitFromPlayerState/ NickName : KKSOO-HOME-BF980E894 / PlayerIndex : 0LogAbyssDiverCharacter: Display: [SERVER] AUnderwaterCharacter::OnPhysicsVolumeCh..

관전 기능언리얼 엔진은 관전 기능을 기본적으로 지원한다. 관전 기능에 사용되는 Spectator Pawn 클래스는 Game Mode에서 구현이 되어 있다. 관전 기능을 실행할 때는 Player Controller에서 시작한다. Game Mode가 아니라 Player Controller에서 시작되는 이유는 관전 모드가 Local에서만 동작하기 때문이다.Spectator State 시작Spectator를 시작하는 함수는 StartSpectatorOnly 함수를 참고하면 된다. StartSpectatorOnly 함수는 현재 Player Controller를 관전만 하도록 허용하는 함수이다.void APlayerController::StartSpectatingOnly(){ ChangeState(NAME_S..