[번역]게임 다운로드 및 업데이트, 패키지를 "대나무처럼 슬림하게" 만드는 방법. 넷이즈. 레이훠 사업부

역자의 말.
넷이즈 항저우 캠퍼스에 위치하고 있는 뇌화 스튜디오의 기술 블로그에 게시 된 내용 몇 개를 한국어로 변환 하여 게시 해 보고자 합니다. 2015년 부터 2017년까지 근무 했던 스튜디오(엄격히 말해 저는 반구 사업부 였지만 합병이 되어서...)에서 어떤 개발을 하는지에 대해서 조금 소개 하고 싶었습니다. 해당 글은 그냥 한국어 발음으로는 니쉐한 이라고 말하고 한글 번역의 경우 역수한 으로 읽어야 하네요. 저는 니쉐한 이라고 쓰겠습니다. 원문은 2023년 11월 18일 작성 된 글입니다.

원문
넷이즈 게임 썬더파이어 비즈니스 그룹(뇌화 사업부) 공식 블로그.

게임 다운로드는 종종 플레이어의 게임에 대한 첫인상, "인생은 첫눈에 불과하다", 자명성의 중요성입니다.
그러나 플레이어의 "인생"과 함께 업데이트 될 수 있으며, 결국 한 번만 다운로드 할 수 있지만 종종 업데이트를 수행하려면 "가을 바람 슬픈 그림 팬"을 원하지 않는 경우 좋은 업데이트 경험을 무시할 수 없습니다.

이번에는 썬더파이어 (뇌화스튜디오) 의 게임 개발 전문가인 펑 린을 초대하여 여러분과 이야기를 나누었습니다. 이 글에서는 게임의 '첫인상'과 '오래 지속되는 동반자 관계'를 잘 만드는 방법을 자세히 소개합니다.

이러한 기법 중 상당수는 많은 사람이 사용하지 않을 수도 있지만 기본적으로 실제 프로젝트에 없어서는 안될 필수 요소입니다. 핵심 기술 중 하나는 압축 기술, 리소스 형식 디자인, 텍스처 압축 등 게임 개발이 아닌 다른 부분도 많이 사용될 수 있습니다. 

우리는 글을 읽은 후 모바일 게임이 10GB 이상, 최종 게임이 100GB 이상이라는 것을 알 수 있습니다.

물론 하드웨어가 업그레이드 되고 게임의 품질도 미친 듯이 반복적으로 업그레이드 되고 패키지가 자연스럽게 폭발하기 때문에 이것은 절대 예외가 될 수 없어요.

따라서 합리적인 게임 리소스 패키징 메커니즘을 설계하는 방법과 게임이 온라인에 진출 한 후(서비스 단계) 리소스를 업데이트하는 방법이 특히 중요합니다.

이 기사에서는 "니쉐한"의 최종 게임의 실제 설치 프로그램에서 시작하여 게임 패키징, 게임 다운로드, 게임 업데이트 및 도구 지원의 네 가지 측면에서 소개합니다. 이 프로그램은 PC를 기반으로하지만 여전히 모바일과 공통점이 많습니다.
파일 디자인, 압축 알고리즘, 업데이트 기술, 데이터 모니터링, 실제 경험, 패키징 및 업데이트 기술의 대부분을 다루려고 노력할 것이며 도움이되기를 바랍니다.

게임 패키징
게임 패키징은 주로 패키징 파일 형식 디자인, 파일 크기, 파일 읽기, 패키징 가속의 네 가지 측면으로 나뉩니다.

패키징 파일 형식 디자인
옛 속담처럼 "만약"을 두려워하지 말고 "10,000"만 두려워하십시오. 따라서 패키징의 목적은 다양한 게임 디렉토리에 10,000개의 파일을 배포하는 대신 10,000개의 파일을 하나로 합성하는 것입니다.
전체 게임의 모든 리소스, 수십만 또는 수백만 개의 파일이있을 수 있으며 패키징을 통해 클라이언트 설치 속도를 향상시킬뿐만 아니라 리소스 읽기 속도를 가속화하는 것도 필수 기술입니다. 

