오늘 한 일
오늘은 ppt발표가 있는 날이라서 다른 사람의 파트, 코드도 읽어보았는데
그걸 위주로 작성해보겠습니다.
저희가 게임을 만들기이전에 초기로 구상해둔 와이어 프레임 입니다.
팀업이다 보니까 기획 먼저하고, 틀을 어떻게 잡을지가 문제였습니다
그래서 저희가 선택한 방향은 Initialization이라는 0번째에 새로운 Scene을 만들었습니다.
여기에 Gamanager 오브젝트를 만들어서 Dontdestroyonload를 추가해주었습니다.
그래서 계속적으로 필요한 프리펩이나 오브젝트들은 여기에 넣어 관리를 했고, 스크립트들도 여기에 추가해서 먼저 테스트를 해볼 수도 있고 굉장히 용이하게 사용할 수 있었습니다.
그리고 각자의 Scene을 만들어서 관리를 하며 분담을 하였습니다.
각 파트별 트러블 슈팅과 기능을 알려드리겠습니다.
Player
점프키를 위해서 isGround와 RayCast를 이용하여 바닥에 닿는지 확인을 하고 점프를 가능하게 했습니다.
TroubleShooting
점프를 할때 미리 입력해둔 값이 선입력이 되는 현상이 있었습니다.
문제해결
디버깅을 통하여 공중에서 레이캐스트 줄기가 땅에 닿을 때 IsGround = true가 인식되고 있다는 걸 확인.
기존에는 Update()에서 입력과 물리연산 처리를 동시에 실행을 했음.
결과
Update()에서는 입력값만 받고, FixedUpdate()를 만들어 여기에는 물리처리를 하게 나누었습니다.
Update()에서는 프레임 단위로 처리를 하기 때문에 이전 프레임과 최신 프레임을 동시에 받을 수 없음
Acivement, JsonSerializer, DataService
JsonSerializer 스크립트라는 Low-level I/O작업을 담당하는 공용 Util클래스를 생성.
내부적으로는 backup 및 temp파일을 생성하여여 예상치 못한 Crash에도 최대한 데이터 보존을 확보할수 있도록 노력함.
하나의 DataService가 하나의 데이터 도메인만 다룰수 있도록 역할을 축소
TroubleShooting
ProgressType을 외부에서 알아야하는 정보로 남겨두었다는 점에서 아쉬움이 남음.
AchievementManager가 원본데이터를 다 가지고 있기때문에 치명적인 실수로 느껴졌다.
문제해결
호출자가 내부 구현(진행 방식)에 의존하게 됨.
실수 시 데이터 손상/회복 곤란.
→ 단일 실수로 원본 데이터 전체가 잘못될 위험이 큼.
결과
외부 API를 의도 수준으로 단순화
대신 AchievementCommand 같은 DTO를 사용:
ApplyProgress(AchievementCommand cmd)
(예: Operation = Add/Set/Increment, Id, Value)
외부는 ProgressType 같은 내부 enum을 몰라도 됨.
원본 데이터는 저장소(Repository)로 분리
IAchievementRepository로 Load/Save 책임 분리.
AchievementManager는 저장소에서 읽은 복사본(working copy) 을 조작 후 저장.
원자적 저장 & 백업
임시파일 → Replace 방식으로 저장(atomic replace), 정기 백업 생성.
