게임 소개
2명의 플레이어는 협동하여 하나의 탱크를 조작한다.
탱크의 이동, 연료 보충, 공격, 장전은 누군가 자동으로 해주지 않는다.
서로 소통하고 협력하여 6개의 보스를 잡아라
들어가며
24년 초, 막 군대를 전역하고 뇌는 그대로 리셋되고
잘쳐줘야 말하는 감자인 상태로 학교에 복학을 하면
학교에서는 윈도우 프로그래밍 이란 걸 배우게 시킨다.
윈도우 프로그래밍에서는 최종 프로젝트로
C/C++ 기반의 Window API를 이용해서 2D 게임을 만들도록 한다.
기간은 4주.
정말 아무것도 모르는 상태에서 시작해서 시행착오도 많았고, 고생도 정말 많이 했지만
지나고보면 나름 재미있는 과목이었다.
각설하고 Brace for impact는 윈도우 프로그래밍의 기말고사겸 텀프로젝트였다.
인생 첫 프로젝트였기도 하고, 나름 애정이 많은 친구다.
기획
초기
군대를 가기 전 21년 겨울에 한 가지 게임을 기획해놨었다.
당시 재밌게 하던 게임 Overcooked에 영향을 받아
다 함께 소통하고 협력하며 스트레스 받는 그런 게임을 만들고 싶었다.
당시에 작성했던 기획서이다.
초기 기획은 플레이어가 4명이었고, 탱크가 아닌 2족 보행 로봇이었으며,
테마는 스팀펑크가 아니었다.
파워레인저 같은 4명의 플레이어가
로봇의 팔,다리, 머리, 무기 등을 마구마구
조작하며 적과 싸우는 그런 게임이었다.
흔히 말하는 메카 괴수 대전이었다
하지만 서버를 구현할 수 없었고, 하나의 컴퓨터로 작동해야 한다는 점에서
플레이어는 2명으로,
내가 2족 보행 로봇의 모든 애니메이션 스프라이트를
그리기엔 무리가 있어서 탱크로 교체했다.
스팀펑크로 교체한 이유는 나도 잘 모르겠다.
바꾸고 나서 진행해보니
스팀펑크는 디테일이 너무 많이 필요한 테마라서
진행하면서 내내 후회했었다.
그렇게 다시 작성한 게임의 프리뷰는 이런 느낌이었다.
(아무것도 모르고 작성한 기획서라 내용이 많이 미흡하다)
플레이어는 각자의 구역을 가지고 각자 역할이 공격과 이동으로 구분되어 있었으며,
간접적으로 서로를 도울 수 있었다.
한명은 탱크의 포신 부분을, 한명은 탱크의 차체 부분을 조종하는 게 재밌겠다 하는 생각이었다.
하지만 팀원의 의견을 반영해서 조종실을 하나로 합치고, 각자 맡은 일이 있다기 보다는
유동적으로 때에 따라 서로 할 일을 해야하는 게임으로 변경되었다.
개발
개발을 진행하기 전에, 한 가지를 정하고 시작했다.
우선, 우리 팀에 게임 개발 경력이 없다는 점,
그 이유로 밸런스나 기획 부분에서 문제가 있을 수 있기 때문에
작동 가능한 프로토타입을 먼저 만들기로 했다.
첫번째로 한 것은 네모로 된 플레이어를 추적하는 사각형들을 만드는 것이었다.
이후 프로젝트는 점차 진행되었는데,
아트로 코드를 단순화시킬 수 있음을 알았다.
예를 들어보자.
이 탱크 이미지는 탱크 전체가 하나의 그림이 아니라
포신과 차체. 이렇게 2부분으로 나눠져 있다
자, 이제 플레이어의 입력에 따라서
차체는 총 상하좌우, 그리고 대각선까지 총 8방향
마찬가지로 포신도 상화좌우 대각선 총 8방향으로 돌아가도록 해야한다.
어떻게 할까?
프로그래머를 닦달하고 겁박하고 고문해서 위에 이미지를 8방향으로 회전시킬까?
좋은 생각이다.
하지만 이 게임은 쿼터뷰(Quater View)이다.
그리고 픽셀로 그려진 그림은 단순히 돌린다고 자연스럽게 보이지 않는다.
답은 간단하다. 그냥 다 그리면 된다.
이 방법은 용량은 늘어날지언정 (프로그래머의)개발 복잡도, 시간 복잡도를 아주 낮춰준다.
예를들어 탱크의 포신을 회전시킬 때는 코드를 통해 이미지를 회전시켜도 되지만,
처음부터 모든 프레임을 그려두면 굳이 그럴 이유가 없이
사진의 출력할 위치만 잡아주는 것만으로도 회전하는 탱크를 구현할 수 있다.
추가로, 중간중간에 프레임을 부드럽게 해주는 중간 프레임들을 그려넣으면
더 부드럽게 회전하는 포신이 완성된다.
몬스터도 마찬가지이다.
적의 이동모션, 피격, 사망, 공격 등,
모든 경우의 수를 생각하고 그린다.
팀원 중 누군가 손을 계속 놀리고 힘든 시간을 보내고 있을 때
팀에 평화가 찾아온다
탱크 내부도 마찬가지이다.
내가 포를 쏠때마다 탱크가 뒤로 움직이게 하려고 한다.
코드를 통해 사진을 뒤로 뺐다가 몇 프레임 후, 다시 앞으로 옮겨도 된다.
하지만 모든 걸 그려넣는 게 시간도 훨씬 빠르고 다양한 문제들을 사전에 방지할 수 있도록 한다.
아 그리고 한가지 더,
스프라이트를 그릴 때는 반드시 이미지 내에 이 전체 이미지의 가로 세로 길이가 어떻게 되는지와
어디서부터 어디를 사용할건지를 적어두자.
그 까닭은 개발 시 이 스프라이트의 크기를 확인하는 데 꽤나 많은 시간이 들기 때문이다.
디자이너가 사진의 전체 크기와 한 칸의 크기를 명시해주지 않으면
꽤나 많은 혼선과 불화가 생긴다.
사진에 직접 수치를 써넣지 않더라도 문서를 통해 알려줬다.
사실 이미지 그리고 코드에 적용하는 건 내가 맡아서 한 부분이라 불화가 생길 일은 없었지만...
그래도 내 머리가 모든 것을 기억하지는 못하기 때문에 적어두는 것이 편하다 아무튼
충돌처리
개발 초창기 맵이다.
위에 큰 도로에서 탱크가 출발할 예정이고, 탱크는 벽이나 건물을 가로질러서 갈 수 없다.
그러기 위해서는 "여기는 지나갈 수 없어"라는 충돌처리를 해줘야한다.
아쉬운 점은 우리가 이때 충돌처리를 어떻게 해야할 지 잘 몰랐던 점이다.
생각했던 건 맵 곳곳에 보이지 않는 사각형을 들어갈 수 없는 부분마다 배치해둬서
장애물 네모와 탱크 네모의 충돌 시 이동하지 않게 하자는 것이었다.
그래서 이런 식으로 맵에 어떤 위치에 사각형을 배치하면 되는지를 작성해줬다.
만약 세세한 수정이 필요할 때는 아래에 수정 사항들을 적어뒀다
말로 설명하기 어려운 컷씬이나 연출의 경우
파워포인트 애니메이션을 제작해서 보여줬다
몹의 정보와 몹의 패턴 역시 이런 식으로 작성해서 팀원들에게 전달했다.
하면서 들었던 생각은 이걸 도식화해서 보여줘도 괜찮았겠다 였지만
후에 Deutornomy 때 도식화해서 보여준 걸 한번도 안읽어봤다는 걸 깨달은 후
그냥 글과 그림으로 적어서 보여주는 게 제일 좋구나를 느꼈다.
아니면 내가 못그려서 그런가?? 잘 모르겠다
아무튼 정말 별의 별 것들을 다 그려서 넣었다.
최적화
이 게임에서는 전체 맵 중 탱크가 있는 곳을 기준으로 카메라를 잡아준다.
그 뜻을 카메라 밖에 있는 요소들을 그려두고 있을 필요는 없다는 의미다.
그래서 적이나 탄막이 카메라 밖으로 벗어날 시
그리지 않도록 구현해뒀다.
이 과정으로 한 20프레임정도 더 성능 개선을 할 수 있었다.
이미지의 경우 따로 헤더(.h)를 만들어서 이런 식으로 관리했다.
게임 초기 시작 시 모든 이미지를 로드하고,
필요할 때만 출력하는 방식으로 최적화를 했다.
공모전 Ver.
성공적으로 프로젝트를 끝마치고,
할거 뭐 없나 찾아보다가
만들래 라는 사이트에서 10분 게임 콘테스트라는 걸 봤다.
우리 프로젝트는 시연용으로는 문제가 없었다.
어차피 우리가 만든 게임 우리가 플레이하니 룰이며 공략이며 전부 알고 있다.
하지만 아무것도 모르는 사람들은
이 게임이 어떻게 해야하는 것인지, 뭐가 목표인지를 모른다.
그래서 게임 룰을 더 자세하게 작성하고, 편의성 등을 개선했다.
제일 먼저 한 것은 룰북을 이해가 되도록 새롭게 그려넣은 것,
한 페이지짜리 룰북을 4페이지짜리로 바꿔서 넣었다.
글을 작성하지 않고 이미지로만 설명하려다보니 잘 설명이 됬는지는 모르겠다
그리고 시연 때는 저작권에 상관없이 아무 노래나 가져다가 썻엇는데,
공모전에서는 문제가 될 것 같아 저작권 문제가 없는 노래들로 바꿨다.
결과는?
한 반타작 정도 했다.
그래픽 개선이 되기 전에 평가를 받아서 그래픽 감점이 있었다.
사실 너무 좋고 재밌는 게임이 많아서 큰 기대는 안했다.
하지만 다수가 내 게임을 플레이하도록 내놓아보는 건 꽤나 큰 경험이었다.
어떻게 해야 사람들이 진행 방식을 손쉽게 이해하고,
어디서 어떤 평가를 내놓는지를 확인할 수 있었다.
과제전 Ver.
10월쯤에 학교에서는 한국공학대전이라는 큰 대회가 하나 열린다.
보통은 우수한 성적을 받은 졸업작품들을 전시하는 행사인데,
우리 게임공학과에서는 졸업생이 아닌 재학생들을 위해 작게나마 과제전이라는 걸 개최한다.
우리 과는 거의 매 학기마다 게임을 만드는 과제를 낸다.
그 중에서 본인이 좀 잘했다 싶은 사람들을 대상으로 본인의 과제를 체험할 수 있게 하는 행사이다.
만들어둔 게 아까운 관계로 과제전에도 참가를 했었다.
가장 우선했던 것은 그래픽의 개선이었다.
대충 GPT 돌려서 빠르게 그래픽을 만들어야 했던 그때와 달리,
지금은 시간도 (비교적) 넉넉했기에 다양한 레퍼런스들을 참조하며 그래픽을 개선했다
초기 개발 때는 맵 종류 단순히 3가지였다.
보스는 총 6마리이므로 한 맵을 2번씩 사용했다.
과제전을 준비할 때는 맵을 새롭게 다시 그리면서
낮과 밤 이렇게 바꿔 모든 보스가 자신만의 맵을 가질 수 있도록 바꿨다.
자세히 보면 기존 맵에서 전체적인 틀 자체는 비슷한 걸 볼 수 있다.
맵을 바꾸면서 힘들게 만들어두었던 충돌 처리 장애물들의 위치를 바꾸기 싫었기 때문이다...
조작지 디자인도 많이 바꿨다.
기존 이미지는 시간이 너무 없어서 그냥 어디서 가져오거나
GPT가 그려준 그림인 반면
다시 그릴 때는 조금 더 탱크 내부에 알맞도록 노력해봤다.
탱크 내부 이미지도 변화를 주었다.
개발을 하면서 가장 우려됬던 부분은
시연해보는 사람들이 과연 룰북을 열어볼까? 였고
설령 룰북을 보더라도 그 조작들을 모두 외울 수 있을까? 였다.
그래서 그냥 탱크 내부에 조작키를 그려넣었고
어떤 게 어떤 기능을 하는지 최대한 가시성있게 그려넣으려고 했다.
그리고 조작기에 상호작용이 가능한 범위에 들어오면
F나 M을 눌러서 상호작용해보라고
다음과 같은 아이콘도 만들었다.
이런 식으로 상호작용 가능한 범위 내에서
어떤 키를 눌러야하는지를 시각적으로 보여줬다
컨텐츠면에서도 변화가 있었다.
기존 최종 보스는 패턴이 단 한가지였으며
마지막 보스라기엔, 그다지 이펙트가 있지 않았다.
그래서
새롭게 보스를 그렸고,
이 최종 보스는 3가지 패턴을 가지도록 만들었다.
사운드에서도 변화가 있었다.
기존에는 WindowAPI에서 지원하는 Playsound()함수를 사용했었다.
Playsound는 사용이 간단하지만, 매우 치명적인 문제가 있는데,
한번에 단 한가지 음악만 재생할 수 있다는 것이다.
이말은 BGM과 사운드이펙트를 동시에 재생할 수 없다는 의미이다.
그래서 이번에는 FMOD 라이브러리를 직접 적용했다.
이제 한번에 여러 소리를 출력하게 할 수 있게 되었다.
탱크 이동 소리, 피격 소리, 적 공격 소리 등등...
그리고 탱크와 적의 거리를 계산해서 적이 멀수록 적이 내는 사운드가 더 작게,
가까울수록 사운드가 크게 들리도록 했다.
이제 플레이어는 소리를 통해 적의 위치를 가늠할 수 있다.
또 이제는 벨런스 조절이 중요했는데,
한 보스를 테스트하겠다고 처음부터 게임을 모두 하기는 시간이 너무 오래 걸린다.
그래서 디버그 모드를 따로 제작해서 스테이지를 선택하거나
무적으로 만드는 등을 통해 쉽게 밸런스를 조절할 수 있었다.
과제전 전날까지 열심히 달렸다.
그리고 과제전 당일,
쌈뽕하게 포스터도 만들었다.
옆에는 듀얼모니터를 연결해서 플레이하기 쉽도록 간단한 튜토리얼 영상을 띄워뒀다
이 게임을 어떻게 해야하는 지 몰라 재미가 반감되는 일은 없어야 했다.
나는 이때 진심이었다.
전날에 과제전 진행 전 마지막 버그 수정 및 컨텐츠 추가하느라 딱 3시간자고 바로 다시 나왔다.
진짜 오는 사람들 응대하고 어떻게 해야하는 지 알려주느라 오전 10시부터 오후 6시까지 쉬지도 못했다.
몸은 정말 힘들었는데, 버틸만했다.
내가 만든 걸 누군가한테 보여준다니
정말 흥분되는 일이 아닐 수 없다.
별개로, 결과는 어떻게 될 지 알 수 없었다.
같은 윈도우 프로그래밍 분야 참가자들의 퀄리티도 좋았고,
어떻게 했는지도 모르겠는 기술들을 구현한 팀도 많았기 때문이다.
팀원들 생각도 똑같았다.
2등은 받을 수 있으려나...
하고 있었는데
헉 최우수상이었다
진짜 이때는 예상도 못했다.
그래 그래도 고생했다 이런 생각으로 맘 편히 기다리고 있었는데,
정말 고맙게도 최우수상을 받았다.
상금으로는 15만원과 마우스 패드를 받았다.
근데 3명이라서 5만원씩 나눠가졌다.
후기
'프로젝트' 카테고리의 다른 글
| 『Deuteronomy』 개발 후기 (0) | 2025.01.24 |
|---|
