게임 아키텍쳐&디자인
*** (:: 내 개인적인 생각)
5장. 기초 아키텍쳐 디자인.
- 최초의 팀은 재능있는 개인들의 집합체였고 현재의 팀은 재능있는 팀.
(:: 게임 아키텍쳐가 필요한 이유)
- 아키텍쳐는 하드 아키텍쳐와 소프트 아키텍쳐로 나눌 수 있음.
하드 아키텍쳐는 (예시적으로) 컴퓨터 하드에ㅜ어와 플레이어간의 인터페이스를 담당하는 입출력.. 같은 걸 포괄한다. 소프트 아키텍쳐는 재사용이 불가능한.. 고유의? 프로젝트 같은 걸 의미하는 듯.
개발 단계 시스템.
0단계 : 프로토타입.
- 실제 개발에 앞서 미리 만들어보는 것. 실제 위험이 닥치기 전에 어떤 위험이 있을지 미리 알아보는 과정. 어떤 방식이든 상관은 없으나 프로토타입에 사용된 코드가 실제 개발에 사용되어서는 안됨.
주된 목적은 게임플레이와 아키텍쳐의 잠재력을 전체적으로 조사하는 것.
1단계 : 그리고 그 이후.. (=ㅁ=..?)
- 낮은 단위화 레벨에서 시작. 하드웨어 인터페이싱 모듈이나 기본 게임의 뼈대가 되는 코드를 구축. 이 시점부터 게임은 항상 출시 가능한 상태로 유지가 되어야 함. (:: 그러니까... 내 졸업작품으로 예를 들자면 창자 부분에 오브젝트들이 쌓였다가 도로 떨어지지 않는 류의 버그가 있을지라도 적어도 일단 실행은 되니까... 그런 상태로 유지가 되어야 함. iTween의 stack overflow로 인해 실행이 되지 않던 상태로 유지하면 안된다는 맥락)
6장. 개발
코딩 표준
- 레이아웃 : 프로그래밍 언어의 구조상 다양한 면을 살펴보고 이를 어떻게 사용할지에 대해 고려해보아야 함. 예를들어, 클래스당, 메소드당, 파일당 최대 제한 줄 수 같은것들.
- 주석 달기와 문서화 : (:: 각자의 방식이 다 다르고 회사마다 다 다르겠지만... 일단 적어도 필자의 의견대로 서술한다면) 주석이 필요하지 않을 만큼 코드를 명확하게 짜고 그럼에도 불구하고 주석을 모두 다는 것이 좋음. 주석은 어떻게 동작하는지가 아닌, 무엇을 하는가에 대한 문제를 서술해야 함.
- 명명규칙과 코딩 규칙 :
(:: 예를 들어 if(name == null)로 써야하는 줄이 있을때 이대로 쓰는 것 보다는 if(null == name) 으로 쓰는 것이 안전하다. 만약에 등치연산자(==)를 대입연산자(=)로 잘못 쓰는 일이 생겼을 때 null 값에 임의의 값을 대입할 수 없기 때문에 컴파일시 오류가 발생하기 때문이다. 반대로 name 을 먼저 쓸 경우, 실수로 대입연산자를 쓰게되면 문법적으로 오류가 없기 때문에 컴파일 에러가 나지 않아서 버그 잡기가 어려워진다.)
(:: 한 줄 짜리 if 문이어도 가능한 중괄호를 써주는 것이 좋다. 졸업작품 코딩할 때도 많이 느낀거지만 한줄짜리 if문이 두줄, 세줄로 늘어나는 경우는 허다하다. 평소에 습관을 들여놓지 않는다면, 진짜 중괄호를 써야할 부분에는 정작 쓰지 않음으로써 커다란 문제를 발생시킬 수 있다. 진짜 한줄짜리 if문을 쓸 요량이라면 엔터도 치지 말고 쓸 수 있을 정도로 짧은 것이 좋다.)
- 클래스 명명규칙, 변수범위지시자.. 등은 캠노트로 책을 아예 찍음.. ;ㅅ;.. 차후 업로드 할 예정.
일단은 여기까지. - 2013년 7월 8일.