[팀 프로젝트 포트폴리오] RC Pointer (동아리 2등)

설치 없이 플레이하기

RCPointer by susoooooo

https://youtu.be/IgjxiNDeO0E

프로젝트 개요

• 게임 제목: RC Pointer
• 개발 기간: 1학년/10/29 ~ 1학년/11/6, 11/26 ~ 12/15
• 플랫폼: PC
• 장르 / 플레이 방식: 종 스크롤 액션, 플랫포머 / 마우스를 컨트롤러처럼 잡고 엄지손가락으로 마우스 휠을 돌려 마우스 포인터를 조종하는 아케이드 게임입니다.
• 팀 구성: 전공 동아리(Devlab) 개발자 5명이 만들었습니다.
• 내 역할: 이번에는 팀장 역할을 맡게 되어 기믹과 맵을 제외한 모든 기획과 역할 분담, 일정 관리, 게임 소개 등을 하였습니다. 개발적인 부분으로는 UI 시스템,게임 오버/앞, 뒤로가기 버튼 UI를 만들었습니다. 그리고 튜토리얼과 전체 기능을 포함한 세팅 UI, 작업물 합치기, 5스테이지 맵 제작, 폴리싱을 맡았습니다.
• 사용 툴 / 언어  / 기타 도구: Unity

기획 의도 / 게임 컨셉

• 게임을 만들게 된 동기: 기획을 하다가 마우스를 컨트롤러처럼 잡고 하는 게임은 어떨까 하는 생각이 들었고, 자동차를 축소화시킨 오락실의 레이싱 게임기를 축소화시킨 RC Car를 축소화시킨 마우스의 휠을 돌려서 방향을 조절하는 게임이 가장 방금 설명한 조작 방식을 잘 살릴 것 같아 아이디어를 냈습니다. 처음엔 다들 애매한 반응을 보였지만, 전 RC Car도 성공했고, 레이싱 기계도 성공했기에 이 조작 방식도 성공할 것이라는 자신이 있었고, 프로토타입을 만들어 친구들에게 보여줬습니다. 친구들이 프로토타입을 보고 바로 제 아이디어를 채택하여 게임을 만들게 되었습니다.
• 핵심 아이디어: 이 게임의 핵심적인 부분은 조작법입니다. 일반적인 마우스의 그립보다는 콘솔의 그립과 유사하고, 그 그립은 그냥 다른 것이 아닌 RC카, 자동차에서 방향 전환을 할 때, 부품이나 핸들의 회전과 비슷한 마우스 휠의 회전을 유도하는 그립법이기 때문에 이렇게 플레이하면 새로움뿐만 아닌 현실 같은 느낌을 더욱 줄 수 있고, 이는 키보드로 하는 것보다 더 뛰어난 몰입감을 선사합니다. 마우스를 컨트롤러처럼 잡고 플레이하는 게임이기 때문에 앞, 뒤로 가기 버튼이 마우스에 없는 경우를 제외하면 플레이어가 UI를 조작할 때 마우스를 내려놓고 다시 바로잡는 귀찮은 과정이 생기지 않게 하기 위해 마우스 버튼만을 사용하는 UI 디자인에 신경 썼습니다.
• 차별점: 조작 방식이 가장 큰 차별점이라고 할 수 있고, 각각 닿았을 때 특별한 기믹이 있는 윈도우 98 컨셉의 장애물로 이루어진 아케이드 게임이기에 다른 게임에선 느낄 수 없는 게임의 분위기와 조작 방식이 차별점입니다.
• 타깃 유저: 피하고 부수는 액션감 있는 게임을 좋아하는 유저들이 플레이할 때 재밌을 만한 게임으로 개발하였습니다.

개발 내용 및 구현

