[뉴비겜톤] 멘토링 내용, 진행내용 정리

경일게임IT아카데미에서 주최한 뉴비겜톤에 참가하고,

프로젝트를 진행하며, 개발 부분에서 느끼게되었던 점을 정리하려한다.

 

 

---

팀개요

이름 : 풀리퀘스트
인원 : 개발2, 기획1, 아트2

프로젝트 : 2d 플렛포머 퍼즐게임

---

멘토링 진행내용

 

신청을 진행 후, 각 1, 2주차 멘토링이 진행되었으며, 게임톤 이후까지 길게 고려하는 프로젝트에서 각 멘토링별 개발 부분 고쳐야할 점이나, 새롭게 알게 된 점을 정리하면 다음과 같았다.

 

 

1.  컨벤션이 중요하다.

- Github 저장소에 commit하며 적게되는 내용, 코드를 작성하며 변수의 이름을 짓는 규칙등이 어떤 형식으로 되어있어야 할지 명히 정의되어있으면,

협업을 진행하는 과정에서 다른 사람이 어떤일을 했는지 한눈에 확인 가능하고, 따로 회의를 진행할 필요없이 원활한 진행이 가능하다.

따라서 컨벤션 문서등을 제작하는 것이 도움이 많이 될 수 있다.

ex) 대표적인 컨벤션을 찾아보면, microsoft c#문서에 컨벤션가이드가 있음을 확인할 수 있다.

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions

 

+ 기술적 컨벤션도 통일해주는 것이 좋다.

ex) unity 내 inputmanager와 inputsystem이 각 작업자간 방식을 통일하는 것이 권장된다.

 

+ 아래와 같이 커밋이후 변경점에 대한 공지를 작성하는것도 다른 개발팀원의 확인에 도움이 되었다.

다만 아래 2번항목과 같이 이를 문서화 시켜두는 것이 기록보존에 더 도움이 될 것이다.

 

 

2. 문서화의 중요

- 개발을 진행하며 구현에 바쁘다보면 신경쓰지 못할 수 있는 부분이다. 다만 작업일지나 다른 추가 사항들을 문서화 해두어 기록으로 남겨두는 것이 중요하다. 

디스코드 채팅의 경우 이후에 유실될 가능성이 있어, 미리 문서화 하여 기록을 다시 살펴볼 수 있게 구성해놓는 것이 좋다.

 

 

3.  Branch관리

- 하나의 branch에서 계속해서 개발을 진행하고, main에 merge하는 방법보다는,

현재 구현하려는 기능이 무엇인지를 나누어서 하나의 기능을 다잡은 후에 branch를 병합하고,

다른 기능을 추가하거나 대대적인 수정이 필요할 때, 해당 기능에 관련한 이름으로 branch를 만들어 따로 관리하는것이 

이후 history등을 볼 때, 어떤 기능이 추가되었는지 명시적으로 편하게 볼 수 있다.

위와같이 하나의 branch선에서 계속관리하면, 한눈에 확인을 진행하기 어렵다.

 

 

 

4. Diagram

- 간단한 구조라도 클래스끼리 어떻게 상호작용하는지에 대한 다이어그램이 존재하면, 코드파악에 도움이 된다.

다만 이는, 구현기간이 짧은 프로젝트에서가 아닌 길고 많은 개발시간을 요구하는 프로젝트에서 진행하면 비교적 더 많은 도움이 될것이다.

 

ex) 간단한 모델 참고자료로는 C4 model이 있다.
https://c4model.com/

Home

 

 

5. 주석

- 협업을 진행하다보면 다른 사람의 코드를 봐야하는 일이있다.

다른 사람이 내 코드를 더 정확히 이해하기 위해서 해야할 점을 간단히 정리해보면 다음과 같다. 

* 함수, 변수이름은 확실하고 각자 하는 기능이 무엇인지 명확해야한다.

