영속성

24시간 연중무휴 항상 온라인 배포로 지속형 월드를 관리하세요 프라이빗 플릿.

많은 장르(MMO, 샌드박스, 소셜 게임)는 지속형 월드를 활용해 플레이어가 다음을 할 수 있게 합니다:

• 새 친구를 만나고 교류하며, 자연스럽게 형성되는 플레이어 커뮤니티를 육성하고,

• 플레이어가 배치한 사용자 생성 콘텐츠로 가득한 살아 있는 오픈 월드를 탐험하고,

• 대규모 그룹 또는 전체 길드와 함께 수시간에 걸친 장대한 레이드 전투에 참여합니다.

다음을 위한 전략을 살펴보세요 최상의 플레이어 경험을 제공하고, 비용을 통제하며, 다운타임이나 롤백으로 인한 플레이어의 불만을 없애세요.

또는 다음을 참조하세요 배포 부분 vCPU 가격 책정을 활용하는 클라우드 오케스트레이션.

✔️ 준비

지속적이고 중단 없는 24시간 연중무휴 항상 온라인 배포를 활성화하려면:

1. 새 앱 버전(또는 기존 버전 업데이트)을 만드세요.

   • 대시보드에서 - 최대 지속 시간을 지정하는 대신 "persistent"를 선택하세요.

   • API에서 - 다음을 지정하세요 "max_duration": -1 를 앱 버전 요청에 포함하세요.

2. 대시보드에서 비공개 플릿을 만들고 호스트를 예약하세요.

   1. 플릿 생성은 무료입니다. 먼저 이를 수행해 위치와 세부 정보를 미리 보세요.

   2. 가상 머신(성능) 또는 베어 메탈(오버드라이브) 사양을 선택하세요.

   3. 호스트를 예약하기 전에 최종 가격을 확인하라는 안내가 표시됩니다.

3. 다음을 사용하여 새 서버를 배포하세요 서버 브라우저 또는 사용자 지정 통합을 사용하세요.

   1. 서버 브라우저는 구성된 설정에 따라 서버를 시작합니다 스케일링 정책.

   2. 사용자 지정 통합은 다음을 해야 합니다 비공개 플릿 API를 사용해 서버를 시작해야 합니다.

서버 스케일링과 종료 프로세스를 테스트하여 비용 제어의 신뢰성을 확인하세요. 메모리에 저장된 서버 상태는 배포가 중지되면 손실됩니다. 다음을 참조하세요 영속성.

도움이 필요하시면 디스코드를 통해 문의해 주세요. 실시간 게임 지원은 저희의 티켓 시스템.

🔑 서버 소유권

엣지 컴퓨팅과 함께하는 최신 소유권 모델과 전통적 소유권 모델의 장단점.

스튜디오 호스팅

서버는 전통적으로 스튜디오가 관리하며, 호스팅 비용은 게임 수익에서 회수합니다.

👍 장점

• 추가 플레이어 요금 없음 - 호스팅 비용은 스튜디오 수익에서 회수됩니다.

• 클라이언트/서버/서비스의 느슨한 결합으로 클라이언트/서버 호환성이 뛰어납니다.

• 게임의 폐쇄형 소스 코드 덕분에 치팅과 악용에 더 강합니다.

👎 단점

• 서버 무결성과 공정성을 보장하기 위해 커뮤니티 모딩 지원이 제한됩니다.

커뮤니티 서버

플레이어가 Edgegap에서 자신만의 서버 비용을 부담하도록 하고, 사용자 경험에 대한 통찰이 부족한 제3자 호스팅 서비스로 흘러갈 호스팅 수익을 확보하세요.

👍 장점

• 선별된 모드와 버전을 통해 모딩 지원을 강화하세요.

• 커뮤니티와의 직접 협업을 통해 게임을 점진적으로 개선하세요.

• 게임 수명 연장과 셀프서비스 모델로 커뮤니티의 신뢰를 구축하세요.

👎 단점

• 모딩 지원과 호환성을 위해 개발 투자가 필요합니다.

• 커뮤니티와 결제 시스템을 관리하기 위한 운영 노력이 더 필요합니다.

• 게임 내부를 노출함으로써 역공학 위험이 증가합니다.

🥛 용량 및 스케일링

서버 비용과 서비스 품질을 최적화하는 고급 기법을 배우세요.

자동 확장 참조 아키텍처

배포를 수동으로 시작하고 URL과 포트를 붙여넣는 것만으로는 라이브 게임에 충분하지 않습니다.

