How & Why to Write an Autopatcher for Your Game
Room 2006, West Hall
Speaker : Robby Zinchak  |  Founder & CEO, Archive Entertainment

이번 강연은 PC binary 패치 방법에 관한 내용입니다.

발표자는 패치를 하기 위해서 binary diff를 사용하여 blob을 생성하고 그 리스트를 관리하는 방식을 사용한다고 했습니다.

만약 버전 1이 서비스 중이고, 버전 2로 패치하는 경우를 가정하면,
버전 1 과 버전 2의 binary diff에 따른 blob 1을 생성하고, 패치 목록에 등록해 둡니다.
또 만약을 대비한 버전 2의 full binary 파일도 목록에 등록 해 둡니다.
해서 버전 1이 버전 2로 업데이트 할 때 blob 1을 다운로드 받아 업데이트 하는 것입니다.

또 버전 3이 준비 된다고 하면, 버전 1에서 버전 3으로 업데이트 하는 경우와 버전 2에서 버전 3으로 업데이트 하는 경우, 총 2가지가 존재하고 이에 따른 blob2, blob3 을 패치 목록에 등록하는 것이지요.
이전 버전의 full binary는 최신 버전의 full binary로 교체 하여 등록 해 둡니다.

업데이트 과정에서 에러가 발생한다면 자동 재시도를 하고, 방화벽이나 하드디스크등의 정보를 로깅하여 에러 핸들링을 한다고 합니다.

이러한 패치 방식의 단점은 역시 패치 목록 생성이 복잡해 지고, 패치 목록 자체가 커질 수 밖에 없다는 것 입니다. n개의 버전이 존재 한다면 패치 목록은 n(n-1) / 2 + 1개 만큼 생성 되어야 하니까요.
다만 업데이트 할 때 다운로드 받는 파일의 크기는 확연히 줄어 들게 될 것입니다.
모바일에서는 어차피 각 Market / Store에서 업데이트 해주기 때문에 이러한 시스템이 필요 없을 수 있습니다. 하지만 CDN을 사용하는 앱이라면 어느정도 고려 해 볼 만한 내용이라고 생각 했습니다.
저희도 CDN을 통한 리소스 업데이트를 하고 있는데, 전체 리소스를 full patch 하다 보니 그 비용이 만만치 않기 때문입니다.

최적화 된 패치를 하기 위해 위 시스템을 도입하면 어떨까 하고 생각해 봤습니다만, 한번의 패치를 위해 여러 리소스의 binary diff를 구해야 하기 때문에 패치 목록 생성 / 관리에 너무 많은 비용이 들고, 각 리소스 별 diff로 생성된 blob을 적용하는 process가 복잡해질 뿐 아니라, 예외 상황도 더 늘어나기 때문에 현재 패치 시스템과 좀 더 비교한 후에 결정을 내려야 할 것 같습니다.

By Justin Hwang