char* FileName = "smile.bmp"; LoadXXX(FileName);        // 파일을 로드하는 함수

이와 같이 짤것이다.

그런데 귀찮은 문제점이 있다.
이런 저런 다양한 테스트를 하게되면 파일들이 많이 쌓이게 되는 문제 말이다.

코드에서야 필요한 파일만 불러오는 코드를 작성하고 불필요한 파일이름의 코드는 지우면 되지만

파일이 한 폴더에 많이 쌓이게 되면 보기 지저분하고 보기 지저분하니 파일관리도 힘들어진다.
"모델데이터는 뭔지 알겠는데 이 모델데이터에 사용되는 텍스쳐는 뭐뭐였지?" 이런 상황?

그래서 파일 관리 좀 하겠다고 폴더를 만들게 되면

char* FileName = "image/smile.bmp"; LoadXXX(FileName);

더 세분화해서 관리한다면

char* FileName = "image/junjihyun/smile.bmp"; LoadXXX(FileName);

이런 코드가 되겠지만 이렇게 폴더 이름과 파일이름을 반복해서 치게되면 엄청 귀찮아 진다.
이렇게 지루한 코드 작성을 계속하다가 문득 떠오른 아이디어가 떠올랐다. :D
작업폴더를 지정하고 그 폴더의 모든 하위 폴더를 관리하여 모든 파일의 이름을 알아 분석한 상태에서
파일 이름만으로 그 파일의 전체 경로를 얻어내는 방식이다.

비쥬얼 스튜디오로 코드 만들고 다른 폴더에 있는 파일 참조 할때
#include"Classes/CJunjihyun.h"
이렇게 해야 될 것을 추가 포함 디렉터리를 지정해서 하여서
#include"CJunjihyun.h"
이렇게 써도 파일이 참조되는것처럼 말이다.
 

장점은 파일 이름만으로 전체 경로를 얻어내서 지루한 코드가 많이 줄어든다는것!
단점은 작업폴더로 지정된 폴더내에서는 분류된 폴더라도 같이 파일이름이 있으면 안된다는점-0-;
파일이름만으로 전체경로를 얻기 때문이다.

그래도 이 단점 말고는 편할것 같아서 클래스를 만들어 보았다.
그 이름은 바로 CFilePathManager !! 어울리는 이름인지는 모르겠다-0-;
소스는 아래 링크로 다운받아서 보면된다! ( 봐주셈... -_-; )
CFilePathManager.h
CFilePathManager.cpp

클래스 메소드에 대한 설명은 CPP 구현단에 있다.
소스를 보면 알겠지만 작업폴더를 지정해줘서 초기화 한번해주고 ( Initialize(...) 함수이며 이때 폴더를 분석하면서 파일이름을 저장한다. )
GetFullPath(..)를 이용해서 파일의 전체경로를 얻을 수 있다.

그럼 이것을 적용한 코드는..

CFilePathManager        FilePathMng;    // 전역 변수     ...     FilePathMng.Initialize( "image" );     ...     char*FileName = "smile.bmp"     char    FilePath[256];     FilePathMng.GetFullPath( FileName, FilePath );     LoadXXX(FilePath);

폴더내에 파일 관리를 깔끔하게 할 수 있고, 파일경로를 써주는 지루함이 없어졌다!


여담으로 현재 학원에서 진행하는 프로젝트에서 이 방법을 써서 파일을 로드하고 있다.
끝까지 쓸것인지는... 생각해봐야겠다. - -;

그래픽과의 인원부족 관계로 그래픽파트는 저희팀과 다른팀까지 2팀을 맡았고
애니메이터는 4팀을 맡았다.

-------------------------------------------------------------------------------------------------

아래에 쓴 글은 내 입장에서 쓴 글이며, 나의 잘못한 점과 실수, 반성에 대한 글이다.

-------------------------------------------------------------------------------------------------