다음 중 하나를 사용해 세션 관리 및 필요에 따른 확장을 위한 인기 게임 흐름을 자동화하세요:

매치메이킹:

• 짧은 라운드

• 온디맨드 매치

• 실력 등급 및/또는 사용자 지정 규칙

서버 브라우저:

• 지속형 또는 라운드

• 소셜 지역 허브

• 자동 할당 및/또는 사용자 지정 검색

사용자 지정 백엔드:

• 라이브 게임 마이그레이션

• v2 API로 배포

• 웹훅 관찰

용량

배포는 활성 플레이어 연결을 추적하거나 관리하지 않습니다 이후에 배포 모든 설계를 구현할 수 있도록 완전한 제어권과 자유를 제공합니다.

서버가 다음을 만족하도록 용량 관리를 구현하세요:

• 호스팅 비용을 통제하고 - 벤치마크하며 플레이어당 서버 리소스 사용을 최적화하고,

• 일관된 경험을 제공하며 - 서버당 CCU를 안전한 범위로 유지하세요.

다음을 참조하세요 서버 브라우저 관리형 서비스로 자동화된 용량 처리를 지원합니다.

팁: 사용자 지정 세션 및 용량 오케스트레이터를 개발하기로 선택한 경우.

• 절차는 동시 예약과 용량 경쟁이 발생하지 않도록 해야 합니다.

• 서버 상태를 동기화하기 위해 오케스트레이터에 자주 하트비트를 보내세요.

• 오래되었거나 충돌했거나 중지된 서버는 검색 프로세스에서 신속히 제거하세요.

• 플레이어가 할당된 시간 내에 연결하지 않으면 용량 예약을 시간 초과 처리하세요.

• 플레이어 비활성 감지 시 클라이언트를 연결 해제하고 용량을 해제하세요.

예약된 배포 리소스의 양은 런타임 동안 변경할 수 없습니다. 조정된을 활용하는 새로운 서버 인스턴스로 수평 확장 애플리케이션 버전 더 많은 CPU 또는 메모리 리소스를 요구합니다.

스케일 업

스마트 스케일링 전략 플레이어 대기 시간을 방지하고 유휴 서버 비용을 최소화합니다.

머신 부하(CPU 및 RAM) 대신 동시 플레이어 기준으로 리소스를 스케일링할 것을 권장합니다 (CPU 및 RAM), 부하 변동으로 인해 가용성이 예측 불가능해질 수 있기 때문입니다.

스케일링에는 지역 트래픽이나 서버 비용을 '대충 추정'할 필요가 없습니다. 예약 프라이빗 플릿 을 위한 용량 저유량 시간대 그리고 예상치 못한 트래픽 급증 시 자동으로 클라우드로 오버플로우됩니다.

활성화 앱 버전에서 활성 캐싱 몇 초 안에 서버를 배포하려면.

스케일 다운

주의 없이 서버를 종료하면 플레이어 경험에 부정적인 영향을 줄 수 있습니다. 출시 전에 다음 요소를 고려하고 변경 사항을 테스트하세요:

플레이어 비활성/연결 해제 감지가 신뢰할 만한가요?

• 플레이어 입력 부재를 신뢰할 수 있나요? 플레이어는 종종 봇과 매크로로 활동을 가장해 강퇴를 피하며, 재연결 시 대기열 대기 시간이 발생합니다.

• 가짜로 만들기 더 어려운 다른 활동 지표가 있나요?

• 봇 사용의 영향/동기를 완화할 게임 디자인 우회책이 있나요?

대규모 롤백 없이 서버를 쉽고 빠르게 재시작할 수 있나요?

• 서버를 재시작하고 상태를 복원하는 데 시간이 걸릴 수 있습니다. 상태 복원이 게임 백엔드에 추가 데이터 전송 또는 서비스 비용을 발생시키나요?

• 플레이어 참여를 유지하기 위해 미니게임/로비로 서버 로딩을 숨길 수 있나요?

플레이어가 특정 서버 인스턴스에 묶여 있나요, 아니면 쉽게 이동할 수 있나요?

• 다른 서버에 연결하면 플레이어의 계정, 구매 내역, 소셜 경험, 진행도, 인벤토리, 그리고 전반적인 플레이어 유지에 어떤 영향을 미치나요?

• 다음을 검토하세요 영속성 그리고 중요한 데이터가 손실되지 않도록 하세요.

• 다운타임이 발생하더라도 투명성과 커뮤니티 관리가 큰 도움이 됩니다.

💭 구성 및 상태

