2026.02.02 (월)

최근에 친구들과 같이 팀을 짜 총 3인 팀으로 게임 개발을 하고 있다. 취미 느낌으로 시작했지만, 출시하는 것도 목표로 하고 있다.

기획과 프로그래밍은 2025년 9월부터 시작했지만, 2025년 12월에 KAIST에서의 마지막 학기가 끝나고 난 뒤부터 본격적으로 프로그래밍을 하고 있다.

 

앞으로 매일 게임 개발을 하며 겪은 사소한 일들을 블로그에 적으며 정리해보려 한다. 프로그래밍을 주로 하고 있기 때문에, 프로그래밍에 관한 내용들을 적으려 한다. 기획은 어느 정도는 비밀로 해야 하지 않을까 싶어 많이 적지 않으려 한다.

---

만들고 싶은 게임

 

우리가 만드려는 게임은 던전에서 여러 방을 차례대로 격파하며 마지막 방까지 클리어하면 던전을 완료하는, 로그라이크 장르에서 많이 볼 수 있는 구조이다. 다만 정통 로그라이크 방식으로 게임을 만들면 진입장벽이 높아 사람들을 끌어모으기 어렵기 때문에, 우리는 허브(집)를 추가하고 허브에서 영구적 강화를 할 수 있도록 하기로 했다. 이는 요즘 나오는 로그라이트 게임에서 흔한 방식이라 생각한다.

 

나는 프로그래밍으로 게임을 구현하는 작업을 주로 하고 있다. 허브, 던전, 전투가 전부 나오는 구조를 만들고 싶었기 때문에 이 세 가지를 분리하여 따로따로 작업을 했다. 원래 나는 던전 쪽만 만드는 것이었는데, 프로젝트를 진행하다 보니 나머지 부분도 같이 만들기로 했다. 아직 허브는 구현이 되어 있지 않아 우선은 던전 + 전투를 만들어서 간단하게라도 돌려보는 것이 목표이다.

---

2026년 2월 1일 (일)

 

2026년 2월 1일 (일)에 오프라인 회의가 3시간 정도 있었다. 라즈베리 라떼를 시켜 마시며 신나게 떠들었다.

우리가 만드는 게임은 로그라이크, 속도 기반 턴제, 다대다 전투 등의 키워드를 가진 게임이다. 이때 회의에서는 피해량 계산 시스템, 캐릭터 성장 방식, 그리고 새로운 커맨드와 게임 시스템이 지금껏 구상해온 컨셉에 맞는지 등 다양한 이야기를 했다.

 

이날 회의를 위해 늦게까지 안 자고 구현을 했었는데, 회의 날 와보니 다른 친구들도 전부 잠을 덜 자서 피곤하다고 했다. 조금 걱정되긴 했지만 막상 회의를 시작하니 다들 열심히 의견을 내며 떠들어서 만족스러웠다. 이 날은 기획 회의를 2시간 30분 정도 하고, 나머지 30분은 내가 지금까지 구현한 데모를 보여주었다.

 

데모는 속도 기반 턴제를 구현한, 디자인이라곤 하나도 없이 오직 뼈대만 있는 게임이었다. 무료 에셋으로 채운 캐릭터와 스프라이트 시트조차 추가하지 않은 적들, 대충 만든 UI... 그래도 필요한 건 다 있어서 그런지, 정말 감사하게도 팀원들이 호평해주었다. 앞으로 어떤 것을 구현할 지 이야기하고 이 날 회의는 마무리되었다.

---

2026년 2월 2일 (월)

 

오늘은 눈이 내려 집 앞 눈을 치우느라 늦게 작업을 시작했다. 늦게 작업을 시작하니 그만큼 게을러지는 것 같다.

 

행동 순서 표시 UI, 스킬 포인트 UI

턴제 기반 전투는 보통 행동 순서가 간단한 편이다. 내가 한 번 행동하면 상대가 한 번 행동하고, 이게 반복. 그러나 우리는 속도 기반 턴제를 구현하기로 했었다. 다대다 전투를 구현하고, 각 캐릭터에 행동 속도가 있고, 각 행동에도 고유 속도가 있는 방식.

이걸 구현하는 것은 코드 상으로는 되어 있었지만 UI는 없었기에 구현했다. 디자인은 추후에 신경쓰기로 하고 우선은 돌아가는지만 확인하기로 했다.

 

또한 스킬 포인트 UI를 만들었다. 속도 기반 턴제 뿐 아니 팀 단위 스킬 포인트를 사용하는 전투이기에 스킬 포인트를 표시할 수 있는 UI가 필요해 간단하게 구현했다. 역시나 디자인은 나중에 신경쓰기로 했다.

 

StringManager

다음으로 StringManager라는 녀석을 구현해 놓기로 했다. 여러 언어를 지원할 수 있게 확장성을 챙기려면 어떻게 해야 할까 하는 고민에서 나온 것이다. UI와 게임 화면에 보이는 문자열들은 언어마다 다를 것이므로, 이걸 C# Dictionary로 관리하면 좋겠다는 생각이 들었다. 어떤 언어를 쓸 것인가에 따라 서로 다른 문자열을 반환하면 되니까.

기존에는 코드에 문자열을 하드코딩해놓았지만 확장성이 매우 부족한 구조이므로 StreamingAssets에 json 형식으로 저장하고 불러오는 방식으로 변경하고, 그 구현을 StringManager로 하기로 했다.

 

우리 게임은 MVC 디자인 패턴을 따르고 있어, StringManager의 문자열들을 채우는 것은 Controller 단에서 하기로 했다. 하지만 언제 어떤 문자열들을 채울지는 아직 정해진 것이 없다. 어떤 유형의 문자열들이 가장 많은 비율을 차지할지는 아직 모르겠다. 유물? 스킬? 캐릭터 정보? 아무래도 스킬이지 않을까 싶기는 하지만 그래도 양을 봐야할 것이다. 또한, StringManager는 전역 변수처럼 기능하므로 메모리 사용량도 고려해야 할 것이다. 던전에 입장할 때 던전에서만 사용하는 문자열들을 불러오고, 퇴장할 땐 제거한다던지. 물론 많은 양의 string보다 Unity 스프라이트 하나가 더 많은 메모리를 잡아먹을 것 같지만, 사소한 최적화도 신경쓰고 싶다.

 

생각할게 많아지다보니 StringManager의 구현은 우선은 껍데기만 해놓고, 메서드들은 나중에 하기로 했다. 당장의 목표는 MVP를 만드는 것이라 확장성은 살짝 후순위로 두고, 문자열을 하드코딩하는 것으로 진행하고 나중에 변경하려 한다.