• 게임 흐름 설명: 플레이어는 게임을 처음 시작하면 메인 화면에 도달하기 전에 튜토리얼을 시작합니다. 플레이어는 튜토리얼에서는 방향 전환, 부스터를 쓰는 방법, 앞을 보는 방법, 아이템 활용, 부스터 활용 등을 배운 후 메인 화면으로 보내집니다. 메인 화면에선 지금까지 얻은 스킨을 자유롭게 장착할 수 있고, 스테이지 선택 화면으로 이동할 수도 있습니다. 스테이지 선택 화면에서는 잠금된 스테이지 없이 원하는 스테이지를 마음대로 진입해 플레이할 수 있습니다. 스테이지를 처음 클리어하면 스테이지마다 정해져 있는 스킨을 얻을 수 있고, 마찬가지로 한 번 클리어한 후에는 스테이지의 목표 시간 내에 다시 클리어했을 경우 히든 스킨을 얻게 됩니다. 스테이지를 클리어하기 위해 계속 도전하는 플레이가 반복되는 게임입니다.
• 직접 구현한 기능 목록: 

기획이 끝난 후 바로 노션에 개발 일정을 짜보았습니다.	마찬가지로 노션에 게임의 핵심 재미나 구조, 개요 등을 작성해 두었습니다. 적은 것 말고도 UI 시안이나 파티클 컨셉, 분위기 등 기획자가 할 일들을 전부 맡아 팀원들이 개발에 집중할 수 있도록 하였습니다. (노션 링크)
마우스를 컨트롤러처럼 사용하는 게임인 만큼 마우스를 내려놓지 않고도 세팅을 마음대로 조절할 수 있는 세팅 UI를 개발하였습니다.	튜토리얼을 진행할 때 속도를 낮추고 다른 입력은 차단하고 필요한 입력에만 넘어가게 하여 저번 프로젝트보다 더욱 유저 친화적인 튜토리얼을 제작할 수 있었습니다.
5스테이지 맵을 제작하였습니다.

• 문제 해결 사례:
  1. SoundManager: SoundManager는 에셋을 사용해 봤는데, 사용 방식은 간단하지만 Play시킨 사운드를 Stop이나 Pause할 수 없다는 단점이 있었기 때문에 AudioSource 객체를 반환하는 메서드를 따로 만들어서 원하는 사운드 매니저는 변수에 저장했고, 화면 밖에서 나는 사운드는 들리지 않게 하기 위해 메서드 오버로딩을 통해 매개변수에 float 매개변수 하나를 추가하여 배경음 같은 화면 밖에서도 들리는 사운드는 원래 사용되던 메서드를 쓰게 하고, 화면 밖일 때 사운드가 들리지 않게 하는 사운드는 float 매개변수에 자신의 y Position을 인수로 주어 카메라 밖일 때는 사운드가 재생되지 않게 하였습니다.
  2. 코드 구조: UI 구조를 짜는데 핑계를 대자면 제가 짠 코드를 남이 사용하는 경험이 적었기도 했고 기간도 촉박했다는 점 정도가 있고, 리팩토링을 하는 습관도 없었기 때문에 제가 제 코드에 빠져서 우물 안 개구리가 되어 구조가 엉망인 스파게티 코드를 짜버렸습니다. 이 사실도 저의 구조를 사용하는 친구가 구조에 대해 불만을 토로했을 때에서야 비로소 깨달았는데, 그 말을 듣고 코드를 보니 과거의 자신이 한심하게 보일 정도로 구조가 엉망이었습니다. 강한 참조는 기본이고 상호 참조도 한 군데 있었습니다. UIController가 IUI 인터페이스를 참조하는 구조였는데, IUI를 상속하는 클래스가 UIController 클래스를 참조하여 CanOpen이라는 bool 변수를 바꾸었습니다. 이런 Input에 대한 접근과 관련된 구현에서 문제가 생겼기 때문에 InputControllManager 라는 클래스로 기능을 분리하였습니다. 이로써 역참조와 강한 참조를 없앨 수 있었고, 튜토리얼을 만들 때도 그 클래스를 사용하였습니다.
  3. 이벤트 구독 해제: 저번 프로젝트에서 이벤트를 구독까지는 했지만, 해제하는 과정을 건너뛰는 실수를 했기 때문에 이번에는 람다식을 사용하지 않고 메서드에 식 본문 멤버를 사용하여 코드가 너무 길어지지 않는 안전한 코드를 짜서 문제를 예방했습니다. 
