본문 바로가기
VCS/협업

게임 팀 프로젝트 기획부터 개발

by Jinger 2023. 4. 18.

서론

    팀 프로젝트는 실제로 실행하기 힘들다. 팀 프로젝트 중 게임 프로젝트 진행 경험과 경험을 보완한 과정을 정리한 내용이다. 깃허브를 활용하는 방법으로 소개하겠다.


아이디어

     팀을 섭외하기 위해, 게임을 개발하고자 하는 욕구 등으로 아이디어를 우선적으로 생각해야 한다. 아이디어를 만드는 방법으로 유명한 브레인 스토밍, 마인드맵 외에 SWOT기법, SCRAMPER 등 여러 방법을 통해 아이디어를 구체화하는 작업을 한다. 중요한 것은 아이디어를 자신의 머리에만 있지말고, 직접 글과 그림으로 정리를 해야한다. 추천하는 사이트로 Edraw mind, Miro, Figma, Twine이 있다.

     특히, 학생들이 프로젝트 시 게임 아이디어를 구상할 때 이미 존재한 게임을 참고하는 경우가 많다. 이때, 우리는 목표를 명확하게 해야한다. 목표를 지정할 때 게임을 똑같이 따라 하는 모작을 목표로 할지, 새로운 게임을 제작할지 지정해야 한다. 이 게임은 2D인지 3D인지, 앱/웹/pc 게임 중 어느 플랫폼을 목표로 할지도 결정해야 한다. 어느 게임 엔진을 사용해도 상관은 없지만, 목표 적절한 게임 엔진도 고려해야 한다.


기획

     이전에 구상한 아이디어를 구체화하는 단계이자, 개발하기 이전 개발 순서를 지정할 수 있도록 큰 그림을 그리거나, 프로젝트 관리 환경을 구축하는 단계이다. 이때 github에서 "Organizations"을 만들거나, 개인 레포지토리를 생성하여 "Collaborators"로 팀원들에게 관리를 지정한다. 필요한 "Features"(Wikis, Projects, Issues 등)을 설정한다. 기획 단계에서 Projects와 Issues에서 게임에 필요한 부분을 기획하고, 완성된 기획 부분을 Wikis에 문서화하여, 개발 시 참고 자료로 사용된다. 만약 변경될 수 있는 사항이라면 Wiki로 문서화하지 말고 프로젝트창과 이슈창에 그대로 남겨두자. 기획서를 총정리한 문서도 만들어두자.

 만약 팀원이 프로젝트 경험이나 개발 능력이 부족하다면 해당 관련 공부를 시키자. 팀 프로젝트하기 위해 게임 제작에 쓰일 게임 언어(최소 클래스), 개발툴(최소 리펙토링), VSC(깃허브), 관련 전공 지식을 공부시키는 것을 추천한다.

도움이 되는 활동

  • 클래스 다이어그램
  • 슈도 코드(의사 코드)
  • UML

그 외 논의 사항

  • Organizations을 만들지, 개인 레포지토리를 만들지
  • 레포지토리를 public으로 할지 private으로 할지
  • 개발팀과 기획팀, 디자인팀 등 팀을 나눌지 의논
    • 소규모인 경우 기획을 우선 진행 후 개발을 하는 것을 추천한다.
    • 중규모인 경우 기획과 개발팀을 나누어 기획팀이 개발 도중에 필요한 에셋이나, 수치, 일정 등을 조절하는 것을 추천한다.
    • 대규모인 경우, 개발팀을 여러 나누어 프로젝트를 여러 개를 동시에 진행하여 나중에 합치는 형식으로 진행된다.


개발

    실제 게임을 구현단계이다. 프로젝트 시 팀원들이 모두 같은 언어로 게임을 제작하게 되는 데, 팀원들이 모두 한 언어만 잘한다는 보장이 없다. 그렇기에 해당 언어의 문법과 네이밍을 통일시켜야 한다. 논의를 하지 않으면 각자 자신이 편한 네이밍을 사용해 코드들이 혼잡해질 수 있다.

개발 초

    게임의 핵심 부분을 우선적으로 개발한다. 만약 현재 개발자들의 역량으로 불가능한 기능이 있다면 다른 기능으로 대체하거나, 취소하는 조치를 취하자.

그 외 논의 사항

  • 브랜치 및 커밋 전략
  • 버전 통일
  • .gitignore
  • 개발 환경(주석 문제)
  • 브랜치 보호 전략(Branch protection rules)
  • 깃허브에 쓰일 태그, 라벨, 카테고리 정리
  • 태그 이슈 생성(유니티)
  • 진행 방법 논의(E.g. 에자일)
  • 파일 정리 방법

개발 중

    게임의 부가적인 부분 및 세세한 부분 개발을 진행한다. 논의한 사항 정리, 기획된 부분 정리, 각자 개발 부분 개발 및 문서화 등을 하며, 만약 게임 기획에 크거나 작은 변화가 생기면 지금 단계에서 수정한다.(웬만해서는 바꾸는 일이 없도록 기획 단계에서 마무리한다.)

    만약 초심자라면 멤버 활동 wiki를 만들어 자신이 개발한 내용을 정리한 문서를 공유하는 것을 추천한다. 나중에 다른 멤버들이 활동한 것을 보며 해당 기술을 배우거나, 피드백 등을 할 수 있으며, 남의 코드를 이해하는 데 큰 도움이 될 것이다.

    중간중간 코드 리뷰 및 개선, 리펙토링 하는 것을 추천한다.

개발 말

   빌드하기 이전 큰 버그를 고치거나, 좀 더 효율적인 알고리즘 개선 및 최적화를 진행한다. 추후에 다시 개발하게 되거나, 포트폴리오용 혹은 게임을 소개하는 용도로 게임 기획서를 완성하자. 깃허브의 README.md와 About도 정리해놓자.

테스트

    구현된 부분을 테스트하며 버그를 찾고 밸런싱하는 단계이다. 직접 플레이하거나 공식을 세워 적절한 밸런스를 찾고 개발 중 찾지 못했던 버그를 찾고 고치는 작업을 진행한다.

도움이 되는 활동

  • 편의를 위한 치트 코드 명세서

출시

    만든 게임을 공개하는 단계이다. 스토브 인디, 스팀, Google play 등에 올려 접근하기 쉽게 하자.


주섬주섬

    직접 게임을 제작한다는 생각으로 해당 씬을 어떻게 표현할지, 좀 더 매력적인 게임이 되기 위해 무엇을 해야할지, 프로젝트하면서 부족했던 점이 무엇이고 어떻게 극복할지 등을 개인 회고록에 기록하며 프로젝트를 진행하는 것을 추천한다.

참고

 

Indie Developer Guide Document

 

studio-docs.onstove.com

 

반응형

'VCS > 협업' 카테고리의 다른 글

VCS 프로젝트 브랜치 전략  (1) 2024.07.14
인코딩 문제와 해결  (0) 2023.09.27

댓글