캠프 28일차 - 발표와 회고

발표

이번 첫 팀 프로젝트에서 발표를 맡게되었는데, 발표를 하기 전부터 엄청난 긴장감을 가진 상태로 발표를 했다. 팀원분들께서는 발표 잘했다고 칭찬과 격려를 많이 해주셔서 너무나도 감사했다.
발표 이후 손튜터님께서 피드백(질문)을 해주셨는데 긴장을 너무 한 탓에 내가 뭐라고 답변했는지 기억이 잘 안난다.. ㅎㅎ

다음과 같이 튜터님께서 질문을 여러가지 해주셨는데 긴장이 풀린 지금 다시 한 번 튜터님의 질문에 대한 답을 드리고자 정리하려한다.

Q. 게임 이름은 왜 안정했는지

• 처음에는 필수 기능을 먼저 구현을 하고, 추가로 구현하고 싶은 기능을 구현하자 라는 생각만 있었지 게임 이름을 뭐로 정할까 라는 생각을 하지는 못했다. 그래서 추가로 구현한 기능인 아스키아트에서 중세풍의 이미지를 사용했기에 자연스럽게 중세 판타지 RPG 라고 급하게? 이름을 붙였다.
• 튜터님께서 게임을 만들때 항상 가장 먼저 해야하고 가장 중요한 것이 게임 이름을 정하는 것이라고 말씀해주셨다. 잊어버리면 죽겠다 라는 마음 가짐으로 절대 잊지 말자.

Q. 클래스와 데이터테이블이 각각 언제쓰이는지

• 클래스는 기능과 로직을 담당하는 주체이고, 데이터 테이블은 순수한 데이터 저장소이다. 클래스는 상점이나 인벤토리와 같은 시스템이 데이터 테이블의 데이터를 받아와 실제 기능을 수행할 때 사용하고, 데이터 테이블은 아이템의 속성을 관리하고 상점이나 인벤토리가 어떤 아이템을 불러올지 결정한다. 이 둘은 서로 상호 보완 관계로 둘 중 하나라도 없으면 안된다.

Q. 다른 곳에서는 아스키아트와 로그를, xy 부분에 대해 잘했는데 왜 상점에서는 배치를 안했는가

• 정확한 답변.. 아니 변명을 하자면 시간이 부족해서가 아닌, 다른 곳처럼 아스키아트와 로그를 통합해야 한다는걸 아예 생각조차 하지 못하였고 자연스럽게 넘어가게 되었다. 튜터님이 짚어주셨기 때문에 "아 이것도 했어야 했구나" 라고 생각하게 되었다. 세부적인 화면 기획을 하지 않았던 점이 잘못이었던 것 같다.

Q. 시간이 더있다면 엔딩부분에서 어떻게 하고싶은지

• 이전 질문과 비슷한 답변일수도 있지만, 이건 기획에는 있었으나 시간이 부족하여 추가하지는 못했던 부분이었다. 보스가 죽은 뒤 바로 엔딩화면만 띡 하고 나오는데, 애니메이션과 엔딩 사운드를 추가하여 유저에게 "게임이 클리어 되었음" 을 확실하게 알려주는 씬을 추가하여야겠다.

Q. 이 게임만의 차별점?

• 아스키아트와 사운드를 통하여 단순한 텍스트로는 느낄 수 없는 몰입감을 제공하고, 단순한 1:1전투가 아닌 다대다 전투로 조금 더 재미있는 요소가 추가되지 않았나 싶다.

KPT 회고

나의 회고

Keep

• 상점 기능을 구현해보겠다고 가져갔을 때, 막상 어떻게 결과물을 내보여야 할지부터 막막했다. 독단적으로 구현하지 않고 먼저 팀원분과 논의해서 결정한 것이 방향성을 잡는 데 큰 도움이 됐다. 다음에도 뭔가 막막할 때 먼저 의논하는 방식을 계속 유지하자.
• 사운드 기능도 처음엔 Windows API의 한계(음악 파일 하나만 재생 가능)에 막혀서 효과음은 그냥 넣지 말고 넘어갈까 싶었는데, 팀원분과 얘기해서 동시 재생이 가능한 방법을 같이 찾아봤고, 다른 라이브러리를 사용해 BGM과 효과음을 동시에 낼 수 있게 됐다. 포기하지 않고 대안을 찾아보는 태도를 계속 유지하자.
• 인벤토리 담당하신 분과 소통을 자주 했는데, 귀찮게 자꾸 질문하는 건가 싶었지만 항상 친절하게 대해주셔서 감사했다. 이런 활발한 소통은 어느 팀을 가든 앞으로도 부담 갖지 말고 계속 이어가고 싶다.

