재생 중에 데이터가 실제로 그렇게 많이 수정 되었습니까?
레벨을 다시 시작하는 사이에 긴 일시 중지가 전체 레벨을 다시로드한다고 가정합니다. 그러나 잘 구현 된 시스템은 레벨의 시작 부분으로 '핑'할 수 있어야합니다.
콘솔에서는 눈에 띄지 만 PC 게임에서는 눈에 띄지 않습니다.
재생 중에 데이터가 실제로 그렇게 많이 수정 되었습니까?
레벨을 다시 시작하는 사이에 긴 일시 중지가 전체 레벨을 다시로드한다고 가정합니다. 그러나 잘 구현 된 시스템은 레벨의 시작 부분으로 '핑'할 수 있어야합니다.
콘솔에서는 눈에 띄지 만 PC 게임에서는 눈에 띄지 않습니다.
답변:
이제는 간단하지만 흥미로운 질문입니다.
레벨을 다시로드 할 때 고려해야 할 많은 요소가 있으므로 대답은 여러 가지 방법으로 갈 수 있습니다.
레벨 상태에 많은 자산 목록이 포함 된 경우 레벨을 다시로드 / 미션 상태로 다시로드 할 때 클린 슬레이트에서 시작하는 것이 더 실용적 일 수 있습니다. 이는 다시로드 할 때 레벨의 정확한 상태를 유지하지만 많이 사용하지 않기 때문입니다. 가공. 그러나 몇 가지만 고려해야 할 경우 자산 만 재설정하는 것이 더 효율적이므로 이러한 작은 수준에서 신속하게 작업을 다시 시작할 수 있습니다. 후자는 특히 장면에서 아무것도 보존 할 필요가 없거나 게임에서 선택한 사항에 영향을받지 않는 경우에 특히 그렇습니다. 마을을 통해 첫 번째 실행에서 시체를 보존 할 필요가없는 경우에는 그렇지 않습니다. 해당 레벨을 통해 다시로드해야하므로 프로세서 시간과 저장 / 미션 상태 액세스 시간이 절약됩니다.
생각해 볼만한 좋은 예는 1 인칭 슈팅 게임으로, 해당 플레이 스루 동안 지속 상태 를 가지고 있지만 체크 포인트 나 레벨을 다시 시작해도 유지되지 않는 터 레인 파괴 / 탄환 데칼을 사용했습니다 .
파괴하고 다시로드하는 대신 레벨 을 되감 으면 각 상태가 변경되는 것을 추적해야합니다. 로켓으로 벽에 구멍을 뚫 으면 벽에서 떨어지는 조각으로 지형 깁스를 생성 할 수 있습니다. 벽의 모델은 구멍을 생성하도록 변경되며 입자 모양이 예쁘게 보이도록 생성됩니다. . "다시 시작 가능"상태로 되 감아 서 정리하려면 다음을 수행해야합니다.
레벨을 되감기 위해 추적해야 할 리소스가 너무 많기 때문에 전체 레벨을 간단히 파괴하고 모든 자산을 기본 또는 미션 특정 상태로 다시로드하는 것이 종종 프로세서 집약적이지 않습니다. 특정 객체를 재설정하려면 장면에서 객체 목록을 검색 한 다음 속성에 액세스하여 재설정해야합니다. 청소를 통해 벽의 총알 구멍을 수리하는 대신 청소 작업을 수행 할 필요가 없으며 메모리에서 전체 레벨을 삭제하고 처음부터 다시로드하면됩니다.
이는 레벨 재로드가 하나의 상태 객체 (저장 게임 파일 또는 미션 스크립트)에서 이루어지며 동적 caluclation이 필요하지 않음을 의미합니다. 콘솔의 경우 디스크와 관련된 로딩 시간으로 인해 악화됩니다. 또한 로딩 시간을 수용 할 수있는 처리 능력이없는 컴퓨터를 고려할 수 있으므로 PC 게임에 도움이됩니다.
따라서 큰 콘텐츠 수준의 경우-하나의 상태를 계산하고 "되감기"대신 단일 상태를로드합니다.
그러나 반격의 예로써 격투 게임 (스트리트 파이터 4 인 실제 사례)은 레벨을 다시 시작하기 위해 많은 자산을 모두 다시로드하지 않아도됩니다. 2 명의 플레이어, 레벨 및 단순 레벨 타이머의 환경 상태는 대부분 정적이고 역동적이지 않습니다 (플레이어 상태는 항상 각 라운드마다 100 %로 다시 나타나고 타이머는 90 초로 재설정되며 레벨에는 총알 구멍이 없습니다. 또는 그렇지 않습니다!] ) 따라서 레벨을 재설정하는 것은 전투기를 완전히 건강하게 만들고 환경을 원래 위치로 되 돌리는 것입니다 (일부 레벨의 구경꾼처럼).
따라서 재 대결을 할 때 싸우는 게임 (라운드에서 라운드로 이동하지 않음)의 경우 다음을 수행해야합니다.
이것이 전체 목록입니다. 즉, 전체 레벨 재로드 대신 빠른 상태 재설정이 더 적합합니다. 처음 경기를 시작할 때 로딩 시간으로 표시 될 수도 있습니다. 모든 캐릭터 및 레벨 모델을로드하는 데 시간이 오래 걸리지 만 이미로드 된 모델과 일치하는 사이에 캐릭터 시작 위치를 재설정하는 데 약간의 프로세서 틱만 있습니다.
경기가 일반적으로 1 분 밖에 걸리지 않기 때문에 플레이어가 엄청나게 빠르게 게임을 다시 시작하려는 경향이 있기 때문에 이것은 또한 게임 싸움에 대한 요구 사항이 더 많다는 점에 유의해야합니다. 장르. FPS는 더 역동적 인 자산을 요구하는 반면 Fighters는 빠른 반복 가능한 작업을 요구합니다.
이것이 귀하의 질문에 약간의 빛을 비추기를 바랍니다.
콘솔에 대한 귀하의 질문에 대한 기존 답변을 명확히하려면 : 더 큰 복잡한 게임을 위해 시작 상태와 현재 상태를 모두 저장할 수있는 메모리가 충분하지 않습니다.
게임은 레벨과 초기 상태를 개별적으로 저장하여 상태 만리스트 림 할 수 있으며, 이는 많은 게임이 할 가능성이 높습니다. 그래도 스트리밍은 메모리에 보관 된 것보다 약간 느려질 것입니다.
"최상의"최신 콘솔은 CPU 데이터와 그래픽간에 512MB의 메모리 만 공유합니다. 작습니다. 현재 콘솔 개발의 골칫거리 중 하나는 적은 양의 메모리로 오늘날의 품질 수준을 충족시키는 게임에 맞추려고 노력하는 것입니다. 킬로바이트 계산은 특히 선적 날짜에 가깝게 중요해질 수 있습니다. 레벨의 초기 상태의 사본을 저장하는 것은 수행하지 않고 수행 할 수있는 데이터의 양으로, 레벨 재로드 속도를 높이기보다는 게임 중에 게임을 더욱 흥미롭게 만드는 데 더 많은 메모리를 사용할 수 있습니다.
이상적으로 플레이어는 죽거나 다시 시작하는 것보다 게임에 더 많은 시간을 소비하므로 재생 중에 더 나은 경험을 위해 최적화하는 것이 더 합리적입니다.
차세대 콘솔과 8GB 메모리로 상황이 크게 바뀔 수 있습니다. 또는 단순히 고해상도 모델과 재질, 수많은 게임 내 오브젝트로 동일하게 유지 될 수 있습니다. 시간이 말해 줄 것이다. PC 게임은 일반적으로 2GB의 RAM과 512MB의 VRAM (많은 규모에서 훨씬 더 큰 값까지)을 가진 머신을 대상으로하기 때문에 8GB의 새로운 콘솔은 최소 기준선까지는 매우 고급스러워집니다. 앞으로 몇 년 안에 1-2GB의 VRAM을 가진 64 비트 CPU / OS 및 4-8GB의 RAM을 요구하는 게임으로의 전환이있을 것입니다. 빠른 스냅 샷을 위해 메모리에 여러 상태를 저장하는 것이 훨씬 쉬워야합니다.
나는 Blue의 답변에 동의하지 않습니다. 레벨을 재설정하지 않는 기술적 사례가 있다고 생각하지 않습니다. 레벨 로딩은 레벨 재설정보다 거의 항상 느립니다. 사실 그렇지 않은 경우를 생각하기가 어렵습니다. 대부분의 경우 개발자가 선택한 경우 게임에서 효과적으로 즉각적인 레벨 로딩을 제공 할 수 있습니다.
실제 대답은 제안 된 것처럼 쉽고 빠릅니다. 레벨의 반복적 인 로딩은 게임에서 어쨌든 필요한 것이므로 이것을 레벨 재시작으로 바꾸는 것은 비교적 간단합니다. 재설정에는 새로운 버그 및 메모리 누수 가능성이 많은 복잡한 새로운 경로가 필요하며 개발자 시간에 대한 적절한 투자가 필요합니다. 경우에 따라 메모리 제한을 푸시 할 수도 있습니다. 게임은 개발자 시간으로 개발되는 경우가 거의 없기 때문에 레벨 재설정과 같은 항목은 유감스럽게도 후퇴하는 경향이 있습니다. 특히 게임 아키텍처가 처음에 가장 잘 구축되지 않은 경우 더욱 그렇습니다.
재설정에 "되감기"가 필요한 상황이 발생할 수 있다고 생각하지만 실제로 대부분의 게임은 원래 상태 만 저장하면됩니다. 유지 된 오브젝트에 대해 해당 상태로 완전히 재설정하는 효과적인 수단과 오브젝트에 플래그를 지정하는 수단을 제공해야합니다. 리셋시 포기. 게임 상태 정보도 저장하고 복구 할 수 있어야합니다. 이러한 종류의 정보는 일반적으로 전체 수준의 요구 사항에 비해 메모리에 상대적으로 가볍기 때문에 디스크에서 텍스처 및 모델과 같은 큰 항목을 포함하여 느리고 값 비싼 데이터를로드 할 필요가 없으며 빠른 속도로 대체 할 수 있습니다. 장면의 메모리 패스.
제한된 메모리 (메모리가 항상 너무 작습니다. 먼저 RAM 또는 그래픽 카드의 한계에 도달하면 문제입니다)와 함께 큰 수준이나 매끄러운 수준의 게임 플레이를 허용하려면 다른 전략이 있습니다.
플레이어가 현재 필요하거나 몇 초 안에 필요로하는 레벨의 일부만 메모리에 저장하십시오. 더 이상 필요하지 않은 모델, 텍스처, 사운드 샘플 등은 메모리에서 제거됩니다.
던전 시즈 (Dungeon Siege)는 메모리 관리가 실제 게임 플레이보다 더 많은 처리 능력을 필요로한다고 주장한 개발자들에게 떠올랐다. 레벨 (또는 30 초 전의 부활 지점)이 더 이상 메모리에 없을 수 있습니다.
종종 새로운 재 장전이 가장 쉬운 방법, 가장 저렴한 방법, 가장 빠른 방법 일 수 있습니다.
편집 : 다음은 Dungeon Siege의 로딩 메커니즘에 대한 논문입니다 : Dungeon Siege 의 연속 세계
물리적 플랫폼 제한과 찬성 결정에 관한 Sean과 Blue의 탁월한 답변을 통해 다른 접근법으로 의견을 확장 할 것입니다.
따라서 loadLevel () 호출이 완벽하게 작동합니다. 레벨 파일 정보로 스트리밍하고,이를 기반으로 월드를 구축하고, 오브젝트를 만들고, 텍스처와 사운드를로드 할 때 단계별로 진행합니다. 그런 다음 재생이 시작되도록 "완료"또는 완료되면 startPlay ()를 호출하면 세상이 드러나고 음악이 재생됩니다.
이제 레벨을 완료했거나 메뉴로 빠져 나가거나 게임을 종료하면 unloadLevel ()을 호출하여 보유한 모든 리소스와 메모리를 확보하여 원활한 경험을 할 수 있습니다.
이제 "다시 시작 레벨"기능을 추가하려고하면 어떻게됩니까? 잘...
unloadLevel(currentLevel);
loadLevel(currentLevel);
startPlay();
그리고 당신은 끝났습니다! 새로운 코드가없고, 간단한 함수 호출이 거의없고, 이미 모든 것을 작성하고 디버깅 했으므로 이제 새로운 반짝이는 재시작 기능이 목록에서 벗어나서 다시는 만나지 않을 것입니다. 최고의 종류입니다! 코드를 restartCurrentLevel () 함수로 옮기면 코드를 접어 다시 볼 수 없습니다. 물론 다시 시작할 수준이 있는지 확인한 후 :)
그러나 이것이 낭비가 아닌지 궁금해하면 다시로드하려고하는 것들을 언로드합니다. 글쎄, 당신의 레벨과 자원이 적다면, 가장 느린 시스템 (그리고 오래된 스마트 폰)에서도 "재시작"이 호출 될 때마다 몇 초의로드 시간이 필요합니다. "조기 최적화", 당신은 당신의 시간과 더 나은 일을했습니다.
아, 그러나 이제 레벨이 커지고 텍스처가 더욱 상세 해지고 사운드 트랙이 모든 음성 및 음악 레이어에 대해 별도의 채널로 512kbps로 찢어졌습니다. (이유는 기억 나지 않지만 당시에는 좋은 생각처럼 보였습니다. ..) 그리고 "상태-원산지 의존적 복셀 광선 추적 다차원 푸리에 변환 행렬"에 관한 것입니다. 실제로는 완전히 구성되어 있고 실제적인 것이 아니라고 생각합니다. 실제 사람들과 테스트 한 결과 비슷한 게임보다 최악의 대기 시간에 대한 열망을 실제로 보여줍니다 (100 명의 플레이어가있는 MMORPG 자본 도시가 <2 초 안에 완전히로드 될 것으로 기대하지 않습니까?), 문제입니다.
어떻게 최적화합니까? 레벨 음, 만약 재 -loading이 문제가, 다음 레벨되지 않은 로드 문제? 그것이 단지 재 장전이라고 생각한다면, 왜 지구상에서 사람들이 레벨을 처음에 레벨을로드하는 것보다 훨씬 자주 당신의 레벨을 재 장전합니까? 코드 엔지니어링 문제가 아니라 게임 플레이 문제처럼 들립니다. 누가 레벨을 계속해서 다시로드하는 것이 재미 있다고 생각하고, 완전히 피할 수있는 것이 아니라 더 빠르기 를 바랄 까요?
실제 문제를 먼저 해결하십시오!
그러나 게임이 적어도 때때로 다시 시작되도록 설계되었으며로드 시간이 길어서 한 번만해도 완전히 피할 수 없을 정도로 길지만 다시 할 필요는 없습니다. 어쨌든 이것은 어떤 종류의 게임입니까? 조금 이상한 문제인 것 같습니다 ... 고해상도 포털과 같은 게임으로 퍼즐을 반복적으로 엉망으로 만들 것입니까?
우선, 이것이 사소한 것이 아니라는 것을 알아야합니다. 완전히 새로운 테스트되지 않은 코드를 작성해야하며, "상태 의존적"이므로 레벨 플레이 사이에 재사용 될 항목이 무엇인지 알지 못할 수도 있습니다. 레벨에 임의의 요소, 스폰, 가변 텍스처 (스켈레톤은 때때로 갑옷을 입는가?) 또는 기타 변화하는 요소가 있습니까? 복장 또는 맞춤형 모델 또는 색상 / 문 / 트랩과 같이 플레이어에 따라 다른 사항이 있습니까?
당신은 비교를 할 것이고, 많은 것들이 있습니다. 레벨 요소를 반복하면서 필요한 것과 현재로드 된 것을 비교합니다 (마지막 레벨에는로드되었지만이 레벨에는로드되지 않은 것들로 무엇을합니까? 하중?). 이것이 실제로 게임에 큰 문제라면로드 / 언로드 코드를 변경하여로드하기 전에 무언가가 이미로드되어 있는지 확인하려고 할 것입니다 (코드를 다목적으로 만들지 만 이전에 작동했던 기능 및 기능에 새로운 버그를 유발할 수 있음) 가까운 시일 내에 사용하지 않을 리소스를 신중하게 공개합니다). 한숨.
무엇을 하든지 게임이 단순하더라도 레벨을 다시 시작할 때 레벨을 처음로드 할 때 발생하지 않는 레벨 / 플레이어 상태를 기반으로하는 모호한 버그가 발생합니다. 따라서 다음과 같은 텍스트로 게임 업데이트를 작성하십시오.
"폭탄의 헬멧을 미사일이 폭발 한 타일에 떨어 뜨려도 200 픽셀 정도의 물이 더 이상 게임 데이터를 손상 시키거나 게임 충돌을 일으키지 않습니다."
대부분의 사람들이 기본 층으로 벗겨내는 대신 기존 벽 위에 페인트를 칠하거나 마른 벽에서 나온 벽을 건드 리거나 카펫 바닥을 위로 당기는 대신 카펫을 깔아 놓는 것만 알고 있습니까?
간단한 사실은 그것이 최소한의 보상을 위해 더 많은 일이라는 것입니다. 기존 벽 위에 페인트 칠하는 것은 대부분의 경우 잘 작동 하며 나무 바닥을 리핑하는 가치는 종종 최소이거나 존재하지 않습니다.
게임에서 멀티미디어 Power Point 프레젠테이션에 이르기까지 소프트웨어에서도 마찬가지입니다. 로딩 화면에서 몇 초만 쉬면 사람들이보고있는 시간의 1 %를 소비 할 수 있습니다. 투자 시간에 대한 수익이 매우 낮습니다.
그리고 대부분의 게임은 귀찮게하지 않으며, 몇 가지 극단적 인 예를 제외하고는 스크린 로딩이 좋은 게임을 덜 가치있게 만드는 많은 게임을 생각하는 데 어려움을 겪고 있습니다. 극단적 인 예는 더 빠른 레벨 로딩을위한 최적화가 의미가있는 곳이며, 이는 대중에게 공개하는 게임의 작은 부분이며, 출시되지 않았기 때문에 아무도 보지 못하는 게임의 일부일 것입니다.
정적 게임 데이터 (텍스처, 지질 정보, 영향을받지 않은 몹 등)를 메모리에 유지하고 동적 데이터 (예 : 플레이어 위치, 플레이어 통계, 퀘스트 상태, 인벤토리) 만 다시로드하는 것과 반대되는 동작을 개발하기가 더 어렵 기 때문에 .
비용과 시간이 더 많이 들기 때문에 게임 개발자는 일반적으로 그렇게하지 않습니다.