내일배움캠프 9일차 WIL

 

오늘의 학습 키워드

 

 

• JSON  Serialize / Deserialize
• KPT

 

---

 

캠프에 참여한지 벌써 10일이 지났습니다.

 

 

유니티 작성하는 카드 매칭 게임 프로젝트 부터 C# Console로 플레이하는 Text RPG까지,

 

 

아직 10일 밖에 하지 않았는데 정말 많은 고난과 역경을 겪은 것 같습니다.

 

 

오늘은 다양한 오류와 만나봤기에,

 

 

해당 오류에 대한 이유와 해결 방안 등에 대해서 이야기를 해볼려고 합니다.

 

---

JSON이란?

---

 

정보 교환 방식

 

 

 

JSON이란 JAVA Script의 기본적인 구문의 형식을 따르는

 

데이터를 전송 및 교환하기 위해서 사용하는 표준화된 텍스트 형식 중 하나입니다.

 

예를 들자면 Server와 Client가 통신하여 데이터를 주고 받을 때

 

위와 같이 JSON은 형식으로 데이터를 작성하여 전달합니다.

 

또한 XML의 형식을  통해서 데이터를  보내기도 합니다.

 

하지만 제 기억상으로는 JSON형식이 제일 많았던 것 같습니다.

 

 

---

 

 

---

오류와의 만남

---

 

 

 

Newtonsoft 로고 이미지

 

 

 

게임에서 가장 중요한 것은 무엇이냐고 질문한다면,

 

게임 시스템(NPC, 상점, 공격 등..)을 생각할 것이라고 생각합니다.

 

하지만 제일 중요한 것은 바로

 

DATA

 

입니다.

 

 

게임을 플레이하면서 코딩된 로직의 흐름대로 프로그램은 데이터를 조작하고 전송합니다.

 

 

또한 로그라이크와 같이 사망 시, 데이터가 초기화되어 남는 것은 플레이어의 경험 뿐인 게임 외라면

 

 

무조건 게임의 플레이 데이터를 저장하고 불러오는 것은 매우 중요한 부분이라고 생각합니다.

 

 

그렇기에 저는 Player의 데이터와 상점의 데이터 내역을

 

Class채로 Json화하여 폴더에 로컬 저장하는 로직을 구현했습니다.

 

        public void Save<T>(T data)
        {
            string json = JsonConvert.SerializeObject(data);

            // 파일명과 디렉터리
            string fileName = $"{DefaultPath()}\\{typeof(T)}.json";

            FileWrite(fileName, json);
        }

        public T? Load<T>()
        {
            string path = $"{DefaultPath()}\\{typeof(T)}.json";

            FileInfo fileInfo = new FileInfo(path);

            if (fileInfo.Exists)
            {
                string json = FileRead(path);

                T data = JsonConvert.DeserializeObject<T>(json);

                return data;
            }

            return default(T);
        }

 

 

하지만 위 코드를 작성하여 실행한 결과 한 오류가 발생했습니다.

 

 

System.NotSupportedException: 'Deserialization of types without a parameterless constructor, a singular parameterized constructor, or a parameterized constructor annotated with 'JsonConstructorAttribute' is not supported. Type 'Sparta_Dungeon.Equipment'. Path: $.Inven.Weapon | LineNumber: 0 | BytePositionInLine: 755.'

 

 

????

 

 

코딩하면서 본 에러 내역 중에 처음보는 예외였습니다...

 

 

얼추 해석해보니...

 

 

Json을 역직렬화 시에 제가 구현한 Equipment.cs의 코드는 역직렬화를 지원할 수 없다고 하는 것 같습니다...

 

 

한참을 구글링을 하며 해당 에러의 원인은

 

 

객체 생성자에 제 Load코드에서 제네릭<T>형식으로 새로운 객체를 만들 때 등의 문제라는 내용이 있어서

 

 

파라미터를 요구하지 않는 순수 생성자를 코드에 넣어달라는 내용이 있었습니다.

 

 

        public Equipment() { }

        public Equipment(string name, int ATK, int DEF, string Description, int Price, bool isEquipped, bool isSelled)
        {
            Name = name;
            this.ATK = ATK;
            this.DEF = DEF;
            this.Description = Description;
            this.Price = Price;
            this.isEquipped = isEquipped;
            this.isSelled = isSelled;

        }

 

 

