Scritchy Scratchy를 다양한 플랫폼에서 실행 가능하게 만들기

Scritchy Scratchy를 PC 와 모바일로 출시하는 동시에 Nintendo Switchᵀᴹ 2 및 Nintendo Switch용으로도 준비한다는 것은 매우 다른 기기에서 촉각적 상호 작용을 적용해야 한다는 것을 의미했습니다.

컨트롤러를 사용해서도 동일한 반응성을 구현하기 위해 개발팀은 입력 방식, UI 동작, 햅틱 피드백, 그리고 게임이 다양한 화면 크기와 화면 비율에 맞춰 조정되는 방식을 재고해야 했습니다.

이식 과정은 성능과 유지보수성 사이의 균형을 맞추는 것을 의미하기도 했습니다. 팀은 플랫폼별로 별도의 브랜치를 만드는 대신, 게임을 단일 Unity 프로젝트에 유지하여 최적화, 버그 수정 및 새로운 콘텐츠가 모든 플랫폼에서 호환되도록 했습니다.

출시 이후 이 게임은 스팀에서 125만 장 이상 , 모바일에서 25만 장 이상 판매되었으며, 14,000개 이상의 리뷰에서 94%의 긍정적인 스팀 평점을 받았습니다 .

저희는 런치 머니 게임즈의 크리에이티브 디렉터인 콘스탄틴 레르비그, 런치 머니 게임즈의 CEO인 한니발 시그푸손, 펀데이 게임즈에서 모바일 및 닌텐도 스위치 이식 작업을 담당하는 프로그래머 크리스티안 비스콥스토 톰센, 그리고 펀데이 게임즈의 제품 및 파트너 총괄인 에밀 키에르와 함께 스크리치 스크래치 의 이식 과정에서 겪었던 가장 큰 어려움에 대해 이야기를 나눴습니다.

*닌텐도 스위치는 닌텐도의 상표입니다.

포팅 과정에서 가장 큰 기술적 어려움은 무엇이었나요?

CBT: 모바일 개발에서 가장 큰 어려움은 플랫폼별 특성에 따른 문제였습니다. 앱 스토어 와 구글 플레이에 맞는 빌드를 제대로 작동하도록 만드는 것, 인증서를 처리하는 것, 플랫폼 SDK를 통합하는 것, 그리고 클라우드 저장과 같은 시스템을 다루는 것이 주요 과제였습니다.

마우스와 터치를 중심으로 게임을 설계했기 때문에 입력 방식이 가장 큰 어려움 중 하나였습니다. 우리는 게임패드에서 스크래칭 기능이 어떻게 작동해야 할지 결정해야 했습니다. 그 과정에는 디자인에 대한 논의와 여러 차례의 수정 작업을 거친 후에야 비로소 만족스러운 결과물을 얻을 수 있었습니다.

에밀 키에르: 티켓을 열고 긁기 시작하면 입력값이 관련 영역으로 자동으로 이동하는 것을 포함하여, 상호 작용이 어떻게 이루어져야 하는지 구체적으로 설계했습니다.

특히 닌텐도 스위치 2의 경우, 마우스 기능도 지원하고 싶었습니다.

모바일 버전에서는 스크래치 동작 시 햅틱 피드백을 추가했습니다. 햅틱 피드백은 특히 Android 기기에서 매우 다양한 방식으로 작동합니다. 일부 사용자들이 휴대전화 진동이 너무 강하다고 신고하는 사례가 있어서, 그 부분을 개선하는 데 몇 번의 시행착오가 있었습니다.

플랫폼 전반에 걸쳐 핵심적인 상호작용이 촉각적인 느낌을 주도록 만드는 데 특별한 어려움이 있었나요?

CBT: 게임패드 조작은 확실히 번역하기 가장 어려운 부분이었습니다. 터치만으로 긁는 메커니즘이 거의 즉시 제대로 작동했습니다. 컨트롤러를 사용하면서 단순히 커서를 일대일로 매핑하는 것이 아니라, 동일한 동작을 어떻게 느껴야 하는지 다시 생각해봐야 했습니다.

