Godot 횡스크롤 라인 오펜스 판단 기록 — 김예찬

김예찬 / Project

ALL DECISIONS

Godot 횡스크롤 라인 오펜스 판단 기록 5건

각 항목은 상황 → 결정 → 이유 → 한계 순서입니다.

01에르엘워즈식 라인 오펜스를 기반으로 삼는다

상황: 졸업 프로젝트로 1년 안에 혼자 완성할 수 있는 장르가 필요했다.
결정: 게임빌의 에르엘워즈를 레퍼런스로, 여러 라인에서 유닛이 진격하고 맞붙는 횡스크롤 라인 오펜스를 만들었다. 아군 11종, 적 8종 유닛을 구성했다.
이유: 유닛을 늘려 갈수록 콘텐츠가 쌓이는 구조라, 기능을 한 번 갖추면 1인 개발로도 볼륨을 키울 수 있다.
한계: 기획은 레퍼런스를 기반으로 했고, 독자적인 규칙 변형은 크지 않다.

02유닛을 컴포넌트로 조립한다

상황: 유닛마다 체력, 공격 범위, 회복 범위, 효과 같은 기능을 조합해야 했다.
결정: 기능을 체력바, 공격 범위, 회복 범위, 효과 컴포넌트로 나누고, 유닛 씬에 필요한 컴포넌트만 붙여 만들게 했다(1/3 컴포넌트화 완료).
이유: 새 유닛을 만들 때 코드를 복사하지 않고 컴포넌트 조합만으로 끝내기 위해서다.
한계: 컴포넌트끼리 직접 참조하는 부분이 남아, 7월에 상태 컴포넌트의 결합도를 다시 낮추는 작업을 했다.

03라인 간 전투를 엔진 물리로 격리한다

상황: 여러 라인의 유닛이 한 화면에 있으면 다른 라인의 유닛과 충돌하거나 교전하면 안 된다.
결정: 라인마다 Path2D로 이동 경로를 나누고(1/22), 물리 충돌 레이어와 마스크를 라인별로 매핑해 라인별 독립 전투를 구현했다(2/2).
이유: "같은 라인인지" 확인하는 필터링 코드를 따로 두지 않고, 엔진의 물리 판정만으로 격리하기 위해서다.
한계: 물리 레이어 수에 한도가 있어 라인 수를 크게 늘리면 매핑을 다시 설계해야 한다.

04교전 컴포넌트를 상태 컴포넌트(FSM)로 바꾼다

상황: 처음에는 교전 처리 컴포넌트(engageComponent) 하나가 유닛의 행동을 맡았다. 넉백 같은 추가 상태를 넣으려면 이 컴포넌트가 계속 커져야 했다.
결정: 상태 관리 컴포넌트와 상태 노드로 나눈 FSM으로 교체했다(4/25). 대기, 이동, 사망, 넉백, 근접·원거리 단일·범위 공격, 시전, 범위 회복을 각각 상태 노드로 두었다.
이유: 넉백과 추가 상태를 구현하려는 것이었다. 상태를 노드로 나누니, 새 유닛은 상태 노드를 조립하는 것만으로 만들 수 있게 됐다.
한계: 상태 전환 규칙이 상태 컴포넌트에 모여 있어, 7월에 결합도를 낮추는 정리를 한 번 더 거쳤다.

05세이브 데이터를 한 곳으로 모은다

상황: 보유 유닛과 슬롯 같은 진행 데이터를 여러 씬에서 읽고 썼다.
결정: Autoload 싱글톤(SaveData)에 데이터를 모으고 getter와 setter로만 접근하게 했다. setter가 호출되면 진행 상황을 JSON으로 저장한다(6/2).
이유: 코드 가독성과 캡슐화를 높이고, 씬이 바뀌어도 데이터가 유지되게 하려는 것이다.
한계: 값이 바뀔 때마다 파일을 쓰기 때문에 쓰기 횟수가 많다. 공개 레포의 마지막 커밋(2024-07) 기준 저장 경로는 res://Saves/이다.

BACK

Godot 횡스크롤 라인 오펜스 소개로

© 2026 Kim Yechan