작성
·
26
0
세이브 저장방식을 Playerprefs 보단 프로젝트 Resource파일 내부에 json으로 저장하는쪽이 개발하는 과정에는 저장하는게 명확하게 보여서 더 좋다고 생각해서 바꾸긴 했는데
Json과 playerprefs이 조금의 속도 차이는 있는거로 아는데 playerprefs에 json으로 저장하는것에는 무슨 차이가 있는지 여쭤보고싶습니다.
그리고 퀘스트의 실패를 만드는것은
다키스트 던전처럼 일단 퀘스트를 무조건 성공하는 취급으로 한 후에 Give 함수에 enum에 따라서 이벤트를 발생 시키게 해서 구현하려는데
이때 Enum인 대성공,성공, 실패, 대실패를 정하는걸 TaskGroup에 넣는게 맞는지 잘 모르겠습니다.
TaskGroup에 Enum변수를 만든 다음에 Quest에 isFailable 변수를 만들고 achievment 처럼 ReceiveReport를 가상함수로 만든 다음에 다른 종류의 퀘스트를 만들고 ReceiveReport를 원하는대로 수정한 다음 성공한 TaskGroup을 따라서 QuestResult가 결정되고 이걸 QuestReward에 QuestResult에 따라서 보상, 실패 처리를 하면 되는걸까요?
public bool IsFailable => this.GetType() != typeof(Quest) && this.GetType() != typeof(Achievement);
이 bool값으로 어떤 유형의 퀘스트인지도 확인을 하고요.
이런식으로 구상을 생각해 보았는데 이러한 설계가 맞는 방향인지 여쭤보고싶습니다.
답변 1
0
수강해주셔서 감사합니다.
Json을 이용하면 추후에 BaaS Service와 연동하여 서버에 Data를 저장할 경우, 그 외 서버와의 통신이 필요할 경우 Json Data를 서버로 보내기만 하면 되기 때문에 서버 작업에 용이합니다.
Playerprefs가 아닌 File 형태로 저장할 경우 저장 Data의 변조가 매우 쉬워지기 때문에 큰 차이가 없긴 하지만 조금이나마 변조가 귀찮으라고 Playerprefs를 이용해 저장하는거구요, 유료로 판매하는 게임에서는 File 형태로 저장해도 무방합니다. Playerprefs에 저장된 Data를 보고 싶으시다면 Playerprefs에 저장된 값들을 Unity Window 창으로 볼 수 있게 해주는 에셋들이 많이 있습니다.
말씀하신 아이디어는 굳이 새로운 class를 만들지 않고 그냥 Quest와 TaskGroup 자체에 생각하신 아이디어를 적용해서 확장하시면 될거 같구요, 웬만하면 상속보다는 먼저 확장(or 모듈화)을 고려해서 설계를 하시는게 좋습니다. Complete시에 TaskGroup들의 성공 여부에 따라 Quest의 성공 단계가 결정되고(=대성공, 성공, 실패, 대실패) Reward에서 성공 단계에 따라 차등 보상을 주는 아이디어는 좋아보입니다.
상속은 엄청난 리스크를 동반하는 행위구요, 기능 몇 개가 추가된다고 상속으로 자식 class를 만들어버리면 나중에 여기저기 중복 Code가 생기면서 Code가 꼬일 가능성이 높습니다. Achievement class 가 약간 오해를 드린 것 같은데요, 강의에서 Quest를 상속 받는 Achievement를 만든건 Quest와 업적이 보편적으로 역활이 나눠지기 때문에 편의성을 위해 나눈 것이지 Achievement class 자체는 없어도 상관이 없습니다.
만약 제가 Quest의 기능을 더 확장한다고하면 Quest 자체를 확장하고, Quest class가 너무 커진다 싶으면 정리를 해서 더 세심하게 모듈화를 하지 웬만하면 Quest를 상속 받는 무언가를 만들 일은 없을 것 같습니다.
감사합니다.
좋은강의와 답변 감사합니다.