우리에게 주어진 시간은 25일 이었다. 그래서 아래처럼 일정을 계획했다. (너무 심플하게 잡았다...;)

계획	투자 시간
엔진 분석-렌더링 기반 클래스	2주
게임 로직과 오브젝트 설계-코딩	1주
UI	2일
최종 점검	2일

그러나 실제로 실행된것은 대략 아래와 같다.
 (순수하게 투자된 시간이라기보다는 작업을 시작하여 마무리한 시간이고, 기록해두지 않아서 정확하진 않다..;)

계획	투자 시간
렌더링 기반 클래스	3/3~3/11
익스포터 테스트	3/3~3/15
충돌처리	3/11~15
물리모델	3/9~12
게임 로직	3/17~27
UI	3/23~27
사운드	3/25~27
이펙트	3/16~27
게임 오브젝트 설계 코딩	3/15~3/27
게임 스크립트	3/16~3/23

작업하면서 느낀 가장큰 문제점은 아래와 같다

문제점 1. 허술한 기반 작업과 두서없이 진행한 작업.

위의 실제 작업한 일정을 보면 참 두서 없이 이것저것 같이 하면서 진행하였다.
한달이라는 시간동안에 렌더웨어를 테스트해보고 익숙해지기까지 많은 시간이 소모될같아 모든지 빨리 짜고 빨리빨리 진행하자는 생각이었기 때문이다.
기반 클래스 설계와 작업후에 그에 파생되는것을 만들어야하는데 말이다.
그래서 나타난 문제점이 뭐 하나 만족할만한 코드도 없었고, 급하게 짜고 일단 되게하자는 생각으로 짠 코드라
코드를 더 덭붙이고 추가적으로 만들면서 여기저기 손봐야될 부분도 많아지고
런더웨어 전반적인 구조를 파악하지 못하고 설계를 해서 다른부분에서 문제가 생겼다.

원인은 우리가 어디까지 만들어야된다라는 목표를 뚜렷하게 정하지 않았고
확실히 목표를 두고 수정할 부분이 생기더라고 마무리 짓고 진행을 하지 않았으며
시간이 부족해서 빨리빨리 기반 클래스 만들려고 작업을 허술하게 하여서 그렇다.
확실한 기반작업과 한 작업에 집중해서 튼튼하게 짯어야하는데 말이다.

아래에 나올 일정배분에 문제점에 연관된것이지만 시간이 부족해서 빨리빨리 진행해야된다는 내 생각 때문이었다.

그리고 막바지에 내가 느끼는것을 팀원 플머는 어떻게 생각하는지 궁금해서 서로에 대해 문제점을 얘기해보니까
내가 느끼는것을 얘기해주었다. 기반 클래스 설계에 투자한 시간이 적다는것 말이다. 많이 미안하고 고마웠다.
부족한 실력과 날림으로 짠 코드인데도 이해해주고 불평한마디 없었기 때문이다.

문제점 2. 일정 배분에 문제점.

예전에 2D 프로젝트는 해보았으나 3D는 처음이었다.
그리고 렌더웨어를 사용해야한다는 조건이 있었다.
그래서 짧은 생각으로 렌더웨어 분석과 클래스 설계에 많은 일정을 두고 게임 로직, UI 와 사운드, 이펙트에 대한 부분에 일정을 적게 잡은것이 문제였고, 어떻게 보면 일정 관리에 가장 크게 작용한 네트워크로 대전격투에 대한것을 확실히 결정하지 못한것도 문제였다. (2주차 쯤 되어 지원 불가라고 선언했다...)
분석과 클래스 설계에 일정을 많이 할애하고 다른부분에 적게 잡았다는게 문제라기 보다는, 처음부터 게임에 UI가 어떻게 나올것인지, 사운드는 어떻게 할것인지, 효과는 어떻게 할것인지에 대해서 정하던가 아니면 이러이러한것이 예상되니 기반작업을 어디까지 해둬야될지를 생각해서 일정을 짯어야 하는데 그렇지 못한것이 문제였다.

