즐거운 토요일... 코딩을 시작해보자.
오늘의 목표는 인벤토리를 어느정도 구현해보는 것이다.
구현에 앞서서...
인벤토리란 무엇일까?
흔히, '가방' 으로 표현되는 인게임 기능으로, 캐릭터가 항상 들고 다니는
아이템 보관함 같은것 이라고 할 수 있다.
어플리케이션 마다 인벤토리의 형식은 많은 차이가 있지만,
내가 생각하는 인벤토리의 가장 기본적인 기능은,
아이템의 소유자를 명시하는 테이블 이라고 보고 있다.
가질 수 있는 아이템의 한계치, 혹은 수량의 중첩 등 부가적인 기능들이 있지만,
기본적으로 어떤 아이템을 '누가' 소유하고 있고, 그 소유자만이 해당 아이템을 사용 할 수 있게 하는것이
인벤토리의 가장 기초적인 기능이라고 생각된다.
그것을 중점으로 생각하여 우선 테이블을 만들어 보았다.
inventoryNumber 는 아직 어떤 기능을 할 지 모르겠지만 왠지 필요할 것 같기에 일단 넣어둔 것이고,
결국 캐릭터의 Id 와 아이템의 Id만 있다면 아이템의 소유를 명시 할 수 있을것이라 생각하고 만들어봤다.
해당 인벤토리 테이블은 서버 내의 '모든' 캐릭터가 소유한 '모든' 아이템을 담게된다.
때문에, 인벤토리는 동일한 캐릭터가 여러번 들어갈 수 있어야 하며,
같은 아이템 또한 여러개의 소지가 가능하기 때문에,
itemId 와 CharacterId를 모두 1:N 관계로 설정했다.
이를 통해 만들어진 인벤토리의 모습
여기서 한가지 문제점 (한가지 만은 아닐테지만)을 발견했다....
현재로서는,
캐릭터의 Id를 특정 할 수가 없는 상태이다.
왜냐하면 지금 구현된 부분은, 계정 로그인만 하고 캐릭터는 따로 접속하는 개념이 없기 때문에,
계정 외에는 특정할 수 있는 부분이 없다.
해결 방안..?
1. 한 계정 당 캐릭터 하나로 제한하여 사실상 캐릭터===계정으로 만들어버린다.
-> 제작 의도와 거리가 멀기 때문에 탈락
2. /api/:character_id/ item~어쩌구 저쩌구
- 캐릭터 id를 params 로 받는 방법.
-> 거의 모든 api 에서 해당 character_id가 계정내 캐릭터가 맞는지 검사해야한다.
-> 유저와 서버와 개발자 모두 별로인 방법
3. 로그인 처럼 캐릭터 접속 기능을 만든다.
-> 지금 생각나는 방법 중에선 가장 그럴싸하다.
당장 해보자.
계정 로그인 API 와 캐릭터 삭제 API의 형식이 묘하게 합쳐져서 캐릭터 접속 API 가 되었다.
하지만, 문제를 해결하려 할 수록 오히려 문제가 늘어가고 있다...
접속에 성공했다면, 해당 캐릭터Id를 어디에 저장해야 할까?
쿠키를 두개 쓴다? 제대로 참고할 수 있을지도 잘 모르겠고,
모든 매 통신마다 보내는 쿠키가 하나 더 늘어나는것은 좋지 않은데다가,
해당 과제 요구사항이 뜻하는 것이 아직 제대로 이해가 되지 않기 때문에
어떻게 해야할지 모르겠다.
진전이 없기 때문에, 일단은 지금의 cookie 를 계속 사용하고 나중에 방법을 다시 알아보기로 했다.
다시 돌아가...자 마자 문제 발생 !!
authMiddleware 가 로그인정보 + 캐릭터 정보 모두 검증하게 만들 계획이었지만,
캐릭터 접속을 하기 위해서는 로그인이 되어야 하기 때문에 authMiddleware 검증이 필요하다.
마치,
자물쇠가 걸린 방 내부에 자물쇠 열쇠가 있어서 못들어가는것 과 같은 상황이다.
해결방안
1. 캐릭터 접속까지 authMiddleware 검증 없이 어떻게든 해결한다??
-> 캐릭터 접속, 생성, 삭제 등 로그인 만 하면 되는 기능들을 전부 직접 검증해야한다
2. 로그인 시 임의의 캐릭터 정보 값을 부여하여, 캐릭터 접속을 가능하게 한다.
-> 임의의 값 일때 캐릭터 접속 이외의 검증은 통과해선 안되기 때문에
검증을 필요로 하는 모든 API 에 추가 조건을 만들어야 할듯..
3. authMiddleware 를 2가지로 나눈다 !! (계정 검증 / 계정+캐릭터 검증)
-> 정말 내키지 않는 방법인데 일단 이 방법이 그나마....
생각해보면
로그인만 해도 가능해야하는 API (캐릭터 생성, 캐릭터 접속, 캐릭터 삭제) 와
캐릭터 접속까지 해야 가능한 API 어느정도 분리되어야 하기 때문에,
authMiddleware 2가지로 나누는게 아주 나쁜 선택은 아닐것이다.
( 평일이 되면 관련 내용을 튜터님에게 피드백 받아보자 )
어렵진 않으니 만들고보자.
그냥 복붙으로 두개로 나눈다음에, 필요한 곳에서 각각 불러오고, 적용하면 끝이다.
캐릭터 접속까지 한 경우를 검증하는 connect.auth 에서는
추가로 char 값이 이상할 때 에러를 발생하게 하면 된다.
이 작은 차이 때문에 복사를 해야한다고?! 생각이 되긴한데 다른 방법이 당장 떠오르지 않는다..
이 타이밍에..... 엄청난 반전이 있었으니...
이럴수가 ...?!?!?!?
도전기능
에 해당하는 부분에서, 캐릭터ID 를 param 으로 받는다는 내용이 기재되어 있었다...
필수 과제만으로 벅찰것 같아서 자세히 확인을 안해본 도전과제에
저런 내용이 있었다니 !!
사실 이는 해당 글의 상단에 있는
2번 해결방안에 해당하는 내용이었다.
그 해결 방안이 과제에서 제시한 방법이었던 것이다.
음.. 별로인.. 방법 아닐지도 ? ㅎ
