think95592 님의 블로그

오늘의 학습 목표오늘은 언리얼 엔진 멀티플레이의 핵심 개념인 다음 내용을 학습했다.Authority와 Proxy를 구분하는 NetRoleServer, Client, NetMulticast RPC액터의 Ownership과 Owning ConnectionRPC와 Ownership의 관계멀티플레이 채팅 메시지의 전달 과정1. NetRole이란?멀티플레이에서는 하나의 액터가 서버와 여러 클라이언트에 각각 존재할 수 있다.하지만 각 컴퓨터에 존재하는 액터가 모두 같은 권한을 갖는 것은 아니다. NetRole은 현재 실행 환경에서 해당 액터가 어떤 역할을 수행하는지 나타낸다.ENetRole LocalRole = GetLocalRole();ENetRole RemoteRole = GetRemoteRole();주요 역할..

오늘의 학습 목표오늘은 언리얼 엔진의 멀티플레이 구조를 이해하기 위해 다음 개념을 학습했다.서버의 역할과 종류Listen Server와 Dedicated Server의 차이현재 게임 인스턴스의 역할을 나타내는 NetMode네트워크 통신을 관리하는 NetDriver서버와 클라이언트의 연결을 표현하는 NetConnection1. 언리얼 엔진의 서버 권한 구조언리얼 엔진의 멀티플레이는 기본적으로 **서버 권한형 구조(Server Authority)**를 사용한다.클라이언트가 이동이나 공격 같은 행동을 요청하더라도 최종 게임 상태는 서버가 결정한다. 서버에서 확정된 결과는 Replication을 통해 다른 클라이언트에 전달된다.예를 들어 플레이어가 적을 공격한다면 다음과 같은 흐름으로 처리할 수 있다.클라이언트..

최근 스팀에서는 대규모 자본을 투입한 게임이 아니어도 친구들과 함께 즐길 수 있는 소규모 멀티플레이 게임이 크게 흥행하고 있다.대표적인 게임이 R.E.P.O., PEAK, 멧챠 카멜레온이다. 조금 오래된 작품까지 범위를 넓히면 Pummel Party 역시 현재 파티게임의 흥행 공식을 일찍 보여준 사례다.이 게임들은 공포, 등반, 숨바꼭질, 미니게임처럼 장르가 서로 다르다. 그런데 플레이 구조를 살펴보면 놀라울 정도로 비슷한 성공 공식을 가지고 있다.핵심은 단순히 ‘친구와 할 수 있는 게임’이 아니다.친구들과 노는 과정이 하나의 이야기가 되고, 실수와 실패가 방송이나 숏폼 콘텐츠로 자연스럽게 만들어지는 게임이 잘되고 있다.요즘 스팀에서 협동게임이 잘되는 이유최근 유행하는 협동게임을 업계와 이용자들은 종종 ..

1. 프로젝트 및 담당 기능 소개프로젝트 소개이 프로젝트에서 거점은 플레이어가 탐색을 준비하고, 획득한 자원을 정리하는 중심 공간입니다.플레이어는 거점에서 퀘스트를 확인하고 아이템을 거래·보관·제작한 뒤 다음 탐색 지역을 선택할 수 있습니다.담당한 기능거점 컴퓨터와 전용 UI퀘스트 시스템상점 및 중고거래제작 시스템창고 시스템레벨 선택 및 이동거점 UI의 MVVM 구조거점 진행 상태 저장 및 복원사용 기술Unreal Engine 5C++BlueprintDataTable 및 Data AssetMVVMGameInstance SubsystemGameplay MessageSaveGame2. 거점의 전체 플레이 흐름거점의 개별 기능을 따로 제공하는 것보다, 탐색 전후의 흐름이 자연스럽게 연결되는 것을 목표로 했습니..

퀘스트 시스템을 처음 구현했을 때는 퀘스트 완료 조건과 아이템 보상 정도만 있으면 충분하다고 생각했다.하지만 실제 퀘스트 데이터를 만들기 시작하자 필요한 정보가 계속 늘어났다.아이템이 아닌 화폐 보상퀘스트별 이벤트 조건여러 줄로 표시되는 목표 문구상점 아이템 해금다음 퀘스트 연결메인 HUD에 표시할 진행 정보이번 작업에서는 단순했던 퀘스트 구조체를 확장하고, 퀘스트 완료부터 보상 지급과 UI 갱신까지 하나의 흐름으로 정리했다.1. 아이템 보상과 화폐 보상을 분리한 이유기존에는 퀘스트 보상을 모두 RewardItems 배열에 넣는 방향으로 생각했다.UPROPERTY(EditAnywhere, BlueprintReadOnly)TArray RewardItems;ProjectFT에서는 화폐도 인벤토리에 들어가는 ..

