작성: COZYGONO 개발·편집팀 · 수정:
S3 World 개발 노트: 함선 설계의 선택을 전투 결과로 연결하기
설계 문서만으로 완성된 게임을 설명하지 않기 위해 웹 전투 코어도 함께 읽었습니다. 화면과 계산의 분리, 방어층별 상성, 사거리·쿨다운이 만드는 선택을 정리합니다.
1) 플랫폼 독립 시뮬레이션 경계
2) 함선 3중 방어층 & 무기 전달 구조
| 방어 계층 | 작동 특성 | 주요 상성 변수 |
|---|---|---|
| 1층: 실드 (Shield) | 시간당 자동 재생 | 에너지/열 계열 계수 민감 |
| 2층: 장갑 (Armor) | 고정 피해 감쇄 | 물리·관통탄 및 단발 고화력 유효 |
| 3층: 선체 (Hull) | 모듈 파괴 직결 | 0 도달 시 함선 격침 판정 |
1. 오래된 계획과 현재 코드를 나누어 읽다
S3 World의 초기 문서는 Unity DOTS 기반 함대 전투를 출발점으로 삼았습니다. 2026년 6월의 개발 기록에는 전투 코어를 웹의 TypeScript로 옮긴 경과가 남아 있습니다. 예전 엔진의 체크리스트에는 미구현으로 적힌 항목이 있으므로 그 표를 현재 웹 버전의 상태표로 쓰지 않았습니다. 이 글은 2026년 9월 4일에 개발 기록과 현재 웹 소스를 다시 대조해 쓴 노트입니다.
2. 화면을 바꾸어도 같은 전투를 계산하려면
웹 버전은 함선과 무기 상태를 다루는 시뮬레이션 코드와 화면 표현을 나눕니다. 특히 방어층 피해 계산은 별도 함수에 있고, 발사·피해 적용·실드 재생·파괴 처리가 전투 진행 단계에 연결됩니다. 화면을 열지 않고도 이런 계산 부분에 입력을 주어 결과를 비교할 수 있는 구조입니다.
분리의 목적은 같은 결과를 재검토할 수 있게 하는 데 있습니다. 화면에서 함선이 반짝였다는 관찰만으로는 피해량이 달라진 원인을 찾기 어렵습니다. 무기 유형과 방어층 상태를 고정하고 계산 결과를 확인하면, 표현상의 문제인지 전투 규칙의 문제인지 질문을 좁힐 수 있습니다. 이것이 웹과 모바일 화면을 함께 다룰 때도 유지하고 싶은 경계입니다.
3. 공격력 하나로 함선을 비교하지 않는 이유
현재 피해 모델은 실드, 장갑, 선체를 구분하고 무기의 속성과 전달 방식도 구분합니다. 예를 들어 에너지 계열이 실드에 작용하는 계수와 장갑에 작용하는 계수는 같지 않습니다. 빔·투사체·미사일의 전달 방식에도 별도의 보정이 있습니다. 그래서 무기의 기본 공격력만 높은 쪽이 언제나 유리하다고 말할 수 없습니다.
처음 살펴볼 때는 같은 상대를 두고 한 조건만 바꾸는 편이 좋습니다. 실드가 남은 상대와 실드가 소진된 상대에게 같은 무기가 어떻게 작용하는지 비교하거나, 무기 속성을 고정한 채 전달 방식만 바꾸어 봅니다. 방어층이 바뀌는 순간의 결과를 따로 보면 어느 조합이 어느 상황을 겨냥하는지 읽기 쉽습니다. 세부 계수는 밸런스 조정 대상이므로 이 글은 고정된 최강 조합을 약속하지 않습니다.
4. 사거리와 쿨다운도 설계의 일부
발사 처리에서는 무기가 있는지, 쿨다운이 끝났는지, 표적이 사거리 안에 있는지 등을 검사합니다. 즉 장착된 무기가 있다는 것과 지금 피해를 줄 수 있다는 것은 다릅니다. 전투 결과를 비교할 때에는 피해량뿐 아니라 발사가 실제로 가능한 시간과 상대의 위치도 보아야 합니다.
관찰 순서는 '사거리 진입 → 발사 가능 여부 → 어느 방어층에 피해가 들어갔는가 → 다음 발사까지의 간격'처럼 잡을 수 있습니다. 사거리 밖에 머물러 발사하지 못한 경우를 무기 피해량 부족으로 오해하면 엉뚱한 모듈을 바꾸게 됩니다. 로그와 화면을 함께 읽도록 하는 이유도 여기 있습니다.
5. 문서에 있는 테스트 숫자를 현재 보증으로 쓰지 않기
웹 README에는 초기 헤드리스 검증 기록이 남아 있습니다. 이것은 해당 시점의 개발 이력이며, 현재 전체 기능이 그 숫자만큼 검증됐다는 뜻은 아닙니다. 이번 글 편집에서는 관련 소스의 존재와 연결을 읽어 확인했지만 게임 전체 테스트나 실제 플레이를 새로 수행한 것으로 표현하지 않았습니다.
직접 비교 기록을 남긴다면 버전, 양쪽 함선 구성, 무기·방어 상태, 관찰 시점, 예상과 실제 결과를 적어 두는 것이 좋습니다. 승리 여부 하나보다 '왜 발사하지 않았는지', '방어층이 언제 바뀌었는지'가 다음 설계 변경에 더 도움이 될 때가 있습니다.
6. 파견대 설계에서 가져온 질문
별도 파견대 계획 문서는 함선을 본대 목록에서 지우는 대신 배치 상태를 표시하고, 지휘 비용을 본대와 파견대 합산으로 관리하는 방향을 제안합니다. 파견했다고 전체 지휘 비용이 사라지지 않게 하려는 설계입니다. 또 파견 중인 자원의 본대 중복 사용을 막고 귀환 때 결과를 정산하는 문제를 다룹니다.
이 항목은 계획 문서에서 읽은 설계 판단으로 소개합니다. 이 글만으로 해당 세부 기능이 배포판에 전부 구현됐다고 주장하지 않습니다. 핵심 질문은 '한 함선을 두 곳에서 동시에 쓰지 않으면서 상태를 어떻게 보존할 것인가'이며, 모듈 설계에서 시작한 자원 배분의 문제가 전략 계층까지 이어진다는 점이 흥미롭습니다.
7. 첫 비교를 위한 작은 기록표
처음부터 모든 조건을 바꾸기보다 같은 함선에 무기 한 종류만 바꾼 비교를 남겨 보세요. 상대 방어층과 관찰 시간을 같게 두고 사거리 진입 여부, 첫 피해, 방어층 소진을 순서대로 적습니다. 다음에는 함대 편성을 바꾸되 무기 구성은 고정합니다. 이렇게 비교의 단위를 줄이면 함선 설계의 선택과 전투 결과 사이의 연결을 더 선명하게 볼 수 있습니다.