S3World

분리의 목적은 같은 결과를 재검토할 수 있게 하는 데 있습니다. 화면에서 함선이 반짝였다는 관찰만으로는 피해량이 달라진 원인을 찾기 어렵습니다. 무기 유형과 방어층 상태를 고정하고 계산 결과를 확인하면, 표현상의 문제인지 전투 규칙의 문제인지 질문을 좁힐 수 있습니다. 이것이 웹과 모바일 화면을 함께 다룰 때도 유지하고 싶은 경계입니다.

처음 살펴볼 때는 같은 상대를 두고 한 조건만 바꾸는 편이 좋습니다. 실드가 남은 상대와 실드가 소진된 상대에게 같은 무기가 어떻게 작용하는지 비교하거나, 무기 속성을 고정한 채 전달 방식만 바꾸어 봅니다. 방어층이 바뀌는 순간의 결과를 따로 보면 어느 조합이 어느 상황을 겨냥하는지 읽기 쉽습니다. 세부 계수는 밸런스 조정 대상이므로 이 글은 고정된 최강 조합을 약속하지 않습니다.

관찰 순서는 '사거리 진입 → 발사 가능 여부 → 어느 방어층에 피해가 들어갔는가 → 다음 발사까지의 간격'처럼 잡을 수 있습니다. 사거리 밖에 머물러 발사하지 못한 경우를 무기 피해량 부족으로 오해하면 엉뚱한 모듈을 바꾸게 됩니다. 로그와 화면을 함께 읽도록 하는 이유도 여기 있습니다.

직접 비교 기록을 남긴다면 버전, 양쪽 함선 구성, 무기·방어 상태, 관찰 시점, 예상과 실제 결과를 적어 두는 것이 좋습니다. 승리 여부 하나보다 '왜 발사하지 않았는지', '방어층이 언제 바뀌었는지'가 다음 설계 변경에 더 도움이 될 때가 있습니다.

이 항목은 계획 문서에서 읽은 설계 판단으로 소개합니다. 이 글만으로 해당 세부 기능이 배포판에 전부 구현됐다고 주장하지 않습니다. 핵심 질문은 '한 함선을 두 곳에서 동시에 쓰지 않으면서 상태를 어떻게 보존할 것인가'이며, 모듈 설계에서 시작한 자원 배분의 문제가 전략 계층까지 이어진다는 점이 흥미롭습니다.

기술 선택 검토 노트에서 한 대목만 옮깁니다. 결론보다, 그 결론이 나중에 어떻게 됐는지가 남을 만해서입니다.

"로블록스나 앱 같은 친숙한 환경에는 무리가 있을까?"

새 엔진을 배우는 비용을 피하고 싶었습니다. 이미 익숙한 도구가 있는데 굳이 돌아가야 하나 싶었습니다.

• 성능: 당시에는 크루 100명 수준에서도 지연이 생길 수 있다고 우려했습니다. 직접 재현한 성능 결과가 아니며, Luau가 처리할 수 있는 인원 상한도 아닙니다. 실제 부담은 개체별 계산량, 갱신 주기, 물리·렌더링·통신 작업을 어떻게 나누느냐와 함께 측정해야 합니다.[1][2]
• 데이터: 경험치·계급·스킬을 오래 보관하려면 저장 단위, 요청 빈도와 재시도를 설계해야 합니다. Roblox DataStore에는 요청별 제한과 오류 처리 조건이 있으므로 현재 공식 문서에 맞춰 검토할 항목입니다.[3]
• UI: 정보가 많은 함대·크루 화면을 당시 팀이 익숙하게 만들 수 있을지 걱정했습니다. 플랫폼에서 구현할 수 없다는 판정은 아니었습니다.
• 이용 경험: 우리가 구상한 긴 호흡의 전략 게임을 어떤 이용자에게 어떻게 전달할지 정하지 못했습니다. Roblox 이용자 전체의 선호를 조사한 결과는 아닙니다.

당시 결론은 "본 게임의 첫 터전으로는 아니다"였습니다. 영원히 아니라는 뜻은 아니었는데, 문서에는 그렇게 읽히게 적혀 있었습니다.

당시 검토표의 요지: HTML5/JavaScript는 복잡한 시뮬레이션에 성능상 부담이 있을 것으로 예상함.

웹도 비추천이었습니다. 로블록스와 같은 칸이었던 셈입니다. 이 역시 특정 브라우저·기기·작업량을 고정해 비교한 벤치마크 결론은 아니었습니다. 그래서 Unity로 갔고, 처음부터 데이터 지향 아키텍처를 전제로 설계했습니다.

비추천 판정은 실측 결과가 아닌 예상이었으므로 현재 구현에 맞춰 다시 검토해야 합니다. 표가 걱정하던 것은 구상 전체의 부하였고, 실제로 먼저 구현한 범위는 그보다 작았습니다. 지금 웹에서 돌리는 것은 함대 전투 시뮬레이션이며, 초기 구상에 있던 수천 명 규모의 크루 개별 시뮬레이션을 웹이 그대로 감당한다는 뜻은 아닙니다.

가능해진 이유는 로블록스가 갑자기 달라져서가 아닙니다. 그때 재던 기준이 "이 플랫폼에서 구상 전체를 감당할 수 있는가" 하나뿐이었기 때문입니다. 구상 전체를 한 번에 얹지 않는다면 질문이 달라집니다. 어느 부분을 그곳에 맞게 가져갈 것인가, 그리고 그 부분을 떼어낼 수 있게 만들어 두었는가.

이 구조 덕분에 웹으로 옮길 때 다시 만든 것은 렌더 레이어뿐이었습니다. 코어는 언어만 바꿔 건너왔고, 브라우저에서는 도트 그래픽을 그리는 얇은 층 하나만 새로 얹었습니다.

플랫폼이 하나 더 늘어날 때 드는 비용도 같은 구조에서 결정됩니다. 규칙이 화면 코드 안에 흩어져 있었다면 새 플랫폼마다 게임을 다시 만들어야 합니다. 규칙이 따로 서 있으면 각 플랫폼에서 만들 것은 그 위에 얹는 층뿐입니다.

하나 더 배운 것은 검토 문서를 쓰는 방식입니다. "부적합"이라고만 적어 두면 그것이 영구 결론처럼 남습니다. 무엇을 기준으로 재서 그렇게 판단했는지 함께 적어 두어야, 기준이 달라졌을 때 결론도 다시 열 수 있습니다.

다음 성능 검토에서는 기기, 클라이언트·서버 역할, 크루당 수행 작업과 갱신 주기를 고정하고 크루 수를 바꿔 비교할 계획입니다. MicroProfiler로 프레임 시간과 스크립트 작업 구간을 기록하고, 저장·통신의 지연은 따로 관찰해야 어느 부분을 줄일지 판단할 수 있습니다.[1][2] 이 글에는 그 시험의 새로운 측정 결과를 싣지 않았습니다.

이 글의 판단은 S3 World라는 특정 프로젝트의 요구사항을 기준으로 한 것입니다. 플랫폼의 성능과 기능은 계속 바뀌므로, 다른 프로젝트에서는 각자의 요구사항으로 다시 재어 보아야 합니다.