NBC 챕터 2주 - 26.05.21 ~ 26.05.29 회고록

프로젝트 종료 회고록

1. 프로젝트 개요

• 프로젝트명: 감자가 생각났어요
• 진행 기간: 26.05.21 ~ 26.05.29
• 팀 인원: 서아영 송용수 장고은 오진민 한수현 현경훈

---

2. 프로젝트 목표

목표

• 용수: 코드 베이스가 없는 상황에서 동시 개발을 위해 명확한 분업을 해보자. P2P 프로그래밍을 해보자.
• 진민: Git 사용 익히기. 협업 경험. 코드 뜯어보면서 이해해보기. 경험 쌓기
• 경훈: Git 협업 경험 , Packet 통신 개발 경험
• 고은: 팀프로젝트로 필수/도전 과제 다 진행해보기
• 수현: Git 협업 경험 및 팀 프로젝트 경험 쌓기, 멀티플레이 코드 사용해보기

주요 기능

서아영

• 레벨업 기능
• 골드 전송 기능

송용수

• 렌더러, 컨트롤러, 게임매니저, IGameState 기반 뼈대 구조
• 레이드 기능 추가

장고은

• 아이템 및 인벤토리
• 상점
• 아이템 거래 시스템 (멀티)

오진민

• 플레이어 캐릭터 생성, 팀원들이 개발한 클래스들 연결하기

한수현

• 플레이어와 몬스터 간의 배틀 시스템 구현
• 멀티플레이 아레나의 플레이어 간의 배틀 시스템 구현
• 아이템 조합 및 강화
• 이미지 컬러 출력

현경훈

• 몬스터 기본 클래스 작성
• 보스 몬스터 클래스 작성
• 아레나 멀티 콘텐츠 코드 구조 설계
• 아레나 패킷 구조체 / 패킷 함수 구현

사용 기술 스택

• Engine: visual studio 2022
• Language: C++
• Version Control: Github

---

3. 프로젝트 결과

미완료 또는 축소된 사항

서아영

• 골드 쓰이는 곳 더 늘리고 싶었는데 시간 별로 안 남아서 그만둠
  • 돈 써서 공격력 강화 ←이거 괜찮아 보였는데 레이드 밸패 끝난 참이라 애매해서 뺌

송용수

• 사운드 넣기: 과해보여서 뺌
• 과제 요구사항을 P2P 구조로 리팩토링: 시간도 시간인데 걍 채점하기 편하게 남기는게 운영진한테도 좋을 것 같아서 살려두었다.

장고은

• 강화 무기 거래 불가능: 조합 전 아이템만 거래가 가능하고, 강화하거나 조합한 아이템은 거래가 불가능하다.

오진민

• UI에 출력 시 칸을 넘어가면 칸으로 지정해놓은 string이 깨지는 현상을 고치지 못함.

한수현

• 디버깅 할 때 편하게 하고 싶어서 치트 넣어보려다가 너무 늦게 생각해서 무산된 것이 아쉬웠습니다.
• 조합 및 강화 때 아이템 등급 색이 안 나오는 것을 너무 늦게 발견해서 고치지 못했습니다. (결과로 등장하는 무기에는 색이 안 입혀짐)
• 멀티 플레이에서 장착한 아이템을 교환하는 것을 막는 기능이 없어서 아쉬웠습니다.

현경훈

• 아레나 시스템의 불안정 : 접속 인원이 많아질 경우 발생할 수 있는 문제점들을 미리 인지하지 못함 / 지속적인 테스트를 해보지 못함
• 아레나의 로그 출력의 불친절 : 플레이어 닉네임이 길면 행동 로그 출력이 잘리는 문제를 고려하지 못함

---

4. 스프린트 운영 회고

잘된 점

서아영

• 상태 전환이나 패킷같은 새로운 개념들을 배울 수 있어서 좋았다
• 이전까지는 다이어그램 없이 작업했었는데, 있으니까 흐름 파악같은걸 하기 쉬워서 좋았다

송용수

• 말로만 들어본 리슨 서버 구현을 직접 해볼 수 있어서 좋았다. 다음에 멀티 플레이 구현을 한다면 쉽게 이해할 것 같다.
• 스냅샷 방식으로 약식으로 멀티 구현하니 상당히 빠르게 서버 권위 구조가 만들어졌다.

장고은

• 멀티까지 해보게 될 줄 몰랐는데, 멀티를 trpg에서 구현해보게 되다니 너무 신기했다.
• 템플릿 형식의 인벤토리 만들기 2번째 도전(1번째 때보다 훨씬 빠르게 만들어서 다행)은 성공적이었다.
• 깃 충돌이 생각보다 많이 안 난 거 같아서 다행이었다.

오진민

• 다이어그램의 중요성 파악. (협업할 땐 필수인듯?)
• 다행히 협업을 경험해보신 분들이 많아서 깃에서 사고쳐도 복구가 잘됐음.
• 빠르게 깃허브 데스크탑말고 Fork를 배운것.
• 멀티플레이를 개발해보는 경험. 패킷 생성부터 send로 보내고 broadcast로 방송하는 경험.

한수현

