취미로 만드는 로그라이크 게임입니다.
발사계 스킬을 추가했습니다. 추가하고 너무 작업 내용이 산만하네요.
그래서 연휴 내내 로그라이크 엔진으로 바꾸는 작업을 진행했습니다. 이렇게 하면 기능 완성 후 데이터만 가지고 엔간한 작업을 할 수 있으니 이 방향이 옳겠다 싶어서였습니다.
처음에는 엔진으로 바꾸기 위한 모든 사항을 입력하니 gemini cli가 API 한도를 넘었다고 그냥 정지해버리네요. 명령줄 하나에 토큰 소진.
웹으로 접속해서 방법을 알아보았습니다.
결국 /clear를 사용하라는 내용이 나옵니다.
-
현재까지의 모든 대화를 요약해서 입력해줍니다.
|이전 대화 내용|핵심 요약 문장|
|—|—|
|ECS 패턴 도입 결정|우리는 컴포넌트-엔티티-시스템(ECS) 패턴으로 로그라이크 엔진을 만들기로 결정했습니다.|
|주요 파일 목록|주요 파일은 component.py, system.py, entity.py, data_manager.py입니다.|
|최근 작업 내용|현재 component.py를 구현하고 있습니다. PositionComponent와 HealthComponent의 정의가 필요합니다.| -
/clear로 대화 내용을 지웁니다.
-
요약된 문장 내용을 한번에 입력해줍니다.
우리는 ECS 패턴으로 로그라이크 엔진을 만들고 있으며, 주요 파일은 component.py, system.py, entity.py입니다. 현재 component.py에 PositionComponent와 HealthComponent를 정의하는 작업이 필요합니다. -
이제 새로운 질문을 생성해서 방금 입력된 요약 문장을 새 기억으로 만들어 맥락을 새로 구축합니다.
이제 기존이 GEMINI.md 파일을 수정해줍니다.
이것 역시 제미나이에게 맞기기 전 다음과 같은 가이드를 제시합니다.
Roguelike Game Engine Architecture (ECS)
최종 목표
터미널 기반의 로그라이크 게임 엔진을 컴포넌트-엔티티-시스템(ECS) 패턴을 기반으로 완성합니다. 규칙과 데이터를 실행 로직과 분리하여 확장성, 유지보수성, 재사용성을 극대화합니다.
핵심 디렉토리 및 모듈 역할
1. Engine Core (엔진 핵심)
| 파일/모듈 | 역할 |
|---|---|
engine.py |
게임의 메인 루프 실행, EntityManager 초기화, 모든 System의 순서별 update() 호출 등 게임 흐름 제어. |
entity.py |
**Entity(개체)**의 고유 ID 생성 및 관리. EntityManager 클래스를 포함하여 컴포넌트 추가/검색 기능 제공. |
component.py |
Entity에 부여되는 모든 순수 데이터 클래스(State) 정의. (예: PositionComponent, HealthComponent, ElementalComponent). |
system.py |
컴포넌트를 가진 Entity를 처리하는 순수 로직 정의. (예: MovementSystem, CombatSystem, RenderingSystem). |
2. Game Data & Definitions (데이터 정의)
| 파일/모듈 | 역할 |
|---|---|
data_manager.py |
외부 데이터 파일(.txt, .json)을 읽어 템플릿(Definition) 객체로 변환하는 로직. |
data/ (디렉토리) |
모든 게임 데이터 파일 저장소. (items.txt, skills.txt, monster_data.txt 등) |
data/spawn_data.txt |
몬스터와 아이템의 스폰 위치, 확률, 드롭 아이템을 결정하는 메타 데이터. |
3. Features & Utilities (기능 및 유틸리티)
| 파일/모듈 | 역할 |
|---|---|
map_manager.py |
던전 맵 생성 및 관리 로직. 충돌 감지, 시야 계산 등을 담당. |
renderer.py |
입력(Input) 처리 및 출력(Output), 터미널 렌더링을 담당하는 UI 인터페이스. |
ui/UI_layout.json |
UI 레이아웃과 관련된 설정(좌표, 크기 등)을 저장하는 데이터 파일. |
개발 가이드라인 (기존 내용 유지)
- 코딩 스타일: 파이썬 코드에 대해 PEP 8 표준을 준수합니다.
- 의존성: 이 프로젝트는
readchar라이브러리를 사용합니다. - 게임 데이터: 플레이어 및 맵 데이터는
game_data/디렉토리에 JSON 파일로 저장됩니다.
- python_project/
├── dungeon/ #
핵심 엔진 및 게임 로직
│ ├── init.py # Python 패키지임을 알림
│ ├── engine.py # 메인 게임 루프, Engine 클래스
│ ├── entity.py # EntityManager
│ ├── component.py # 모든 ECS 컴포넌트 정의
│ ├── system.py # 모든 ECS 시스템 (로직) 정의
│ ├── data_manager.py # 데이터 파싱 로직
│ ├── map_manager.py # 맵 관리 로직
│ ├── renderer.py # 렌더링/UI 로직
│ ├── skills.py # 스킬 관련 데이터/로직 (System으로 분리 예정)
│ └── trap.py # 함정 관련 데이터/로직 (System으로 분리 예정)
│
├── data/ #
외부 데이터 파일
│ ├── items.txt
│ ├── skills.txt
│ ├── monster_data.txt
│ ├── spawn_data.txt
│ └── UI_layout.json # UI 레이아웃 설정
│
├── game_data/ #
저장된 게임 상태 (세이브 파일)
│ └── player_save.json
│
└── Start.py #
게임 시작 파일 (엔진 초기화 및 실행)
이걸 바탕으로 데이터 구조와 디렉토리 구조를 개편하려는데 다시 API 토큰 문제가 발생합니다.
어쩔 수 없네요.
gemini의 config.json 파일을 수정해서 gemini-2.5-pro에서 2.5 플래쉬로 바꾸려고 하니 안됩니다.
스크립트 하나짜서
touch ~/gemini.sh
chmod +x 주고 실행권한 만든다음
gemini -m gemini-2.5-flash
를 넣어줍니다.
이제 2.5 pro에서 플래쉬로 버전을 낮췄습니다.
순식간에 토큰 소진하던게 넉넉해졌습니다. 굳이 내 수준에 pro를 사용하지 않아도 될 거 같긴한데..
pro가 한번에 끝낼 일을 두번 세번 반복해서 수정하니 비슷한 거 같긴하네요.
작업 시간은 조금 길어졌습니다.
프레임 2: 이동 중
프레임 3: 충돌 (몬스터 제거, 충돌 마크)
프레임 4: 정리 (게임 재개)
프레임 1: 폭발 (즉시 광역 효과)