Chapter 3 - 3 팀 프로젝트를 마치며 느낀점

우선 팀원들과 확고하게 어떤 장르로 게임을 만들지 정했기에 계획을 세우는 부분에 있어서

굉장히 수월하게 진행됐다. Figma나 기능명세서를 이용하여 본인의 역할과 게임을 어느 방향으로

어떤 기능을 만들지 탄탄하게 세웠다. 하지만 예상과는 반대로 많은 변수들이 있었는데 이러한 것들을

통해 느낀점을 말하고자 한다.

 

1. 처음부터 너무 큰 틀을 잡으면 안된다

위에서 말했듯이 디펜스 게임을 목표로 설정하고 계획을 세우고 있었다.

그 중에서 디펜스를 멀티로 하면 어떨까? 아이템은 이러이러한 것들을 해서

하면 어떨까? 이러한 질문들이 마구 쏟아져 나왔다. 이를 모두 수용하고

개발을 하기도 전에 거의 다 계획에 넣었다면 변수가 생겼을 때 대처하기 어렵다.

 

보통 기능을 분담할 때 연관된 기능을 묶어서 배정하는데 만약 한 사람이 갑자기

도중에 나간다거나 아파서 쉬어야 할 경우 이 연관된 기능 때문에 모든 작업이 멈춰야

하는 경우가 생기고 만다. 그렇기에 우선 기간을 설정하고 이 기간까지 가능한 선에서만

만들자는 계획을 설정하는 것이 좋다고 생각한다.

 

2. 코드 병합은 자주 해야한다

아무리 목표 기능을 설정했다고 해도 이 목표를 달성하기 전까지 병합을 하지 않는다면

정말 많은 코드 오류가 발생할 것이다. 사실 기능을 만드는 것보다 여러 개의 코드를

합치는 부분에 있어서 많은 시간을 소비하기 때문에 코드를 만드는 시간보다 통합과정에서 생기는

버그를 해결하는 시간이 더 많아 질 수 있다는 것이다. 그러면 시간은 시간대로 낭비되고

작업의 진행속도는 늦어질 것이다.

 

3. 빠른 판단을 내려야 한다

실제로 이번 프로젝트에서 팀원 한명이 중도 하차를 했다. 그 분이 플레이어와 몬스터를

담당하고 계셨는데 갑자기 사라지셨다. 하염없이 그 분을 기다리며 작업의 진행은 멈췄고

다음날 연락오셔서 확인을 하니 하차를 하신다고 하셨다. 나는 이번 프로젝트에서 팀장을 맡았을 뿐더러

탄탄하게 세운 계획이 갑자기 무너져 내렸기 때문에 이를 빠르게 판단해야 했다. 

플레이어와 몬스터는 큰 연관을 가진 기능이기 때문에 역할을 배분하는 것에 있어서 시간이 걸렸고

이를 어떻게 조화롭게 해결해 나갈지 고민을 많이 했다. 결국 어찌어찌 잘 해결됐지만 아쉬움이 조금 남았다.

 

애초에 처음부터 작업의 진행이 잠깐 멈췄을 때 새로운 예비 main브랜치에 테스트용 플레이어, 몬스터를 만들어서

작업을 진행했으면 어땠을지 생각했다. 물론 섣부른 판단이 더 큰 화를 불러올 수 있지만 목표 기능을 높게 잡지 않았기

때문에 더 아쉬움이 남는다.

그리고 플레이어와 몬스터의 역할을 배분할 때 쓸데없는 고민을 하지 말고 바로 계획서에 적혀진 기능을 한명 씩 맡아서

진행했으면 좋았을 것 같다. 왠지 계획서를 열심히 만들었는데 이를 이용하지 못했던 것이 아쉬웠다.

그래서 이러한 경우가 있을 때 시간 낭비를 하지 않고 빠르게 판단하는 결단력이 있으면 좋다고 생각한다.

 

4. 마감기한을 꼭 지켜야 한다

이번 프로젝트는 학습 목적으로 진행한 것이기 때문에 마감기한이 조금 넘어도 주의만 주실 뿐이지

실제로 본인에게 입는 타격은 없다. 그렇기에 마감기한을 자꾸 안지키려는 습관을 가진분들이 있다.

수요자와 공급자를 가정해서 말해보자면 공급자가 조금만 더 기능을 만들고 싶다는 자신의 욕심 때문에

마감기한을 넘겨 버렸다고 가정하자. 그러면 필요한 것을 요구한 수요자는 더욱 퀄리티 있는 게임을 보고

감동하는 것이 아니라 그냥 마감기한도 못지키는 무능한 공급자라고 생각할 것이다. 그렇기에 수요자는

이미 실망을 해버린 상태여서 게임을 바라보는 입장이 굉장히 부정적으로 변해있을 것이다. 

 

결론은 아무리 좋은 기능을 만들고 싶다 하더라도 우선 마감기한을 꼭 지켜야 한다.

게임 뿐만 아니라 뭐든지 말이다.

 

 

회고

오늘 적은 것 중에서 물론 틀린 말도 있을 것이다. 하지만 이러한 경험 들이 하나 둘씩 쌓여서

더 나은 나를 만드는 것이라고 생각한다. 앞으로도 많은 것을 경험하면서 배워나가고 싶다.