서버 시드 매개변수를 정의하고, 플레이어/서버 상태를 안정적으로 관리하세요.

구성 관리

구성 또는 시드는 다음을 의미합니다 배포 중 서버에 전달되는 초기 데이터:

• 환경별로 주입되는 변수:

  • 예: 클라이언트/서버 버전 호환성 데이터,

• 서버 위치, 서버 포트 및 기타 서버 정보,

• 매치메이킹 정보 또는 사용자 지정 배포 변수,

• 서드파티 통합 매개변수, 키, 시크릿.

구성은 변경 불가능합니다. 서버 시작 시 읽히며, 런타임 중에는 수정할 수 없습니다.

상태 관리

상태는 런타임 데이터를 의미합니다, 이전 플레이어 동작 및 서버 이벤트의 결과입니다:

• 플레이어 연결, 플레이어가 제어하는 상태 변경(예: Pawn),

• 레벨/씬에 포함된 속성 변경(예: Actor, 게임 오브젝트),

• 다음과 관련된 변경 사항 게임 모드, 게임 상태, 또는 게임 씬 정보.

상태 데이터는 자주 변경됩니다. 동기화는 초당 여러 번 발생합니다(틱 속도).

빈번한 상태 백업은 데이터 손실을 방지하는 데 도움이 됩니다 예상치 못한 충돌/문제가 발생할 경우:

• 서드파티 게임 백엔드 API와의 비동기 업데이트, 예: Heroic Labs의 Nakama,

• 직렬화된 상태 파일을 다음으로 전송하는 주기적 서버 하트비트 클라우드 오브젝트 스토리지.

상태 저장 구성 요소는 일반적으로 서버 또는 플레이어 중 명확한 지정 소유자가 있습니다.

서버 소유 객체

서버 소유 객체는 서버만 조작할 수 있습니다. 연결된 플레이어는 서버 소유 객체에 대해 제한된 읽기 권한만 가집니다.

서버 소유 객체는 대체 서버에 의해 복원될 수 있습니다(상태 마이그레이션). 일반적으로 동시에 실행되는 서버 간에 공유되지 않습니다(요구 사항: 서버 메싱).

플레이어 소유 객체

플레이어 소유 객체는 플레이어와 서버 모두가 조작할 수 있습니다. 지속형 월드 객체의 소유권을 플레이어에게 할당하면 저장과 상태 마이그레이션이 더 쉬워질 수 있습니다.

플레이어 소유 객체를 플레이어 기기 또는 게임 백엔드에 백업하세요 세션 간에. 무단 수정을 감지하려면 플레이어 상태를 암호화하고/하거나 상태 체크섬을 업로드하세요.

복구 목표

일부 데이터 범주는 데이터 손실과 복구 시간에 더 민감할 수 있습니다.

팀 내에서 다음 사항을 논의할 것을 강력히 권장합니다:

• 게임 클라이언트, 서버, 게임 백엔드에서 처리하는 데이터 범주.

• 각 범주의 데이터 손실이 플레이어와 비즈니스에 미치는 영향.

• 복구 시점 목표 - 심각한 피해가 발생하기 전 허용 가능한 데이터 손실량.

• 복구 시간 목표 - 시스템이 얼마나 빨리 복구해야 하는지.

아래의 간소화된 복구 목표 평가 예시를 검토하세요:

데이터 범주	RPO	RTO
계정, 구독, 구매	🔥 5분	🔥 30분
진행도, 인벤토리, 실력 등급	🔥 5분	🔥60분
중재, 성능, 오류 추적	⚠️ 30분	⚠️ 8시간
소셜 기능, 채팅 기록, 행동 분석	⏬ 24시간	⏬ 72시간

가장 중요한 범주에 대해서는 미리 재해 복구 플레이북을 준비하세요.

서버 충돌 처리는 사용자의 프로세스 재시작 정책. 서버 상태가 손실될 수 있습니다.

👀 관측 가능성

장시간 실행되는 지속형 서버는 새로운 관측 가능성 과제를 가져오며, 특히 모니터링, 로깅, 버그 추적에서 이상을 탐지하는 것이 중요합니다. 우리는 서버 재시작 알림 구현을 강력히 권장합니다 추적 가능성과 가동 시간에 대한 추가 감독을 확보하기 위해서입니다.

연결하세요 엔드포인트 저장소 배포 로그를 저장하려면, 그렇지 않으면 삭제됩니다!

사용자 지정 로그와 버그 추적을 추가하세요(Sentry, Bugsnag)를 추가하여 부분적 실패를 해결하세요.