EK: 우리 네 명은 워크숍을 위해 자리에 앉아 PC 버전을 직접 살펴보았습니다. 우리는 효과적으로 상호작용 방식을 분해하고 다른 플랫폼에서 사용할 수 있는 와이어프레임으로 재구축했습니다.

그렇게 하고 나니 직관적인 접근 방식이 상당히 명확해졌습니다. 이는 우리가 크로스 플랫폼 을 고려하여 초기 디자인을 얼마나 꼼꼼하게 구상했는지를 보여줍니다. 모바일 버전 출시와 이후 컨트롤러에 맞춘 조작 방식 개발 과정에서 많은 시간을 절약할 수 있었습니다.

어떤 포팅 전략을 사용하셨나요? 플랫폼별로 맞춤 설정된 단일 빌드를 사용하셨나요, 아니면 플랫폼별 별도 브랜치를 사용하셨나요? 왜?

CBT: 각 플랫폼별로 별도의 장기 브랜치를 유지하는 대신, 단일 Unity 프로젝트와 코드베이스를 선택했습니다.

별도의 플랫폼 분기들은 서로 멀어지는 경향이 있습니다. 한 브랜치에서 무언가를 수정하고 나면 다른 브랜치에 통합해야 합니다. 일단 네 개 이상의 목표를 지원하게 되면, 금방 지루해지기 시작합니다.

단일 프로젝트에는 조건부 컴파일과 플랫폼별 검사가 코드 전체에 걸쳐 발생하기 때문에 나름의 단점이 있습니다. 하지만 스크리치 스크래치 의 규모와 복잡성을 고려하여 관리 가능한 수준으로 유지했습니다.

CL: 단일 프로젝트의 또 다른 큰 장점은 모든 작은 최적화 및 버그 수정 사항이 모든 빌드에 적용된다는 것입니다.

Unity 프로파일러는 플랫폼별 병목 현상을 찾아 해결하는 데 어떻게 도움이 되었나요?

CBT: 성능 개선 작업을 하면서 Unity Profiler를 많이 사용했습니다. 제 작업 흐름은 기본적으로 다음과 같습니다. 먼저 프로파일링을 해서 실제로 속도가 느린 부분을 확인한 다음, 추측하기보다는 그 부분을 수정하는 것입니다.

가장 대표적인 예는 스크래치 입자였습니다. 티켓을 긁으면, 표면의 질감에서 정보를 추출하여 긁는 부분의 색상과 일치하는 입자를 생성합니다. PC 에서는 정말 잘 작동했지만, 원래 방식은 모바일에서는 너무 부담스러웠습니다.

해결책은 해당 파티클에 GPU 인스턴싱을 사용하는 것이었습니다. 그 변경을 하고 나니, 그것은 포트에서 가장 중요한 성능 최적화 중 하나가 되었습니다.

Input System 어떻게 다양한 제어 방식을 지원하는 데 도움이 되었습니까?

CBT: Input System 에서 터치 기능이 거의 완벽하게 작동한다는 점은 매우 유용했고 시간을 많이 절약해 주었습니다.

컨트롤러를 PC 에 연결하고 에디터에서 직접 조작감을 테스트한 다음 닌텐도 스위치용 게임을 빌드할 수 있습니다. 컨트롤러 매핑은 Input System 통해 그대로 전달되므로 반복 작업이 훨씬 빨라집니다.

HS: 프로젝트 초기부터 Input System 과 나머지 코드 사이에 계층을 구축했습니다. 게임 코드는 모든 종류의 하드웨어 입력에 직접적으로 신경 쓸 필요가 없습니다. 해당 레이어를 사용하여 입력이 포인터를 활성화했는지 여부, 포인터의 위치 또는 포인터의 월드 위치가 무엇인지 확인할 수 있습니다.

