코드헌터

오늘 할일은 다음과 같다. - 폭뢰가 흔들흔들 하면서 떨어지기 - 적함선의 AI구현 - 폭뢰를 적함선에 적당하게 부착하기

물속 바닥과 충돌시, 물위로 올라왔을때 수평처리 바닥 충돌시 충격파를 모사하기 위해 여러효과를 구상해 봤는데 아래와 같다. 1. 선체 떨리기 2. 번쩍이는 화면효과 3. 물속 뿌연 먼지나기 4. 데미지 세팅 5. 기체 수평 여기서 일단 1번과 5번만 구현해놓고 다른건 셰이더쪽에서 구현하기로 했다. 또한 물위로 올라왔을때는 바로 수평으로 처리하는것 보다는 위 아래로 피치 운동을 하면서 높이값을 수면과 동일하게 맞춰졌더니 물위로 올라오는 효과가 그럴싸하게 구현되었다.

3일동안 파도만 생각했더니 머리가 다 아프네... 4일째까지 구현하다 안되면 걍 환경맵핑처리로만 가야겠다. 오리가 나오는 유명한 파도 데모를 구해서 붙일시도만 4일을 했다. ㅡㅡ;; 그러나 결과는 대 실패!! 실패원인을 분석해보니 소스분석을 얕게하고 무조건 소스를 갖다 붙일생각만 해서 그런거 같다. 카메라쪽파트가 내가 구현하고 있는 소스쪽으로 너무 억지로 이것저것 건드렸더니 프레임도 안나오고 오히려 원본보다 안좋아 졌다. 일단은 이건 패스를 하고 다른 구현이 끝난후 다시 시도를 하던지 다른 소스를 찾아봐야겠다.

이번에 카메라 클래스를 원래 함께있던 게임씬에서 분리해내면서 예상치 못한 문제들이 발생했다. 기존에는 카메라 포인터를 여기저기서 가져다가 쓰면서도 하나의 테두리 안에 위치해 있어서 카메라변환시 큰 문제가 없었지만 카메라 클래스 자체를 분리를 하자 이 포인터를 게임씬에 어떻게 공급할지가 우선 큰 문제였다. 그래서 해결방법으로는 카메라 클래스들만 관리하는 카메라 관리자 클래스를 하나 생성한뒤 아무 제약이 없는 자유카메라만 우선적으로 만든뒤에 게임씬 생성시 이 포인터를 넘겨주는것으로 일차 마무리는 되었다. 하지만 바로 또 문제가 발생하였는데 스카이 박스의 조종사 카메라 기준으로 처리시에 바뀐 카메라 포인터를 넘겨 주어야 하지만 서로 분리된 클래스에게 포인터를 넘겨줄 방법이 마땅히 떠오르지 않았다. 계속 소스를..

리팩토리작업을 하던중 일차적으로 소스정리까지 겸해서 깨끗하게 정리했다. 기본유닛 클래스인 CPlane, CShip, CSubMarine 클래스들을 CActor 클래스로 합쳤고 CEnemy, CEnemySub, CEnemyShip, CHero, CHeroSub, CHeroShip 클래스들도 싹 정리해서 CHeroEx, CEnemyEx로 정리하고 나니 속이 다 후련하다. 또한 이벤트리시버를 받는 구조도 전에 게임씬과 인트로씬만 작성한거에서 카메라를 따로 분리해서 독립적으로 해놓은거 또한 성과중에 하나일듯 싶다. 아래는 비주얼 스튜디오에서 제공하는 다이어그램으로 작성한 유닛클래스 다이어그램이다. 아래는 이벤트리시버 다이어그램이다. 카메라가 따로 분리되어 나온걸 알수있다. 큰 뼈대는 이제 대충 마무리 된듯싶다...

슬슬 중간 점검과 리팩토링을 고려해볼때가 된거 같다. 물론 지형과 기타 필요한 꾸미기가 들어가지를 않았으나 중요핵심요소를 구현했고 충돌체크까지 체크되었으니 메인뼈대는 완성되었다고 보면 될듯하다. 이 뼈대를 중간점검해서 좀더 튼튼히 만들어야 다음 확장때도 무리가 없을듯 싶다. 일단 첨에 잡은 주요일정을 다시 살펴보면 다음과 같다. 전체목표 - 5월 23일~29일 (2주) : 맵구성, 카메라구성, 리소스다듬기, 라이트처리 - 5월 30일~6월 5일 (3주) : 충돌처리, 효과처리 - 6월 6일~12일 (4주) : 충돌처리, 효과처리 - 6월 13일~19일 (5주) : 프레임별 구성처리 - 6월 20일~26일 (6주) : 사운드작업, - 6월 27일~7월 3일 (7주) : 디버깅작업 - 7월 4일~7월 10일..

논리적 구조화 작업도 테스트까지는 끝냈고 문서화작업도 더이상 늦추면 안될듯 하다. 슬슬 시작해야겠다.. (이미 늦었음) 원칙은 이미 유명한 블로그인 아래의것을 따르기로 했다. http://a.tk.co.kr/130 그중에서 쓰기 쉬운 몇가지만 고르면 - 소스 파일의 최상단에 파일명, 날짜, 제작자, 설명을 명기한다. - 클래스 및 구조체 인터페이스 윗부분에 클래스 명, 날짜, 제작자, 설명 등을 첨부한다. - 클래스 / 구조체 멤버 변수 주석은 공백 1칸을 띄우고 "///

기능 위주로만 플밍을 하다가 나중에 더 복잡해지기 전에 전체적인 그림을 한번 잡고 가야할거 같다. 스타 UML로 대충 그린걸 캡쳐한 화면이다. 그림의 맨위의 제목에 있는 블로그를 참조해서 그려봤는데 일단은 그림 그대로 적용해볼 참이다.

일단 전반적인 상속상황을 살펴보면 아래와 같다. - src │ ├- GameProc : 실제 게임메인 프레임 │ ├- AirCraft : 비행체관련 클래스들 │ ├- CPlane : 비행체 추상클래스 │ └- CHero : 주인공비행기 클래스 │ ├- System : 게임의 전체적인 영향을주는 클래스들 │ └- CCamera: 각 시점별 카메라 │ ├- Unit : 게임에서 쓰이는 모든 객체의 추상클래스 │ └- CUnit : │ ├- Weapon : │ └- CBullet : │ ├- CRailGun │ │ └- CTornado │ ├- CMissile │ ├- CAntiSubBomb │ └- CTorpedo │ ├- Ships : │ └- CShip : │ ├- CHeroShip : │ └- CSub..

문자열쪽에 메모리릭이 발생되는걸로 봐서 문자열에 관여하는 어떤 함수가 생각났다. 바로 와이드ANSI 변환 함수들!! 헤더파일 // 유니코드를 ANSI코드로 char* LPCWSTR2STR(const WCHAR* wstr); void LPCWSTR2STR_Release(char* str); // ANSI코드를 유니코드로 WCHAR* LPCSTR2WSTR(const char* str); void LPCSTR2WSTR_Release(WCHAR* wstr); 본체 //>> 유니코드에서 ANSI 문자열로의 변환 방법 char* LPCWSTR2STR(const WCHAR* wstr) { if ( wstr ) { char* str = NULL; int nLen = WideCharToMultiByte(CP_ACP, 0..