* 함수의 대략적인요약과 사용법

	/// <summary>
    /// 함수에 대한 설명
    /// </summary>
    private void Test1()
    {
        
    }
    
    /// <summary>
    /// 함수에 대한 설명
    /// </summary>
    /// <param name="num">매개변수</param>
    /// <returns>리턴 값</returns>
    private string Test2(int num)
    {
        return null;
    }

위와 같이 간단하게 함수에대한 설명이나, 매개변수에 대한 설명을 작성 할 수 있다.

 

 

---

 

게임톤 진행내용

 

개발시간을 진행하며, 그간 1, 2주차동안 개발된 내용을 바탕으로

컨텐츠의 개선, 조립 작업을 진행하게 되었다.

 

- 첨부 기능에 대한 논의

이를 바탕으로 추가해야할 기능과, 게임톤에 들어갈 내용이 무엇인지를 가지치기 하는 작업을 진행하게 되었다.

게임톤 특성상 시간내에 완성해야하는 목표이므로 넣어야할 기능과, 넣지 말아야할 기능을 확실히 분류해야 했다.

 

현재 내가 이 시간 내에 어떤 기능까지 진행할 수 있는지를 명확히 알고있어야 어떤기능을 추가로 배치해야할지 선택할 수 있는데

다음과같은 논의를 진행하게 되었다.

 

또한 일의 우선순위를 잡는 것도 매우 중요하였다. 어떤 기능이 최우선적으로 구현되어야할지와, 그 후 순위로 두어야 할 기능이 무엇인지 교통정리를 해야 가장 중요한 구현사항을 놓치지 않는것에 도움이된다. 

 

ex)

- 타이틀, 던전, 스코어 3개의 flow구성

-> 초기에는 던전 전에 진입 입장맵과 연출을 두기로 했으나, 게임톤 기간 내 연출까지 추가 제작하는 것은 무리가 있음을 판단, 이후 게임의 기능을 보여주는 것을 우선순위로 잡고 위 3개로 이루어진 flow로 구성하기로 진행

 

- 게임 기믹 진행 시, perfect, miss 등의 이펙트 추가

-> 기능은 우선 구현을 진행하였지만, 보여지는 요소에서 사용자가 어떤 기믹을 진행하였는지 확인을 명료하게 하지 못하는 이슈가 있어 해당부분 게임톤 개발 기간내 추가하는 것을 진행

 

 

- 지속적인 현황 체크

첨부 기능에 대한 논의가 완료된 후, 구현을 진행하며 서로의 지속적인 구현 현황 체크가 중요시 되었다.

일이 항상 일정하고 원활하게 진행되는 것은 아니기때문에 현재 상황에 따른 지속적인 계획 수정이 중요시되었다.

 

마치 agile기법으로 개발프로세스를 진행하는것과 비슷하게 느껴졌다.

 

 

- 빌드

프로젝트내에서 기능이 전부 완성되더라도, 실제 빌드가 안되고, 구현환경에서 테스트가 안된다면 이전의 과정이 아무 의미가 없어진다.

따라서 개발중간중간 실제빌드를 몇번 진행해본 뒤, 빌드가 원활한지, 실제 구동은 의도된 기능으로 잘 작동하는지를 몇번 체크해줄 필요성이 있다.

위와같이 빌드가 안정적으로 된다면 매우 안심이 된다..

 

 

- 느낀점

개발기간동안 프로젝트에 필요한 기능이 하나씩 구현될때마다 완성에 점점 가까워지는것이 도파민이 많이 터졌다.

내가 어떤 양을 어느기간에 할 수 있는지도 다시 알 수 있는 계기가 되었다. 이부분이 가장 중요하게 생각드는데,

항상 내가 뭘할수 있는지 객관화가 좀 중요했던 경험이 있어서였다.

협업이 참 신경써야할 사항이 많지만 내가 못하는 분야를 믿고 맡길 수 있어서 매우 편안하고 좋은 구현을 진행할 수 있었다.