그냥 스크래치 형식으로 간단히 정리
생각날때마다 더 붙여쓰자
1. 엔진을 살 것인가? 아니면 바닥부터 만들 것인가?
요즘은 워낙 복잡도와 요구조건이 높아졌기 때문에 예전에 만들어 놓은 엔진이 없이 바닥부터 만드는건 신선놀음 하는 프로젝트가 아닌 이상 거의 불가능 하다.
2. UI Framework 는 어떤걸로?
이건 그냥 요즘 대세인 Scaleform을 쓸 것인가 말 것인와 동일한 질문이다. 거지같은 퍼포먼스와 뻔뻔한 IME 지원을 생각하면 안 쓰고 싶지만 그렇다고 바닥부터 만드는것도 역시 삽질. Scaleform은 이미 빡시게 사용 했기 때문에 그래도 담에 쓰면 좀 나을거 같기도 하고.
3. 다양한 Utility Library 준비
우선 STL을 쓸지 말지를 결정하고 안 쓸거라면 최소한 그에 버금가는 라이브러리를 준비해 놓아야 한다.
물론 1에서 좋은 엔진을 사면 웬만한건 다 있으니 걱정 안해도 될지도...
대충 필요한 라이브러리의 기능은
Formatting 함수 : printf 류의 함수는 절대 쓰면 안되고 c# 형식으로 {0} , {1} 같이 처리하는 함수가 필요
String, Smart Pointer
다양한 자료 구조들 : List, Vector, Stack, Queue, Map, Hash
파일 이름 관련 함수들
4. 로컬라이제이션 정책 준비
개발때부터 최대한 유연한 구조로 만들어서 추후에 해외 진출을 할 때 쉽게 쉽게 변경할 수 있는 구조로 만들어야 한다. 특정 게임 기능들을 코드 수정없이 쉽게 On / Off 할 수 있어야 함.
5. 멀티 스레딩 준비
이것도 좋은 엔진을 사면 별로 고민하지 않아도 된다. 하지만 꾸진걸 사거나 바닥부터 만든다면....애도
6. 리소스 패키징 정책
클라이언트 배포시에 리소스를 어떻게 패키징 하고, 어떻게 다운로드 시킬지 결정. 예를 들어서 길드워 처럼 실행 파일 하나만 다운받고 필요시마다 다운로드 받아서 패키징 한다던가 와우처럼 필요한 최소한의 리소스만 받고 게임 진행하며 같이 다운로드 받는 형태라던지..
7. 유연한 이벤트 고려
4와 조금은 비슷한 내용인데, 라이브 서비스를 하게 되면 이벤트는 필수. 이를 위해서 게임내 거의 모든 로직을 데이터 드리븐으로 만들고 이걸 서비스 하는 쪽에서 실시간에 쉽게 제어 가능하게 만들어야 한다.
8. 띄우기 관리하기 쉬운 서버 구조
서버 바이너리와 데이터 파일들을 받았을때 바보라도 띄우고 관리하고 패치 할 수 있는 서버를 만들어야 한다. 이게 복잡하면 해외 서비스 할 때 정말 캐고생
9. 서버를 C#으로? C++로?
이상하게 서버는 항상 바닥부터 다시 짜는 일이 많은데 왜 그런지는 잘 모르겠음. 아무튼 C#을
10 . 확실한 코드 컨벤션 및 디렉토리 구조
이게 프로젝트 초반에 제대로 안 잡히면 뒤에가서 정말 머리속이 복잡하고 짜증나는 상태가 되서 후임자들에게 저주를 받으리..
11. 스크립팅 언어를 얼만큼 어떻게 사용할 것인가
스크립팅 언어를 쓸것인가 말 것인가 부터 결정. 쓸꺼라면 무조건 디버깅이 편한걸로 "하나만" 쓰자.
12. 기술적으로 지원 가능한 비쥬얼적 목표를 결정하고 빡시게 컨트롤 하는 정책을 수립
이게 안되면 잡몹에 텍스쳐를 압축도 안한걸 쓰면서 각종 쉐이더 효과로 떡칠하는 안습의 사태가 벌어질수도 있다..대부분의 디자이너들의 목표는 게임 프레임이 아니고 예쁜 모델들이라는걸 명심.
13. Asset 관리 정책 수립
개발용 리소스를 어떤 SVN을 통해서 어떻게 관리 할지를 결정. 예를 들어 AB를 쓰기로 했다면 주기적인 백업 프로세스, 프로젝트 설정 및 디렉토리 구조 정립등을 해야 할 것이니라..
(클베 3일전에 Asset 머신의 Raid (0+1)으로 세팅된 하드가 날아가는 경험을 해본적이 있는가..)
14. 빌드머신 설정
소스 코드 및 각종 개발용 리소스들을 입력 받아서 실제 배포되는 리테일용 바이너리와 데이터로 가공해주는 자동화 프로세스를 만들어 둬야 한다.
15. DLL을 쓸 것인가 말 것인가
DLL을 안 쓰고 바이너리 파일 하나로 두면 뭔가 깔끔하고 핵실드 같은데서 보호도 좀 더 잘 되고 각 모듈간에 통신이 간단해 지지만 빌드 시간 안습.
모 프로젝트처럼 DLL로 마구마구 쪼개 놓으면 빌드 시간도 별로 안 들고 좋지만, 점점 뒤로 갈수록 각 모듈간에 통신하느라 만들어 놓은 덕지덕지 함수들 때문에 좌절할지도. 게다가 보안상 더 안좋다.
개발할땐 다 DLL로 구동시키고 배포용 버전은 .Exe로 하나로 나가는 작전도 있긴 한데 걍 별로인듯 하다. (배포판이랑 개발판이랑 저런식으로 데이터가 다르면 어디선가 꼭 문제가 생김)
16. 쉽게 Iteration 될 수 있는 구조를 고려
여러번 테스트 하고 다듬는 작업이 쉽게 되게 하기 위해서 필수. 서버와 클라이언트가 띄우는데 한세월이 걸리면 이미 글른거다.
