Unity 게임 개발 [1984] + 회고
1984
회고
브릿지 2회차 프로젝트로 23년도 1학기에 진행된 프로젝트다.
약 6개월 정도를 진행했고, 기획상 마음에 드는 디자인을 선택하였다.
1984라는 원작 소설의 세계관에서 플레이어의 선택에 따라 달라지는 선택지, 세계관을 가진 게임이라 되게 매력적이라 호기롭게 시작했지만, 출시까지는 가지 못했다.
코드 구조
UI를 좀 더 유연하게 다루고 싶다는 생각이 들어 코드 구조를 구체적으로 짜본 프로젝트이다.
어몽어스나 구스구스덕의 미션을 많이 참고하였으며, 한 미션에 여러 미션(Action)이 존재할 수 있다는 부분을 모듈로 뽑아 제작하였다.
즉, 하나의 미션자체는 MissionController가 담당하여 여러 미션(Action)을 관리하고, 각 미션은 IMission인터페이스로 연결된다.
한 가지 미션(Action)에 대해서도 해동하는 액션들에 대해서 Funtion으로 정의하여 C#클래스 단위로 분리하여 목적을 좀 더 명확하게 만들었다.
CountLogic같은 경우에는 말 그대로 생성 시 목표한 카운트 값을 받고 AddCount를 통해 목표한 값에 도달한다면 해당 델리게이트를 호출한다.
이를 활용하여 시간미션, 클릭횟수 미션, 해당 오브젝트의 개수를 셀 때 등 다양한 미션등에 활용되었다.
해당 미션은 Mono를 상속받아서 기획자 레벨에서 컴포넌트를 조작하여 미션을 설계할 수 있도록 설계하였다.
OOP에 개념에 좀 더 다가가고자 DI를 통해 의존성을 주입하고 동작과 목적을 분리하여 가독성을 높였다.
대부분의 미션은 위와 같이 제작하였으며 이를 관리하는 Controller가 있다.
해당 컨트롤러에 미션을 등록하고 모두 수행된다면 해당 미션을 종료하는 형태이다.
조금 아쉬웠던 부분은 굳이 비동기를 써야했는지에 대한 생각이다.
당시에는 미션종료자체 따른 다른 행위가 발생하는 기획서를 읽고 비동기로 처리했지만, 이후에 테스트 코드를 공부하면서 조금 애를 먹었다.
UI는 Navigation구조로 쉽게 호출하여 사용할 수 있도록 제작하였다 (중복 없이)
지금보니 UI Manager은 그렇게 좋은 구조는 아닌 것 같다.
프로그래머의 입장
브릿지라는 동아리 특성 상, 게임을 공부하는 대학생들의 모임이기에 높은 퀄리티를 기대할 수는 없다.
물론 마음에 잘 맞고, 목표가 같은 팀원들끼리 진행한다면 끝까지 가볼 수 있을 것 같다.
하지만 나는 타인과 다르고 목표도 제각각이다.
이를 이해하는 것이 매우 중요하고 답답하다면 대화를 해야한다.
기획자와 프로그래머는 항상 발을 맞춰서 걸어야 하는데 이번 프로젝트는 그러지 못한 것 같다.
대화도 부족했고 회피하는 기획자를 붙잡지 못한 것도 문제가 되었다.
객체지향적으로 코드를 짜기 위해서 공부하게된 좋은 프로젝트였지만 모두가 포폴정도의 프로젝트로 바라봤기 때문에 완성하지 못한 것 같다.
마무리
좋은 프로젝트도 있지만, 좋지 못한 프로젝트도 있다.
누구나 실패를 겪는다.
가장 중요한 것은 실패를 기록하고 더 나아갈 수 있는 방법을 찾는 것 같다.
프로그래머로썬 더 어려운 과제가 주어졌으면 한다.
게임 개발자로썬 성공한, 팬이 있는 게임을 하나 만들어보고 싶다!
댓글남기기