또한 프로토타입을 미리 뽑아서 추후에 작업은 어떻게 될것인지 게임성은 괜찮은지에 대해서 논의를 하고 다시 일정 계획을 검토했어야하는데 그 점을 간과했었다.

그래서 프로젝트 마감때부터 드는 생각은 일정 관리가 완정 엉망이라는 생각이 들었고 자괴감이 사무쳤다..

문제점 3. 대화의 부족

프로그래머 파트에서의 문제점은 같이 작업을 하는 프로그래머와 많은 대화를 하지 못한것이 문제였다.
2D프로젝트때 여러가지 느낀것이 많아서 이번 프로젝트때는 최대한 자율성을 주고 서로 대화를 하면서 조율을 하려고 했으나...
서로 간의 자율성은 무관심이 되었고 대화는 그냥 합의가 된듯한 느낌이라고 할까..
그렇다고 너는 너! 나는 나! 처럼 한것이 아니지만 대화를 더 아주 더 많이 했어야 했다.
어느분이 말하길 수다쟁이 프로그래머가 되라고 했는데. 우린 과묵한 프로그래머였다....

기획 파트와는 프로그래머 파트에서 좀더 빨리 프로토타입을 뽑아내서 게임성에 대해서 팀원들과 많이 대화를 하면서 조율하고 했어야했다.
그리고 생각하는 게임이 어떠한 것이지..
게임이라는 결과는 나왔지만 교수님들이 말씀하시길 너무 어려운 조작체계, 난이도 최고(너무 어렵다!)...

(난이도 최고에 대한 문제점은 오토 타겟팅을 지원하지 못하고 타겟을 잡는부분에서 프로그램적으로 깔금하게 되지 않는게 큰 원인이기도 하다.)

느낀점!

다들 놀지도 않고 작업만 했으면서도 프로젝트를 진행하며 드러난 문제점을 통해 느낀것은
일정이 빡빡하고 시간이 부족하더라도 너무 섣부르게 진행하지 말아야 하며, 나중을 위해서 충분히 논의해야 한다는것.
그것도 안되면 매일매일 각각의 파트별로 진행상황을 점검하면서 논의하고, 우선순위 매기며 작업을 해야한다는것.

잘된점!

서로간의 이해로 팀원간에 큰 불화가 없었다. (팀웍에 기본이긴 하지만 말이다.)

팀 프로젝트니까 그래픽이 어떻다, 기획이 어떻다. 프로그래밍이 어떻다는 논외다.
잘된점이 너무 짧긴하지만 냉정하게 게임을 만드는 프로젝트에 대한 점만 평가하면 더 이상 잘된점이 없다고 생각한다.
이번에 느낀것을 토대로 다음번에 더 잘하면되지!!


마지막 한마디!

마지막으로 진한 다크서클이 생기고 피곤이 어깨를 짓눌러도 끝까지 같이 해주신 팀원들에게 감사합니다.(마치 사장처럼 얘기하네요;)

그리고 팀원 나이순!으로 한마디씩 하자면

봉기형 : 이쁜 캐릭터 만들어 주신것과 이래저래 불화를 막아주신고 정신적지주가 되어주셔서 감사감사
진형형 : 일단 날림으로 짠 제 코드를 참아주셔서 감사. 그리고 마감 몇시간 전에는 그 동안 누적된 피로때문에 서로 방금 한 말도 잊어버리면서 같이 코딩한 오교수님 감사
초기형 : 플스1스펙으로 저렴하게 잘했다는 칭찬?을 받게끔 모델링에 제약을 많이 걸어서 죄송염; 여튼 이래저래 많이 도움을 주셔서 감사감사
남욱형 : 좋은 기획이었는데 원하는것 다 짜르고, 네트워크 못붙여서 죄송염;




초반 회의랑 마지막 작업때 사용한 기록을 스캔한 이미지...;