게임 패치 시스템 관련 글 정리

게임 패치 시스템과 관련된 글 8개를 모으고 정리했다. 게임 패치 시스템이 기본적으로 어떻게 동작하는지에서부터 효율적으로, 잘 서비스를 하기 위해 CI/CD를 어떻게 하는지 이해를 하는데 도움이 된 글들이다. 

 

---

Those who cannot remember the past are condemned to repeat it
- George Santayana

 

과거에서 배우지 못한 사람은 과거를 되풀이한다는 말이 있다. 새로운 기술들은 확실히 과거의 기술보다 여러모로 개선된 점들이 있지만, 더 복잡하고 어렵기도 하다(물론 신기술이 더 쉬울 때도 있음). 그래서 쉽거나 조금 더 익숙하다는 이유로 과거의 기술을 선택하면 처음에야 편하지만 시간이 지날수록 새로운 기술에서는 이미 해결한 문제를 맞닥뜨리게 되기도 한다😦.

 

다 이유가 있어서 하는 것들인데 문제를 맞닥뜨리기 전까지는 그 필요성을 느끼지 못한다. 

 

그런 이유로! 

예전에는 어떻게 게임 패치/업데이트를 했고, 요즘은 어떻게 게임 패치/업데이트를 하는지를 알기위해 관련 글들을 정리했다. 

 

2011:

 

• 온라인 게임 패치를 위한 서버, 시스템 및 그 방법(링크) - 네오위즈 특허 

KR20110127434A - 온라인 게임 패치를 위한 서버, 시스템 및 그 방법 - Google Patents

 

이를 위하여 본 발명의 온라인 게임 패치 시스템은 사용자 단말이 패치 파일의 이전 버전의 온라인 게임을 하는 동안 패치 파일을 전송하는 패치 서버 및 상기 패치 서버에 접속하여 온라인 게임을 실행하는 중에 패치 파일을 수신하고, 상기 패치 서버로부터 수신한 패치 파일을 실행하는 사용자 단말을 포함한다.

 

- 온라인 게임 패치 시스템의 구성

1) 사용자 단말이 패치 파일의 이전 버전의 온라인 게임을 하는 동안 패치 파일을 전송하는 패치 서버

2) 상기 패치 서버에 접속하여 온라인 게임을 실행하는 중에 패치 파일을 수신하고, 상기 패치 서버로부터 수신한 패치 파일을 실행하는 사용자 단말

 

"패치"란 이미 정식으로 배포된 소프트웨어, 즉 운영체제 및 각종 응용 프로그램의 문제점을 보완하고, 이들의 결점을 해결해 주는 공급자의 추가 패키지라고 할 수 있다. 이러한 패치는 단순히 보안뿐만 아니라, 응용 프로그램의 실행 속도 개선, 메모리 누설 방지 등과 같이 여러 측면에서 소프트웨어의 성능을 향상시켜주기 위한 것이다. 패치는 대상 시스템에서 있어 취약성을 보완해주는 일종의 보조 프로그램이라고 할 수 있으며, 이러한 패치를 통하여 대상 시스템에 적합성을 유지하면서 배포된 소프트웨어를 업데이트 할 수 있다.

특히 온라인 게임의 경우 배포 이후 게임이 업데이트 되거나 오류를 발견하여 수정을 해야 하는 경우가 생기는데, 이러한 경우에도 패치를 통하여 업데이트를 하거나 오류를 수정할 수 있다. 게임의 재미 요소, 신규 아이템 등의 변경을 통해 완성도를 높여나가기 위한 작업이 계속 진행되므로 온라인 게임의 경우, 패치 작업이 필수적이다.

- 패치

1) 이미 정식으로 배포된 소프트웨어, 즉 운영체제 및 각종 응용 프로그램의 문제점을 보완하고, 이들의 결점을 해결해 주는 공급자의 추가 패키지

2) 보안뿐만 아니라, 응용 프로그램의 실행 속도 개선, 메모리 누설 방지 등과 같이 여러 측면에서 소프트웨어의 성능을 향상시켜주기 위함

 

- 온라인 게임 패치

1) 게임 업데이트 또는 오류 수정

2) 게임의 재미 요소, 신규 아이템 등의 변경을 통한 완성도 향상

 

기존엔 패치 파일을 1:1로 다운로드하여 설치하였는데 이 방법이 가장 보편화된 패치 형태로 가장 안정한 방법이다. 하지만 많은 네트워크 트래픽 비용이 발생하고 패치 시간이 사용자의 네트워크 환경에 의존적이라는 문제점이 있다.