Problem

• 사운드 기능을 넣긴 했지만 완성된 결과물에서는 사실 일부 씬에서만 BGM을, 일부에서만 효과음을 넣어서 전체적으로 디테일 완성도가 떨어진다 생각한다. 시간이 부족했던 것도 맞지만, 근본적으로는 처음부터 어느 부분에 어떤 사운드를 넣을건지, 계획을 디테일하게 잡지 못하고 러프하게만 잡아서 "아, 이런 부분도 필요했구나"를 나중에서야 파악했기 때문에 생긴 문제라고 생각한다. 해결 방안: 기획 단계에서 씬/기능별로 필요한 사운드 목록까지 미리 체크리스트로 뽑아두고 시작하면, 이런 누락을 줄일 수 있을 것 같다.

Try

• 다음 프로젝트는 시작 단계에서부터 게임의 이름과 컨셉을 확실하게 정하고, 화면에 무엇을 그릴지부터 명확하게 설계하고 들어가보자.
• 기획할 때 기능별/씬별 체크리스트를 미리 만들어보고, 이번 사운드 완성도 문제처럼 나중에 빠뜨린 부분을 뒤늦게 발견하는 일을 줄여보자.

팀 회고

개인회고&팀회고 이미지

Keep

• 데이터-기능 분리 설계. 몬스터/아이템 등 종류별 데이터는 데이터 테이블로 분리 관리해서, 기능 코드 수정 없이 데이터만 바꿔도 확장할 수 있게 만들었다. (박준석, 이승기, 김채우)
• 사전 설계 프로세스. 요구사항 분석과 UML·플로우차트로 구조를 먼저 설계한 뒤 구현에 들어가서, 개발 중 팀원 간 충돌을 최소화했다. (이승기, 김채우)
• 막힐 때 독단적으로 처리하지 않고 팀원과 논의하는 문화. 구조가 이해 안 되거나 방향이 막막할 때 담당 팀원에게 먼저 질문하고 논의한 뒤 진행했다. (박준석, 김형래)

Problem

• 통합(병합) 단계에서 구조적 안전장치 부재. 브랜치 병합 시 리소스 경로가 충돌하고, 모듈 간 파일 경로·데이터 키값이 어긋났다. 통합을 전담하는 클래스 없이 메인 파일에서 이어붙이다 보니 코드도 난잡해졌다. 각자 겪은 원인은 달랐지만, 결국 "통합 지점을 사람이 매번 조심하는 방식에만 의존했다"는 공통 문제로 정리했다. (박준석, 이승현, 김채우)
• 공통 요소·세부 완성도를 초반에 충분히 계획하지 못함. 재사용할 공통 UI를 초기에 정리하지 못했고, UI에 신경 쓸 여유도 부족했다. 사운드 적용 계획도 러프하게 잡아서 일부 씬에만 반영됐다. (박준석, 이승기, 김형래)

Try

• 통합 전담 구조/규칙 도입. 다음 프로젝트는 게임 매니저 같은 통합 전담 클래스를 두고, 병합 전 체크리스트(브랜치 상태·수정 파일·리소스 경로)를 만들어 통합 과정을 구조적으로 관리하자. 이승현이 제안한 템플릿 메소드 패턴도 같은 방향의 시도다. (박준석, 김채우, 이승현)
• 공통 UI/재사용 요소 우선 설계. 메뉴, 선택 패널, 화면 전환처럼 여러 화면에서 공통으로 쓰는 요소를 먼저 만들고, 이후에 화면별 요소를 추가하자. 레퍼런스를 참고해서 UI 감각도 함께 높이자. (박준석, 이승기)
• 기능/씬별 체크리스트 사전 작성. 기획 단계에서 씬·기능별로 필요한 요소(사운드 등)를 체크리스트로 미리 뽑아 누락을 방지하자. (김형래)
• AI 활용 기준 정립. AI가 생성한 코드는 바로 적용하지 말고, 기존 구조·책임 분리에 맞는지 확인한 뒤 연결하는 보조 도구로 쓰자. (박준석)