• 협업 방식: 깃허브를 사용하였고, 열심히 하는 친구들이 많았기 때문에 제가 일정을 보고 기간 제한 없이 일을 시킨 후 만들어진 작업물을 저에게 보여주면 피드백을 주고, 너무 느리다 싶으면 제가 옆에서 케어해주는 방식으로 협업하였습니다. 의욕이 많은 친구들로 이루어진 팀이라면 퀄리티 면에서 이런 방식으로 협업하는 것이 나을 것 같다고 생각하였고 실제로 완성도 있는 게임이 만들어졌습니다. 

테스트 및 결과

• 플레이 테스트 방식: 다들 자신이 만든 맵은 확실히 깰 수 있도록 맵을 만들며 플레이해 보는 방식으로 스테이지를 테스트했고, 마지막에 다 같이 빌드본을 플레이해 보며 버그가 있는지 확인도 하고 스테이지당 클리어 시간을 구해 히든 스킨 시간을 구했습니다.
• 게임의 완성도 / 구현율: 보스전을 빠르게 포기하여 게임의 난이도를 제외하면 버그도 딱히 없고 스킨 시스템이나 튜토리얼, UI, 이펙트, 기믹이 뭐 하나 빠진 것 없이 잘 구현되어서 완성도는 90% 정도인 것 같습니다. 보스를 포기했기 때문에 초기 기획에 대한 구현율은 그에 비해 좀 낮은 80% 정도인 것 같습니다.
• 플레이 시간: 플레이 시간은 게임의 난이도가 높은 편이라 전부 클리어한다면 30분을 넘길 것 같습니다.
• 개선하고 싶은 점: 계속 말했지만, 시간이 많이 없었기 때문에 서로의 소통이 잘되지 않은 상태에서 스테이지를 제작하여 거의 모든 스테이지의 난이도가 높아져 가장 중요한 부분이라고도 할 수 있는 스테이지가 가장 맘에 들지 않아 스테이지의 난이도를 개선하고 싶습니다.

다운로드 및 영상 링크

• YouTube 영상 링크: https://youtu.be/IgjxiNDeO0E
• 플레이 링크: https://susoooooo.itch.io/rcpointer
• 다운로드 링크: https://drive.google.com/drive/folders/1B6cAEbZNi38lokiiukHsElXpMI4Nz7q6
• GitHub 링크: https://github.com/Development-Lab-s/ScrollShooter

회고 및 느낀 점