ProjectFT의 허브 터미널에는 플레이어가 퀘스트를 확인하고 수락하거나 완료할 수 있는 퀘스트 UI가 있다.초기 퀘스트 UI는 일반적인 게임의 퀘스트 목록처럼 구성했다.왼쪽: 퀘스트 목록오른쪽: 퀘스트 상세 정보하단: 수락 버튼과 완료 버튼기능적으로는 문제가 없었지만, 허브 터미널이 컴퓨터 형태의 UI로 바뀌면서 기존 퀘스트 목록이 전체 디자인과 어울리지 않았다.또한 퀘스트를 “NPC에게 직접 받는 임무”가 아니라 “터미널로 전달받은 의뢰”처럼 표현하고 싶었다.그래서 퀘스트 UI를 메일 클라이언트와 비슷한 구조로 변경했다.메일 목록= 퀘스트 목록보낸 사람= 퀘스트 의뢰인메일 제목= 퀘스트 이름메일 본문= 퀘스트 설명과 목표첨부 정보= 필요 아이템과 보상메일 액션= 수락 또는 완료이번 글에서는 퀘스트 ..

게임의 기능이 늘어나면 서로 다른 시스템이 같은 사건에 반응해야 하는 경우가 많아진다.예를 들어 플레이어가 아이템을 획득했을 때 다음 시스템들이 반응할 수 있다.InventoryComponent는 아이템을 추가한다.퀘스트 시스템은 목표 진행도를 확인한다.HUD는 인벤토리나 퀘스트 표시를 갱신한다.사운드 시스템은 획득 효과음을 재생한다.튜토리얼 시스템은 안내 단계를 진행한다.저장 시스템은 변경된 상태를 기록할 수 있다.이 기능들을 직접 참조로 연결하면 Item Actor가 여러 시스템을 알아야 한다.Item Actor├─ InventoryComponent├─ ObjectiveSubsystem├─ HUD Widget├─ SoundManager├─ TutorialSubsystem└─ SaveSubsystemP..

ProjectFT의 퀘스트에는 여러 종류의 목표가 존재한다.특정 아이템 획득아이템 사용제작 완료상점 구매 및 판매매대 훼손 또는 파괴절도 완료NPC에게 발각보안요원 호출레이드 진입레이드 탈출초기에는 퀘스트 진행도를 UI가 직접 확인하거나, 일정 시간마다 현재 상태를 검사하는 방식을 고려했다.하지만 퀘스트 종류가 늘어나면서 이런 방식은 시스템 간 의존성을 크게 만들었다.이번 작업에서는 UGameplayMessageSubsystem과 UFTObjectiveSubsystem을 중심으로 게임에서 발생한 사건을 메시지로 전달하고, 활성 퀘스트와 일치하는 조건만 갱신하는 이벤트 기반 구조를 만들었다.현재 구조에서는 아이템 목표와 이벤트 목표를 서로 다르게 관리한다.아이템 목표= 현재 플레이어와 창고의 실제 보유 수..

ProjectFT의 허브에는 여러 경제 시스템이 존재한다.상점에서 아이템 구매 및 판매중고거래 게시글 거래작업대에서 아이템 제작퀘스트 완료를 위한 아이템 제출화폐 소비와 보상 지급처음에는 각 시스템이 플레이어 인벤토리만 확인했다. 이 구조에서는 필요한 재료를 창고에 보관하고 있더라도 제작이나 퀘스트를 진행할 수 없었다.플레이어 인벤토리: 물 1개창고 인벤토리: 물 4개필요 수량: 물 5개기존 결과: 재료 부족실제 총수량: 물 5개플레이어는 필요한 아이템을 이미 가지고 있지만, 시스템이 창고를 확인하지 않기 때문에 매번 창고 UI를 열고 아이템을 꺼내야 했다.이를 개선하기 위해 허브 경제 시스템의 공통 규칙을 다음과 같이 정리했다.비용과 재료 검사= 플레이어 인벤토리 + 창고 인벤토리비용과 재료 소비= 플..

프로젝트의 허브에는 플레이어가 아이템을 사고팔 수 있는 중고거래 시스템이 있다.처음에는 거래 게시글마다 제목, 설명, 아이템, 수량, 가격을 직접 작성하는 방식을 사용했다. 게시글 수가 적을 때는 문제가 없었지만, 아이템 종류가 늘어나면서 같은 작업을 반복해야 했다.또한 매번 동일한 게시글만 표시되기 때문에 중고거래 시스템이 정적인 상점 목록처럼 보이는 문제도 있었다.이번 작업에서는 아이템마다 게시글을 직접 작성하는 대신 다음 데이터를 조합해 거래 게시글을 자동 생성하도록 구조를 변경했다.Prefix+ 아이템 이름+ 거래 이유+ Ending+ 아이템 가격+ 랜덤 수량게시글 생성 규칙과 문구는 UFTShopDataAsset에서 설정하고, 실제 런타임 게시글 생성과 거래 처리는 UFTShopSubsystem..