기존의 다른 패치 방법으로, 패치 파일을 작은 단위의 파일들로 패킹하여 (Resource Packing) 특정 단위파일만 패치가 가능하도록 하는 방법이 있다. 수정된 내용만 패치가 가능하다는 장점이 있지만 게임 개발사의 입장에서는 배포자가 제공한 Pack Library를 사용한 추가작업이 필요하다는 문제점이 있다.

기존의 다른 패치 방법으로 이진 파일의 형태인 패치 파일에서 수정된 부분만 추출하여 해당 영역만 패치하는 방법이 있다. 이 방법은 많은 네트워크 비용을 절감하고 효율이 높을 경우 사용자 패치 시간이 감소한다는 장점이 있지만, 각 패치마다 제어하기 힘들고, 그에 상응하여 별도 파일을 생성하여야 하는 문제점이 있다. 또한 패치하는데 시간이 많이 들고 운영 비용이 증가하는 문제점도 있다.

기존의 다른 패치 방법으로 게임 실행시 필요한 최소한의 파일만 다운로드 받아 프로그램 실행 후 필요한 파일을 하나씩 다운로드 받는 방법이 있다. 이 경우 클라이언트에 전체 프로그램 패키지를 다 설치할 필요가 없다는 장점이 있지만 사용자 네트워크의 환경 변수에 매우 민감하여 다운로드해야 할 파일이 많을 경우 게임이 멈출 수 있는 문제점이 있다.

- 게임 패치 방법 

1) 패치 파일을 1:1로 다운로드하여 설치 > 많은 네트워크 트래픽 비용이 발생하고 패치 시간이 사용자의 네트워크 환경에 의존적

2) 패치 파일을 작은 단위의 파일들로 패킹하여 (Resource Packing) 특정 단위파일만 패치 > 수정된 내용만 패치가 가능하다는 장점이 있지만 게임 개발사의 입장에서는 배포자가 제공한 Pack Library를 사용한 추가작업이 필요

3) 이진 파일의 형태인 패치 파일에서 수정된 부분만 추출하여 해당 영역만 패치 > 많은 네트워크 비용을 절감하고 효율이 높을 경우 사용자 패치 시간이 감소한다는 장점이 있지만, 각 패치마다 제어하기 힘들고, 그에 상응하여 별도 파일을 생성하여야 하는 문제점이 있음. 또한 패치하는데 시간이 많이 들고 운영 비용이 증가함.

4) 게임 실행시 필요한 최소한의 파일만 다운로드 받아 프로그램 실행 후 필요한 파일을 하나씩 다운로드 > 클라이언트에 전체 프로그램 패키지를 다 설치할 필요가 없다는 장점이 있지만 사용자 네트워크의 환경 변수에 매우 민감하여 다운로드해야 할 파일이 많을 경우 게임이 멈출 수 있는 문제점

 

 

• 게임 애셋 스트리밍 패치(링크) - SlideShare 넥슨 프론티어팀 이승재님 

게임 애셋 스트리밍 패치

- 스트리밍 패치

1) 필수적인 애셋을 다 받으면 바로 게임 시작(나머지는 필요할 때 받음)

2) WoW: 대격변에서 사용함

 

- 기존 온라인 게임 패치 vs 스트리밍 패치

1) 기존 온라인 게임 패치: 모든 파일이 최신이 아니라면 패처를 실행함. 패처가 모든 파일을 최신 버전으로 맞추고 다시 게임을 실행함. > 게임과 패처가 완전히 분리됨

2) 스트리밍 패치: 작동에 필요한 최소한의 파일을 우선 받음. 게임 도중에도 다운로드 작업이 필요함. > 작동에 필요한 최소한의 파일 리스트가 필요하고 게임 클라이언트가 패처 기능을 포함해야 함.

 

2013:

 

• 게임제작개론 : #8 게임 제작 프로세스 (링크) - SlideShare NHN NEXT 구승모님

게임제작개론 : #8 게임 제작 프로세스

 

게임 제작의 전체적인 프로세스는 크게 Pre-production - Production - Post-production로 구성된다.

 

- Pre-production > 배포(release) 및 QA 프로세스 수립

1) 형상 관리(SVN, GIT 등), 이슈 트래킹 및 브랜치 구조 수립

2) 배포 도구 및 지속적 통합(CI; Continuous Integration) 도구 개발 

 

- 라이브 서비스

1) 라이브서비스는 오픈(launch) 이후의 모든 과정을 말함. 개발이 아닌 서비스 관점에서 의사 결정을 하고, 일반적으로 조직 구조가 변경됨.

2) 업데이트는 소규모 패치와 대규모 업데이트로 나뉨. 소규모 패치는 치명적인 버그 수정, 밸런스 조정 등으로 라이브 팀에서 주로 작업함. 대규모 업데이트는 콘텐츠 추가, 확장팩 등으로 차기 콘텐츠 개발팀에서 주로 작업함.

