문의 응대 : 평일 오전 10시 ~ 오후 6시
문의를 남기실 경우 다음 항목을 작성해 주세요.
정보가 부족하거나 응대시간 외 문의하는 경우 확인 및 답변이 지연될 수 있습니다.
- 뒤끝 SDK 버전 : 5.8.0
- 프로젝트명 : 다크니스
안녕하세요. 질문 드리기 전에 한 가지 제가 대장장이의 전설을 운영했었는데, ios는 현재 운영하지 않아 테스트 상태로 프로젝트를 설정했습니다. 그런데 계속 문자가 날아오네요. appstore 인증 번호가 유효하지 않다구요. 이 부분 처리 부탁드리겠습니다. 아니면 제가 따로 설정을 해야 할까요?
본론입니다! 뒤끝서버 너무 잘 이용하고 있습니다. 질문이 있는데요. 현재 저장 방식 자체가 자꾸 403 오류 (일시적으로 접속 차단)가 발생합니다. 현재 인게임 내 저장 방식을 다음과 같이 사용하고 있습니다.
- 1분마다 10개 테이블(전체 데이터) 자동 저장
- 각종 뽑기 저장 (1.5초의 딜레이 존재) (뽑기 아이템이 존재하는 테이블)
- 메뉴창을 닫을 때 10개 테이블 전체 저장
현재 테이블을 여러개로 나누어 [PlayerInfo, ShopInfo, Inventory 등] 총 10개의 테이블에 데이터를 저장하는 형태로 사용하고 있는데요. 그러다 보니, 예를 들어 장비 뽑기를 진행하면 장비와 플레이어가 사용한 보석 등이 저장되어야 해서 PlayerInfo, Inventory, QuestInfo 3개의 테이블을 저장하게 됩니다. 그런데 저장 방식이 샌드큐 방식으로 Where 절을 사용해 저장하다 보니 매번 플레이어의 Indata를 불러오는 함수와 업데이트 함수를 2번 호출하게 됩니다.
정리해보자면, 무기 뽑기를 하는데 서버 호출을 총 6번이나 하게 됩니다. (1). PlayerInfo 테이블의 Indata값, (2). PlayerInfo 테이블 업데이트 (3). Inventory 테이블의 Indata값 (4). Inventory 테이블 업데이트 (5). QuestInfo 테이블의 Indata값 (6). QuestInfo테이블 업데이트 이런식으로요.
아무래도 제 저장 방식이 이상한것 같은 생각이 들어서요. 아니면 다들 이런식으로 진행하고 계신건지 하는 의문입니다. 혹시 더 나은 방법이 있을까요? 아무래도 1개의 테이블에 정보를 너무 많이 넣으면 그게 더 부하가 오고 추후 CS를 진행할때 어려움이 있을 것 같아 테이블을 나누다 보니 10개나 된 것인데요. 차라리 그런건 생각하지 않고 PlayerInfo 테이블로 모든 데이터를 모조리 저장하는 것이 더 좋은 방법일까요?
출시가 코앞으로 다가와 만약 현재 저장 방식보다 더 좋은 방법이나, 방식을 추천해주실 만한 것이 있을까하여 문의 남겨봅니다. 감사합니다.