• 잘하는 팀원들이 있으면 팀 프로젝트가 잘 굴러간다는 것을 확실히 느꼈습니다.
• 다들 다이어그램 쓰는 것을 보고, 이해하기가 쉬워서 저도 다음부터는 다이어그램을 쓰기로 했습니다.
• 깃허브 데스크탑 이외의 깃 프로그램을 사용하는 것의 필요성을 느꼈습니다.

현경훈

• 기존 시스템에서 멀티가 추가되는 과정이 의외로 자연스럽게 진행되어 좋았음
• 기존에 사용하던 네트워크 라이브러리가 아닌 패킷 통신을 통해 깊이 있는 학습 경험이 됐음
• 새로운 구조를 설계하고 해당 설계에 맞게 인원분배를 해보는 경험이 소중함

---

아쉬웠던 점

서아영

• 구조를 알아도 코드를 어떻게 짜면 좋을지 모르겠어서 오래 걸린게 아쉽다. 오류 났는데 어떻게 고치면 좋을지 몰라서 거의 90%를 팀원에 싹싹 빌어서 해결한 듯…
• 골드전송을 녹일 곳이 없다 (늦게 추가해서22) 차라리 돈주기가 아니라 돈뺏기 하는게 더 재밌었을 듯 (로그 안 남기게 만들어서 돈 뺏고 빨리 쓰는 사람이 이득인 식으로)

송용수

• 깃 규칙을 대충 잡아서 메인에 바로 푸시하고 좀 팀원들이 다 잘하겠지에 의존한 경향이 있다.(덕분에 빠르게 만들기도 했다.)
• IGameState 네이밍에 맡게 모두 순수 가상 함수로 구현해야 했는데 팀원들에게 전파하는 비용을 고려해서 Enter, Exit는 그냥 가상함수로만 구현했다.
• DATABASE 헤더에 데이터들을 다 짬때린게 구조적으로 이슈가 있다고 생각한다.

장고은

• 조금 더 시간이 있었다면 멀티 서버에 대한 공부를 먼저 한 후 확실히 이해하고 개발을 할 수 있지 않았을까 싶어서 아쉬움이 남지만, 개발하면서 배우는 것도 나쁘지 않았다.
• 다음에는 이슈를 사용해서 깃 관리를 진행하면 좋을 거 같다는 생각이 들었다.(시간이 넉넉할 때)
• 다음에는 싱글톤 패던을 사용할 때 이름을 잘 지어 봐야겠다고 생각했다.

오진민

• 게임 개발이 처음이다보니 실력부족이 아쉬웠음.
• 다른사람들의 코드를 보고 이해하는 시간이 오래걸리고 녹여내는데 AI의 도움이 필요했다.
• 오류를 수정하려고 해도 위와 같은 이유로 수정이 매우매우 오래걸림.
• NetworkManager를 다같이 필요한걸 집어넣다보니 엄청난 스파게티 코드가 된걸 방치했음 (결국 경훈이가 정리함) 나이스
• 개념부족. 싱글톤이 뭔지도 모르고 왜 GetInstence()를 사용하는지도 몰라서 이해가 힘들었음… ㅠㅠ

한수현

• 팀원들이 내는 의견을 따르긴 했는데 의견을 제시하지 못한 것이 아쉬웠습니다.
• 이번 팀 프로젝트 과정에서 Git을 사용하는 과정에서 Merge 실수를 많이 해서 프로젝트를 꼬이게 하는 경우가 많아 아쉬웠습니다.

현경훈

• 후반 마무리 단계에서 브랜치를 쓰지 않고 main으로 핫픽스해서 머지 과정 관리가 약간 미흡해짐
• 네트워크 관련 코드를 작성하기에 급급하여 유지보수, 가독성을 버려버리고 하나의 클래스에 몰빵하여 후반에 디버깅 추적에 어려움을 늦김 → 추후 리펙토링을 통해서 ArenaNetworkManager로 옮겼지만 아직도 아쉽다고 느낌
• 패킷이 필요할 때마다 재사용이 아닌 새로운 패킷 구조체를 만들어 사용한 점이 코드의 유지보수에 큰 패널티를 주었다 생각함

---

5. 팀 협업 회고

좋았던 협업 방식

• 브랜치를 각자 고유의 브랜치로 정해두고 관리한 것
• State방식을 사용해 각자 개발을 한 후 SetCurrentState를 이용해 상태만 전환 시키면 연결이 되는 것
  • State 덕분에 중간에 기능 추가 할 때 코드 많이 안 수정해도 돼서 좋았다
• 각 파트를 확실히 분리하여 상의할 일이 생길 경우 해결이 용이했다
• 시스템을 설계할 때 기본적으로 다이어그램을 작성 / 공유 코드의 파악이 용이했다

---

개선이 필요한 부분

• 비주얼 스튜디오에서 깃 협업을 할때 vcproj랑 필터가 자주 머지 컨플이 났다. 필터를 안쓰는 라이더로 환경을 바꾸거나, CMake 같은 것을 도입해보는 것이 좋아보인다.
• 원격에 반영할 때 꼭 로컬에서 빌드되는지 확인해보기
• 깃허브 데스크탑 이사하기
  ㄴ 대체품 추천부탁드립니다(소스트리, fork)
• 메인으로 반영하는거 락을 안검
• 풀리퀘 승인없이도 가능하게 만듦
• 데일러 스크럼을 체계적으로 진행하지 못했다.(다들 파트는 받았는데 그날 뭐할지 구체적으로 정하지는 않았다.)