그래서 위와 같이 파리미터가 있는 생성자와 없는 기본 생성자를 구현했습니다.

 

 

휴...

 

 

 

???

 

 

다시 똑같은 오류가 발생합니다.

 

 

즉, 생성자의 파라미터로 인한 오류가 발생할 경우에도 위와 같은 오류 내역이 뜰 수 있지만,

 

 

저의 경우는 다르더군요...

 

 

그렇게 다른 클래스들과의 차이를 비교하면서 고민한 결과 하나의 차이점을 발견할 수 있었습니다!

 

 

public abstract class Equipment

 

 

그렇습니다. 

 

 

Equipment 클래스는 무기와 방어구 클래스를 생성 시 상속시켜주려고,

 

 

Equipment는 누군가에게 상속되는 클래스임을 나타내기 위해서 넣었던 Abstract가 문제였던것입니다.

 

 

그 결과 abstract를 제외하고 실행하니 매우 잘됩니다!

 

 

 

 

이와 관련해서 오늘 튜터님께 이를 해결할 좋은 팁을 받을 수 있었습니다!

 

만약! Player의 정보를 Json으로 저장하고 로컬 또는 외부에 데이터를 저장 후 주고 받고 싶을 경우!

 

 

PlayerData와 같이 정보만을 저장하는 클래스를 따로 만들고

해당 클래스의 데이터를 직렬화/역직렬화 한다면,

 

 

abstract를 사용하던 virtual을 사용하던 아무런 걱정이 없는 것입니다.

 

 

Github나 다른 블로그의 글들을 참고하다보면 PlayerData, ItemData 등

 

 

각 클래스 별 필요한 프로퍼티들을 ScriptableObject로 구현하는데,

 

 

지금까지 든 생각은, 음... 왜? 굳이? 라는 생각이었지만

 

 

이제서야 그렇게 나눈 이유를 알 것 같습니다.

 

 

또한 그런 엔티티별 고유 ID를 만들고 지정해둔다면 더욱 더 데이터를 관리하기 수월해질 것입니다.

 

ex) Entity 종류 1. 플레이어 2. 몬스터, 3.NPC 등...

 

---

[엔티티 번호 EID]

 

(1)001 => 플레이어

 

(2)001 => 몬스터

 

(3)001 => NPC

---

 

 

---

 

 

이번 주 KPT

 

이번 주가 마무리 되면서 팀 회고를 해볼까 합니다.

 

 

특히, 이번 주 변경 된 팀에서는 제가 팀장이었기에 때문에 더욱 와닿지 않았을까 싶습니다.

 

 

---

KEEP

---

 

1. 

 

4 - (1:휴식) - 4 - (1:휴식) - (2:마무리) 형식으로 이루어지는 캠프 시간에서

 

4시간의 집중 시간을 갖고,

 

1시간 휴식 후,

 

머리가 맑아진 상태에서 서로의 현재 진행 상황과 애로 사항을 확인했습니다.

 

 

이로 인해서 팀이 좋은 방향으로 나아갈 수 있게 문제점을 잡아갈 수 있었습니다.

 

 

 

2.

 

마무리 시간은 반드시 문제점, 풀리지 않는 코딩 등을 코드 리뷰를 통해서

 

서로의 코드를 화면 공유하며 의견을 나눴습니다.

 

또한 문제점 지적, 방향성 제시만을 하는 것이 아닌,

 

좋았다고 생각한 부분을 솔직히 말하여 서로를 칭찬하는 것을

 

반드시 실행하여 팀 분위기를 좋게 만들고 코딩에 자신감을 붙여줄 수 있었습니다.

 

 

---

Problem

---

 

다행히도 문제점은 없었습니다.

 

KEEP에 적었던 사항들이 문제점을 대부분 해결해준 것 같습니다.

 

---

TRY

---

 

이번에 깃허브에 프로젝트를 PUSH 및 Commit 후에 README를 작성하려고 했으나,

 

마크다운으로 작성해야한다는 것을 알고 난항을 겪게 되었습니다.

 

그 결과 작성을 못하였으나, 다음 프로젝트 때는 반드시 작성해보는 시간을 갖겠다고 판단했습니다.