• 개발하면서 느낀 교훈: 제가 짠 코드를 제가 사용할 때 좀 불편하더라도 굳이 고칠 필요까지는 없다고 느끼고 나름대로 잘 짰다고 생각해서 냅뒀는데, 제가 짠 코드가 제가 사용하는 데 불편하다면 다른 사람은 사용 자체도 못한다는 것을 알았습니다. 지금까지는 코드를 짤 때 ‘내가’ 나중에 읽기 좋게, ‘내가’ 나중에 기능 추가하기 좋게와 같이 저를 중심으로 코드를 짰지만 이젠 남을 중심으로 코드를 짜서 협업할 때 남이 쉽게 코드를 읽고 사용할 수 있게 지금의 ‘나’를 중심으로 한 코드에서 한 단계 나아간 코드를 짜야겠다고 느꼈습니다. 또한 자기 코드에 갇혀서 자신도 모르게 성장하지 않는 개발자가 될 수도 있다는 것을 알고, 서로가 서로의 코드를 보고 배우고 고치는 리팩토링이 얼마나 중요한지 알았습니다.
• 팀 프로젝트로서 배운 점: 프로젝트를 하면서 처음 팀장 역할을 맡아보았는데, 팀장 역할의 책임감이 생각보다 무거웠던 것 같습니다. 원래 다 같이 알던 친구들이었음에도 불구하고, 일정 관리를 할 때 친구들의 역량을 파악하며 일을 분배하는 것이 쉽지 않았고, 팀에 기획자도 없었기 때문에 기획서도 다 작성해야 하고 선배님에게 설명을 할 때 원래는 잘 나서지 않던 제가 나서서 말을 하니 순식간에 기가 빨렸습니다. 그 외에도 사운드, 아트 에셋을 찾거나 적용하고 작업물을 합치는 등의 귀찮고 재미없는 부분들을 맡아서 한 것과 팀원들이 의욕을 잃지 않게 케어해주는 그런 세세한 것까지 신경 쓰니 팀장이 아닐 때보다 훨씬 피곤해졌습니다. 지금 팀이 다들 친하고 열심히 하는 친구들로 이루어져 있었기 때문에 대부분 일정에 맞게 작업이 끝나고 불화는 없었는데, 팀원끼리 잘 맞지 않거나 열심히 하려고 하지 않는 팀원이 있었다면 아직 리더십이 없는 저한테는 정말 힘든 역할이 되었을 것 같습니다. 적어도 이번 팀에서 팀장은 게임을 완성하는 데에 가장 큰 책임을 짊어지고 재미없는 개발과 피드백, 개발 외의 일을 자주 하다 보니 개발도 많이 하지 못하고 기획자가 있었다면 프로젝트 외적으로 남는 것이 많이 없었을 것 같습니다. 이러한 경험으로 팀장이 얼마나 힘든지 체감하긴 했지만 개발 외적으로는 배우는 것도 많고 힘들더라도 저의 취약점과 메꿔지지 않은 부분을 메꾸는 데 도움이 될 것 같았고, 게임을 만들면서 팀장이었을 때가 몸과 정신은 피곤했지만 팀장이 아니었을 때 느낀 마음 한켠의 불안한 느낌이 없어져서 팀장이 적성에 맞을지도 모른다는 생각을 하게 되었습니다. 기회가 된다면 리더십에 신경 쓰며 다시 팀장이 되어보고 싶다는 느낌이 들었습니다.
• 지금 다시 만들면 바꾸고 싶은 부분: 게임에 새로운 요소들이 많이 있다 보니 무리하지 않고 캐주얼한 게임으로 만들어 나갔어야 했는데 개발자만 5명이었기 때문에 분량을 좀 늘렸습니다. 게임에 기믹들을 많이 추가해서 쉽게 질리지 않는 게임이 되기는 했지만 종 스크롤 게임은 플레이어가 위쪽을 길게 보지 못하다 보니 간단한 규칙을 가진 캐주얼 게임이 더욱 어울렸을 것 같아 픽셀 아트가 아닌 벡터 이미지를 사용하여 기믹이 아닌 플레이어의 반응 속도와 스킬 중심으로 플레이하는 게임으로 바꿔보고 싶습니다.
• 앞으로 만들고 싶은 게임 방향: 지금까지 프로젝트 블로그를 쓰면서 테스트 방식에 대해 쓸 때 그냥 플레이를 해봤다 정도로만 작성했습니다. 게임을 플레이하는 직업이 따로 있을 정도로 QA가 중요한 것은 알고 있지만 한 번도 빠짐없이 시간이 모자라서 제대로 된 QA를 하지 못했습니다. 겨울 방학 때 만들 팀 프로젝트에서는 조금 아쉽더라도 완성에 의의를 두고 QA를 제대로 해보며 크게는 게임에 허점이나 재미, 작게는 불편함과 버그를 발견하여 완성도를 올리는 작업을 통해 실제로 팔릴 만한 게임을 만들어보고 싶습니다.