각 플랫폼별로 어떤 성과 목표를 설정하셨고, 목표 달성률은 어느 정도였습니까?

EK: 우리는 모바일에서 지원되는 최소 OS 및 API 수준을 설정한 다음, 해당 범위의 하단에 가까운 기기들을 대상으로 테스트를 진행했습니다.

파티클 시스템에 대한 GPU 인스턴싱 수정 작업을 완료한 후에는 해당 기기에서 의미 있는 프레임 속도 문제가 발생하지 않았습니다.

iOS의 경우, 저희는 특히 아이폰 X와 아이폰 XS를 포함한 여러 기기를 테스트하여 지원하고자 하는 하드웨어에서 게임이 원활하게 실행되는지 확인했습니다. Android 에서도 동일한 철학을 따랐습니다.

CL: 스크래치 스크래치는 부드럽게 작동해야 합니다. 게임이 렉이 걸리면 스크래치하는 재미가 바로 사라지기 때문입니다.

요구 조건은 마치 손가락으로 실제 스크래치 스티커를 긁는 듯한 느낌이 들어야 한다는 것이었습니다. 실제로 이는 초당 약 60프레임 정도의 부드러운 화면을 목표로 한다는 것을 의미했습니다.

CBT: 해상도 문제도 또 다른 난관이었습니다. 저희는 오리지널 게임을 와이드스크린 PC 디스플레이에 맞춰 디자인했습니다. 대부분의 가로형 스마트폰 해상도는 비교적 자연스럽게 변환되었지만, 아이패드의 화면 비율은 변환하기가 더 어려웠습니다.

출시 전에 아이패드 버전도 제대로 작동하도록 만들 충분한 시간이 있었습니다. 그 과정에는 프레젠테이션을 조정하고 확대/축소 기능을 사용하여 레이아웃이 자연스럽게 맞도록 하는 작업이 포함되었습니다.

목표는 사용자가 Scritchy Scratchy를 PC, 휴대폰 또는 iPad에서 처음 접했든 상관없이, 마치 해당 기기에 원래부터 있었던 것처럼 느껴지고, 어설픈 이식작처럼 느껴지지 않도록 하는 것이었습니다.

플랫폼 전반에 걸쳐 배송 품질에 가장 큰 영향을 미친 배포 결정은 무엇이었습니까?

EK: 가장 중요한 배포 결정은 모든 것을 하나의 프로젝트에 유지하는 것이었습니다.

이는 최초 항구 구축뿐만 아니라 이후 유지보수에도 중요한 문제입니다. 게임에 새로운 콘텐츠가 추가될 때, 저는 여러 독립적인 플랫폼에 해당 콘텐츠를 배포하는 데 얼마나 시간이 걸릴지 걱정할 필요가 없습니다.

CL: 덕분에 인력을 여러 업무 간에 이동시키는 것도 쉬워졌습니다. PC 버그를 수정하던 개발자가 별도의 모바일 코드베이스를 배우지 않고도 바로 모바일 문제 해결에 투입될 수 있었습니다.

여러 플랫폼으로 게임을 이식하려는 개발자들에게 가장 중요한 팁은 무엇인가요?

CL: 디자인 관점에서 볼 때, 게임이 출시될 가능성이 있는 플랫폼을 초기에 결정하는 것이 중요합니다. 우리는 게임패드에 크게 집중하지 않기로 일찌감치 결정했고, 나중에 그 결정이 추가적인 작업량을 발생시켰다는 것을 알게 되었습니다.

HS: 게임 개발 초기부터 입력 방식, 해상도, 화면 비율, 그리고 다양한 플랫폼에서 게임이 어떻게 느껴져야 하는지를 고려해야 합니다. 그런 것들은 나중에 추가하기가 훨씬 더 어렵습니다.

스크래치 스크래치스팀 , 앱 스토어 , 구글 플레이 에서 이용 가능합니다. Unity 블로그 와 리소스 허브 에서 Unity 개발자들의 더 많은 이야기를 확인해 보세요.