3) 이벤트는 콘텐츠 추가 없이 retention을 유지하는 대표적인 방법으로 라이브 팀과 퍼블리셔가 협의함

4) 효율적인 브런치 관리가 필요함. 안정성 확보가 최우선이므로 코드/데이터 변경이 쉽지 않음. 차기 콘텐츠 작업과 라이브의 마이너한 패치의 충돌을 피해야 함. 

 

* 게임의 규모가 커질 수록 복잡도는 제곱으로 증가한다. > CI 의 필요성

 

2014:

 

• 사설 서버를 막는 방법들 (프리섭, 더이상은 Naver) (링크) - SlideShare NHN NEXT 구승모님

사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)

 

2015:

 

• Python과 Git으로 만드는 모바일 게임 패치 시스템 (링크) - SlideShare 데브시스터즈 오영택님 

Python과 Git으로 만드는 모바일 게임 패치 시스템

 

- 패치 시스템 조건

1) 개발 환경에서 필요한만큼 독립적으로 브랜치를 정의

2) 파일이 전부 버전관리되고, 변경점이 명확하게 파악됨

3) 브랜치를 원하는 상태로 쉽게 리셋

4) 최소 변경점만이 반영되고 패치로 생성할 수 있음

 

- 구성

1) 패치 파일 서버: Git 원격 저장소로부터 최신 내용을 항상 받아옴. 클라이언트에 브랜치의 최신 커밋을 알려줌. 요청받은 커밋 A와 커밋 B 사이에 달라진 파일들을 하나로 압축해 내려줌.

2) Git 웹 클라이언트: 원파는 브랜치에 파일을 업로드하고 변경사항을 커밋

3) 콘텐츠 배포 시스템: 필요한 패치 파일들을 생성하고 AWS S3에 업로드, CDN에 해당 파일들을 반영하고 사용자들에게 배포

 

 

2017:

 

• How does update/patch works? (링크) - 레딧 게시글 

How does game update/patch works?

Yeah a patch does all those things. At its core, its just a script and a set of files that get compressed together. When a patch is applied, they all get decompressed and the script is run. The script is free to copy files into the game's directory and may include binary executables, scripts, images, models, or other resources. It will also typically migrate data files the describe the game's state to work correctly with the new release. That's probably the best way to think of it - the first half of the patch is just the difference between the old static files and the new static files. It applies that difference and then runs some custom script you have to write to have the old game data make sense in this new release.

- 패치는 게임 파일을 변경한다. 콘텐츠와 게임의 매커니즘은 모두 파일에 포함된 데이터일 뿐이다. 따라서 콘텐츠의 변경이든 게임 메커니즘의 변경이든 패치 측면에서 동일한 방식으로 처리 된다. 

- 패치의 핵심은 함께 압축되는 스크립트와 파일 세트로, 패치가 적용되면 압축이 풀리고 스크립트가 실행되어 파일이 변경된다. 

 

 

2018:

 

• 스팀(steam) -> 게임 패치는 이렇게 (링크) - 티스토리 게시글 

스팀(steam) -> 게임 패치는 이렇게

 

2021:

 

• CI/CD 를 AWS 에서 손쉽게 구현해보자! ::: AWS Game Master 온라인 시리즈 #1 (링크) - SlideShare Amazon Web Services Korea

CI/CD 를 AWS 에서 손쉽게 구현해보자! ::: AWS Game Master 온라인 시리즈 #1

- Continuous integration

1) 새로운 코드가 준비되면 자동으로 새로운 빌드 시작

2) 일관되고 반복 가능한 환경에서 코드를 빌드하고 테스트

3) 지속적인 배포가 가능한 Artifacts 준비

4) 지속적인 빌드 실패에 대한 피드백 

 

- Continuous deployment

1) 자동으로 변경된 부분을 테스트하기 위한 staging 환경에 배포

2) 고객에게 영향을 주지 않고 안전하게 배포 가능

3) 배포 빈도가 증가, 배포 시간이 감소로 빠르게 새로운 빌드를 고객에게 제공

4) 배포 실패율이 감소

 

- CI / CD 기능의 핵심 정리

1) 자동화: 더 빠른 배포 주기, 쉬운 빌드 과정으로 실패율이 낮아짐. 개발자의 효율성이 증가함.

2) 일관된 환경: 언제든지 배포 가능한 일관된 Artifacts

3) 안전한 배포: 고객에게 영향이 거의 없는 배포(무중단 배포), 롤백 용이 

 

- 배포 전략

1) In-place(rolling update) > 쿠버네티스

2) Blue-Green 배포 > 로드 밸런서 

3) Canary

 

• Jenkins vs Travis-CI: What is the difference? (링크) - guru99.com

Jenkins vs Travis-CI: What is the difference?