========================================
* 시간 : 15:00 ~ 17:00

* 참석자 : 조수운, 류기현, 류기훈

* 주제 : 클라이언트의 시스템 설계 공유 및 보완점 토론
========================================

* 장면 구조

 - 장면(Scene)은 *.unity 파일과는 별도의 개념을 가진 용어임
 : 보통 *.unity 파일을 장면 파일이라고 칭하기는 하지만, 설계상으로는 정확한 용어가 아니다.

 - 장면과 장면을 전환하는 사이에 로딩 GUI가 필요하고, 사실상 이것 때문에 UI 관리자는 전역 관리자가 되었다.
 : 각 장면마다 UI 관리자가 있었다면, 생성 / 삭제에 대한 처리를 신경쓰지 않고도 깔끔하게 구현이 되었겠지만, 로딩처럼 전환 과정에 필요한 GUI는 어찌할 방도가 없어서, 결국 UI Manager는 전역 관리자 객체가 되었다.



* 스테이지 구조

 - 스테이지가 여러 개의 스테이지 영역을 소유하고 관리할 수는 있게 되어 있지만, 이를 실제로 전환하는 구현은 완성되지 않았다.
 : 개념상으로 그렇게 관리만 가능하게 해놓은 것이고, 또 1스테이지 - 1스테이지 영역의 구조를 그대로 가져간다면, 굳이 여러 스테이지 영역을 넘나드는 구현이 시급하지 않기 때문이기도 하다.



* 캐릭터 구조

 - 캐릭터들은 컴포넌트를 조립하는 방식으로 설계했다.

 - 컴포넌트끼리 통신하는 메시지 이벤트의 인터페이스를 구현하고 있음

 - 컴포넌트 간 통신하는 메시지 이벤트 객체 중에서 Get~ 으로 시작하는 이벤트 객체가 많은 게 문제다.
 : 이벤트 객체는 Pooling을 하기 때문에 과도하게 힙 할당 / 삭제가 반복되지는 않겠지만, 어쨌든 '단지 참조 하나 얻기 위한' 작업 치고는 너무 무거운 방식의 인터페이스로 돌아가고 있다.

 - 단순히 캐릭터의 기본 정보를 얻기 위한 부분은 따로 EodEntity의 기본적인 데이터만을 가진 클래스로 취급하고,(엔진 의존적인 정보가 전혀 없음) 모든 EntityComponent가 사전에 참조를 가지고 있게 하는 게 더 나을 것 같다.



* 데이터 스크립트 구조

 - Excel 데이터를 txt 대신 XML로 변환하는 방식을 고려했으나 취소함
 : 테스트 결과, 읽어들이는 속도 차이가 심하게 난다. 
   특히, 파일 개수가 많을수록 차이가 더 심해서, 심지어 PC에서도 전체 데이터를 불러들이는 속도가 5, 6초씩 차이가 나기도 한다.
   아무래도 데이터 스크립트 파일이 많아질 수 밖에 없는 장르의 게임이라서...

 - 대신, XML 기능을 그대로 썼을 때의 장점을 몇 가지 자체 구현해서 이식한다.
 : 특정한 필드는 읽어서 변수에 탑재하지 않고 넘겨버리는 기능 등

 - 필드 데이터가 사전에 정해진 값에서 고르는 방식일 때, 이를 열거형의 문자열로 표현할지, 사전에 분류한 정수값으로 표현할지?
 : 향후 구성할 기획팀이 편한 방식대로...

 - 일반 타입 코드(General Type Code, GTC)의 분류 기준 명세는 서버에서 사용하는 데이터, 서버 - 클라이언트가 둘 다 필요로 하는 데이터에만 적용한다.
 : 클라이언테에서만 필요로 하는 데이터 스크립트는 GTC 분류 기준 명세를 반드시 충족할 필요는 없다. , 작업자가 적당히 알아서 분류해도 된다.
   이유는, 명세가 지나치게 엄밀하게 작성되어 있어서, 뭔가 새로운 데이터 아이템 행(Row)을 추가하고자 할 때, 그 데이터 아이템에 부여할 적절한 GTC를 조합하는 과정이 힘들다고 함.

 - 문자열을 검색 키로 사용하는 부분 전부 정수형으로 대체
 : GTC의 스펙을 지키지는 않더라도, 정수형은 사용해야 한다.
   같은 자료구조의 사전 테이블(Dictionary)에 쓰더라도, 정수형 키 검색이 문자열 키 검색보다 훨씬 빠르다.
   또한, 사용 경험상으로, 데이터가 아주 많아지면 문자열로 키를 쓴다고 해서 코드 번호 부여하는 게 더 간편해지지도 않는다. 심지어, 오타 찾기는 더 힘들다.
   
 - 열거형으로 정의할 수 있는 타입들은 기본 무효값을 -1로 정한다.
 : 0은 유효한 값이다.
   이는 서버와 클라이언트 모두 공통으로 적용해야 한다. (같은 타입을 공동으로 사용해야 할 수도 있기 때문이다.)
   0은 배열 인덱스의 첫 번째 원소로 사용할 수 있기 때문에, 이렇게 정한다.



* 그 외

 - 레드마인에는(레드마인 아니더라도 유명한 이슈 관리 시스템에는) 프로젝트 진행에 유용한 기능이 아주 많으니 적극적으로 활용하자
 : 이슈의 이력 관리, SVN 로그와의 연동, 위키 등

 - SVN에 커밋할 때, 로그 메시지와 이슈 번호는 가급적 꼭 남기자
 : 깜빡하고 커밋한 뒤일지라도, 나중에 로그를 삽입할 수도 있음

 - 상세한 구현을 하기 이전에 설계와 코드 인터페이스를 자주 공유하자.