1부에서는 RogueTD를 왜 만들기 시작했는지 적었고, 2부에서는 아이디어가 실제 게임 화면으로 넘어오면서 생긴 문제들을 정리했습니다. 이번 3부는 그 다음 이야기입니다. 이제는 “일단 돌아간다”에서 끝나는 단계가 아니라, 실제 휴대폰에서 손으로 눌러보면서 불편한 부분을 하나씩 잡는 단계로 들어왔습니다.
개발하면서 제일 많이 느낀 건, PC 화면에서 마우스로 확인할 때는 괜찮아 보였던 것들이 모바일로 넘어가면 바로 티가 난다는 점입니다. 포탑을 놓는 위치가 손끝과 조금만 어긋나도 이상하고, 버튼을 눌렀는데 게임이 내가 생각한 상태로 넘어가지 않으면 답답합니다. 스킬도 마찬가지입니다. 버튼을 눌렀으니 바로 나가야 하는지, 아니면 조준하고 놓아야 하는지 흐름이 분명해야 했습니다.
그래서 오늘까지의 작업은 화려한 새 콘텐츠를 더 넣는 쪽보다는, 손으로 플레이했을 때 덜 헷갈리게 만드는 쪽에 가까웠습니다. 포탑 설치 위치를 다시 맞추고, 선택한 포탑을 바로 업그레이드하거나 팔 수 있게 하고, 스킬 조준 방식을 다시 만들고, 포탑 크기와 전투 가독성도 손봤습니다. 겉으로 보면 작은 수정처럼 보이지만, 실제로는 게임이 “테스트용 화면”에서 “플레이 가능한 화면”으로 넘어가는 데 필요한 작업들이었습니다.
VFX Diary VFX 아카이브에도 앞으로 이런 개발 과정을 조금씩 남겨두려고 합니다. 완성된 결과만 올리는 것보다, 중간에 막힌 부분과 고친 이유까지 남겨두는 게 나중에 훨씬 도움이 될 것 같았습니다. 특히 Unreal Engine으로 혼자 게임을 만들다 보면 기능, UI, 이펙트, 빌드, 테스트가 한 번에 엮이기 때문에 기록을 안 해두면 금방 흐려집니다.
이제는 화면이 아니라 손끝 기준으로 봐야 했다
이번에 가장 오래 붙잡은 부분은 Android 터치 위치였습니다. 화면 위에서는 포탑 설치 버튼을 누르고 빈 타일을 터치하면 될 것처럼 보였습니다. 그런데 실제 기기에서 눌러보니, 손끝으로 찍은 위치와 게임 안에서 계산되는 월드 위치가 조금씩 어긋났습니다. 특히 화면 비율, HUD 캔버스 크기, 실제 렌더 타깃 크기가 서로 다르면 이런 문제가 더 잘 보였습니다.
처음에는 포탑 설치 로직 자체가 문제인가 싶었습니다. 하지만 확인해보니 단순히 포탑을 생성하는 함수만의 문제가 아니었습니다. Android 기기에서는 실제 화면 크기와 UMG 캔버스 좌표가 완전히 같은 느낌으로 움직이지 않았고, 그 사이에서 월드 좌표로 바꾸는 과정이 흔들렸습니다. 결국 “터치한 지점이 어느 월드 위치인가”를 다시 계산해야 했습니다.
그래서 이번에는 HUD 좌표와 월드 좌표 변환을 다시 정리했습니다. 1280×720 화면에서 플레이하는데 캔버스 쪽은 다른 기준으로 잡혀 있던 부분을 맞추고, 실제 배치 가능한 셀을 확인하면서 테스트했습니다. 설치 버튼을 누르고, 빈 공간을 터치하고, 포탑이 올라가는지 보고, 다시 선택되는지 확인하는 흐름을 여러 번 반복했습니다. 이런 작업은 글로 쓰면 굉장히 단순한데, 실제로는 몇 픽셀 차이를 계속 따라가는 작업이었습니다.
좋았던 건, 이 과정을 지나고 나니 게임을 만지는 느낌이 훨씬 자연스러워졌다는 점입니다. 타워디펜스에서 포탑 설치는 가장 기본적인 조작입니다. 여기서 신뢰가 생겨야 그 다음에 전략을 생각할 수 있습니다. “내가 누른 곳에 정확히 놓인다”는 감각이 없으면, 아무리 웨이브나 포탑 밸런스를 다듬어도 플레이어는 먼저 조작에서 스트레스를 받게 됩니다.
그리드를 다시 줄인 것도 같은 이유였다
설치 위치를 맞추면서 그리드 크기도 다시 봤습니다. 이전에는 셀 하나가 비교적 크게 잡혀 있었습니다. 처음 개발할 때는 큰 셀이 편합니다. 배치 확인도 쉽고, 포탑 간격도 넉넉하고, 길과 설치 영역을 나누기도 단순합니다. 그런데 실제 플레이 화면에서는 셀이 너무 크면 선택지가 적어 보였습니다. 타워디펜스에서 재미있는 순간은 “여기 하나 놓으면 막을 수 있을까?” 하고 고민하는 데 있는데, 셀이 크면 그런 촘촘한 판단이 줄어듭니다.
그래서 Greenwood 맵의 그리드를 200 기준에서 140 기준으로 줄이고, 전체 셀 수도 14×9에서 20×13 쪽으로 늘렸습니다. 숫자로 보면 단순한 변경이지만, 플레이 감각은 꽤 달라집니다. 포탑을 놓을 수 있는 후보 지점이 늘어나고, 길 옆에 한 칸 더 붙일지 뒤쪽에 둘지 같은 고민이 생깁니다. 대신 그만큼 터치 판정과 화면 좌표가 더 정확해야 했습니다. 셀이 작아졌는데 터치가 어긋나면 불편함은 더 크게 느껴지기 때문입니다.
이 작업은 앞으로 밸런스에도 영향을 줄 것 같습니다. 셀이 많아지면 포탑 배치 자유도가 올라가고, 자유도가 올라가면 웨이브 난이도도 다시 봐야 합니다. 적이 지나가는 길, 포탑 사거리, 비용, 판매 회수량, 스킬 쿨타임이 모두 연결됩니다. 그래서 이번에는 그리드를 줄이는 것에서 끝내지 않고, 나중에 밸런스 테스트를 다시 돌릴 수 있도록 작업 로그에 계속 남겨두고 있습니다.
포탑을 선택한 뒤 바로 판단할 수 있게
포탑을 설치한 뒤에는 그 포탑을 다시 선택하는 흐름도 고쳤습니다. 처음에는 타워를 놓는 것과 타워를 선택하는 것이 서로 다른 단계처럼 느껴졌습니다. 이미 설치된 포탑을 눌렀을 때, 플레이어가 이 포탑을 고른 상태인지 확실히 알기 어려운 순간이 있었습니다. 업그레이드나 판매 버튼도 화면에서 분리되어 있으면 “지금 어떤 타워를 대상으로 하는지”가 덜 분명했습니다.
그래서 설치된 포탑을 터치하면 해당 포탑 위쪽에 Upgrade와 Sell 버튼이 뜨도록 정리했습니다. 동시에 사거리 링도 같이 보여서, 이 포탑이 어느 범위를 보고 있는지 바로 확인할 수 있게 했습니다. 이건 단순한 UI 배치 문제가 아니라 전략 판단과 연결됩니다. 포탑을 팔지, 강화할지, 아니면 다른 곳에 새로 지을지를 판단하려면 지금 선택한 포탑의 위치와 범위가 같이 보여야 합니다.
골드 피드백도 같이 손봤습니다. 포탑을 팔았을 때 +nG 형태의 표시가 뜨고, 돈이 부족해서 살 수 없는 버튼은 회색으로 비활성화되게 했습니다. 이런 부분은 대단한 기능처럼 보이지는 않지만, 실제 플레이에서는 꽤 중요합니다. 플레이어가 “왜 안 눌리지?”라고 생각하는 순간을 줄여주기 때문입니다. 버튼이 회색이면 지금은 돈이 부족하다는 걸 바로 알 수 있고, 판매했을 때 골드가 돌아오는 것도 눈으로 확인할 수 있습니다.
저는 이런 피드백이 타워디펜스의 기본 체력을 만들어준다고 생각합니다. 게임이 어려운 건 괜찮지만, 불친절해서 헷갈리는 건 좋지 않습니다. 특히 모바일 화면에서는 손가락이 화면을 가리고, 버튼도 작아질 수 있기 때문에 상태를 더 명확하게 보여줘야 합니다. 이번 작업은 그 기준을 잡는 과정이었습니다.
스킬은 버튼보다 조준 흐름이 중요했다
이번 3부에서 개인적으로 제일 많이 배운 부분은 스킬 조준이었습니다. 스킬 버튼을 눌렀을 때 바로 시전되게 만들 수도 있고, 버튼을 누른 뒤 목표 위치를 찍게 만들 수도 있습니다. 처음에는 단순히 버튼을 눌러 스킬을 쓰는 식으로 생각했지만, 타워디펜스에서는 위치를 찍는 스킬이 훨씬 자연스럽습니다. 적이 몰려오는 길목에 슬로우 필드를 깔거나, 독 구름을 특정 지점에 놓는 식의 판단이 재미를 만들기 때문입니다.
문제는 조준 흐름이 생각보다 섬세하다는 점이었습니다. 버튼을 누르는 순간 스킬을 발동하면 조준할 시간이 없습니다. 반대로 버튼을 누른 뒤 화면을 다시 터치해야 한다면, 플레이어가 지금 조준 상태인지 아닌지 헷갈릴 수 있습니다. 그래서 흐름을 이렇게 정리했습니다. 먼저 스킬 버튼을 누르면 스킬이 장전됩니다. 그 다음 월드 쪽을 누르면 범위 표시가 나타나고, 손가락을 움직이면 범위가 따라다닙니다. 마지막으로 손을 떼면 그 위치에 스킬이 발동됩니다.
이렇게 바꾸고 나니 스킬이 훨씬 게임처럼 느껴졌습니다. 그냥 버튼 하나를 누르는 기능이 아니라, 내가 어디에 쓰는지 고르는 행동이 생겼기 때문입니다. Slow Field, Poison Cloud, Time Freeze, Armor Break 같은 스킬은 효과가 서로 다르기 때문에, 앞으로 밸런스를 잡을 때도 이 조준 방식이 중요해질 것 같습니다.
물론 구현할 때는 예상보다 자잘한 문제가 많았습니다. 스킬 버튼을 누른 직후에 게임이 버튼 영역을 계속 터치로 받아들이는지, 월드 드래그를 제대로 따라오는지, 손을 뗐을 때 정확히 한 번만 발동되는지 확인해야 했습니다. Android 실기에서 여러 번 눌러보고, 스크린샷을 남기면서 확인했습니다. 이런 부분은 마우스로 한 번 클릭해보는 테스트만으로는 부족했습니다.
포탑이 작으면 전략도 작아 보였다
포탑 크기도 다시 봤습니다. 처음에는 맵이 잘 보이는 게 중요하다고 생각해서 포탑을 비교적 작게 두었습니다. 그런데 실제 모바일 화면에서 보니 포탑이 너무 작으면 존재감이 약해졌습니다. 내가 설치한 타워가 어디 있는지, 어떤 방향을 보는지, 어떤 종류인지 한눈에 들어와야 하는데, 화면 안에서 배경과 섞여버리는 느낌이 있었습니다.
그래서 포탑 시각 크기를 크게 키웠습니다. Poison, Freeze, Cannon, Lightning 계열은 더 크게 보이도록 정리했고, Ballista도 다른 포탑과 균형을 맞췄습니다. 여기서 중요한 건 충돌 크기나 설치 판정을 무작정 키우는 게 아니라, 시각적으로 읽히는 크기를 키우는 것이었습니다. 포탑이 커졌는데 선택 링이나 사거리 표시가 어긋나면 또 다른 문제가 생기기 때문에, 중심점과 선택 UI도 같이 맞춰야 했습니다.
이 작업을 하면서 “가독성”이라는 말이 단순히 글자에만 쓰이는 게 아니라는 걸 다시 느꼈습니다. 게임 화면에서는 포탑, 적, 이펙트, 길, UI가 모두 읽혀야 합니다. 특히 타워디펜스는 화면에 오브젝트가 계속 쌓이는 장르라서, 초반부터 크기와 중심을 잘 잡아두지 않으면 나중에 웨이브가 복잡해졌을 때 문제가 더 커집니다.
이 부분은 교육자료 쪽에서 나중에 따로 정리해도 좋을 것 같습니다. Unreal에서 Paper2D, Billboard, Material, UMG가 섞이면 “보이는 위치”와 “계산되는 위치”가 다르게 느껴지는 순간이 자주 생깁니다. 이번 RogueTD 작업도 결국 그런 문제를 실제 프로젝트 안에서 만난 사례였습니다.
상단 HUD는 조용하지만 계속 중요한 영역
이번 기간에는 상단 HUD도 계속 손봤습니다. 게임 화면 위쪽에는 웨이브, 골드, 생명, 속도 같은 정보가 모입니다. 처음에는 기능 확인이 우선이라 필요한 값을 표시하는 데 집중했습니다. 그런데 플레이를 반복해보니 상단 HUD가 화면을 차지하는 방식도 중요했습니다. 너무 크면 맵을 가리고, 너무 작으면 전투 중에 읽기 어렵습니다. 특히 모바일 가로 화면에서는 세로 공간이 넉넉하지 않아서 더 조심해야 했습니다.
그래서 B 타입 상단 HUD를 실제 런타임 화면에 붙이고, 버튼과 텍스트가 겹치지 않는지 확인했습니다. 이 작업은 화려한 변화는 아니지만, 게임을 계속 켜놓고 플레이할수록 중요해집니다. 플레이어는 매 웨이브마다 골드를 보고, 다음 선택을 생각하고, 남은 생명을 확인합니다. 이 정보가 자주 시야에서 흔들리면 게임을 오래 하기 어렵습니다.
개발자 입장에서는 HUD를 “나중에 예쁘게 만들면 되는 것”으로 미루기 쉽습니다. 저도 처음에는 그렇게 생각했습니다. 하지만 이번에 직접 Android 화면으로 보면서 생각이 조금 바뀌었습니다. UI는 마지막 장식이 아니라, 게임 규칙을 플레이어에게 전달하는 통역에 가깝습니다. 포탑이 아무리 잘 공격해도, 플레이어가 현재 골드와 웨이브 상황을 놓치면 전략을 세우기 어렵습니다.
전투 피드백도 조금씩 붙기 시작했다
오늘까지의 작업에는 캐논 쪽 전투 피드백도 포함됐습니다. 대포 포탑은 공격이 묵직해야 하는데, 발사체와 피격 이펙트가 약하면 존재감이 살지 않습니다. 그래서 캐논 히트, SubUV, 포신 불꽃, 먼지 느낌을 위한 로컬 FX 리소스를 붙이고 Level01에서 확인했습니다. 아직 최종 연출이라고 말하기에는 이르지만, 적을 맞췄을 때 “무언가 맞았다”는 반응이 조금씩 살아나기 시작했습니다.
다만 이번 글에서는 원본 리소스 이미지를 직접 크게 보여주지는 않겠습니다. 이전 글에서도 이야기했지만, 리소스는 개발 중인 원본이 그대로 노출되면 조금 부담스럽습니다. 대신 실제 게임 화면 안에서 어떻게 보이는지 위주로 공유하는 게 더 맞다고 봤습니다. 결국 플레이어가 보는 건 개별 PNG 파일이 아니라, 맵 안에서 움직이고 터지는 장면이니까요.
VFX 작업은 늘 이 지점이 어려운 것 같습니다. 리소스 하나만 보면 괜찮아 보여도, 게임 안에 들어가면 너무 크거나 작을 수 있고, 배경색과 섞일 수도 있고, 모바일 화면에서는 생각보다 안 보일 수도 있습니다. 그래서 앞으로도 단일 이미지보다 실제 플레이 화면 기준으로 판단하려고 합니다. VFX Diary에 남기는 개발일지도 가능하면 그렇게 가져가겠습니다.
빌드와 검증도 계속 반복했다
오늘 기준으로 Android 빌드도 계속 이어졌습니다. 최근 작업 결과물은 ProjectA_20260713_09.apk까지 나왔고, 내부 확인용으로 SHA-256 값도 기록했습니다. 아직 공개 배포용 릴리즈라고 말할 단계는 아니고, 개발 확인용 Shipping 빌드에 가깝습니다. 그래도 실제 기기에서 설치하고 눌러보는 흐름을 계속 가져가는 건 중요했습니다.
이번에 확인한 건 단순히 “빌드가 된다”가 아니었습니다. 포탑 설치가 손끝과 맞는지, 설치된 포탑을 다시 눌렀을 때 선택 UI가 뜨는지, 스킬 조준 범위가 드래그를 따라오는지, 손을 떼면 한 번만 발동되는지 같은 부분을 직접 봤습니다. 어떤 수정은 Mac에서 먼저 확인하고, 다시 Android로 넘겨서 보는 식으로 진행했습니다.
반대로 아직 남은 것도 있습니다. 전체 자동 테스트 기준으로 보면 밸런스, 저장 흐름, 시작 플로우, 일부 이름 검증 쪽에 남은 이슈가 있습니다. 그래서 이번 글에서 “다 끝났다”고 말하기보다는, 플레이 조작의 큰 불편을 하나씩 줄여가고 있다고 보는 게 맞습니다. 게임 개발은 늘 이런 식으로 조금씩 좁혀가는 것 같습니다. 어제는 안 맞던 위치가 오늘 맞고, 오늘은 불편했던 버튼이 내일 자연스러워지는 식입니다.
웨이브와 스킬은 이제 같이 봐야 한다
7월 9일 전후로는 웨이브 계약, 맵 이벤트, 액티브 스킬 쪽도 많이 움직였습니다. Slow Field, Poison Cloud, Time Freeze, Armor Break 같은 스킬이 들어오면서 전투가 단순히 포탑만 지켜보는 구조에서 조금씩 벗어나기 시작했습니다. 포탑 배치가 기본 전략이라면, 스킬은 위기 순간에 플레이어가 직접 개입하는 장치에 가깝습니다.
다만 스킬이 들어오면 밸런스는 더 어려워집니다. 포탑만 있을 때는 적 체력과 포탑 공격력, 사거리, 비용을 중심으로 보면 됩니다. 그런데 스킬이 생기면 특정 웨이브를 한 번에 넘길 수 있는지, 쿨타임이 너무 짧지는 않은지, 플레이어가 스킬을 안 써도 클리어 가능한지까지 같이 봐야 합니다. 자동 플레이 테스트에서는 10웨이브 클리어 흐름도 확인했지만, 실제 손 플레이에서는 또 다른 문제가 나올 수 있습니다.
그래서 다음 단계에서는 웨이브와 스킬을 따로 보지 않고 같이 볼 생각입니다. 특정 몬스터가 몰려오는 타이밍, 포탑을 설치할 수 있는 골드, 스킬을 쓸 만한 위기 순간이 서로 맞아야 합니다. 타워디펜스의 재미는 “막을 수 없을 것 같은데, 배치와 스킬로 겨우 막았다”는 순간에서 나온다고 생각합니다. RogueTD도 결국 그 느낌을 향해 가야 합니다.
3부를 정리하면
이번 3부는 모바일 조작감을 잡는 시간이었습니다. 포탑을 원하는 위치에 정확히 놓고, 이미 설치한 포탑을 다시 선택하고, Upgrade와 Sell을 바로 판단하고, 스킬을 누르고 조준해서 쓰는 흐름까지 정리했습니다. 거기에 포탑 크기, 선택 링, 골드 피드백, 캐논 FX, Android 빌드까지 이어졌습니다.
처음 RogueTD를 만들기 시작했을 때는 “작아도 처음부터 끝까지 하나의 게임을 만들어보자”는 마음이 컸습니다. 지금은 그 말이 조금 더 현실적인 무게로 다가옵니다. 게임 하나를 끝까지 만든다는 건 큰 기능을 한 번에 넣는 일이 아니라, 이런 작은 불편을 계속 찾아서 없애는 일에 더 가까운 것 같습니다.
다음 개발일지에서는 웨이브, 밸런스, 몬스터 흐름, 전투 연출 쪽 이야기를 더 정리해볼 수 있을 것 같습니다. 앞으로 개발일지를 계속 기록할 예정이니 많은 기대 해주세요.
참고 출처
이번 글은 RogueTD 내부 개발 로그, Android 실기 확인 스크린샷, Unreal Engine 프로젝트 작업 기록을 바탕으로 작성했습니다. 외부 뉴스나 공식 릴리즈 분석이 아니라, 현재 개발 중인 프로젝트의 작업 기록입니다.