dotgimon 제작기 19. 워치 앱 설계와 P0 스파이크 계획

둥근 반투명 배경은 도트 화면에 안 맞았다

오전과 오후에는 마무리 작업을 했다. 서식지 배경을 버전별로 다시 디자인했는데, 둥근 반투명 도형이 "너무 정신없어서" 원래대로 되돌렸다. 도트 화면에는 격자에 맞는 각진 형태가 어울렸다.

조그레스(두 몬스터의 합체 진화) 후에는 몬스터가 너무 높이 떠 있었다. 합체체는 44px라 일반 몬스터보다 크다. 발끝을 일반 몬스터와 같은 줄에 맞췄다.

똥을 싸기 전 1.2초 동안 움찔움찔하는 연출도 넣었다. 훈련에 드는 비타민 비용은 성장 단계별로 나눴다.

연결 플러그인이 빌드 설정을 덮어써서 dev launcher가 깨졌다

가로 모드를 허용하고 Expo 57.0.x / RN 0.86.3 패치 업데이트를 했다.

dev launcher(Expo 개발 빌드에서 앱을 띄울 때 먼저 나오는 실행 화면)도 깨져 있었다. Nearby(근처 기기끼리 직접 연결하는 Google의 통신 기능) Swift 패키지를 연결하는 Config Plugin(Expo 프리빌드 때 네이티브 프로젝트 설정을 코드로 수정하는 플러그인)이 기존 빌드 설정을 덮어쓰고 있었다. 덮어쓰지 않고 기존 값 뒤에 이어 붙이도록 고쳤다.

"워치앱도 개발돼야 해"에서 시작했다

저녁에는 워치 앱 설계로 넘어갔다. 처음엔 폰 화면을 워치에 미러링만 할지 고민했다. 결국 워치에서도, 폰에서도 키울 수 있어야 한다고 정했다.

대전과 합체는 Nearby와 번호 공유 방식을 함께 두고, 워치에서는 번호 공유만 써도 되게 하는 방향을 검토했다.

Wear OS(Google의 스마트워치 운영체제) 에뮬레이터를 설치하고, 워치 앱 설계 스펙과 P0 스파이크 계획을 작성했다. 스파이크는 본 구현 전에 기술적으로 되는지만 짧게 확인하는 실험이다.

워치에서 JS 엔진이 안 돌면 엔진을 다시 써야 했다

P0 스파이크의 질문은 하나였다. 폰에서 돌던 TypeScript 게임 엔진을 워치에서도 그대로 돌릴 수 있는가. 안 되면 KMP(Kotlin Multiplatform, Kotlin 코드 하나를 iOS·Android 등 여러 플랫폼에서 공유하는 기술)로 엔진을 다시 써야 했다.

스파이크 경로는 이렇게 잡았다.

엔진은 64×64 팔레트 버퍼에 그리게 하고, RN에 의존하지 않는 createCore로 떼어낸다. 시드를 고정한 결정론 시나리오로 golden(기대 출력을 저장해 두고 실제 결과와 비교하는 기준값)을 만들고 esbuild로 번들한다. 이 번들을 QuickJS-ng(기기에 내장할 수 있는 경량 JS 엔진 QuickJS의 커뮤니티 포크)에서 실행하고, 공용 C API pxhost를 거쳐 watchOS(Apple Watch 운영체제) 앱과 Wear OS 앱에 붙이는 구조였다. Wear OS 쪽은 JNI(Java·Kotlin에서 C 코드를 호출하는 인터페이스)로 잇게 했다.