개발 지침서
[브랜치 관리]
- 브랜치는 3가지 형태로 관리합니다. "개발용", "통합용", "빌드용"
1-1. 개발용 - Dev
- 개발용은 개인 브렌치 또는 특정 이슈 및 기능 개발용으로 목적으로 사용됩니다.
- 개발용 브랜치는 통합용을 기점으로 생성합니다.
- 모든 수정 사항은 개발용에서 진행합니다.
1-2. 통합용 - Main
- 통합용은 안정성을 보장한 형태로 이루어진 메인 브랜치입니다.
- 개발용에서 이루어진 수정사항들은 버전 수정까지 개발용에서 이루어진후 머지가 이루어집니다. 개발용을 유지하고자 하는 경우에는 쌍방 머지로 브랜치를 최신화 하십시오.
1-3. 빌드용 - Release
- 빌드용은 최종적으로 실게임으로 배포가 가능한 형태의 빌드 브랜치입니다. 개발용에서 사용되는 내부 네트워크 통신이나 디버그 기능, 개발용 치트 등의 기능들이 모두 제외된 버전이기때문에 별도로 관리됩니다.
- 버전 관리
버전은 사소한 수정이여도 메인에 머지가 이루어질 직전이라면 버전을 1개 카운터해서 머지하는것을 권장합니다. 버전의 기본 구조는 0.000 구조를 사용합니다. 맨앞자리는 프로토타입 이후나 런칭 이후같이 특별한 경우에 카운터되고, 소수점을 카운터해서 올려주세요.
[스크립트 및 오브젝트 명명법]
해당 명명법은 가능한 지켜졌으면 하는것들입니다. 이름을 통해서 가지는 효과는 다양하게 존재합니다. 첫번째로는 한눈에 해당 대상에대한 의미와 역할을 이름을 통해서 명확하게 전달되고 이해 할 수 있다는 점이 있습니다. 그것은 앞으로 계속 개선되고 증대되어가는 코드와 스크립트들 속에서 이슈를 추적하고 분석하는 시간을 단축시키는데 생각보다 지대한 영향을 끼치는 요인입니다. 그렇기때문에 이름에 대한 '약속'을 통해서 개발의 유지보수를 상당부분 개선시킬수가 있습니다. 두번째로는 첫번째로 인해 형성된 역할에대한 개발 지향성이 발생한다는 점에 있습니다. 스크립트에 특정한 역할을 하는 이름을 부여한다면 해당 스크립트는 그 이상의 역할을 가지지 않는 방향으로 코드 작성의 방향을 유도할 수 있습니다. 이름에 의한 구분이 보다 명확한 역할과 기능이 부여되면서 스크립트간의 관계성을 명확히 세워 보다 안정적인 시스템 구축을 이룩하는데 기반이 될 수 있습니다.
- 기본 명명법
이름은 가능한 간결한 형태를 띄는것이 좋지만 몇가지 키워드를 정해서 해당 단어들을 조합하는 형태를 가지는 구조를 취하고자 하고 메인 기능들은 그런 방향성을 가지고 짜여져있습니다.
1-1. "키워드""이름" 1-2. "키워드""이름"_"속성"
위와 같은 예시의 형태를 따릅니다.
키워드는 일반적으로 대상에 대한 역할이나 특정 기능을 정의합니다. 이름은 일반적인 C#의 코드 지침을 따릅니다. 코딩 작성 규칙 : https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/coding-style/coding-conventions 속성은 예외적인것으로 동일한 기능을 하는것이 존재하나 거기에 부수적으로 동일한 기능과 구분되어지는 역할을 지정할때 사용됩니다. 특히 함수(메서드)의 명명 규칙은 위와 같은 형태로 짜여져있습니다.
다시 한번 말씀드리지만 메인 기반 코드들이 위와같은 코드 규칙을 따를뿐 필수는 아닙니다. 개발자의 역량에 맞쳐서 스스로 판단해주십시오.
- 스크립트 명명법 <키워드>
2-0. GameManager
게임매니저는 유니티에서 지정하는 유명한 이름중 하나입니다. 그 역할과 의미를 살리고자 그대로 가져가서 구성되어있습니다. 게임 매니저의 역할은 전반적인 게임의 흐름을 통제하는 것입니다.
2-1. Base
기반 코드에 해당하는 스크립트입니다. 해당 베이스를 단독으로 사용되는것은 권장되지않습니다. 그래서 일부 Base 기반 코드들은 추상화되어 있습니다. 대부분 이후 로직들은 기반 Base 코드들을 가지고 있기때문에 MonoBehaviour가 아닌 해당 Base 기반 코드를 상속 받아서 사용해주세요. Base 의 역할은 게임의 대부분 로직과 기능들이 시스템의 통제를 받기위해 시스템의 종속화 시키는 역할을 합니다. 즉, 규격화를 하는 행위입니다.
2-2. Global
전역적으로 사용이 가능한 스크립트들은 Global의 키워드를 사용합니다. Global의 역할은 간단합니다. 정적으로 관리되어 외부 어떤 환경에서든 쉽게 접근하여 사용 할 수 있는 코드들은 Global 의 키워드를 가집니다. 해당 Global 의 키워드를 가진 로직들은 가능한 모든 씬에서 일관된 접근성을 제공하는것이 바람직합니다.
2-3. Panel
스크립트의 구조화를 위해서 가장 기본적인 흐름의 첫 단계를 의미하는 Panel 입니다. Panel 의 역할은 외부로부터 콜백과 같은 입력을 받거나 이벤트를 할당하거나 또는 직접적인 로직을 담고 있지는 않으나 그런 로직을 담고 있는 기능들을 직접 통제하는 역할을 가집니다.
2-4. Graphic
Panel과 쌍으로 주로 사용되는 키워드입니다. Panel은 일종의 조종대라면 Graphic은 그 조종에 의해 움직이는 몸체같은 역할을 합니다. 직접적인 그래픽을 가시적으로 표현하거나 (움직임, 연출 등), 그와 연동되어 특정한 기능적인 내용들을 담깁니다. Graphic은 Panel의 통제를 받기 때문에 Panel은 Graphic을 가지고 있으나, Graphic에서 Panel로 흐름이 역행하는것은 바람직하지않습니다.
2-5. Module
MonoBehaviour 를 상속하지않고 내부적인 로직기능을 담고 있는 독립된 스크립트입니다. 모듈은 이름 처럼 모듈화되어 사용되는것을 원칙으로 합니다. 모듈화라고 하는것은 하나의 기능적 파츠로서 단일 역할을 하면서 해당 로직이 분리와 조립이 자유로운 형태를 가지는것을 말합니다. 그렇기때문에 Module은 가능한 독립된 내부 구조를 가지는것이 좋습니다. 필수 로직이나 유틸리티의 사용은 불가피하나 다른 통제의 역할을 하는 스크립트간의 독립성은 보장되어야합니다. 쉽게 Module의 키워드를 가진 스크립트는 다른 통제 스크립트에 내장만하면 해당기능을 사용 할 수 있어야합니다.
2-6. Controller
Controller는 입력과 작동 로직이 한몸처럼 움직이는 로직입니다. Panel과 Graphic의 합성된 구조라고 이해하시면 편합니다. Controller에 해당하는 기능들은 대부분 분리 될 수록 수직적 관계 유지가 쉽지않은 형태의 스크립트들이 주로 사용됩니다.
2-7. Interface
인터페이스 구현을 위해 만들어진 스크립트들은 Interface 키워드를 사용합니다. 기존 통상적인 명명법에 따르면은 I를 붙여서 사용되는것이 권장되지만 게임내에서 만들어진 인터페이스는 수많은 다른 외부 라이브러리에 해당하는 인터페이스들과는 구분이 될 필요성이 높습니다. 그 역할과 의미가 상당히 다른용도로도 사용될 개연성이 높기때문입니다.
2-8. Logic
Logic은 수직구조의 하단에 해당하며 그래픽적인 연출이 아닌 계산이나 세부적인 기능의 구현과 같이 외부로 노출되지않으나 시스템에 필요한 일부들만을 담는 기능입니다. 해당 Logic 들은 다른 스크립트의 종속적 관계를 가집니다.
2-9. Utility
공통적으로 사용되어지는 통용 기능들을 묶어서 쉽게 접근할 수 있도록 하는것이 핵심적인 Utility의 역할입니다. Global과의 차이점은 Utility 는 스스로 흐름을 통제하지 않으며 오히려 Logic의 묶음에 가깝습니다. 자주 사용되어지는 Logic의 기능들이 똑같이 여러곳에서 반복해서 들어가는것을 Utility 로 대체하는 형태입니다.
2-10. Library
Library 는 여러 데이터들을 한곳에 모아서 한번에 처리하는 큰 카테고리입니다. Player, Option 과같이 복잡한 데이터들이 복합적으로 사용되면서 잦은 데이터 취급이 필요한 경우에는 Library 의 형태로 구현됩니다.
2-11. Data
Data는 데이터 자체에대한 정의를 가집니다. 사용자 정의 자료형으로 Data에대해 구현하는 역할입니다. 다른 어떠한 기능도 내포하지않는것을 원칙으로합니다. Data를 보관하지도 않고 단순한 정의에대한 내용을 포함합니다. 일종의 스키마같은 역할을 합니다.
- 오브젝트 명명법
오브젝트의 이름은 해당 오브젝트가 가지는 가장 명확한 기능을 따라가는것을 권장합니다. 즉, 오브젝트가 Panel_Template 스크립트 컴포넌트를 가지는 오브젝트라면, 해당 오브젝트의 이름은 해당 컴포넌트의 이름을 따라가는것이 바람직합니다. 이는 Unity - HIerarchy 에서 직접적인 오브젝트들이 배치되는 경우가 빈번하기때문에 각 오브젝트의 이름만으로 찾고자하는 오브젝트를 빠르게 파악하는데 도움이 됩니다. (위의 경우 오브젝트의 이름이 Panel_Template가 되는겁니다.) t:를 활용한 검색법도 존재하지만, 가시적으로도 한눈에 파악할수 있는 구조를 가지는게 바람직합니다. Unity에서 제공되는 여러 형태의 컴포넌트의 경우에는 약어를 지정하여 해당 이름을 따옵니다. 위와 같은 이유는 해당 오브젝트들은 동일한 형태로 반복적으로 많이 사용되기 때문에 오브젝트간의 구분이 어려울수 있기 때문입니다. (ex : Image 배경 오브젝트 -> I_Bg) (ex : 팝업창의 닫기 Button -> B_Close)
- 함수 및 변수 명명법
4-1. 변수 명명법
오브젝트가 캐시처리된 변수의 경우에는 가능한 오브젝트의 이름을 따라가 주세요. Unity - HIerarchy상에서 해당 오브젝트를 구분하는데 상당히 도움이 됩니다. 이는 이슈 추적과 유지보수를 유리하게 만듭니다. 디테일한 이름법을 제한하다보면 배보다 배꼽이 더큰 경우가 생길 수 있습니다. 관리가 편한 프로젝트를 만들기위한 방식이 개발에 영향을 주는것은 피해야 하닌깐요. 그외에는 본인이 판단하기에 가장 적합한 방식을 채택해주세요.
4-2. 함수 명명법
해당 함수 명명법은 함수의 이름을 만드는 규칙이라기보다는, 기존 코어의 함수들이 해당 방식대로 짜여져있습니다. 기존 코어 코드들을 분석할때 참고 하십시오.
4-2-1. Logic_ooo
해당 스크립트의 기능적인 내용을 지정합니다. Logic의 키워드식 사용법은 여러 개발자분들이 기반 코드를 상속받아 사용되었을때 기반코드와 추후 작성된 코드간의 함수를 구분하기 위해서입니다. 일종의 순번을 매겨서 이름 정렬된 리스트에서 기반 코드를 묶어서 찾기 쉽게하기위한 목적이 큽니다.
4-2-2. Onooo
On이 붙은 함수들은 콜백함수입니다. 참조가 없더라도 외부에서 콜백의 형태로 해당 함수들을 참조하여 사용됩니다. 이는 기존 유니티의 이름 명명법을 따라갑니다.
4-2-3. ooo_base
해당 함수는 상속해서 사용되는 함수이지만 부모 함수가 기반 코드를 포함하여 내용도 같이 상속하기를 희망한 경우에 base 속성이 붙습니다. 그렇기 때문에 기반 기능에 대한 숙지가 부족하다면 가능한 base를 호출해서 사용해야 합니다. 기반 코드 파악이 미숙한 상태로 base 속성을 무시할 경우 예기치못한 문제가 발생 할 수 있습니다.
4-2-4. ooo_custom
해당 함수는 상속해서 사용하는데 기반 코드에 아무런 영향을 주지않습니다. 부담없이 상속해서 사용해도 무관합니다.
[네임스페이스]
네임스페이스는 여러 코드들의 논리적 구조화를 이루도록 도우며 코드간의 이름 충돌, 어셈블리 참조 간소화 등의 여러 역할에서 중요한 쓰임이 존재합니다. 그렇기 때문에 규모가 크던작던 네임스페이스를 통한 구조화를 이루는것이 바람직합니다. 너무 세분화된 구조를 사용하는것은 피해야하기때문에 유니티내의 어셈블리가 적용되는 형태와 동일하게 폴더의 배치에 따른 네임스페이스 구조를 가지도록 설정하였습니다.
[어셈블리]
어셈블리의 사용 목적이나 장점 그런것을 제쳐두고 현 프로젝트에서 어셈블리를 사용한 이유에대해서만 간단하게 설명하도록 하겠습니다. 첫번째, UnSafe 코드의 제한을 위해서 어셈블리가 사용되었습니다. 클라이언트가 보안상 취약점이 존재 할 수 밖에 없지만 그렇다하여 안정성을 높히려는 시도조차 하지않는다면 프로젝트의 완성도는 생각지도 못한곳에서 훼손이 될 개연성을 제공할 수 있습니다. 그렇기에 최소한의 조치를 취하고자 어느정도 위험성이 있는 코드들을 통합 관리하게 됩니다. 두번째, 현재 프로젝트의 시스템 구조는 4가지 형태로 구성되어있습니다. 모든 데이터 타입들을 한곳에서 관리하는 <데이터 라이브러리>, 게임 시스템의 기반 코드를 가지는 <코어>, 비 개발자분들의 에디터 사용의 편의성을 제공하기위해서 커스텀한 에디터 코드들의 묶음인 <에디터>, 그리고 실질적으로 동적이면서 게임의 전반적인 내용을 담고있는 <메인> 입니다. 이 4개의 시스템 구조간의 상관관계를 명확하게 "보장" 하기위해서 어셈블리를 채용하여 사용됩니다. 코어는 시스템의 기반을 담고 있습니다. 전반적인 큰 흐름을 담당하기 때문에 코어의 추가나 개선은 게임에 지대한 영향을 끼칠 수 있습니다. 그렇기때문에 어느정도 그안에서의 독립성을 보장하면서 제한적 환경을 구성하여 안정성을 확보하는것이 중요합니다. 그렇기 때문에 메인 -> 코어 간의 단방향 수직관계를 보장하는 역할이 핵심입니다.
[개발 과정 참고사항]
-
주석