10.16 - TIL

오늘의 코드카타

• 가장 큰 수
  • 정수를 이어 붙여 만들 수 있는 가장 큰 수 찾기 (사전순 아님)
  • 비교할 때, 문자열을 앞뒤로 붙여서 비교하기
  • https://school.programmers.co.kr/learn/courses/30/lessons/42746
• 소수 찾기
  • 만들 수 있는 문자열 완전 탐색 : dfs 활용
  • 소수인지 검사하기
  • https://school.programmers.co.kr/learn/courses/30/lessons/42839
• 쿼드압축 후 개수 세기
  • 분할 탐색 : 2차원 배열을 4등분해서 검사
  • https://school.programmers.co.kr/learn/courses/30/lessons/68936
    
    

오늘의 공부

팀 프로젝트 KPT 회고

Keep - 현재 만족하고 있는 부분

• 처음부터 끝까지 온전한 게임을 제작하게 되어 좋았고 협업의 과정을 겪어볼 수 있어서 성장 체감을 느꼈다.
• 멀티플레이 프로젝트는 어떻게 개발해야 하는지, 어떤 문제가 있는지 공부할 수 있어서 좋았다.
• 게임의 완성도가 전체적으로 높았던 것 같고 기획이 좋았던 것 같다.
• GAS같은 고급 프레임워크를 배우고 적용할 기회를 얻어서 좋았다.
• EOS 보이스챗과 같은 외부 플러그인을 사용하여 더 몰입도 있는 게임을 만들 수 있었다.

Problem - 불편하게 느끼는 부분

• #ifdef 같은 전처리기를 사용해서 log 출력을 특정 모드에서만 실행되도록 하면 더 좋았을 것 같다.
• 마일스톤 단위로 나눠서 진행하고 회고로 마무리 하는 방법도 좋은 거 같다
• 원래는 코드 정리도 계획에 들어있었는데 코드 정리를 하지 못해 아쉽다.
• 폴더 정리가 이상하게 되어서 관리가 힘들었다. 특히 에셋을 찾기가 너무 힘들었다.
• 노션을 통해 WBS를 정리하고 일정관리를 하고자 했으나, 가시성이 너무 떨어지는 것 같고 많은 사람이 같이 쓰니까 지저분해졌다.

Try - Problem에 대한 해결책, 당장 실행 가능한 것

• 프로젝트 접두어를 EG_ 이런식으로 붙이고, 에셋은 붙이지 말자
• GameMode_MainMenu, GameMode_Lobby 이런 식으로 네임 컨벤션을 명확하게 정해서 수정하자
• 폴더관리 무조건 컨텐츠 > 프로젝트 폴더 내에서 관리하자
• 개인적으로 WBS를 쓰고, 팀 전체적으로 마일스톤 관리하자
• ServerRPC_FunctionName, ClientRPC_FunctionName : RPC에 대한 네이밍을 명확히 하자
• 플러그인을 조심해서 쓰자
  
  

오늘의 CS

• 언리얼 엔진의 핵심적인 Gameplay Framework의 역할에 대해...
• https://velog.io/@uji06134/Gameplay-Framework

GameMode

• 게임 규칙을 정의하는 클래스
• 역할
  • 게임의 시작 및 종료 조건 : 승패 조건, 점수 계산 방식 등
  • 스폰 관리 : 어떤 Pawn을 사용할지, 어디에 스폰할지
  • 클래스 정의 : PlayerController, Pawn, GameState, PlayerState 등의 기본 클래스를 지정함
• 특징
  • 서버에서만 존재하며 동작함
  • 한 레벨당 하나만 존재함

GameModeBase vs GameMode

• GameModeBase
  • 가장 기본적인 게임 진행 관리 기능만 제공
  • 캐주얼 게임, 퍼즐 게임, RPG 등 매치 로직이 명확하지 않거나 단순한 게임에서 활용
• GameMode
  • GameModeBase를 상속한 확장형 클래스로 더 다양한 기능을 제공
  • 클래식한 FPS/TPS 규칙 (팀전, 스코어, 시간, 승리 조건 등) 지원
  • 경쟁 기반 게임 (FPS, 배틀로얄 등) 에서 활용
    
    

GameState

• 현재 게임의 상태(점수/시간, 팀 정보, 게임 진행 상황 등)를 기록하고 공유하는 클래스
• 역할
  • 게임의 전역 상태 정보 제공 : 현재 라운드 번호, 경기 시간, 맵 이름 등 게임 전체가 공유해야 하는 정보를 저장함
• 특징
  • 서버와 모든 클라이언트에게 복제됨 -> 공개적인 정보만 저장
  • UI에서 읽기 전용으로 접근하거나 참조만 가능하게 해야 함
  • GameMode만 수정할 수 있게 보안이 중요

PlayerController

• 플레이어의 입력과 상태를 제어하는 클래스 -> "플레이어의 뇌"
• 역할
  • 입력 처리 : 키보드, 마우스, 게임 패드 등 사용자의 입력을 받음
  • Pawn 조종 : 입력에 따라 연결된 Pawn을 조종하는 명령을 내림
  • 플레이어 상태 제어 : 카메라 설정, UI, 인벤토리 등 플레이어 개개인에게만 필요한 제어 로직을 담음
• 특징
  • 플레이어당 하나씩 존재함 -> 각자의 클라이언트에서 각자의 Pawn 제어
  • 서버와 해당 플레이어의 클라이언트에 존재
    -> 클라이언트에서 다른 플레이어의 컨트롤러는 존재하지 않음

Pawn

• 게임 세계에 존재하는 물리적 개체인 클래스 -> "플레이어의 육체"
• 역할
  • 물리적 표현 : 캐릭터 모델, 콜리전, 움직임 등을 담당함
  • 조종 가능 : PlayerController 또는 AIController에 의해 빙의되어 조종될 수 있음
• 특징
  • 서버와 모든 클라이언트에 복제되어 존재
  • ACharacter는 APawn을 상속받아 인간형 캐릭터에 특화된 기능을 추가한 클래스임

PlayerState

• 각 플레이어의 개별 정보 (점수, 킬/데스 등) 을 저장하는 클래스
• 역할
  • 개인 상태 정보 저장 : 현재 점수, 레벨, 킬/데스 수 등 특정 플레이어에게 종속된 정보를 저장
• 특징
  • 서버와 모든 클라이언트에 복제되어 존재
  • 모든 플레이어가 다른 플레이어의 정보를 볼 수 있게 해줌
    -> 다른 플레이어에게 보여줄 정보만 관리를 해야 함