티스토리 뷰
실시간 게임이라 하더라도, 내부적으로는 모든 게임의 구성은 턴으로 구성하는 것이 좋다. (실제 초당 n프레임 같은 개념에서 각 프레임은 턴과 같은 개념이기 때문이다.)
이 턴의 동작 주기를 입력, 렌더, 로직 등을 잘 구분지어 처리하는 것이 좋다.
예를 들면, 입력은 1초에 5번, 렌더는 1초에 30번, 로직은 1초에 5번 등의 턴 기준을 명확히 정해 쪼개 놓는 것이 좋다.
그래야 네트워크 동기화, AI 구현 등의 처리 규정을 명확히 세울 수 있다.
로직을 1초에 5번으로 규정을 짓는다면, 한턴은 200ms이고, 200ms동안 이루어진 로직의 변화는 묶어서 다른 클라이언트로 전송하고, 내 변화도 묶어두었다가, 다른 유저의 정보를 수신한 다음턴이 돌아올 때 처리하는 식으로 구성하면 된다.
LOL의 경우에도 4단계를 두고 지연 시간에 따라 턴이 어떻게 밀리는가를 표시한다.
위에 언급한 방식으로 구현을 하면, 처리 규정이 명확하므로 지연시간 발생시에 얼마만큼의 늦은 반응성을 보여줄 것인지가 표현 가능하고, 이를 본 사용자가 자신이 겪고 있는 상황에 따라 판단이 가능하다는 장점이 있다.
로직 처리 방식 분류
액션 베이스
- 현재 값 수신.
- 이전 -> 현재 보간.
이벤트 베이스
- 명령에 대해 전달. 새 명령을 수신하거나, 기존 명령을 완수할 때 까지, 기존 명령을 수행함.
어떠한 방식을 취하던 크게 상관없으나, 기본적으로 이벤트 베이스를 두는 것이 지연에 대처하기 조금 더 유연한 방식이라고 할 수 있다.
액션 베이스는 보간을 위한 기준값이 있으며, 이를 넘어서서 늦게 도달시에는 그만큼 어색할 수 있고, 지연이 조금이라도 발생한다면 지연 시간 동안 어떤 액션을 취해야 하는지 알 수 없기 때문이다.
이벤트 베이스라고 해도, 지연시간이 일정 시간이 넘어서면 제대로된 반응성을 보장하지 못한다. 하지만, 사용자의 입력이 적용 완료될 때까지의 시간동안 보여줄 이벤트가 존재하기에 상대적으로 여유가 있다.
물론 이벤트 베이스에서도 지속적으로 지연시간이 발생한다면 제대로 된 플레이는 어렵다고 볼 수 있다. (롤 400핑 이상에서의 플레이에서의 반응성은 정상적인 게임 진행이라 보기 어렵다)
그렇지만 이벤트 베이스로 구성되어야 이벤트를 묶거나, 이벤트 적용 과정도 조금 더 매끄럽기 때문에 이벤트 베이스 방식으로 구현하길 권장한다. (상대방의 이벤트 수신 코드와, 내 이벤트 처리 코드 부분을 일체시켜 나의 플레이와 상대방의 플레이를 구분 짓지 않고, 모든 것을 이벤트로 처리하기 쉽게 코드가 작성될 수 있기 때문이다.)
'Network' 카테고리의 다른 글
FlatBuffers Guide (0) | 2016.07.22 |
---|---|
동기화에 대한 간략 정리 (0) | 2016.06.30 |
TCP/IP, UDP 주요 포트 (0) | 2013.03.22 |
ncftp 사용법 (0) | 2011.02.17 |
FTP Passive / Active 모드 (0) | 2011.02.17 |
- Total
- Today
- Yesterday
- svn
- 엘키
- EzShortcut
- Rails
- 리버스 엔지니어링
- TraceRoute
- ftp
- 디버깅
- 멀티스레드
- 디자인 패턴
- 게임데브포에버
- perfmon
- 임백준
- MS-SQL
- RoR
- TDD
- 루비
- 게임개발포에버
- EasyExec
- CppSQLite
- 바로가기 프로그램
- SQLite Spy
- 조엘 온 소프트웨어
- c언어
- 좋은 프로그래머
- 루비 온 레일즈
- NDC2013
- ruby
- Ruby on Rails
- SDL
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |