Lockstep 서버는 주로 멀티플레이어 실시간 게임에서 사용되는 전투 동기화 방식의 하나입니다. 특히 빠르고 정밀한 액션이 중요한 게임에서 클라이언트 간의 상태를 정확히 동기화하기 위해 사용됩니다.
Lockstep 방식이란?
"모든 클라이언트가 같은 입력만 보내고, 게임 로직은 각자 클라이언트에서 똑같이 실행한다"는 철학의 네트워크 구조입니다.
Lockstep 방식에서는 "누가 언제 어떤 입력을 했는가"를 모든 유저가 공유하고, 그 입력을 동기화된 타이밍에 실행합니다.
핵심 개념
- 모든 클라이언트가 매 프레임의 입력(조작 정보)만 서버에 보내고, 서버는 이 입력을 모든 클라이언트에 전달합니다.
- 각 클라이언트는 동일한 게임 상태에서 동일한 입력을 받아, 동일한 로직을 실행해서 결과적으로 똑같은 게임 상태를 유지합니다.
Lockstep의 동작 흐름
- 입력 수집: 각 플레이어는 자신의 입력(이동, 공격 등)을 서버에 전송.
- 입력 동기화: 서버는 일정 간격(예: 1프레임마다)으로 모든 플레이어의 입력을 모아서 전체 클라이언트에 전송.
- 입력 처리: 모든 클라이언트는 동일한 입력을 동일한 순서로 받아서 동일한 로직을 실행.
- 결과 유지: 이를 통해 모든 클라이언트가 같은 게임 상태를 유지하게 됨.
그래서 다수의 플레이어가 빠른 속도로 스킬을 쓰고, 몹을 피하고, 콤보를 이어가는 액션 게임에서는
- 서버에서 위치나 상태를 1초에 몇 번씩 보정하는 일반적인 방식(Authority 서버 방식)으로는 지연과 부정확성이 발생.
그래서
- 모든 플레이어의 입력만 공유하고,
- 동일한 물리/판정 로직을 클라이언트가 실행하도록 하여, 빠른 액션에도 정밀한 동기화를 유지하려는 구조를 선택함.
LockStep Server의 Frame 동기화 방식을 사용하려면?
1. 완전히 동일한 게임 로직
- 클라이언트는 모든 계산이 100% 동일하게 실행되어야 함.
- 예: 물리 엔진, 판정, 피해량 계산, 스킬 범위 처리 등
2. 결정론적(Deterministic) 계산
- 같은 입력이 들어오면 언제나 같은 결과가 나와야 함
- 예: Random을 쓰더라도 같은 seed를 사용해야 함
→ 그래서 UnityEngine.Random 대신 System.Random(seed)처럼 관리
3. 부동소수점 연산 통일
- 부동소수점(Floating-point) 연산이 플랫폼마다 미세하게 다를 수 있음
→ Windows vs Android vs iOS 등에서 연산 오차 발생 가능 - 그래서 아예 정수 기반 fixed-point 수학을 쓰기도 함 (ex: FixMath.NET)
4. 입력 지연 처리 (Input Buffering)
- 네트워크 지연을 감안해서 2~3프레임 뒤에 입력을 적용
→ 입력이 늦게 도착해도 모두가 동일한 프레임에서 실행하도록 조정
5. Logic층을 Unity의 LifeCycle에 종속되지 않도록 분리한다.
6. Logic층에 "나"와 같은 개념이 존재하면 안된다.
7. 실행순서의 보장 (= View / Logic 분리)
오차가 생기면?
예를 들어, 클라이언트 A에서 적이 죽었는데, 클라이언트 B에서는 살아있다?
그 순간부터 게임 상태가 분기(fork)되고, 몇 초 지나면 완전히 다른 세계선으로 나뉘어버림
그래서 던파 모바일이나 RTS 게임(스타크래프트 등) 같은 데선
초기화/재동기화 기능도 구현해서 오차 발생 시 서버가 강제로 게임 상태를 덮어씌우거나 재실행하기도 한다.
장점
- 매우 정밀한 동기화 가능 (입력만 공유하므로 지연이 적음)
- 데이터 전송량의 최소화
- 빠른 반응이 필요한 게임에 적합
- 손쉬운 Replay 기능 구현
단점
- 모든 클라이언트가 동일한 로직을 가져야 함 (심지어 부동소수점 오차도 관리해야 함)
- 네트워크 지연 문제 : 하나라도 느린 클라이언트가 있으면 전체가 기다려야 함 (lockstep, 즉 “잠금 발걸음”처럼 함께 움직여야 해서)
- 서버 운영 비용
- 높은 개발 난이도 (여러 로직들이 필요)
- 반응 속도 저하
728x90
'네트워크' 카테고리의 다른 글
MMORPG 서버 (기록용) (3) | 2025.06.02 |
---|---|
게임 네트워크 (1) | 2025.05.31 |
터널링(Tunneling) (0) | 2025.05.23 |
gRPC (1) | 2025.01.16 |
RESTful API (0) | 2025.01.16 |