# 스프린트 4

## 계획

### 가용 시간

#### 첫 주 (시험 집중 기간)

- 정원준: 7h
- 손유진: 8h
- 김지후: 13h
- 김연재: 10h
- 전민혁: 12h

#### 둘째 주 (작업 집중 기간)

작업에 방해가 되는 사항 위주로 기록

- 정원준: 논설 기말
- 김연재: OS, 시프
- 손유진: 화요일 보고서, 목요일 시험 (사실상 크게 참여 불가)
- 김지후: 큰 일 없음
- 전민혁: 동아리 운영 관련 잡무

### 플래닝

- 사운드 구현: 만들어진 시스템에 효과음 얹기
- GameManager: 타이틀, 스테이지 이동 구현 필요
- Softbody 구현 확정, 적용: 게임 퍼즐의 핵심 기믹
- 게임 전체 통합 테스트: 모든 사항 의도대로 동작하는지 확인 필요
  - 위 작업 도중 파생되어 나오는 버그들 전부 가능한 사람이 Ad-Hoc으로 처리.
- UI 구현: GameManager 랑 맞물려서 표시, 버튼 작동할 필요 있음.

- 버그가 상당히 많이 발생할것으로 예상됨. (그리고 실제로 많이 발생함)

실제 작업 인원 배분 관련해서는 [Trello Board](https://trello.com/b/rQ5yKs74/main-board)에서 더 자세히 확인 가능.

## 작업 진행

### Cumulative Flow Chart (Burnup Chart)

![sprint4_flow](img/sprint4_flow.png)

> 크런치 모드로 작업하는 과정에서 티켓을 제 때 Done 시켜놓지 않아 실제 작업을 반영하지 못함

### 커밋 기록

첨부한 commits.log 파일을 참조.

### 에셋 커밋 기록

- [에셋 정리 시트](https://docs.google.com/spreadsheets/d/1oFWm3P8v-1VS19Ub4nAjRWvM8Q4Xpd5cmEWyAfkwICc/edit?gid=1152651607#gid=1152651607) 참조
- Start Scene 모델: 게임 시작 화면에서 보이는 공중섬 + 마법사의 타원 모델을 제작하였다.
  - branch: start_scene_modeling
  - commits:
    - [add: start scene](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/51/commits/d02dba0bad63e6459003645139c600fd27308cca): start scene 생성. 모델 추가
  - 에셋 목록
    - 공중섬: [스케치펩 무료 모델](https://sketchfab.com/3d-models/floating-island-low-poly-vr-e03583671344487d8c853749f2de6d37)을 블렌더로 수정
    - 마법사 타워: [스케치펩 무료 모델](https://sketchfab.com/3d-models/xyz-homework-detailing-fantasy-tower-14b4caee67e2400797d30912f94688a6)을 블렌더로 수정
- UI: 게임 내 UI에 사용될 png 파일을 이번 스프린트에 제작, 커밋하였다.
  - branch: add_ui (start_scene_modeling에서 분기)
  - commits:
    - [add: logo png file](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/e099aeb9c627d67ee75a855d06ebbf7af71be2c8): "ALCHESLIME" 로고 추가
    - [fix: magic circle 4-parts version](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/e74a43cd1c01bccb701d34ffcc51266a9b5afdb1): 마지막 스테이지를 위해 마법진을 4개의 파트로 분리하여 추가
    - [add: ui png images](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/eb71f478840401c649f2e3ef84ceb7cb4d6d6471): UI에 사용될 png 이미지 추가
    - [add: start scene canvas](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/22a843f08df697bee9cfd4c0cfe287c40c6a0b92): start scene에 ui요소 배치된 캔버스 추가
    - [add: exit button scene](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/b29579793e6ac07eae67cffabfb11d8d1174f246): 스테이지 내에서 esc 눌렀을 때 나오는 일시정지 화면 캔버스 추가
    - [fix: make prefab](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/637c5ccc2edcd96520f84da03facc25238b70576): 캔버스에 배치되었던 요소들 그룹화 + 프리팹화
    - [add: basic ui](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/b14eb4fa8bb6bf3d3d2f79f614dfe71159bb00a7): 스테이지 내 UI 요소 (left-top menu, playtime placeholder 등) 추가
    - [add: stage screne](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/961921f5935010de77077a406d1d2efd0379b4a6): 스테이지 클리어 성공 / 실패 시 사용할 캔버스 요소 제작
    - [add: state screen](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/1439cb5c6779e2b4d22d3455f4265268542a0801): 스테이지 시작 시 / 로딩에 사용할 캔버스 요소 제작
    - [add: stage canvas](https://github.com/2024FALL-SWPP/team-project-for-2024-fall-swpp-team-03/pull/54/commits/a6fd4adf60ec3e7e949ad1196d6e6f754f9690d8): 제작했던 캔버스 요소 들 프리팹화
  - UI 요소는 [Freepik 에셋](https://www.freepik.com/free-vector/set-game-menu-selection-rpg-adventure-game-including-menu-level-selection-options_14245091.htm)을 Inkscape로 수정하여 제작하였다.
  - 추가된 에셋 목록
    - button_basic: 기본 직사각형 버튼
    - button_square: 기본 정사각형 버튼
    - button_exit, button_next, button_pause, button_reset, button_rest, button_resume: button_square에 알맞은 아이콘 추가
    - left_top_menu: 왼쪽 상단 플레이어 재질과 남은 변화 횟수 표시
    - playtime_placeholder: 스테이지 내 플레이타임 표시
    - radial_{active, deactive, hover}_{left, right, bottom}: 재질 변화에 필요한 radial ui 각 요소
    - 그 외 title logo, start, clear 텍스트 이미지

### 백로그 조정

> **12/04**
> 스프린트 4를 시작한 날이기 때문에 대대적인 조정이 들어갔다.
>
> - 바닥버튼 콜라이더 재작성 : 우선순위 중 -> 상
>
>   당장 게임이 돌아가야 하기 때문에 우선순위를 올렸다.
>
> - 테스팅 티켓 분리 : 테스팅(우선순위 중) -> 퍼즐 요소 테스트(우선순위 상), 비주얼 테스트(우선순위 중), 시스템 테스트(우선순위 중), UI 테스트(우선순위 중), 스테이지 테스트(우선순위 중)
>
>   QA TC 작성이 완료되었으므로(여전히 계속 수정되긴 해야 하지만) 실제로 작업을 하기 위해 TC 항목별로 테스팅도 티켓을 분리하였다. 해당 테스트 항목에 관련된 작업을 한 사람들을 티켓에 배정하였다.
>   softbody와 퍼즐 요소 동작을 병렬적으로 구현한 후 둘을 합쳐 게임을 만드는 것이 우리 계획이었기 때문에 퍼즐 요소 테스팅만 우선순위가 높고, 다른 테스팅은 우선순위를 살짝 낮추었다.
>
> - 리팩토링된 에셋에 애니메이션 re-linking to In Progress : 추가(우선순위 상)
>
>   코드 리팩토링뿐만 아니라 에셋도 리팩토링하였는데, 이에 따라 guid 등 많은 것이 바뀌면서 scene 내부에서 다시 오브젝트간 연결을 해 줘야 하는 일이 발생하였다. 이 작업이 완료되어야 게임이 조금이라도 진행되므로 우선순위는 높게 잡았다.
>   실제로 작업을 계속 하다 보니 연결이 수도 없이 끊겼는데, 우선순위가 높기 때문에 그때그때 다시 연결하여 main 브랜치에 commit을 넣어야 했다.
>
---
> **12/05**
>
> - 특수 맵 요소 : 우선순위 중 -> 삭제
>
>   게임을 만들다 보니 특수 맵 요소라고 불릴 만한 것이 없어 삭제하였다. 특수 요소를 만드는 것은 매우 오래 걸리기 때문에 스테이지 디자인 단계부터 최대한 배제하였다.
>
---
> **12/06**
>
> - 맵 꾸미기, 세이브/로드 : 우선순위 하 -> 삭제
>
>   남은 기간이 촉박하여 시간을 아끼는 방향으로 결정하였다.
>
> - 스테이지 선택 화면, 시작 화면 : 추가(우선순위 중)
>
>   UI의 실제 작업 단계로 들어갔기 때문에 티켓을 분리하여 추가하였다. 필수 요소지만 더 급한 것이 많아 우선순위는 중이다.
>
> - 마무리 리팩토링 : 추가(우선순위 중)
>
>   꼭 해야 하는 내용이지만 당장 게임이 돌아가지 않기 때문에 바로 작업할 수는 없어 우선순위는 중이다.
>
> - 스테이지 1 기본 플레이 테스트 : 추가(우선순위 상)
>
>   테스팅 중에서도 스테이지 1을 클리어할 수 있게 하는 것을 목표로 하는 테스팅 항목을 만들었다. 다른 대부분의 작업들은 이 스테이지 1을 클리어하는 것을 목표로 진행되기 때문에 우선순위는 상이다
>
---
> **12/07 이후**
>
> 이 이후로는 티켓을 추가하거나 변동하지 않았다.
> 이미 backlog에 올라온 티켓 이외에 할 작업은 모두 버그픽스의 일환이었다. 따라서 테스트 티켓 안에서 TC표를 기반으로 failed된 항목들에 대해 작업하는 방식으로 하였다.

## 회고

### 잘 된 것

- 모두가 열심히 한 것 같다
- 시간도 많이 넣었다
  - 잠을 잘 못 잤다
- 과정이야 어찌되었든 결과적으로 Softbody가 예쁘게 잘 나왔다
- 집중적으로 일해야 할 때 다 같이 모여서 작업하니 딜레이가 없어서 좋았다

### 안 된 것

- Softbody를 너무 늦게 넣게 되어서 버그가 기하급수적으로 발생하였다
- 마찬가지로 서로 분리되어서 작업되던 사항들을 막판에 한꺼번에 통합하면서 버그가 많이 발생하였다
- 위 두 개 사항 때문에 결과적으로 게임의 완성이 제 때 되지 못함.
- 집중적으로 동시에 일을 하다 보니 커밋 그래프가 꼬여서 작업사항들을 고쳐야 하는 일이 많이 발생하였다

### 개선하면 좋을 것 (다음에 다른 프로젝트에서 개발한다면)

- 더미로라도, 어떠한 기능 파트에 대해서 구현이 존재해야 나중에 통합할 때 문제가 안 생길 것 같다. 개발 과정에서 외면되고 있는 기능부분이 존재하지는 않은지 체크하자
- 매니징 관점에서, 티켓 하나하나의 에이징과 완료 시점에 대해서 미진하게 대처한 것 같다. 한 티켓이 너무 정체되어있으면 이를 빠르게 해결할 수 있도록 해야 할 것 같다.
- 작은 팀, 작은 개발 기간이기 때문에 이터레이션 주기를 좀 빠르게 했으면 좋았을 것 같다.
- 같이 작업하는 시간이 좀 더 있었으면 좋았을 것 같다.

## 디자인 패턴

### UML (Prop, Conductor)

[Drive link](https://drive.google.com/file/d/1P99fDfugPd4WlVNOA8gzOdHT3YDk3php/view?usp=drive_link)

### Softbody 시행착오

참고한 구현방식

- Joint 기반 착시
- Voxel 기반 자체 물리
- 표면 파티클 기반 자체 물리

우리는 여기서 Joint 기반 착시를 선택하였다.

이 경우, Player를 구성하는 Rigidbody가 여러개여서 충돌 관련한 세부 로직이 오류가 발생할 수 있었다.
또한, 우리는 게임 플레이 도중 플레이어의 모양이 고정될 수 있어야 하므로 이 순간에 대해서 Joint의 시뮬레이션이 일시정지되어야 하는 문제가 있었다.

Joint의 시뮬레이션은 플레이어를 구성하는 주변 Particle들을 SetActive(false) 하는 것으로 해결하였다.
그러나 이 경우 다시 SetActive(true) 할 때 Joint의 Limit 계산이 처음부터 다시 됨에 따라, 다음 step 의 물리 연산의 값이 있을 수 없는 값으로 수렴해버리는 문제가 있어 별도 조치를 취해야 했다.

또한, 300개가 넘는 Particle들의 위치를 일일이 가져와서 List의 값에 저장하고, 그것을 다시 렌더용 메시에 반영하는걸 프레임마다 하는 것이 상당한 성능적 부하가 있을 것이라는 우려가 있었다.
이를 해결하기 위해, C# Job System 을 통해 해당 부분을 병렬적으로, 그리고 native 하게 처리함으로서 해당 성능을 조금이나마 상승시켰다.
다만, 이 부분은 Mesh의 GraphicsBuffer를 직접 건드릴 수 있었으면 더 성능을 빠르게 만들 수 있었을 것 같다.

## 테스팅

스프린트 3에서 "무엇을" 테스팅할지를 정했고, 스프린트 4에서는 그 테스팅 항목들을 실제로 테스트하였다.

다음은 테스트에 사용한 TC 시트이다.

[시트 링크](https://docs.google.com/spreadsheets/d/1we7UW4qIK2VqOh-znoSiv9xZsbei_SDM7qtCuA-7Bbk/edit?gid=102119220#gid=102119220)

### 스프린트 3에 비해 변경된 사항

앞으로 스테이지를 추가한다면 필요할 수도 있겠지만, 당장 우리의 5스테이지 구성에 필요하지 않은 테스트 항목은 Block하였다.

- 1개 이상의 금속상자를 밀고, 플레이어 또한 접촉하여 양극을 연결한다
- 금속 상자를 독극물에 빠뜨리면 가라앉는다.

특정 로직에 의해 필요 없어진 테스트 항목은 Block하였다.

- 가스에 상자를 접촉시켜 없앤다. (가스를 건너 상자를 옮기는 행위를 막기 위한 테스트 항목이지만, 생각해보면 플레이어는 가스와 닿았을 때 슬라임으로 변하기 때문에 상자를 옮기는 것 자체가 불가능하다)

작업 로드가 크지만 필수적이라고 생각이 들지 않는 요소들을 Block하였다.

- 세이브/로드
- 사망신
- 스테이지 시작/종료 시 텔레포트 효과

구조적/기능적으로 변경(혹은 타협)된 기획에 대해 항목을 추가/삭제 하였다.

- 스테이지 내부의 재시작 항목을 Block하였다.
- 대신 스테이지 내부에서 일시정지 항목과, 일시정지 화면에서 재시작 항목을 추가하였다.
- 스테이지 4에서 유저에게 부조리하다고 생각 되는 부분을 수정하면서, 관련 테스트 항목을 Block하였다.

스프린트 3에는 없던 유저 경험적인 부분 등 기타 항목을 추가하였다.

- 플레이어가 원하는 곳으로 이동하는 것이 "쉬운가?"
- 상자를 원하는 곳으로 미는 것이 "쉬운가?"

테스팅 방법

automated test를 하기에는 대부분의 class들이 유저의 input/output과 멀지 않은 거리에 있고, 시간이 충분하지 않아 전부 manual 테스트로 진행하였다. 이를 위해 TC에는 해당 테스트 항목을 실행하기 위한 사전 조건과 테스팅 방법이 적혀 있고, 그 방법을 따라가면서 기대 결과를 만족하는지를 검사하였다.

대부분 black box 테스팅으로 진행하였다. 하지만 테스터가 코드나 에셋의 내용을 어느 정도 알고 있으면 black box와 white box의 경계가 모호해졌다.

테스터가 테스트를 하다가 버그를 발견하였을 경우, 먼저 관련 코드/에셋 작성자의 job queue를 확인하였다. 만약 queue가 그리 길지 않거나 로직이 복잡하다면 버그를 리포트하고 다음 테스팅으로 넘어간다.
만약 queue가 길거나 로직이 간단하면, 테스터가 직접 코드를 분석하고 log를 찍어 디버깅을 하였다.

단위 테스트와 통합 테스트의 구분은 명시적으로 하지는 않았지만, 프로젝트의 시간적 계획에 의해 적절히 테스팅 범위가 점점 커지도록 설계하였다.

통합의 예시

플레이어가 버튼 위로 자연스럽게 올라가는지 확인 + 버튼 위에 물체를 올려놓았을 때 버튼이 잘 눌리는 지 확인 + 벤트에 신호가 갔을 때 잘 열리는지 확인
(통합) -> 플레이어가 버튼쪽으로 이동하면 벤트가 열리는지 확인

softbody 구현 전의 플레이어가 버튼을 누를 수 있는지 확인 + softbody가 물리적으로 잘 작동하는지 확인
(통합) -> softbody가 적용된 플레이어도 버튼을 누를 수 있는지 확인

각각의 퍼즐 요소들이 잘 작동하는지 확인
(통합) -> 스테이지를 클리어 가능한지 확인

각각의 스테이지를 클리어 가능한지 확인
(통합) -> 튜토리얼부터 마지막 스테이지까지 플레이가 이어서 가능한지 확인

## 리팩토링

- CameraController
  1. 기존 변수명과 코드 스타일을 팀의 컨벤션에 맞게 정렬.
  2. 변수 선언을 serialize filed와 아닌 것들을 구별해서 정렬
- InGameScreenBehaviour
  1. 초기화 로직을 InitializeAudio, InitializeUI, SubscribeEvents 등의 메서드로 분리하여 Start 메서드의 책임을 줄임.
- Onbuttonclick event 를 button name 기준으로 분리 → 기능별로 분리(stage 이동, stage 상태 조절)
- GameState 세분화 → button click 시의 상태, 재질 변화시의 상태, start 화면에서의 상태 등을 추가하여 case sensitive 한 코드 구현
- UIManager 에서 serializefield 에 할당 → gameObject.Find(name) 으로 할당, 더 깔끔한 inspector 창
- 한줄, 한번 할당하는 메서드 삭제(불필요한 메서드화 삭제) : 메서드 종류 줄임, if문에서 어떤 작업을 하는지 바로 확인 가능
- Gamestate property 화 → get, set method 구현하지 않고 간략하게 사용
- Conductor 코드에서 Connected 상태인 오브젝트를 받는 인터페이스를 추상화