16일

17일

Turn Base Web RPG을 만들면서 느낀점

  • Turn Base로 만든 이유
    1. latancy 에 민감하지 않아서 최적화를 안해도 된다고 생각함.
    2. req/res 모델로 나타낼수 있을것이라고 생각해서 Web 이랑 유사할듯 하여서
    3. Game Rule을 바닥 부터 만들기에는 게임 기획부분이 문외한이라 힘든데, 기존의 TRPG(Table RPG, D&D 나 GURPS)에서 Rule을 참고 할수 있다고 생각함. 대부분의 TRPG는 Turn Base 이므로.
  • 기존 Web Application 와 Turn Base Web RPG의 차이점
    • Web Application은 모든 데이터를 DB에 저장해두고 Web Application 자체에는 (세션을 제외하고) 별다른 Data를 두지 않는 경우가 많으나, RPG의 경우에는 데이터를 종종 Memory 상에만 두고 DB에 Sync 해야 하는 경우가 많음.
    • Web application 은 정형 데이터가 많고, RPG의 경우 비정형 데이터가 많음. 특히 개발하다보면 기존 Web Application 만들듯 RPG 만들면, 아무리 ORM을 쓰더라도 데이터 모델링 하는데 많은 시간을 쏟게 되고, 그 데이터모델도 자주 바뀌게 되어 다시 작업해야 하는 경우가 속출.
      • 예를들어 HP/MP를 가지는 캐릭터만 있다가 액션 포인트를 사용하는 도적을 추가 하기 위해 HP/AP 구조도 가질수 있게 바꾼다고 하자. 그러면 아무리 ORM 을 쓰더라도 머리가 터져나가게 된다.
      • NPC나 적의 경우에도 AI 등을 짜게 되면 추가 정보를 그 NPC 에게 저장해야 하는 순간이 온다. 그러면 Table 구조를 갈아 엎거나 새로운 테이블을 만들어 추가 정보를 저장하고 Join 으로 얻어오거나 해야하는 등, 상당히 복잡해 진다. 그런 데이터들은 사실 Memory 에 저장하는 것이 맞는데, 이런경우 Session Store 가 또다른 변수로 작용한다(용량 제한이 있거나 Type의 제한이 있거나).
    • Web Application의 한 유져의 동시접속은 별로 상관 없지만, RPG 에서는 문제가 된다.
      • 허용 하지 않는다면, 인증 단계에서 동시접속을 막기위한 방안들을 만들어야 한다.
      • 허용 한다면, 한쪽에서의 동작이 다른 쪽에도 반영이 되게 만들거나, Input이 특정 Sequence 대로 될수 있도록 동시성 제어 되어야 한다.
      • 이 부분을 잘못한다면, 버그의 온상이 된다.
    • Web Application 의 경우 서버에서 주기적으로 동작하는 작업이 Batch 로 무언가 하는 정도면 충분하지만, RPG의 경우 Turn Base 인데도 서버의 로직(그러니까 일반적인 게임에서 하듯 Loop 돌리고 계속 해서 처리 하는)이 필요하다.
      • 이게 처음에 잘못 생각했던건데 Turn Base 이니까 Req/Res 만으로 충분 할것이라 생각했다. 그런데 Multiplay 요소가 들어가면, 별도의 Server Loop(뭐라고 칭할지 이름을 모르겠다)가 필요하다. 나의 경우에는 지역들을 Faction 들이 월드맵단위에서 서로 서로 점령 하는 일종의 End contents를 도입하려 했고, Player 들이 PvE 전투를 해당 지역에서 할때마다 점수가 획득되서 소속 faction 이 점령하기 더 쉬워지는 그런 Logic 을 도입하려 했다. 그런데 가만히 생각해보니 Player인원이 적을떄도 전선이 고착화 되지 않고, 무언가 움직이는 느낌을 주려고 하니 그 서버 루프가 필요해 졌다.
        • 사실 멀리 갈것도 없이 각 턴에 시간제한이 있다고 하면, 시간 제한 완료 되는 것을 체크하여 상대 턴으로 넘겨주거나 해야 하면 어쨌든간에 이런 로직이 필요하게 된다.
    • Web Application 은 SPA 로 하더라도 Client 에서 주기적 Looping animation 이 필요하지 않지만, RPG는 필요하다.
      • 이건 사실 WebGL을 쓰려다 보니 그렇게 되는 것 같긴 하다.
    • Web Application에서 Server push 는 반드시 필요한 경우가 잘없는데, RPG는 대부분 필요함.
      • 일단 시간 제한 같은경우에는 당연하고…
      • Req/Res 모델에 잘 안맞는 다는 반증이기도 하다.
  • Web Application 과 Turn Base Web RPG의 기술 스택
    • 쓰이는 기술은 큰 차이가 없다.
      • WebGL 에 욕심 내는 것만 아니면…
    • SPA를 만드는 감각으로 만들면 되긴 하는데, 순서와 우선순위의 차이가 있다.
    • 순서와 우선순위의 차이일뿐 결국 최종적으로 쓰거나 구현하는 방식 같은것은 거의 비슷 하다.
  • Turn Base Web RPG를 만들때 Tip
    • Data Store는 그냥 KV로 하고, Join이 필요하다고 생각되면 그냥 Application 단에서 처리하는것이 개발이 편하다.
      • 데이터 저장을 너무 고민 하지 않고, 그냥 JSON 으로 때려박는 다는 생각으로 처리 하는것이 편하다.
      • consistancy 에 너무 집착하지 않는것이 좋다.
    • 하나의 Request에 Response 가 여러개 되어야 하는 상황들이 오는데 두가지 해결법이 있다.
      • Response를 애시당초 Array 같은것으로 Return 하게 만드는것
      • Response는 그냥 Accept만 표현하고 처리 결과는 Web Socket 같은 server push 로 전달하는것
    • Client 는 반드시 Redux 같은 구조를 갖추는게 좋다. Redux기준으로 Action에서 Animation을 처리하고 State에 반영하게 하면 된다.
      • 단, Redux로는 이렇게 못하게 되는 케이스도 생기므로 Redux 비슷한것을 직접 구현 하게 되는 케이스가 생긴다.
      • 애시당초 Redux의 컨셉자체가 어려운것이 아니므로 필요한 만큼만 직접 구현해 쓰는것이 그리 어렵지는 않다.

23일

last update: 2020-06-23T04:26:51Z