아래 그림은 "니쉐한"의 최종 게임의 리소스 패키지의 일부이며, 접미사 WDF가있는 파일에 많은 리소스가 패키징되어 있음을 알 수 있습니다. 
각 WDF 파일은 대략 1~3GB입니다(패키지가 약 2GB일 때 프로그램 성능이 더 좋아진다는 것이 입증되었습니다. 이것은 터무니없는 경험적 가치, 순전히 개인적인 주관적인 감정이며 실제 경전으로 받아들이지 마십시오. 모든 WDF 파일은 4GB로 엄격하게 제어됩니다. (엑스트라 넷에 적응하기 위해 다른 파일 시스템에 존재할 수 있음, NTFS 가 아닌 FAT 그것 또한 시장에 일부 게임이 있으며 패키징 파일은 100MB와 같이 더 작아지며 게임 프로젝트에 따라 스스로 결정할 수 있습니다.

단일 패키지 파일의 설계 프로세스는 주로 파일을 가능한 한 작게, 가능한 한 빠르게 읽고, 업데이트 친화적으로 고려합니다. 이러한 요구 사항에 따라 패키지 파일의 구조는 대략 다음과 같이 설계되었으며 주로 파일 헤더, 파일 색인 정보, 파일 콘텐츠의 세 가지 콘텐츠 팩업으로 구성되며 그중 파일 헤더와 파일 색인 정보는 상대적으로 작고 파일 콘텐츠는 큰 머리입니다. 이러한 방식으로 파일 헤더와 파일 색인 정보는 메모리에 상주 할 수 있으며 전체 오버 헤드가 너무 크지 않아 파일 존재 여부를 확인해야하는 일반적인 작업이 매우 효율적이됩니다.

 

헤더
현재 버전 번호, 특수 기능 열기 여부 등과 같은 일부 구성 정보를 남겨 두어야하는지 확인해야하는 실제 필요성에 따라. 주로 업데이트를 위해 설계된 여유 공간 표시, 특정 업데이트에서 파일이 삭제 될 수 있으며 구멍이있을 수 있으며 해제 된 공간은 다른 새 파일에 사용할 수 있으므로 공간이 비어 있음을 표시하는 표시가 있어야 파일을 빠르게 작성하기 쉽습니다. 파일 헤더에 어떤 정보를 저장할지 완전히 확실하지 않은 경우 약간의 공간을 예약 할 수 있으며 항상 "수정"할 수있는 기회가 있습니다.

파일 색인 정보
각 파일 색인은 파일 콘텐츠의 주소와 크기를 가리키며, 여기에는 둘 이상의 주소 기능을 설계해야 할 수도 있습니다. 예를 들어, 파일 1, 첫 번째 패키지는 완전히 함께 있지만 업데이트 과정에서 구멍의 크기가 그림이 세 부분으로 잘리는 것과 같이 여러 부분으로 자르기에 충분하지 않기 때문일 수 있습니다. "니쉐한"의 최종 게임의 실제 테스트에서 1 년 동안 수십 번의 업데이트 후 여러 부분으로 잘린 파일이 있지만 거의 4 개를 초과하는 경우는 거의 없습니다.

파일 내용
공간의 전체 섹션을 4kb와 같은 동일한 크기의 여러 블록으로 자릅니다. 블록이 너무 크면 6MB 파일과 같은 더 많은 빈 공간 낭비가 발생하고 4MB 블록은 2MB를 차지해야하며 블록이 5MB 일 때도 2MB를 차지해야합니다. 블록이 너무 작 으면 4MB를 낭비해야합니다. 여유 공간을 유지하는 것은 더 많은 비용이 듭니다. 따라서 프로젝트에 있는 대부분의 파일 크기에 따라 더 적절한 값을 찾아야 합니다.

이 구조의 설계에는 또 다른 장점이 있습니다. 파일 헤더와 파일 색인 정보는 처음에 다운로드 할 수 있고 다른 파일은 재생하는 동안 다운로드 할 수 있다는 것입니다. Against the Current는 재생 중에 다운로드하는 일련의 메커니즘도 지원하지만 방법이 약간 다르며이 콘텐츠는 나중에 업데이트 모듈에서 소개 될 예정입니다.

업데이트 과정에서 파일이 변경되거나 커지거나 작아질 수 있으며 여러 청크로 자르기를 지원하지 않으면 내부에 불필요한 빈 공간이 너무 많이 생길 수 있기 때문입니다. 단일 파일을 여러 부분으로 자르면 여러 개의 디스크 검색이 발생하므로 상대적으로 많은 수의 존재가 리소스 읽기에 영향을 미치므로 패키지 파일의 작업을 정기적으로 정리해야합니다.

파일 크기
파일을 가능한 한 작게 만들려면 압축 알고리즘, 파일 가중치 제거, 파일 삭제의 세 가지 주요 요소를 고려해야 합니다.

압축 알고리즘
일반적인 압축 알고리즘은 압축률, 압축 시간, 압축 해제 시간 비교에서 이러한 압축 방법에 대해 인터넷에 많이 있으며, 종합적으로 고려할 때 "니쉐한"에 사용 된 압축 알고리즘은 주로 압축률이 떨어지지 만 압축 및 압축 해제는 상대적으로 좋은 lz4입니다. 그러나 나중에 언리얼은 oodle이라는 압축 기술을 사용한다는 사실을 알게되었습니다.
데이터 압축 (http://www.radgametools.com/oodlecompressors.htm 등의 링크)을 압축하여 약 10 %를 향상시킬 수 있으며, 대용량 패킷 게임은 여전히 매우 향상되고 실제 테스트 다운, 프레임 속도에 큰 영향을 미치지 않으므로 oodle의 프로그램도 좋은 선택입니다. 온라인 게임의 경우이 부분의 교체가 더 번거롭기 때문에 게임이 아직 온라인 상태가 아니므로 더 나은 프로그램을 종합적으로 비교하고 확인하고 사용할 수 있습니다.

게임의 많은 리소스는 텍스처 맵이며 전체 클라이언트 데이터 볼륨의 절반 이상을 차지할 수 있습니다. 따라서 텍스처 맵을 더 잘 압축할 수 있다면 패키지 본체의 감소량은 매우 큽니다. 원래 니쉐한 프로젝트는 아트 부문에서 제작한 어셋을 tga압축을 통해 dds 매핑으로 변환하여 어느 정도의 매핑 감소가 있지만 공식 Microsoft 방식을 통해 생성 된 dds는 압축 알고리즘을 사용하여 2 차 압축을 수행하므로 압축률이 좋지 않습니다. 나중에 tga 맵을 dds로 변환 할 수도 있는 oodle 텍스처 기술이 도입되었고 oodle 알고리즘으로 생성 된 dds는 압축 알고리즘에 매우대응하기 좋으며 rdo-lambda라는 매개 변수가 있습니다.

이 기술에는 압축 된 매핑의 품질을 제어하는 rdo-lambda 라는 매개 변수가 있으며 궁극적으로 압축을 위해 rdo-lambda = 90을 사용하는 dds 매핑을 기본값으로 선택하고 전체 매핑 압축 비율은 약 40-50 %이며 간단한 매핑 비교의 효과를 볼 수 있지만 실제 게임에 투입되는 것은 장면이나 게임 예술의 역할에 관계없이 상대적으로 높습니다. 이전에는 기사가 있으며,이 매핑 압축 기술에 대한 자세한 소개가 있으며 관심있는 분들은  아래 링크를 참조 하세요. 자연스럽게 모든 사람이 (포인트) 사용 (칭찬)하도록하고 싶고,이 기술의 사용을 정말 권장합니다.

oodle texture

물론 이 두 알고리즘의 우들 제품군은 무료는 아니지만 전체 가격은 비싸지 않습니다. 패키지 본체 감소는 매우 의미가 있으며 성능에 영향을 미치지 않으므로 사용을 평가할 수있는 것이 좋습니다.

파일 중복 제거
파일 중복 제거도 할 가치가 있습니다. 프로젝트 초기에 우리는이 콘텐츠에 너무 많은 관심을 기울이지 않았고, 서비스 시점이 가까워 질 때까지 패키지 본문이 상대적으로 크거나 조금 제어하고 싶거나 최적화 가능한 장소를 확인하고 싶거나 강조 제거가 여전히 매우 필요하다는 것을 발견했습니다. 통계를 통해 컴파일 된 셰이더 파일과 텍스처 및 모델과 같은 아트 리소스의 두 가지 종류의 중복 파일이 있음을 발견했습니다.

1번의 문제는 니쉐한 프로젝트의 셰이더 컴파일과 밀접한 관련이 있을 수 있으며, 반드시 큰 문제가 아닐 수도 있습니다. 아트 리소스 복제는 많은 프로젝트에 공통적으로 발생할 수 있는 문제입니다.이러한 어셋의 MD5 값을 기반으로 모든 패키지 파일의 중복을 제거해야 합니다.

중복 파일이 발견되면 아트에 알려서 제거하도록 할까도 생각했지만, 기술이 예술에 걸림돌이 되어서는 안 된다는 생각에 보류했습니다. 결국 포장 과정에서 이 문제를 처리했습니다. 중복 파일의 경우 하나의 사본만 패키징하고 나머지 중복 파일은 파일 리디렉션을 통해 읽었습니다. 데이터 처리를 위한 리디렉션은 파일 읽기가 하드 드라이브 읽기를 두 번 수행해야 하고, 어느 정도의 오버헤드가 있으며, 중복 수가 상대적으로 많으면 근본 원인부터 해결해야 할 수도 있습니다.

여기서 주목해야 할 또 다른 점은 대부분의 패킹이 병렬로 수행되기 때문에, 즉 서로 다른 파일의 패킹을 수행하는 프로세스가 두 개 이상 있기 때문에 서로 다른 파일의 정보를 알지 못한다는 것입니다. 로컬 중복 제거, 즉 파일 내에서 단일 파일로 중복 제거를 수행하는 방법과 글로벌 중복 제거, 즉 모든 패키징이 끝난 후 모든 파일의 정보를 가져와 패키징 후 처리를 수행하고 파일 리디렉션을 수행하여 복제되는 파일을 제거하는 방법 등 일반적으로 두 가지 방법이 있습니다.

파일 삭제
게임이 온라인 상태가 된 후 안정적인 작동이 지속되는 한 패키지의 증가는 종종 매우 빠르며 실제로 1 년에 수십 GB가 증가합니다. 제작 과정에서 삭제되지 않고 포장 된 일부 임시 파일이 있습니다. "존재는 합리적이다"라는 원칙에 따라 존재하지 않는 파일을 삭제하는 것이 가장 좋습니다.

파일 삭제는 프로젝트 설계 고려 및 구현의 시작 부분에서 시작하는 것이 가장 좋으며, 실제로 "수선 할 양"이 끝난 후에야 라인에 도달하는 것이 정말 "오랫동안 영웅의 눈물을 옷깃으로 가득 채우는"것입니다. 조작이 번거로울뿐만 아니라 잘못된 것을 삭제하면 사고가 발생할 수 있기 때문에 감히 쉽게 삭제하지 않는 경우가 많습니다. 니쉐한 프로젝트는 정말 철 재질이 많아서 패키지 본체를 가능한 한 조금이라도 줄이기 위해 다음과 같은 작업을 수행했습니다:

1. 일일 자동 테스트에서 모든 리소스가 기록되고, 리소스가 실행되지 않은 것으로 확인 된 후 몇 달 동안 리소스를 삭제할 리소스로서 테이블 헤드에 기록 된 후 이러한 파일이 삭제됩니다.

2. 인트라넷의 일일 개발 테스트에서 "삭제 대상 리소스"가 다시 사용될지 여부를 판단하고 사용 기록이 여전히있는 것으로 확인되면 "삭제 대상 리소스"에서 삭제합니다. 이는 내부 2차 테스트이며, 이 주기는 몇 달 동안 그대로 두는 것이 가장 좋습니다.

3. 모든 내부 테스트를 통과한 후 "삭제할 리소스"로부터 반년이 지났습니다. 이 목록을 아웃트라넷에 올립니다. 아웃트라넷은 리소스를 읽을 때 '삭제 대상 리소스'가 여전히 사용되고 있는지 모니터링하고, 플레이어가 사용하고 있다면 서버로 전송되어 기록되며 목록에서 삭제됩니다. 

4. 인트라넷과 아웃트라넷을 통해 검증된 '삭제할 자원'은 1년이 지났을 수 있으며 이 시점에서야 실제로 이러한 자원을 패키지에서 삭제할 수 있습니다.

보시다시피 전체 프로세스가 매우 번거롭고 네 번째 단계까지 삭제 된 리소스에 문제가 없을지 확신 할 수 없으며 실제로 장님이 칼길 위를 걷는것과 같죠.

그래서 아..., 게임 디자인은 자원의 조기 삭제, 장기 운영을 고려하지 않는 것이 패키지가 더 크고 더 큰 문제가 될 것입니다. 초기 단계에서 좋은 고려를하는 것이 여전히 권장되며, 초기 좋은 디자인은 나중에 많은 문제를 줄일 수 있습니다. 그리고 많은 경우 반드시 기술적 인 것이 아니라 다음과 같은 프로그램 일 수도 있습니다.

1. 모든 품목을 수명주기로 설계하여 품목이 실제 어셋 목록에서 제외 된 것을 관리하고 이후 자원을 삭제할 수있는 시기를 쉽게 모니터링 할 수 있도록 할것.

2. 아아팀의 경우 품목의 개별 가치등을 설계하십시오. 특히 의상과 같은 것들을 게임의 판매 포인트로 삼아 패션 관련 추가 어셋들이 매우 끔찍하게 증가 하겠지만 이미 서비스 이후 오랫동안 나온 패션을 고려하여 패키지를 줄이기 위해 매핑 품질 감소를 고려한다면 분명 그 계획은 받아 들여지지 못할것이며 플레이어에게서 그것에 대한 항의를 피드백으로 받을 것입니다.

파일 읽기

가능한 한 빨리 읽게하기 위해 다음과 같은 작업을 수행했습니다:

1. 파일 압축을 더 작게 만듭니다.
일반적으로 파일 크기가 작아지면 자연스럽게 읽기 속도도 빨라집니다. 그러나 압축이 너무 심하면 압축을 푸는 데 시간이 많이 걸리므로 크기와 속도를 동시에 고려해야 합니다.  ( 엄청 난해한... ㅎㅎㅎ )

2. 비동기 읽기 및 캐시.
게임 리소스, 수천 개의 리소스를 언제든지 읽을 수 있으므로 전체 리소스 관리 프로그램은 비동기 읽기를 수행해야하며 조건은 캐시를 가장 잘 지원하고 하드 디스크에서 읽는 데 걸리는 짧은 시간을 줄여야 합니다.

3. 캐시 파일 헤더. 
파일이 존재하는지 여부를 결정하면 리소스가로드되지 않더라도 게임이 종종 논리를 사용하는지 여부도이 판단이 있습니다. 이 데이터를 항상 하드 드라이브에서 읽어야하는 경우 많은 시간이 낭비됩니다. 파일 헤더에 이 정보를 기록했기 때문에 데이터의 이 부분을 메모리에 상주시킬 수 있으며 전체 오버헤드가 너무 크지 않습니다.

4. 공유 파일은 서로 나란히 패킹됩니다. 
패킹에는 알파벳순, 디렉토리순 등 어떤 순서로 패킹할 것인지가 반드시 포함됩니다. 동시에 사용할 수 있는 리소스는 가급적 같은 패키지에 넣는 것이 좋으며, 앞뒤에 인접하는 것이 가장 좋습니다. 예를 들어 캐릭터를 렌더링할 때 두 개 이상의 텍스처를 사용해야 할 수 있으며 이때 이러한 텍스처를 함께 넣을 수 있습니다. 이렇게 하면 디스크 탐색의 오버헤드를 어느 정도 줄일 수 있습니다.

패킹 가속
플레이어의 경험이 가장 중요하지만 패키징 속도가 충분히 빠르지 않으면 결국 테스트 할 버전을 플레이하는 데 매일 비효율적으로 발전 할 것입니다. 최적화 전에는 전체 패키징에 3~4시간이 소요될 수 있으며, 효율성이 매우 떨어집니다. 패키징 가속화를 위해 많은 최적화를 수행했으며 주요 작업은 다음과 같습니다:

1. 하드웨어 업그레이드 : SSD, 메모리 크기, CPU 성능은 모두 페키징에 상대적으로 큰 영향을 미치며 페키징 빌드머신의 속도 개선을 가져 오는 하드웨어 업그레이드는 매우 강력하고 적극 권장됩니다. 또한 SSD를 장시간 사용하면 성능이 저하되어 포장 속도가 저하 될 수 있으며, 포장 속도가 저하 된 경우 SSD 교체를 고려할 수 있습니다. 하드웨어 효과, 즉각적인 효과, 돈으로 해결할 수 있습니다!
(역자 주 : 개인적으로 쿠킹 머신이나 빌드 머신의 SSD 는 4세대 이상의 NVme 를 사용하길 권장 합니다. )

2. 병렬로 패키징하십시오. 열린 다중 스레드 또는 다중 프로세스로 패키징 하거나 분산 시스템을 잘 수행하여 여러 시스템에을 사용하여 패키지 빌드 합니다. 병렬 처리는 분명한 개선을 가져옵니다. 물론, 이를 위해서는 각 패키지가 상대적으로 독립적이어야 하며, 이 기능의 패키징을 위해서는 대부분 상호 배타적이어야 쉽게 할 수 있습니다.

3. 데이터 사전 처리. 
패키징은 데이터를 함께 넣을뿐만 아니라 텍스트 파일을 바이너리 파일로, tga 맵을 dds 맵으로, 모델 병합, 모델로드 데이터 생성 등과 같이 데이터를 처리해야하는 경우가 많으며, 사전 패키징 처리 작업이 많이 있을 것입니다.
이 모든 작업을 패키징 시간에 넣으면 많은 시간이 소요됩니다. 따라서 이러한 작업을 최대한 앞당겨서 일상 업무에 포함시켜야 합니다. 예를 들어, TGA 매핑을 수정하고, 적시에 발견되는 것을 모니터링하여 포장 공간에 dds 매핑의 사본을 생성합니다. 즉, 패킹 관련 데이터는 작업이 실행될 때까지 기다릴 필요없이 패킹 시간까지 기다릴 때 수정할 수있는 데이터입니다. 이러한 방식으로 이러한 전처리가 완료된 패킹을 수행하면 시간을 크게 절약 할 수 있습니다. 단, 추가 데이터 저장을 위해 더 많은 하드 드라이브 공간을 준비해야 한다는 단점이 있습니다.

4. 증분 포장 지원. 
각 패키지를 다시 패키징하는 대신 최신 변경 사항이 이전 패키지에 추가됩니다. 이 로직은 실제로 게임 업데이트와 매우 유사합니다. 다만 처리해야 할 로직이 조금 더 복잡할 수 있습니다. 이 솔루션을 사용하면 게임 업데이트 패키지를 동시에 수행할 수도 있습니다. 1석 2조의 접근 방식을 살펴볼 가치가 있습니다.

게임 다운로드
인스톨러
비교적 초기에 게임 다운로드는 초기에 더 인기있는 NSIS 프로그램 인 "니쉐한 2018 온라인 버전과 같은 독립적 인 다운로드 도구를 만들고 NSIS를 사용하여 설치 프로그램을 만들고 플레이어는 게임 패키지 압축을 풀고 다음 데이터 및 설치 exe와 유사합니다.

하나는 공식 다운로더이고 다른 하나는 썬더볼트입니다. 이것은 요즘 대부분의 게임이 취하는 새로운 접근 방식입니다. 공식 다운로드는 먼저 설치 프로그램을 다운로드하고, 설치 프로그램은 게임 다운로드 전에 설치되며, 다운로드 프로세스는 게임이 서버에서 로컬공간으로 직접 다운로드 한 각 파일을 패키징 한 직후에 이루어집니다. 전체 프로세스, 하드 디스크 공간은 복사본 만 차지하며 파일 압축 해제 작업이 없습니다. 매우 직관적이고 친숙합니다. 게임을 다운로드 한 후 이 설치 프로그램을 게임 런처로도 사용할 수 있습니다. 전체 인터페이스는 다음과 같습니다:

썬더볼트

다운로드의 초기 프로그램도

썬더볼트 다운로더

를 통해 게임 압축 패키지를 다운로드하고 플레이어가 압축을 풀고 게임을 플레이하는 방식이었습니다. 하지만 이제 썬더볼트는 압축되지 않은 패키지 다운로드 방법도 지원하며, 공식 다운로드와 전체 다운로드 프로세스는 실제로 동일 할 수 있습니다. 썬더볼트 다운로드 모드를 클릭하면 설치가 필요없는 버전을 직접 다운로드 할 수 있으며, 프로세스는 다음과 같습니다:

실제로 공식 인스톨러에서 게임 다운로드를 위한 유사한 썬도볼트 SDK에 액세스하여 다운로드를 완료할 수 있습니다. CDN에서 직접 다운로드하는 것과 비교했을 때, 썬더볼트 프로그램을 통해 다운로드하면 일부 지역에서는 속도가 더 안정적이고 빠를 수 있습니다. 물론 게임 패키지에 대한 비용을 지불하는 데 필요한 썬더볼트 SDK에 대한 액세스는 상대적으로 크며 플레이어의 다운로드 경험을 향상시키는 비용의이 부분은 여전히 매우 가치가 있으며이 부분은 특정 프로젝트 별 분석이 될 수 있습니다.

아웃트라넷의 네트워크 환경이 더 복잡하기 때문에 네트워크 장애 또는 다운로드 속도가 너무 느리면 자동으로 또는 플레이어가 수동으로 다른 회선으로 전환 할 수있는 방법으로 두 개 이상의 다운로드 프로그램 세트를 설계하는 것이 가장 좋습니다.

또한 온라인 구성을 만들었으므로 구성을 실시간으로 수정하여 아웃트라넷에서 권장되는 다운로드 채널의 우선 순위와 다른 채널의 권장 다운로드 비율을 조정할 수 있다는 점을 언급할 가치가 있습니다. 다운로드 프로그램에 문제가 발견되면 아웃트라 넷 문제를 처리하기 위해 제 시간에 구성을 수정할 수 있으며 동시에 새 다운로드 프로그램에 액세스하려는 경우 점진적으로 증가하는 안정성이 확보 된 후 처음의 비율을 줄이는 등 매우 좋은 테스트 방법이 될 것입니다. 구성이 없기 전에이 세트를 수행하려면 다운로더 업데이트를 수행하거나 특별한 표시 등을 수행하려면 간단히 말해서 매우 번거 롭습니다.

버전 다운로드
게임의 정식 버전은 용량이 매우 크기 때문에 평균적인 하드웨어와 인터넷이 좋지 않은 플레이어에게는 적합하지 않습니다. 그래서 저희는 게임 클라이언트의 라이트 버전이라고도 하는 작은 버전을 만들었습니다. 표준 버전과의 차이점은 주로 리소스, 특히 매핑 리소스에 있으며, 라이트 버전에 패키지 된 처음 3 단계의 밉 맵 매핑 리소스를 직접 제거하므로 혜택의 패킷 크기 감소는 의심 할 여지없이 매우 큽니다. 처음에 저희 게임의 정식 버전은 약 60GB, 라이트 버전은 20GB 미만이었습니다. 현재 정식 버전은 거의 130GB, 라이트 버전은 거의 50GB이므로 라이트 버전이 정식 버전의 크기에 도달한 것은 사실입니다.

그러나 다운로드 가능한 버전이 증가함에 따라 게임 패키징 시간, 게임 업데이트 패키지를 수행하는 시간이 증가하고 QA 테스트 작업량도 증가하고 시장을 보면 일부 게임은 비슷한 관행을 가지고 있으며 심지어 버전이 3 개입니다. 버전을 만드는 것은 쉽지만 여러 버전을 만들거나 장단점을 적절히 비교해야하는 콘텐츠 회귀에 대한 비용이 상당히 많이 듭니다. 여러 버전을 시작하고 싶으시다면, 먼저 QA 모집부터 하셔야 할 것 같습니다~.

확장팩
게임에 실험적인 기능을 추가했지만 모든 사람이 느끼지 못할 수 있는 경우. 이러한 리소스는 모든 사람이 다운로드할 필요는 없습니다. 우리는 이 리소스를 확장팩이라고 부릅니다. 예를 들어, 니쉐한의 엔드게임에는 모멘터리스 렌더링, 쉬머링( 일렁이는 듯한 희미한 빛 )렌더링과 같은 기술이 있고, 매우 높은 정밀도로 독립적인 장면을 만들었지만 하드웨어에 대한 몇 가지 요구 사항이 있어 모든 플레이어가 이를 느낄 수 있는 조건이 갖춰져 있지 않다는 것을 의미합니다. 화면 연출이 뛰어나기 때문에 모든 플레이어가 실제로 다운로드할 수 있도록 허용하면 작은 씬에 4~5GB의 리소스가 필요할 수 있습니다. 그래서 확장팩이라는 개념을 도입했습니다.

확장팩의 경우 독립적인 유지보수, 독립적인 버전, 독립적인 업데이트가 필요합니다. 이것은 메인 트렁크와 관련이 없으며 문제가 발생하지 않습니다.

실제로 초기 단계의 디자인, 파일 구조에서 더 나은 디자인을 할 수 있고 텍스처 리소스와 같은 확장 팩의 개념에 따라 많은 리소스를 패키징 할 수 있다면 일부 사람들이 특정 게임 플레이를하기 위해 오랫동안 게임을 하지 않을 수 있으며 이러한 게임 플레이 관련 리소스는 전혀 사용할 수 없습니다. 또한 지난 1 년 동안 수행 한 새로운 작업은 별도로 관리되는 등 시간에 따라 관리 할 수 있으며, "월드 오브 워크래프트"와 같이 게임의 경험에 명백한 차이가있는 경우 플레이하는 동안 플레이하는 것이 좋습니다.

마이크로 엔드 다운로드
라이트 버전의 화질이 분명히 낮기 때문에 플레이어가 더 높은 화질의 효과를 경험할 수 있기를 바라기 때문에 라이트 버전을 기반으로 "마이크로 엔드"다운로드 기능을 만들었고, 플레이어는 게임 플레이에 차이가없는 것은 리소스의 차이이므로 고화질 리소스 다운로드에는 실시간 요구 사항이 매우 높지 않으므로 마이크로 엔드를 보시죠!
"주문형 다운로드"는 실제 게임 경험에 영향을 미치지 않는 실현 가능한 솔루션이되었습니다.

마이크로 엔드의 기본 메커니즘 : 마이크로 엔드 다운로드 기능이 활성화되면 별도의 마이크로 엔드 프로세스가 시작되어 고화질 리소스의 다운로드 및 관리를 담당합니다. 게임 클라이언트와 마이크로 엔드는 프로세스 간 통신을 통해 명령을 전송하고, 다운로드한 리소스는 공유 메모리를 통해 게임에 제공됩니다. 전체 프로세스는 대략 다음과 같습니다:

게임의 마이크로 엔드 다운로드 기능은 또한 다중 개방의 이점이 있으며, 일반적으로 둘 이상의 클라이언트가 동일한 작업을 수행하고 필요한 리소스가 종종 유사하며 이번에는 둘 이상의 클라이언트가 동일한 공유 메모리에 액세스 할 수 있으며 다중 개방에 매우 친숙합니다.

마이크로 데이터 스토리지 : 마이크로 데이터 플레이어 로컬 스토리지의 경우 HD 데이터는 현재 HD 매핑이기 때문에 매핑 크기가 일반적으로 더 확실하므로 별도의 마이크로 데이터 스토리지 프로그램 인 게임 패키지 WDF 프로그램을 참조하며, 주요 변경 사항은 모든 파일 정보가 저장을 위해 단일 파일에 집중되고 파일 분할을 통해 최대 2 배의 저장 분할을 허용하고 여유 공간 관리에서 최소 관리 공간 크기가 증가한다는 것입니다. 여유 공간 관리에서 최소 관리 공간의 크기가 증가합니다. 물론 패키징 형식을 직접 재사용하는 것도 나쁘지 않습니다.

마이크로 엔드 데이터 패킹 : HD 리소스의 준비 및 다운로드와 관련하여 패킹 할 때 모든 HD 맵을 앞뒤로 연결하여 가장 간단한 방법으로 조합하고 서버에 업로드하는 동시에 모든 HD 리소스 파일과 해당 md5 정보가 포함 된 구성 테이블을 생성합니다.

마이크로 엔드 리소스 업데이트 : 게임 패키지가 모든 HD 리소스에 대한 구성 테이블을 유지할 때마다 리소스 ID와 해당 md5 값이 있으며, 마이크로 엔드 프로세스가 시작되면 최신 구성 테이블을 다운로드하고, 게임이 HD 리소스 요청을 보낼 때 마이크로 엔드 프로세스는 로컬 데이터가 있는지 판단하고, 로컬 데이터가 있으면 최신 데이터인지 판단하고, 최신이 아닌 경우 서버에서 최신 파일을 다운로드하라는 요청 만 시작하고 서버에서 최신 파일을 다운로드하라는 요청도 시작됩니다. 최신 파일이 아닌 경우 서버에서 최신 파일을 다운로드하라는 요청, 즉 HD 리소스 업데이트를 완료하라는 요청을 시작합니다. 동시에 다운로드 효율성을 높이기 위해 다운로드 요청이 여러 개있을 때 연속 주소가있는 리소스를 함께 다운로드하여 서버의 액세스 압력을 줄입니다. 다운로드 및 업데이트의 전체 프로세스는 아래 그림에 나와 있습니다:

이 기술은 실제로 완료되었을 때 더 유용합니다. 리소스가 자연스럽게 패키지화되어 있기 때문입니다. 또한 나중에 게임 아웃소싱 에디터에 이식된 이 기술의 사용에 대해서도 이야기하고, 아웃소싱에 비교적 새로운 에디터를 제공하길 바라지만 유출을 방지하기 위해 핵심 리소스에 액세스하지 못하게 하고 싶지 않습니다. 마이크로 엔드 접근 방식은 매우 훌륭합니다.

역자 주.
중국은 큰 개발사들은 외주회사와 깊게 협력하기 때문에 게임에 사용 된 렌더링 프레임워크 일부를 분할 하고 암호화 한 후 라이트한 에디터 버전을 외주사에 제공 합니다. 외주비용이 매우 막대하기 때문이고(다른 렌더링 설정이나 에디터 환경을 사용할 경우 최종 룩이 맞지 않고 이것을 추가 요청할 때 모두 비용이 발생하는데요....시간이 금보다 가치가 있다고 꽤 맹신하는 사람들이기 때문입니다.  재무팀의 압박도 상당하죠. ^^

 

게임 업데이트
게임 업데이트, 두 가지 방법이 있습니다. 하나는 매번 새 파일을 다운로드하는 것입니다. 이것은 간단하고 빠르며 편리하며 단점은 파일을 더 자주 업데이트해야하며 게임을 다시 다운해도 실제로 차이가 없으며 비용이 확실히 가격보다 높다는 것입니다. 따라서 일반적인 게임 업데이트는 다른 방법 인 차별화 된 업데이트를 선택합니다. 니쉐한의 최종 버전은 매주 버전이 나올 것이므로 매달 업데이트에 사용되는 패치 파일은 거의 4 개가 될 것이며 각 패치는 약 1-2GB입니다.

업데이트 방법
초기에는 버전을 따라 매주 업데이트하는 방법만 지원했습니다. 게임이 오랫동안 업데이트되지 않은 경우, 다운로드해야 하는 패치 수는 새 게임을 다운로드하는 것만큼이나 많습니다. 최적의 환경을 제공하기 위해 당사는 시간에 따라 다양한 업데이트 유형을 지원합니다.

1. 장시간 업데이트가 없는 경우: 다운로드한 패치의 총 크기가 게임 클라이언트의 80%를 초과하는 경우 게임 재다운로드 기능을 직접 트리거합니다. 플레이어는 업데이트가 되고 있다고 느끼지만 실제로는 로컬에서 게임을 다시 다운로드하는 것입니다.

2. 중간 시간 미 업데이트 : 예를 들어 10 개 이상의 패치가 다운로드되지 않았지만 1 가지 상황을 충족하지 못하고 다른 특수 업데이트 메커니즘 세트를 트리거하고 파일 자체를 직접 다운로드해야 업데이트해야하며 업데이트의 차별화로 이동하지 않도록 제한합니다.

3. 매일 업데이트 유지: 패치를 배치하고 차별화 업데이트를 위한 패치를 적용하는 일반적인 방법으로 이동합니다.

시나리오 1과 3은 비교적 이해하고 작업하기 쉽습니다. 하지만 시나리오 2의 경우 어떻게 하면 비교적 적은 비용으로 이를 달성할 수 있을까요? 우리의 첫 번째 아이디어는 별도의 데이터 세트를 유지하고, 패키지 데이터의 각 버전을 저장하고, 플레이어는 로컬 버전의 정보를 기반으로하고, 이러한 데이터를 직접 다운로드하고, 비용은 다른 패키지 데이터 세트를 유지하고, 이미 칼을 들고 칼을 갈고있는 패키지 빌드 팀원들을 볼 수 있습니다.
나중에 우리는 실제로 파일을 재정렬 할 수있는 시간에 따라 WDF 파일을 패키징하는 것이 실제로 수행 될 수 있음을 발견했습니다. 원래 파일 패킹 순서는 상대적으로 임의적이며, 이제 다음 차트로 재구성 된 시간에 따라 현재 플레이어 버전이 11이고 최신 버전이 20이라고 가정하면 WDF 오프셋에서 버전 12에서 20까지의 구성 테이블을 통해 얻을 수 있습니다. 이 데이터를 얻은 후이 데이터의 WDF를 다운로드하고 현재 WDF의 헤드를 교체합니다. 이러한 방식으로 별도의 패키지 데이터를 유지할 필요가 없으며 구성 테이블을 유지하고 각 파일의 각 버전을 기록 할 필요가 없습니다. 보시다시피 원본 파일과 최신 파일을 직접 다운로드하는이 방법은 패치를 적용 할 필요가 없으며 경우에 따라이 방법이 차등 업데이트보다 여전히 빠릅니다.

업데이트 작업
차등 업데이트를 사용하는 경우, 프론트 클라이언트와 백 클라이언트에 대한 패치를 차등적으로 적용합니다. 각 패키지 파일에 대해 개별 파일을 패치합니다. 예를 들어 1.wdf에 1000개의 파일이 있는 경우 이 1000개의 파일을 각각 패치합니다. 업데이트 작업은 일반적으로 다음과 같은 유형으로 이루어집니다:

1. 신규. 새 파일을 추가하여 패치를 생성하고 새 파일 데이터를 패치에 기록합니다. 패치가 적용되면 새 파일이 패키지 파일에 추가됩니다.

2. 삭제. 파일을 삭제하려면 패치에 삭제 정보를 쓰기만 하면 됩니다. 패치를 적용할 때 삭제하면 무효화될 수 있으며 이때는 처리되지 않습니다.

3. 수정. 수정 작업은 차별화 도구를 사용하여 차별화 된 데이터를 생성하며 일반적으로 사용되는 알고리즘은 xdelta 및 bsdiff이며 현재 우리는 여전히 주로 xdelta를 사용하며 패치 크기가 더 민감한 경우 두 알고리즘을 모두 고려할 수 있으며 궁극적으로 작은 방식의 차별화 된 데이터를 최종 방법으로 취할 수 있습니다.

4. 이동. 초기에는 이 작업을 지원하지 않았기 때문에 특정 폴더의 데이터가 A 폴더에서 B 폴더로 이동하는 등 데이터의 위치를 이동해야 할 때 이동 작업이 지원되지 않으면 데이터 삭제를 수행하고 데이터를 추가하여 상대적으로 큰 패치를 생성합니다. 데이터 변경 없이 패치를 크게 만드는 것은 비용 효율적이지 않습니다. 나중에 삭제 작업과 비슷한 이동 기능을 지원하여 패치에 이동 작업만 쓰면 되므로 비용이 매우 저렴합니다.

4. 압축 알고리즘. 압축 알고리즘은 일반적으로 수정하기 쉽지 않으며 수정하면 데이터의 차이도 상대적으로 클 수 있으므로 플레이어의 로컬에서 압축 해제를 지원하고 새로운 압축 알고리즘 압축 방법을 다시 사용하는 것을 고려할 수 있으며 시간이 조금 더 많이 소요될뿐만 아니라 패치 크기에 너무 많은 압력을 가하지 않습니다.

어떤 사람들은 패키징이 데이터 압축이 될 것이기 때문에 압축 전후의 데이터를 사용하여 패치의 차이가 상대적으로 작을것이라고 물어보고 싶을 수도 있습니다. 실제 테스트 상황, 상황은 때로는 압축 전, 때로는 압축 후 통합 될 수 없습니다. 현재 니쉐한의 최종 게임은 여전히 차별화 된 데이터 생성을 위해 압축 데이터를 사용하고 있습니다. 패치 크기에 민감하다면 두 가지를 모두 고려하고 결국 더 작은 패치를 선택할 수 있습니다.

패치 제작
패치 제작 과정에서 모든 파일을 패키징된 파일과 패키징에 포함되지 않은 파일(예: 게임 exe 파일)의 두 가지 범주로 나눕니다. 이 두 가지 유형의 파일은 별도로 처리해야하지만 본질적으로 패키지 파일은 결국 각 개별 파일에 대한 패치를 만들어야하기 때문에 큰 차이는 없습니다. 패치 파일의 구조는 기본적으로 헤더와 각 파일 패치 데이터, 패치 데이터는 파일 ID, 업데이트 유형, md5 이전 업데이트, md5 이후 업데이트 및 차별화 된 데이터에 저장되며 다른 데이터는 프로젝트 요구 사항에 따라 추가하거나 삭제할 수 있습니다. 여기서 한 가지 주의할 점은 패키지 파일의 경우 패키지 파일의 각 파일에 개별적으로 패치를 적용하기 때문에 플레이어가 다운로드한 게임의 초기 버전이 동일하지 않을 수 있으므로 패키지 파일의 전체 MD5 값이 동일하다고 보장할 수 없으므로 패키지 파일 전체의 MD5 값에 대한 비교 기준이 없습니다.

패치 애플리케이션의 경우 업데이트 전용 exe 프로그램이 확실히 생성됩니다. 그러나 업데이터 자체 업데이트는 문제이며, 결국 업데이트 프로세스가 자신의 수명이 될 수 없으며, 자신의 프로세스에서 직접 할 수 없습니다. 현재 우리는 업데이터가 처음에 자체 업데이트가 필요한지 감지하고, 다른 프로세스를 시작하고 자체 종료해야하는 경우 다른 프로세스가 업데이터 업데이트를 완료하고, 업데이터가 자체 업데이트를 완료하면 게임 리소스가 업데이트되는 방법을 사용합니다.

패치 파일의 형식이 결정된 후에는 다시 수정하지 마십시오. 외부 네트워크에서 플레이어가 업데이터의 자체 업데이트 작업이 성공할 것이라고 보장 할 수 없으므로 플레이어가 이전 버전의 업데이터를 사용하여 게임을 업데이트 할 가능성이 있으므로이를 위해 1. 새 버전이 필요한 사람들을 위해 수동 다운로드 인터페이스를 제공하지 않았으므로 플레이어가 직접 다운로드하여 교체 할 수 있습니다. 엑스트라넷에 두 개 이상의 클라이언트 버전이 있는 경우, 플레이어가 직접 다운로드하여 교체할 수 있도록 새 버전을 수동으로 다운로드할 수 있습니다.

아웃트라넷에 여러 버전의 클라이언트가 있는 경우 서로 다른 패치를 적용해야 합니다. 또한 아웃트라넷 버전보다 인트라넷 버전이 더 많기 때문에 인트라넷 업데이트를 지원할 수 있는 메커니즘이 필요합니다. 초기 QA 테스트에서는 매번 게임을 다시 다운로드하고 다운로드 및 압축 해제 시간이 최대 1 시간까지 걸리는 경우가 많아서 작업 효율성에 큰 영향을 미쳤고, 그 후 모두 훨씬 빠른 아웃트라넷과 유사한 패치 업데이트 메커니즘으로 변경했습니다. 새 업데이트에서 이전 버전에 이르기까지 모든 버전의 수요에 대한 인트라넷 업데이트가 존재하기 때문에 롤백 패치도 특별히 지원한다는 점을 언급 할 가치가 있습니다. 이 업데이트 가젯은 다음과 같으며 업데이트하려는 대상 버전을 선택하여 모든 버전으로 업데이트 할 수 있으며, 테스트의 효율성을 매우 향상시키는 실제 사용은 이 기능을 수행하면 QA가 큰 포옹을 할 것입니다.

역자 주.
중국에서 9년 정도 실무진으로 일 하면서 느낀 점은 개발팀과 QA 부서의 협력이 매우 기민 하다는 것입니다. 매우 매우... 텐센트 퍼블리싱의 경우 내부 규정집 기준 5% 내외로 들어오지 못하면 같은 회사 게임 타이틀도 서비스 될 수 없을 만큼 규범이 견고 합니다. 이런 점은 한국이 배워야 하고 QA 들의 기술 자체 검증. 피드백. 문서화 . 자동화 스크립트 제작 능력등을 상향시킬 필요가 있습니다. -> 전문성. 한국은 일단 QA 전문성에서는 중국에 많이 뒤쳐져 있습니다.

메모리 패치
주간 버전 업데이트를 위한 패치는 비교적 큰 규모이지만, 엑스트라넷 충돌이 발견되면 일일 버전 업데이트 중간에 소규모 패치를 수행해야 할 때가 있습니다. 패치는 작지만 반드시 수행해야 합니다. 클라이언트 측 리소스 패치 프로세스는 실제로 더 많은 시간이 소요되며, 플레이어는 트리거되기 전에 클라이언트를 종료하고 다시 시작해야 하므로 좋은 경험은 아닙니다. 저희는 서버 루아 핫 업데이트 메커니즘에서 차용하여 메모리 패치 기능을 만들었습니다.

전체 아이디어는 아주 간단합니다. 루아 핫 업데이트 메커니즘을 재사용하고 데이터를 루아 패치로 플레이어에게 직접 전송하는 것입니다. 플레이어가 게임을 시작하거나 게임이 실행 중일 때 루아 패치를 발견하면 플레이어는 데이터를 수신하고 해당 파일의 ID와 데이터를 메모리에 저장하여 별도로 관리하고 파일 읽기 작업이 트리거 될 때마다 메모리 패치 관리자에서 먼저 읽어서 메모리 패치의 데이터가 먼저 사용되도록합니다.

그러나 메모리 패치는 네트워크를 통해 데이터를 전송해야하기 때문에 너무 큰 파일이 될 수 없으며 그렇지 않으면로드에 문제가 발생하기 쉽습니다.

사실, 우리는 또한 루아 핫 업데이트 메커니즘을 사용하여 유사한 임시 패치 기능을 만들었지 만 클라이언트의 전송은 데이터 자체가 아니라 네트워크 주소, 플레이어의 네트워크 주소에서 다음으로 이동할 파일, 다운로드 후 로컬로 저장할 수도 있으므로 다음에 시작할 때 다시 다운로드 할 필요가 없습니다. 게임이 일반 버전으로 업데이트될 때 관련 데이터를 삭제해야 합니다.

두 가지 방법 모두 작은 패치 요구 사항을 처리하는 것이 더 편리 할 수 있습니다.

도구 지원

게임 복구 관리자

플레이어의 로컬 게임 클라이언트는 하드 드라이브, 네트워크, 업데이트 프로세스 오류 등 다양한 원인으로 인해 파일 오류 문제가 발생할 수 있습니다. 따라서 복구 도구는 필수입니다.

복구 도구를 사용하면 네트워크 리소스 낭비를 피하기 위해 조금 더 세부적으로 세분화 할 수 있습니다:

1. 오류의 양이 비교적 많습니다. 이 경우 패키지 파일을 직접 다시 다운로드 할 수 있습니다.

2. 개별 파일 오류. 이 경우 교체할 단일 파일의 리소스만 다운로드하세요.

타이밍에 의해 시작된 수리, 주로 두 가지, 하나는 플레이어의 주도권 또는 수동 조작에 의해 안내되고, 하나는 리소스 문제가 발견되면 실행중인 게임이 기록되고, 게임 실행기는 상황을 시작하기 전에 기록을 읽고 오류가 시작된 수리가 있음을 발견합니다.

우리는 정리 도구를 솔루션에 통합했습니다. 정리는 주로 플레이어가 업데이트 과정에서 많은 빈 구멍을 만들어 게임 클라이언트의 하드 드라이브 점유를 증가시키고 정리를 통해 이러한 빈 구멍을 제거하고 클라이언트의 점유를 줄이는 목적을 달성 할 수 있음을 의미합니다. 게임 런처가 시작될 때마다 공백을 검색하고이 프로세스는 매우 빠르며 공백이 너무 많으면 사용자에게 정리하도록 상기시킵니다. 전체 프로세스는 데이터를 읽고 다시 쓰는 것이지만 속도는 SSD 하드 드라이브에서 여전히 비슷합니다.

압축 파일 압축 해제 도구
압축 파일 압축 해제 도구는 주로 문제 확인의 편의를위한 것입니다. 때때로 엑스트라 넷에 리소스 문제가있어 데이터를 확인해야하며 원래 데이터 상황을 복원하기 위해 패킹 도구를 완전히 압축 해제하고 부분적으로 압축 해제 할 수있는 도구가 필요합니다. 패키지 파일에 기록하는 정보에는 파일 이름 정보가 없기 때문에 ID로 변환되므로 패키지 파일에 해당하는 ID 및 파일 경로 테이블도 유지 관리해야합니다. 이 테이블은 자동으로 다운로드되어 압축 해제 도구에서 사용됩니다.

게임 크래시 수집 시스템
게임이 내부적으로 테스트를 잘 마쳤다고 해도 오프라인 상태가 되면 온갖 이상한 문제가 발생할 수 있습니다. 따라서 크래시는 적시에 합리적인 방식으로 처리해야 합니다. 크래시가 발생하면 스택 정보가 포함된 덤프 파일과 특정 정보를 기록하는 로그를 서버에 업로드할 수 있습니다.

덤프 수집이 필요하며, 이는 아웃트라넷의 문제를 찾는 중요한 경로 중 하나입니다. 그리고 덤프 데이터를 파싱하는 것이 훨씬 더 중요합니다. 
엄청난 양의 크래시를 사용하는 것은 매우 어렵고, 스택 및 기타 정보에 따라 Dump를 분류하는 동시에 시간에 따른 다양한 데이터의 변화를 모니터링하여 긴급하게 처리해야하는 문제, 새로운 문제, 업데이트 후 결과가 유효한지 여부를 알 수 있어야합니다.

게임 업데이트 모니터링 시스템
게임 충돌과 마찬가지로 게임 업데이트에도 다양한 오류가 발생할 수 있습니다. 이러한 오류를 합리적으로 모니터링해야 엑스트라넷의 업데이트 상황을 더 잘 제어할 수 있고, 새로운 기능을 추가할 때 엑스트라넷의 상황을 제때 파악할 수 있습니다. 게임이 출시된 후에야 이 시스템을 설계하고 사용하기 시작했기 때문에 프로젝트 초기에 이 시스템에 관심을 기울이고 사용하기 시작했더라면 더 좋았을 것입니다.

에디터 제작 아웃소싱
요즘은 아트 아웃소싱에 대한 수요가 점점 더 커지고 있으며, 프로젝트 엔진을 사용하여 제작을 검증하는 것이 더 좋을 것입니다. 그러나 프로젝트 개발, 많은 리소스가 더 중요하고 아웃소싱에 모두 유출 될 위험이 크며 상주 회사가 모든 액세스 권한을 아웃소싱 할 수 있다고해도 총 리소스 양도 골칫거리이며, 수년간의 게임 운영과 1TB를 돌파하기위한 모든 리소스의 향상 요구 사항의 품질도 점점 더 높아질 가능성이 있습니다. 이러한 문제에 대응하여 실시간 데이터 아웃소싱이 그렇게 높지 않기 때문에 특정 지연이 존재할 수 있으므로 마이크로 엔드 기능을 확장하여 편집기에서 최신 엑스트라 넷 데이터의 주문형 다운로드를 통해 하드 드라이브 임계 값의 편집기 사용도 상대적으로 낮을 수 있지만 데이터 보호 작업을 더 잘 수행 할 수 있도록 마이크로 엔드 기능을 확장 할 것입니다. 프로젝트 팀에 아웃소싱에 대한 요구가 더 많은 경우 이러한 편집기는 여전히 큰 의미가 있습니다.

해피 엔딩
시대의 물결은 "슈팅"플레이어가 100GB의 게임 용량 크기를 수용 할 수 있었지만 좋은 패키징, 업데이트 프로그램은 게임이 게임에 더 많은 우수한 리소스를 투입하고 플레이어에게 더 몰입감있는 경험을 제공하기 위해 결국 플레이어가 시간을 다운로드 할 수있는 용량의 크기, 고품질 기대치가 있습니다. 

오래된 게임은 패키지 크기가 약간 변덕 스러울 수 있으며, 새로운 게임은 가능한 한 작아야하며, 플레이하는 과정에서 점차적으로 다른 리소스를 다운로드하고 처음에 플레이어를 설득하지 마십시오.

두 번째 단계, 글을 조금 수정하여 더 재미있게 읽을 수 있도록 도와 주신 GPT에게 감사드립니다. 매우 찌그러진 느낌이 든다면이 기사의 저자가 "심각한"이라고 말한 GPT에게 항의 하십시오. 하하.