Skip to content

collaboration guide for unity developer team with artists, programmers, designers, etc

Notifications You must be signed in to change notification settings

IJEMIN/Unity-Team-Handbook

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

8 Commits
 
 

Repository files navigation

유니티 팀 핸드북 (Unity Team Handbook)

아티스트, 디자이너, 프로그래머 등 다양한 직군으로 이루어진 유니티 개발팀이 한몸 같이 협업할 수 있도록 돕는 가이드북.

대상

이 가이드는 다음과 같은 독자들을 대상으로 작성되었습니다.

  • 개발 직군과 비개발 직군 사이의 의사소통 비용이 큰 팀
  • 유니티를 이용한 개발에 대한 이해도가 구성원마다 너무 다른 팀
  • 유니티 에디터를 직접 실행하는 것이 두려운 다른 직군을 위해, 관리가 힘든 매크로를 많이 만들고 있는 팀
  • 명확한 가이드를 세우기에는 시간이 촉박한 팀

이 가이드는 공격적으로 최신 기술을 도입할 수 있는 팀(개발자로만 이루어진 팀이나 기술 중심 팀)이나 취미 개발자를 위해 작성된 문서가 아닙니다. 이 문서는 유니티 팀 작업의 정석적인 워크폴로우와 각종 문제 상황을 여러 직군이 함께 해결하는데 필요한 기준을 제시합니다.

환경 구성

유니티 설치

  • 유니티 에디터 관리는 유니티 허브를 사용합니다.
  • 유니티 개별 인스톨러를 사용하면 안됩니다.

유니티 에디터 버전 선택

다음과 같은 기준으로 버전을 선택합니다.

기본적으로 분기점마다 가장 최신 LTS 버전을 사용하는 것을 추천합니다.

프로젝트 첫 시작시

다음 중 하나의 버전을 선택합니다.

  • 베타가 탐나는 기능을 가진 경우 → 베타
  • 가장 최신 정식 버전
  • 최신 LTS 버전

프로젝트를 처음 시작하는 경우에 한해서만 베타 버전을 선택할 수 있습니다. 이 경우 베타에만 존재하는 편리한 기능들이, 프로젝트가 진행되는 도중 해당 버전이 안정화 될것이라고 기대할 수 있기 때문입니다.

알파 버전은 선택하지 않습니다.

프로젝트 리부트시

근본부터 수정해야하는 설계의 결함 등으로 프로젝트 전반을 리팩토링 하는 경우, 다음과 같이 버전을 선택하고, 기존 프로젝트를 업데이트하거나 처음부터 작성합니다.

  • 가장 최신 정식 버전
  • 최신 LTS 버전

프로젝트를 진행 도중에 업데이트

프로젝트가 어느정도 궤도에 오른 다음에는 다음과 같이, 주기적으로 버전을 업데이트합니다.

  • 현재 주버전의 가장 최신 버전 (예 : 유니티 2018.1.1 → 유니티 2018.4.3)
  • 가장 최신 LTS 버전 (예: 유니티 2019.4.3(LTS) → 유니티 2019.4.8(LTS))

릴리즈가 된 이후

  • LTS 버전을 유지합니다.

버전 관리

성공적인 버전 관리의 핵심은 비개발자 직군들이 프로젝트를 망가뜨릴 두려움없이 작업할 수 있도록 하는 것입니다.

  • 유니티 프로젝트에 SVN은 절대 쓰지 마세요.
  • github와 git을 사용합니다.
  • 비개발자 직군에게 친화적인 인터페이스를 가진 다음과 같은 클라이언트를 사용합니다.
    • github desktop
    • fork
    • 유니티의 깃 공식 플러그인

버전 관리 시스템으로 협력하기

git은 아티스트와 개발자 성향을 모두 지닌 사람이 제대로 설명하면 비개발 직군도 충분히 쉽게 재밌게 이해할 수 있습니다.

반드시 깃을 통해 버전관리를 하도록 모든 직군들에게 이해를 시켜야 합니다.

업데이트 주기

유니티 에디터 버전 선택의 기준에 따라, 유니티 에디터는 마일스톤이나 스플린트 시작 직전에 최신버전으로 업데이트합니다. 마일스톤과 스플린트의 기간은 팀마다 다를 수 있습니다. 여기서는 4주에서 3달을 기준으로 합니다.

코드 규약

클래스와 타입들의 이름은 파스칼을 사용합니다. 필드명은 카멜을 사용합니다.

  • 프로퍼티는 파스칼로 작성합니다.
  • public 변수는 카멜을 사용합니다.
  • private 변수는 가장 앞에 _를 사용합니다.

좋은 코드 짜기

  • 런타임에 Find 메서드를 절대 사용하지 않습니다.

리소스 관리하기

  • 절대 무슨 일이 있어도, Resources 폴더를 애셋을 모아두는 폴더로 사용해서는 안됩니다.
  • 모든 직군은 Resources 폴더가 리소스를 모으는 폴더가 아니라는 것을 제대로 이해해야 합니다.

게임 오브젝트 이름 짓기

  • 모든 게임 오브젝트의 이름은 사람이 읽기 쉬운 형태로 작성해야 합니다.

  • 정상적인 유니티 개발 환경에서는 게임 오브젝트의 이름에 민감하지 않습니다.

  • 레거시 OS에서 파일 경로를 적듯이 이름을 짓지 마세요.

  • 소문자와 언더스코어를 조합하여 사용하지 마세요. (특히 UI 게임 오브젝트 이름을 그렇게 짓는 사람들이 있는데 그러면 안됩니다.)

    • 다음과 같이 이름을 지으면 안됩니다. 형편없이 읽기 힘들며 "게임 오브젝트"라는 단일 개체로서의 맥락이 드러나지 않습니다.
      • monster_a_something
      • img_bg
      • btn_summit
      • overlay_canvas
      • camera_follow
      • item_manager
      • info_panel
  • 다음과 같이 지으세요

    • Title Text
    • Label Text
    • Monster
    • Master Canvas
    • Follow Camera
    • Item Manager
    • Information Panel

프로젝트 관리

About

collaboration guide for unity developer team with artists, programmers, designers, etc

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published