8차 회의
일시: 2024.11.20. 17:40 - 20:40
- 잘 된 부분
- 싸우지 않고 스프린트를 잘 마무리함
- 계획한 만큼 시간을 씀
- 게임이 계획대로 잘 만들어지고 있다 (윤곽이 잡히고 있다)
- 디자인 패턴에 대한 필요성을 조기에 발견하고 잘 대처 중임
- 안 된 부분
- 완료되지 않은 태스크가 8개 있음
- 백로그에서 명확하지 않았던 구현 범위
- 로봇 캐릭터 리깅 & 애니메이션 태스크가 "애니메이션을 만드는 것"까지 vs. "게임에 적용하는 것"까지인지에 대한 견해 차이
- 스프린트 2에서 애니메이션까지 만들고, 스프린트 3에서 유니티에 적용하기로 함
- 로봇 캐릭터 리깅 & 애니메이션 태스크가 "애니메이션을 만드는 것"까지 vs. "게임에 적용하는 것"까지인지에 대한 견해 차이
- 백로그에서 고려하지 못한 의존성
- "주운 쓰레기"에 의존하는 태스크가 4개, "남은 목숨"에 의존하는 태스크가 3개 있었음. (아래 그림 참조)
- 이를 MVC 패턴으로 구현하기로 했으나, Model에 대해 논의할 시간을 확보하지 못해 미리 정해진 모델 구조 없이 각자 개발함
- 특히 쓰레기를 4종류로만 구별해서, 큐상에서 쓰레기의 구체적인 종류 (바나나, 캔, ...)를 나타낼 수 없는 문제가 있었음
- -> 다음 스프린트에서는 디자인 패턴 및 사용할 모델 구조에 대해 논의해서 확실히 정한 후 개발을 시작할 수 있도록 할 계획
- 쓰레기 줍기와 쓰레기 던지기 기능은 강한 연관성이 있지만 11/13 PP에서 함께 개발하면 괜찮을 것이라고 생각했는데, 당일에 장애물 배치에 집중하다 보니 쓰레기 관련 기능 구현이 완료되지 못하고 따로 PP 일정을 잡지 않으면서 개발에 어려움을 겪음
- "주운 쓰레기"에 의존하는 태스크가 4개, "남은 목숨"에 의존하는 태스크가 3개 있었음. (아래 그림 참조)
- 백로그 우선순위 조정 기록
- 쓰레기 "던지기" 기능의 구현 난이도가 높은데 반해, 실익이 낮다고 판단해 바닥에 쓰레기를 놓는 대신 쓰레기 큐를 "rotate"하는 기능을 구현하기로 스펙 변경
- 쓰레기 버리기 (던지기) 기능의 구현을 줍기 기능이 완성된 후에 시작하기로 해서 Hold함
- 목적지 기능을 목적지 타일이 완성된 후에 해야 해서 Sprint 3으로 Hold함
- 인게임 UI가 쓰레기와 목숨 데이터 Model이 완성된 후에 해야 해서 Hold함
- 배터리팩이 목숨 데이터 Model이 완성된 후에 해야 해서 Hold함
- DataManager 구현이 다음 스프린트에 예정되어 있었으나 이번 스프린트에 진행함
- 바나나 렌더링이 제대로 되지 않아 태스크를 만들어 해결함
- 쓰레기 배치 로직과 쓰레기 interaction (줍기, 버리기) 태스크를 2개의 PR에서 진행함
- 스프린트 백로그 및 태스크 선정 이유
-
선정 이유: 이전 스프린트에서 넘어온 태스크의 양과 줄어든 개발 시간을 고려해, 동적 장애물을 포기하기로 결정.
-
파워업이 구현되고 완성도가 낮은 게임 vs. 파워업 없이 완성도가 높은 게임을 비교함.
- 파워업 없이도 충분히 재미있는 게임이 될 수도 있을 것이라고 생각함.
- 따라서, 파워업을 포기하고 스테이지의 난이도를 조절하는 데 시간을 더 쓰기로 결정함
-
이전 스프린트에서 넘어온 태스크 (14시간)
- (UE-010) 레벨 1 설계 및 제작 : (Incomplete) 2시간
- (UG-004) 쓰레기 줍기 기능 구현 : (Pending review) 1시간
- (UG-005) 쓰레기 버리기 기능 구현 : (Incomplete) 2시간
- 플레이어 애니메이션 적용 : (Not Started) 3시간
- (UG-010) 배터리팩 아이템 구현 : (Not Started) 2시간
- (UG-003) 인게임 UI 구현 : (Incomplete) 1시간
-
게임 클리어 (4시간)
- 목적지 타일 제작 : 1시간
- (UG-008) 목적지 구현 : 1시간
- 게임 클리어 구현 : 1시간
- 실시간 점수, 최종 점수 계산 : 1시간
-
파티클 및 음향 효과 (5.5시간)
- (B-009) 파티클 효과 제작 : 1시간
- (B-009) 음향 효과 제작 또는 선정 : 1시간
- (B-009) 게임 음악 선정 : 1시간
- 파티클 및 음향 효과 적용 : 1.5시간
- 음악 재생 : 1시간
-
스테이지 디자인 (12시간)
- 레벨 2용 타일 제작 : 2시간
- (UE-012) 레벨 2 설계 및 제작 : 4시간
- 레벨 3용 타일 제작 : 2시간
- 레벨 3 설계 및 제작 : 4시간
-
테스팅 (3시간)
- (UE-021) 게임 클리어 테스팅 : 1시간
- 게임 실패 테스팅 : 1시간
- (UE-024) Persistent Storage 테스팅 : 1시간
-
UI 미화 (7시간)
- (B-010) Start, LevelSelect, LevelClear, LevelFail 화면 디자인 : 2시간
- (UE-013) StartingScene 미화 : 1.5시간
- (UE-015) LevelSelectScene 미화 : 1.5시간
- (UE-016) LevelClearScene, LevelOverScene 미화 : 2시간
-
PM 태스크 (6시간)
- 스프린트 3 시작 회의 : 1시간
- 스프린트 3 종료 회의 : 0.5시간
- 일별 태스크 진행 요약 작성 : 0.5시간
- Critical Path 분석 : 1시간
- 진척도 Update 및 리스크 분석 (1주차) : 0.5시간
- 진척도 Update 및 리스크 분석 (2주차) : 0.5시간
- 스프린트 3 회고 회의 준비 : 0.5시간
- 스프린트 4 시작 회의 준비 : 1.5시간
-
기타 태스크 (1시간)
- 디자인 패턴 논의 : 1시간
- 개인별 가용시간 체크 및 태스크 할당 표
이선재 김동욱 이상규 이정민 김준원 합계 1주 (11/20 - 11/26) 2시간 10 10 10 10 10 50 2주 (11/27 - 12/03) 2시간 5 12 7 10 7 41
- 91시간, 20% 버퍼 제외하면 73시간. 페어 프로그래밍 1.5배로 계산하면 49시간. 총 태스크 52.5시간.
- 스프린트 4는 기말고사 기간임을 고려해서 QA와 리팩터링 기능에 집중하고, 이번 스프린트에 무리해서라도(52.5/49 시간) 완료하기로 계획.
- 스프린트 내 개발 완료가 무엇보다 중요한 만큼 스프린트 기간을 아래의 4개 기간으로 나누어 관리
- Checkpoint 1 : 11/20(수) - 11/23(토)
- Checkpoint 2 : 11/24(일) - 11/26(화)
- Checkpoint 3 : 11/27(수) - 11/30(토)
- Checkpoint 4 : 12/01(일) - 12/03(화)
- 페어 프로그래밍은 11/27(수) 실습시간에 진행하기로 결정
- 12/3에 기말고사가 있는 점을 고려해, 첫 3개 Checkpoint에 대부분의 태스크를 배치함.
- dependency graph를 그려 태스크를 계획함
- C1, C2, C3, C4는 각 태스크가 몇 번 체크포인트 안에서 진행될 계획인지 나타냄
- ALL, ㄷㅇ(동욱), ㅈㅇ(준원), ㅅㅈ(선재), ㅈㅁ(정민), ㅅㄱ(상규)는 태스크의 Driver의 이니셜을 나타냄.
- 파란색으로 형광펜 칠한 부분이 이번 스프린트의 Critical Path임.
- 태스크 할당 표의 구체적인 내용은 스케쥴 참고.
- 인게임 데이터
- 점수 : int : 모델에서 관리
- 쓰레기 버리면 증가
- 쓰레기가 화면 끝에 닿으면 감소
- 카메라 이동
- 목숨 : int : 모델에서 관리
- 쓰레기 화면에 닿으면 감소
- 배터리팩 먹으면 증가
- 0이 되면 Game Over
- 진척도 : float (0 ~ 1) 카메라 불러와서 바로 계산
- (카메라의 z좌표 - 카메라의 시작 z좌표) / (목적지의 z좌표 - 카메라의 시작 z좌표)
- 들고 있는 쓰레기 Queue
- 현재는 List of (TrashType, TrashSubtype)
- List of (TrashSubtype)를 저장하고, 필요할때 Mapping[TrashSubType, TrashType]을 이용
- MVC 구조 이용
- 점수 : int : 모델에서 관리