콘솔 포팅에 대한 이 글에서는 저장 시스템을 변환하기 위해 찾은 솔루션에 대해 구체적으로 설명합니다.
관련 분야: 프로그래밍
작성자: Oleksii Honcharov
오늘 소개할 사례는 다름 아닌 아름답고 비평가들의 찬사를 받은 별을 향한 여정(The Star Named EOS)입니다. 콘솔 포팅에 관한 이 글에서는 저장 시스템을 번역하기 위해 찾은 솔루션에 대해 구체적으로 설명하겠습니다. 더 이상 고민하지 말고 바로 시작하겠습니다.
별을 향한 여정(The Star Named EOS)에서 시스템 작업은 비동기식 상호 작용 없이 직접 동기식으로 수행됩니다. 이는 많은 도전 과제를 제시하는 매우 흥미로운 작업입니다. 예를 들어, PlayStation 5는 메모리 마운트를 통해 저장하는 방식으로 작동하는데, 이는 즉각적으로 이루어지지 않습니다. 중요한 점은 메모리 영역을 마운트 해제해야만 저장이 완료된다는 것입니다. 사실 PlayStation의 경우 메모리 마운트와 유사하게 작동하는 PlayerPrefs를 사용할 수 있지만, 이 모든 것은 우리가 통제할 수 없는 백그라운드에서 발생합니다. 그러나 이 방법은 게임 설정을 저장하는 것이 주된 목적이기 때문에 사용 가능한 메모리 용량이 제한된다는 큰 단점이 있습니다. 따라서 제한은 꽤나 예상되는 부분입니다. 그러나 스크린샷이 저장에 사용되기 때문에 이 제한은 충분하지 않으므로 첫 번째 저장 옵션이 기본으로 유지됩니다.
Xbox는 어떻게 되나요? Xbox는 현재 GDK API를 기본으로 사용하고 있으며, 프로젝트 시작 시 이를 사용하기 위해 항상 클라우드 데이터와 동기화가 이루어집니다. 이는 이미 프로젝트의 다른 요소인 초기화에 영향을 미칩니다. 하지만 여기서 논의하고자 하는 것은 이 문제가 아닙니다. Xbox에서 저장 작업의 기본 개념은 쓰거나 읽을 때마다 컨테이너를 열고, 필요한 작업을 수행하고, 변경 사항(있는 경우)에 대해 GDK API에 알리고, 컨테이너를 닫아야 한다는 것입니다.
Switch는 어떤가요? 마운트 및 마운트 해제에 시간이 걸리는 것은 PlayStation과 거의 동일합니다.
작업 중인 오리지널 게임에는 데이터가 어떻게 저장되나요? 세이브는 데이터가 저장되고 화면의 스크린샷이 찍힌 다음 세이브에 기록되는 방식으로 생성됩니다. 세이브가 삭제되거나 새 세이브가 생성될 때마다 데이터를 다시 읽습니다.
저희는 이 프로젝트를 위해 모든 플랫폼에 대한 단일 진입점으로 통합된 저장 시스템을 만들었습니다. 각 플랫폼마다 저장 작업을 위한 자체 SDK와 방법이 다르기 때문에 일관성을 보장하기 위해 통합 시스템을 만드는 것이 필수적이었습니다. 그 결과, 어댑터 패턴을 사용하여 작동하는 단일 엔트리 포인트 스크립트를 만들고 각 플랫폼의 엔티티를 제어하여 사용 중인 플랫폼을 파악하고 적절한 스크립트를 실행했습니다.
이제 주요 과제를 어느 정도 완벽하게 파악할 수 있게 되었습니다. 어떤 것들이 있을까요?
- 프로젝트 코드는 핵심 실행 로직을 손상시키지 않고 메인 스레드를 해제할 수 있어야 합니다.
- 비동기 호출도 멈춤을 일으킬 수 있으므로 저장 시스템에 대한 호출 수를 최소화해야 합니다.
- 비동기 호출이 있으므로 한 번에 한 번만 저장 시스템을 호출한다는 기본 조건을 지켜야 합니다.
간단하고 매우 효과적인 해결책은 작업. 비동기를 사용하는 것입니다. 왜일까요? 원래 로직을 일시 중지했다가 필요할 때 다시 시작할 수 있기 때문입니다. 이것이 프로젝트 성능 측면에서 최고의 솔루션인가요? 아니요. 가장 빠르고 기대에 부응하는 결과를 제공하나요? 네. 그렇습니다.
물론 이 접근 방식은 컴파일 후 많은 추가 코드를 생성하지만 예상한 결과를 정확하게 제공합니다. 이제 파일 시스템에 대한 모든 직접 호출을 제거하고 Task에서 개발한 “새 저장 시스템 구현”에 대한 새 호출로 대체해야 합니다. 비동기.
그런 다음 저장 시스템 메서드를 호출하는 모든 메서드를 비동기화하도록 재작업하여 모든 저장 또는 로드 작업이 완료될 때까지 실행을 일시 중지할 수 있도록 합니다. 또한 필요한 경우 호출 계층 구조에서 상위 수준의 메서드도 부분적으로 재작업합니다. 따라서 가장 중요한 첫 번째 문제가 해결되었습니다.
다음 단계는 무엇인가요?
이 단계에서 유니티의 “플레이어 환경설정”에 문제가 발생했습니다. 이 문제를 해결하기 위해 유사하게 작동하지만 데이터를 파일에 저장하여 Switch를 포함한 모든 플랫폼에서 사용할 수 있는 커스텀 아날로그를 만들었습니다. 이 솔루션이 필요했던 이유는 닌텐도 스위치가 유니티 “플레이어 환경설정”을 지원하지 않고 네이티브 닌텐도 SDK를 사용하여만 저장할 수 있기 때문입니다.
그런 다음 저장 시스템에 대한 호출을 최소화해야 했습니다. 원래 프로젝트는 다음과 같이 구현되었습니다: 스크린샷에 액세스하고 데이터를 저장하는 데 사용되는 저장 이름이 포함된 사전, 즉 파일에 기록되는 PlayerPrefs의 아날로그가 있습니다. 파일을 읽거나 쓰거나 삭제할 때마다 파일을 처음부터 다시 읽습니다. PC, 특히 SSD를 사용하는 경우에는 문제가 되지 않으므로 최적화를 무시할 수 있지만, 저장소가 12개 이상인 콘솔에서는 심각한 문제가 발생할 수 있습니다.
이 문제에 대한 몇 가지 해결책이 있습니다:
대량의 데이터를 묶어 일괄 작업으로 저장에 액세스합니다(원래 로직을 다시 작업해야 하고 시간이 많이 걸릴 수 있음).
이미 로드된 저장에 대한 캐시를 생성하고 캐시된 데이터를 사용하여 반복적으로 액세스합니다.
두 번째 옵션은 구현하기가 훨씬 더 편리했기 때문에 기본 옵션으로 선택했습니다. 하나의 개체를 수십 번 다시 쓰거나 동시 읽기 및 쓰기 작업이 있을 때 추가적인 상호 작용 시나리오를 생성하지 않습니다. 이러한 상황은 그다지 분명하지 않을 수 있지만 처음부터 피하는 것이 나중에 큰 문제가 되지 않습니다.
이제 마지막 과제인 다중 동시 쓰기, 읽기, 삭제 작업이 하나 남았습니다. 이 작업은 비동기 호출을 사용할 때 관리하기가 매우 쉽습니다. 파일 작업을 시도할 때마다 세마포어나 간단한 변수와 같은 표시기를 사용해 대기열이 여전히 사용 중임을 알릴 수 있습니다. 태스크, 비동기 작업에 대한 원래 로직을 재작업했기 때문에 코드가 추가 호출을 기다리고 있으며, 저장 작업이 시작되면 증가를 수행하고 종료되면 감소하는 간단한 변수로 충분합니다. 이렇게 하면 여러 작업이 동시에 발생하지 않도록 할 수 있으며, 상호작용 로직이 진입점에서 경쟁을 제거합니다.
잘 읽으셨기를 바라며 무언가를 배우셨기를 바랍니다. 다음 시간까지...
* 원문:
Featured Blog | Save the saves
In this article about console porting, we’ll discuss specifically the solutions we found to translate the save system.
www.gamedeveloper.com
* 게임 사이트:
Save 30% on The Star Named EOS on Steam
The Star Named EOS is a story-rich puzzle adventure built around photography. Recreate compositions of past photos to uncover the truth of a family mystery. Experience a harmonious mixture of beautiful hand-drawn art and engaging puzzles on a journey of re
store.steampowered.com
댓글