레이옷 아저씨 한테 이어 받은 내용입니다-ㅅ-;

몇 살 때 게임 개발을 시작했나요?
 흐음.. 몇살일까요.
 중1때였으니까, 14살.. 92년.. 경이네요.

어떻게 게임 개발을 시작하게 되었는가?
 으음.. 집에 있던 XT컴퓨터에서 삼국지3가 안돌아가서 좌절하고나서(orz) 그 당시에 이미 새로 나오는 게임들은 집에서 돌아가지 않는 상황이라 에잇. 내가 만들고 만다~ 라는 웃기지도 않은 동기로 시작하게 되었습니다.

게임 개발을 처음 시작했을 때의 개발 환경은?
 처음에는 정확히 기억나지는 않는데. 터보베이직인가 파워베이직인가를 썼던것 같습니다.
 한글라이브러리도 만들고 도트툴도 만들고 하다가, 한계를 느끼고 중3때 동네 컴퓨터 학원을 가서 C언어를 배웠습니다.
 그 후부터는 터보씨쫌 쓰다가 왓컴씨로 금방 갈아타고 대학가면서 VC로 갔습니다.

최초로 개발한 상용 게임은 어떤 게임이었나?
 다크에덴(http://darkeden.com). 아직도 절찬리에 서비스중인 초장수 게임.
 2001년 2월부터 개발에 참여하였습니다. 시기는 오픈베타 시작하고 한달이 좀 안됐을때 입니다.
 당시 동접이 150명정도로 기억을-_-;
 삽질도 많이 하고 좋은 동료분들이 많아서 배운것도 많았습니다.
 그 회사에서 일을 시작한게 인생의 가장 큰 전환기중 하나라고 생각합니다.
 다른 회사에 갔더라면 지금과는 상당히 다른 모습이 되어 있을지도 모르겠네요.

게임을 개발해오면서 사용했던 프로그래밍 언어들은?
 뭐 윈도우 프로그래머다 보니 상당히 한정적이군요.
 Visual C++ (6,2002,2003,2005), MFC, C#, ActiveX, HLSL, Python, Lua, XML(XML은 레이옷이 썼길래 썼는데. 이건 언어라고 하기에는 좀-ㅅ-)
 써놓기는 많이 써놨지만 실제로 많이쓰는건 VC, MFC, XML정도인겁니다.;

다시 직업을 선택하라고 해도 또 게임 개발을 선택할 것인가?
 아.. 어려운 주제입니다.
 게임을 만드는것도 좋아하고 코딩을 하는것도 좋아하지만..
 흐음....
 뭐 딱히 다르게 하고 싶은 직업은 없지만..
 다른 걸 해보고 싶기도 하군요.
 반반이라고 하지요.

신입 게임 개발자에게 알려주고픈 딱 한가지만 고른다면?
 기술적인 것들을 공부하는것도 중요하지만 논리적인 사고력을 기르는 것도 상당히 중요합니다.
 여태까지 일하면서 논리적인 부분이 부족해서 코드가 엉망이 되는 경우를 많이 보고 그것때문에 많이 고생했었습니다.
 더 중요한건 그런 사고방식을 고치려고 하지 않는 사람들을 많이 봐왔습니다.
사람의 성격이나 사고방식에 대해서 뭐라고 할 생각은 없지만 직업이 프로그래머라면 논리적인 사고력은 필수 입니다.

 그 외에는 위에도 잠깐 언급했지만 처음 취업을 할때는 꼭 유지보수팀으로 들어가기를 추천합니다.
 저도 처음 취업할때 유지보수팀(이라고 하기에는 개발할게 너무 많았지만orz)으로 들어갔었고, 프로그래머 인생중에 처음 취업을 신규개발팀이 아니라 유지보수팀으로 들어갔고, 그렇지 않았다면 지금보다 훨씬 발전속도가 느린 상태였을거라고 생각합니다.
유지보수팀에 신입으로 입사하는 것에 대한 장점은 상당히 공감가는 포스트가 있어서 링크하겠습니다.

왕멀님의 포스트 : http://wangmul.egloos.com/1724223

게임 개발을 하면서 가장 감동적이었던 것은?

고등학교 1학년때 이리저리 도트툴도 만들고 친구한놈 잡아다가 그림도 그리고 해서..
풀밖에 없는 배경위에 2프레임밖에 없는 캐릭터가 고개를 깔딱깔딱 하면서 움직였을때..
해냈다.. 하는 느낌과 함께 뭔가 새로운 생명체를 탄생시킨 조물주가 된 것 같은 기분이었습니다.

다음 사람은?

쭈니, 무적풍운

우선 아래 글들을 읽으시기 바랍니다.

채용이 번복된 사람의 글
그 내용에 반박하는 사람의 글 - 반박글 원본은 글 쓰신 분이 지우셔서 댓글을 보시다 보면 다른 분이 올리신게 있습니다.

좀 민감할 수도 있는 내용이고, 이런 주제는 제 생각만 적는 경우는 괜찮지만 이런 특정 경우에 대한 내용에 대해서 글을 적는 걸 별로 안좋아 하는 편이라 고민을 하다가 결국 글을 쓰게 되었습니다.

참...안타깝습니다.
채용번복이 된 것 자체야 어떤 경위로든 결국은 같이 일할 사람들이 마음에 들지 않는다면 같이 일할 수 없는 것이니 어쩔 수 없다고 해도 풀어나가는 방법이 좀 문제가 있군요.

저도 어쩌다 보니 팀장이라는 직책을 5년 넘게 하며 많은 분들을 면접보고 채용하고 했습니다만.
제가 회사를 들어갈때도 그렇고 사람을 채용할때도 그렇고.
늘 생각하는건 회사입장에서도 면접자를 면밀히 판단하여 선택을 하는 것이고, 면접자 입장에서도 회사를 면밀히 판단하여 선택을 하는 것이라고 생각합니다.

그래서 항상 면접볼때 가능하면 다른 괜찮은 회사들이 있으면 면접들을 더 보고, 그리고 나서 저와 같이 일하는 걸 선택해주는게 가장 좋다고 면접자분들께 말씀드립니다.
그 이유는 실제로도 뽑아주기만 하면 무조건 오겠다.. 라거나 다른데는 잘 안되서 어쩔 수 없이 오게 되었다든가, 그냥 대충 보니 괜찮아 보여서.. 가 아나라 다른 회사들과 비교를 해보고 분명한 이유를 가지고 선택해서 들어왔다.. 라는 생각을 가지고 입사후에 아.. 그때 그 회사를 가는게 나았으려나.. 하는 생각 없이 선택을 최선의 선택으로 만들기 위해서 노력하기를 바란다는 말씀을 드립니다.

저의 경우는 미심쩍은 게 있는 면접자는 아무래도 뽑기가 힘들어지는 성격입니다. 그건 회사를 입사할 때도 마찬가지입니다. 미심쩍은 부분들은 일단 뽑아놓고 보자.. 라거나 일단 들어가고 보자.. 라는 건 좀 거부감이 있습니다.
저도 면접후에도 사소한 것들에 대한 의문을 물어보는 경우들이 많고, 면접자 분들이 사소한 것들을 물어보셔도 회사 들어오고 나니 이런 문제가 있더라.. 라는 것 보다는 회사 들어오기 전에 알고 들어오는 것들이 좋으니 궁금한게 있으시면 부담갖지 마시고 전화하시라고 하는 편입니다.

사실 회사라는 곳이 들어가고 나서 이 회사 진짜 막장이구나.. 하고 판단할 정도가 되면 이미 발을 빼기가 힘든 상황들이 많고, 그 회사의 문제점들이 사소한 부분들에 묻어나는 것들을 보고 판단할 수 밖에 없는 경우들이 많습니다. 그래서 사소한 부분들을 간과하고 넘어갈 수 없는 경우들이 있습니다.

저는 일하다보면 제 코가 열자쯤-_-되는 경우가 많기 때문에(보통은 스스로 무덤을orz) 관리업무를 소홀한 경우가 많아서 그리 좋은 팀장은 아니었던거 같습니다.(뭐 싸이코라는 말도 들었었지만 ㅎㅎ)
그나마 좋은 부분이라고 해봤자 다른 팀원의 코를 열자로 만드는 대신에 제코가 열자가 된다는 정도겠지만, 그건 귀찮아 하거나 싫어하는 일을 다른 사람에게 떠 맡기는 걸 싫어하기 때문이지요.(제가 이상하게 그런 귀찮은 일들을 재밌어하는 경우가 많기도 하지만-_-)

뭐 이런 방법이 팀관리 차원으로 보면 좋은 경우는 아니기는 합니다만, 팀원들에게는 싫은 일을 아예 안할수는 없겠지만 가능하면 실력향상이 되거나 스스로 재밌어하거나, 경험이 있어서 잘 할 수 있는 업무들만 주고 싶은 마음 깊은 배려-_-;가 있습니다;; 귀찮은 것들은 차라리 내가 하고 말고, 팀원들은 기분좋게 일하게 하자... 하는 생각입니다만..(그냥 싫은 소리 하는걸 잘 못하는 걸지도..orz)

뭐 얘기하다 보니 내용이 좀 잡다해졌읍니다만..
다른 사람들과 같이 생각을 맞춰서 일을 하고, 새로운 팀원들을 뽑는 것들은 몇년이 지나도 그리 쉽지 않은 것 같습니다.
하지만 IT업계는 사람이 재산인 만큼 신중하게 할 수 있도록 계속 노력해야 되겠습니다.
(결론이 무슨 공익광고 같애;;;)

'게임개발 > 생각' 카테고리의 다른 글

Game Development Meme  (9) 2008.07.13
C# vs C/C++ Performance  (4) 2008.03.03
요즘 구인광고들을 보면..  (12) 2008.02.29
VisualStudio 스프링노트 Addin?  (4) 2008.02.26
Visual Studio 2008 shell을 보니.  (3) 2008.01.17
C# vs C/C++ Performance

흐음 흥미로운 글이네요.

대략 정리하면 C#의 경우는 native C++과는 달리 .net 프레임웍 기반에서 실행되면서 듀얼 코어라든가, 하이퍼 스레딩, SSE등의 인스트럭션등을 사용자 PC에 맞게 사용이 되기 때문에, 잘 디자인 된 C#코드의 경우 동등한 잘 디자인된 native C++보다 90%정도 빠르다.. 그리고 native C++의 경우 코드 크기가 커질수록 page fault가 자주 일어나서 하드를 읽어야 하기 때문에...가비지 콜렉션 기능이 있는 C#이 낫다..라는 내용인것 같습니다.

그렇다는 얘기는 managed C++도 같은 얘기일까요?

사실 프로그램은 점점 복잡해지고 있고, 사양은 높아져 가고 있어서..
요즘은 스크립트로 많이 대처된다거나 하고 있기 때문에..
속도가 중요한 엔진이나 서버쪽 중요로직들 외에는 퍼포먼스보다는 개발속도를 높이고 유지보수가 쉬운쪽으로 가는 추세라고 생각합니다.

뭐 스크립트도 좋지만, C#의 경우는 C++과는 컴파일속도가 비교할 수 없을 정도로 빠르기 때문에 스크립트 보다는 C#을 사용하는 편이 재실행을 해야 한다 라는것 외에는 개발적으로 훨씬 좋다.. 라고 생각하고 있는데.. native C++하고 bind하는 게 영 불편한지라-_- 엔진도 C#으로 만들게 아닌 이상은 실제로 사용하기는 힘들다고 생각합니다;

뭐 그래도 꾸준히 C#에 대한 공부를 하고 있긴 하지만 별도의 어플리케이션 외에 C++과 코드를 공유해야 하는 경우는 아직은 좀 더 생각해 봐야 할 것 같습니다.

ps. 도대체 왜 ms는 native c++과 C#을 bind하기를 이렇게 어렵게 만들어 놨을까요;;

요즘 여러회사에서 제안이 들어오는것들도 있고, 면접이 잡힌 회사도 있고, 따로 게임잡을 살펴보기도 합니다만...

뭐 사실 큰 회사야 특정 프로젝트가 아니라 회사로 공고를 하고, 지원이 들어오면 각 팀별로 살펴보게 되니까.. 뭐 그거야 각각 올릴수는 없으니 그렇다고 쳐도..

게임잡에 올라온것들을 보면 회사에서 필요한것들만 잔뜩 써놓고 정작 구직자가 필요한것들은 전혀 없는 것들이 대부분이라 보고 있으면 한숨이 나옵니다.

이미 게임내용이 웹진같은데 공개된 경우는 괜찮지만..
그렇지 않은 경우는 많이 써있어봐야 장르정도가 전부입니다.
그나마도 장르도 기재되어 있지 않은 경우도 많네요.

이건 게임잡에 있는 것 뿐만이 아니라 제안이 오는 경우도 마찬가지입니다.
회사명만 떨렁 얘기하고 제안이 들어오는 경우가 있지를 않나..
회사명도 얘기안하고 제안을 보내는 헤드헌터들이 있지를 않나..

게임에 대한 간단한 소개정도 쓰는게 그렇게 큰 문제가 됩니까?
도대체 뭘 보고 입사지원을 합니까?;

저 같은 경우는 입사지원을 할 때 보는게 프로젝트, 출퇴근, 밥;; 3가지입니다.
면접을 보고나면 프로젝트, 사람, 출퇴근, 밥;; 이렇게 4가지가 됩니다;
뭐 출퇴근이야 당연히 출퇴근 하기 좋은가를 보고(정확히는 2호선 테헤란로와 8호선;;), 밥은 점심은 주나 밥집들은 맛있나;; 를 봅니다.
뭐 사람이야 면접 때 판단하는거고..
프로젝트는 게임의 가능성이나 아니면 언리얼3-_- 를 쓴다거나 하는걸 봅니다;

입사지원 3가지 조건이 전혀 충족되지 않은(프로젝트 정보를 몰라서;) N모사를 다음주에 면접보기로 한 예외상황같은 경우도 있지만..
이런 경우는 회사 인지도가 워낙 좋으니 통과;

사실 가장 가고 싶은 회사는 드래곤네스트를 만드는 아이덴티티란 회사에 게임플레이쪽으로 들어가고 싶었는데..(집에서 걸어갈수 있고, 프로젝트가 200%쯤 마음에 듭니다)

이 회사가 GPGStudy에 화요일날 저녁 다 되서 구인광고를 올려놓고..
목요일날 지원할까..하고 보니 오전에 이미 뽑았다는 글이 올라와있는걸 보고 좌절orz
수요일날 당일면접봐서 바로 결정난겁니까!!;;;

아직 엔진파트는 뽑고 있지만.. 이젠 흠좀 다시 게임만들고 싶어서;;
엔진도 재미 있지만 역시 게임만든다는 생각은 안들어서 말이죠...
엔진을 한 4년정도 했는데 처음 엔진할때는 재미반 게임만드려면 엔진을 알아야 하니까 반..
뭐 이렇게 였습니다.
진로를 엔진으로 바꿨다기 보다는 게임만드는데 엔진을 할 줄 알아야 한다고 생각해서 했던거였는데..
계속 엔진프로그래머를 못뽑으면서 생각보다 너무 오래했습니다;;
뭐 틈틈이 게임플레이쪽도 꽤 했지만 말입니다.

어쨋건 딱히 마음에 드는 회사가 없어서 고민중입니다..;;
아 머리아프네요.

'게임개발 > 생각' 카테고리의 다른 글

최근 문제된 채용과 관련된 당황스러운 일.  (9) 2008.03.28
C# vs C/C++ Performance  (4) 2008.03.03
VisualStudio 스프링노트 Addin?  (4) 2008.02.26
Visual Studio 2008 shell을 보니.  (3) 2008.01.17
SUI  (2) 2006.10.21

흐음.
이전 프로젝트를 할때 명세서를 작성하고 기획팀에게 브리핑을 한 뒤 명세서상으로 피드백을 받고 진행했었습니다.
서버쪽은 wiki를 사용했고 클라이언트쪽은 스프링노트를 사용했었는데요.

요즘 TDD관련 작업들을 하다보니.
명세서를 작성하는 대신에 TestFirst로 작업을 진행하고, 그 테스트 코드를 브리핑하는 방법도 좋을것 같습니다.
사실 명세서는 처음에는 잘 작성하지만 유지보수가 잘 안되거나 하는 경우들이 꽤 많아서 불편한 부분들이 있는데.
테스트 코드를 그대로 사용하게 되면 유지보수야 당연히 하는것이니 일이 줄어들거고, 기획쪽에서 볼때도 상세하고 실제적인 명세를 볼 수 있을거라 생각합니다.
물론 어느정도의 설명을 주석으로 달아야 겠지만요.

그런데 문제가 테스트코드파일들을 스프링노트나 위키에 긁어붙이는것도 꽤 번거로운데요.;;
(게다가 스프링노트는 소스코드를 넣는 형식이 있음에도 컬러링을 지원하지 않아서 보기가 불편합니다.)

흐음.. 이부분을 Addin형태로 만들어서 Upload버튼을 누르면 자동으로 스프링노트에 컬러링을 포함해서 올려주는 기능이 있으면 꽤 편해지지 않을까...라는 생각이 듭니다.
아니면 커밋되는게 있으면 자동으로 올려주는것도 괜찮겠네요..이러면 addin이 아닌가-_-;

물론 기획팀이 잘 봐야 말이지만, 꼭 기획팀이 보는 용도가 아니어도 같은 팀 내에서 본다던가(이건 코드 보는게 빠를듯), 코드 리뷰등을 할 때 사용할수도 있고, 서버팀과 클라이언트팀의 경우는 사실 코드를 따로 관리하기 때문에 소스를 열어서 보기는 좀 부담되니 스프링노트에서 본다던가 하는것도 괜찮겠네요.

좋지 않은점은, 피드백이 힘들다는 점인데..
일방적인 전달 경로로는 괜찮지만, 노트에 피드백을 받기가 힘들다...하는 부분이 있습니다.
이부분은 중간중간 피드백을 하지말고 하단에 코멘트 메쉬업을 달고 upload시 그부분을 유지시켜주는 방법도 있는데...흐음 좀 불편할거 같기도 합니다..

구현자체는, 해본적은 없지만-_- msn bot으로 스프링노트에 글을 쓰는 게 가능하지 이론상으로는 구현이 가능할 것 같습니다.

...
한참 써놓고 나니 addin보다는 서버단에서 커밋되는걸 처리하는게 날 것 같고, 아니면 그냥 내부 인터넷용으로 websvn을 붙여버리는 편이;;;;

쓸잘데기 없으려나..흐음;;;

'게임개발 > 생각' 카테고리의 다른 글

C# vs C/C++ Performance  (4) 2008.03.03
요즘 구인광고들을 보면..  (12) 2008.02.29
Visual Studio 2008 shell을 보니.  (3) 2008.01.17
SUI  (2) 2006.10.21
ONE OUTS 2권 중..  (4) 2006.10.21
vs shell은 대략
http://www.curse.com/articles/details/4361/
위 url의 동영상같은 걸 해주는 내용입니다.

처음에 UI모듈을 저런식으로 만들어 볼까? 라고 생각했다가 머 이리저리 생각해보니 별로 일것 같아서 신경끄고 있었는데..

오늘 문득 든 생각이...
embed script용 툴을 만들면 괜찮겠다는 생각이 들었습니다.

lua를 쓰면서 임베딩된 상태에서 사용이 많이 불편했던 부분들이

* 브레이크 포인트를 걸거나 Step기능을 쓰기 힘들다.
* 변수값을 실시간으로 확인하기 힘들다.(print문으로 변수값을 출력하게 lua를 바꿔서 reload해서 사용하는 방식으로 사용했지만)
* 편집하고 저장한 뒤에 reload를 호출해줘야 한다.(실제로 개발용 버전에서는 lua파일을 함수콜 할 때마다 다시 로딩되게 해서 사용해서 실제로 reload가 불편하지는 않았지만)
* 보통 vs에서 편집하는데 칼라링이 안된다.(이거야 전용 ide를 사용하면 되긴 하지만 vs와 전환해가며 사용하기는 꽤 불편해서)
* 인텔리 센스가 지원되지 않는다.

뭐 대충 이정도 내용이군요.
사실 bind도 귀찮긴 하지만 이건 툴적인 부분에서 어쩌기는 힘든 내용이니까;(클래스 구조를 파싱해서 bind코드를 자동으로 생성해주는 정도는 가능하겠지만요)

위의 내용중에서 vs addin으로 만들게 되면
다른거는 대충 될 거 같은데 인텔리센스는 힘들겠군요.
visual assist처럼 vs기능을 사용하지 않고 별도로 띄워버리면 가능할 것 같기도 하지만 말입니다;

인텔리센스가 불편해도 addin으로 만들면 메인 프로젝트와 같은 IDE에서 볼 수 있다는 장점이 있죠. 전환하는건 둘째 치고 debuging의 경우는 이쪽 IDE에서 cpp쪽에 걸렸다가 이쪽 IDE에서 스크립트에 디버깅 걸렸다가 하면 디버깅 하기 힘들테니까..

나중에나중에나중에나중에 스크립트를 많이 써야 하는 상황이 되서 위의 기능들없이 개발하기가 너무 힘들어지는 상황이 되면 한번 만들어봐야겠습니다..

흐음.. UI모듈이나 새로 구상해볼까... 하고 생각을 시작했다가 UI모듈의 이벤트 핸들링을 스크립트랑 연동시키는 내용생각하다가 여기까지 왔군요.;;
너무 멀리 왔습니다.. 후우~ -_-)y=~

lua가 별로 맘에 안들어서 다음엔 squirrel이나 써볼까 하고...이것도 살펴보고 있었는데-ㅅ-;
할일이 없으니 이리저리 딴 생각만 하게 되네요ㅎㅎ

'게임개발 > 생각' 카테고리의 다른 글

요즘 구인광고들을 보면..  (12) 2008.02.29
VisualStudio 스프링노트 Addin?  (4) 2008.02.26
SUI  (2) 2006.10.21
ONE OUTS 2권 중..  (4) 2006.10.21
사실은  (4) 2006.10.21
새로운 UI모듈을 만들일 같은건 없을거라고 생각했는데( http://www.larosel.com/69 참고 )..

왠지 슬슬 새 UI모듈을 만들고 싶어졌다.

회사에서 사용하는걸 계속 리펙토링을 할까..도 생각해봤는데..
베이스를 새로 만들고 싶어져서 기존 만들어 놨던것들을 다 뒤집기는 무리가 있다..;

진행은 무척이나 천천히..;; 할 생각이고 하다가 귀찮아질 가능성이 높기 때문에 왠만큼 나와준다는 보장도 없다....;;

먼가 구상문서를 적을곳이 필요한다.. 도메인을 티스토리에 연결시켜버려서 호스팅의 위키를 쓰기도 좀 머하고..
전에 잘못깔아서 새로 깔아야 하는데 그것도 귀찮다.

그렇다고 블로그에 적자니.. 먼가 문서화랑은 안맞고..

흐음....
시작도 안했는데 귀찮아 졌다..;;

'게임개발 > 생각' 카테고리의 다른 글

VisualStudio 스프링노트 Addin?  (4) 2008.02.26
Visual Studio 2008 shell을 보니.  (3) 2008.01.17
ONE OUTS 2권 중..  (4) 2006.10.21
사실은  (4) 2006.10.21
개인적인 욕심  (1) 2006.10.10
- 토야 선수, 어째서 리카온즈가 근 몇 년간 B클래스의 저조한 성적을 보인다고 보십니까? 라는 질문에 대해서

위기감이 없으니까.
다른 녀석들은 오늘도 똥줄 빠지게 연습하고 있는 모양인데,
녀석들은 매일매일 연습을 더 하고 열심히 뛰기만 하면 시합에서 지더라도 용서받을 수 있다고 생각하고 있어.
프로 야구 선수란... 야구를 하는 게 직업이 아냐.
이기는 게 직업이지.

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

최선을 다했다... 라는 말은 함부로 쓰면 안된다.
그 말을 사용하는 순간 자신의 한계가 정해져 버린다.

최선을 다하지 못해서 결과가 안좋은것보다...
최선을 다했는데도 결과가 좋지 않다는 것이 최악이다.

정말 최선을 다했는데도 그렇다면 자신이 그정도 밖에 안되는걸 인정하는 거다.

일하는 시간만 늘려봐야 열심히 했다는 말은 들어도 잘 했다는 말은 듣지 못한다.
끊임없이 생각하고 끊임없이 갈구해야 한다..

자신을 그렇게 싼값에 넘기지 마라.
자신의 한계를 그렇게 쉽게 정하지 마라.
인간이라는건 자신의 한계를 계속해서 뛰어넘을 수 있다.

신은 자신이 감당할 수 있는 시련만 준다고 하지 않는가..
주어진 시련이 아니라 신의 뜻이라고 생각하는 순간 신은 당신을 놓아버린다.

'게임개발 > 생각' 카테고리의 다른 글

Visual Studio 2008 shell을 보니.  (3) 2008.01.17
SUI  (2) 2006.10.21
사실은  (4) 2006.10.21
개인적인 욕심  (1) 2006.10.10
TypeTraits  (0) 2006.05.10
캐릭터, 레벨, 이펙트, GUI
네개 중에 하나만 제대로 하고 싶다..;;

하는게 많다 보니 이것도 별로 저것도 별로..
완성도가 전체적으로 떨어진다..;

엔진 담당이 네명이 있으면 한명이 하나씩 할 수 있을까-_-a;

'게임개발 > 생각' 카테고리의 다른 글

SUI  (2) 2006.10.21
ONE OUTS 2권 중..  (4) 2006.10.21
개인적인 욕심  (1) 2006.10.10
TypeTraits  (0) 2006.05.10
공개 UI모듈  (0) 2006.01.03

프로젝트를 하다보면 프로젝트 자체에 대한 욕심보다는 개인적인 욕심이 들 때가 있다.
물론 내용자체에 프로젝트랑 관련되어 있으니 프로젝트에 대한 욕심이랑 구분짓기는 어렵지만
게임의 재미와는 상관없는 것들...에 대한 얘기다.

내용에 따라서는 게임자체의 재미와도 연관이 있는것들이 있다.
공들여서 만들고 다른게임에서는 볼 수 없는 것들을 보여줘서 새로운 재미를 줄 수도 있지만.
실제 효과는 미미한 내용들이 있다.

예를 들면 이런 내용이 있다고 하자.
채팅을 치는데 중간 중간 색을 넣을 수 있다고 하자.
freetype과  uniscribe로 만들었다면 구현이 쉬울수도 있으나.
dx의 drawtext를 사용하고 있다면 상당히 어려운 내용이다.
가변폰트를 고려해야 하기 때문에(해외의 경우 고정폰트를 못쓰는 경우도 있어서)
추가적으로 복잡한 uniscribe를 작업해야 한다.
게다가 여러번 나눠서 찍어야 하기 때문에 프레임도 떨어진다..;

물론 한글자 한글자 색을 넣을 수 있다는건 꽤 재밌어 보이는 아이디어지만
실용성이 상당히 떨어진다.
어느 유저가 채팅을 하는데 msn같은 채팅 전체 색이면 몰라도 글자별로 색을 넣고 있겠는가.
장사꾼들이 사용할지도 모르겠지만 비용에 비해서 별로 실용성이 없는 내용이다.

이런 내용을 기획자가 요구를 하는 경우도 있고 프로그래머가 개발을 해보고 싶은 욕심이 생기는 경우도 있다.
하지만 게임의 재미에 영향력은 미미하므로 구현이 하루내로 끝날게 아니라면 때려치우는게 낫다
( 사실 하루도 아까운 내용이다 )

머 대표적으로 보면 물표현이 있다.
실시간 리플렉션과 리프랙션, 물그림자가 바닥에 지는거까지 멋지게 구현해봐야
유저는 처음 볼 때 어 멋지네..하고 신경 안쓴다
리프랙션은 사실 별 의미 없고 리플렉션은 하늘과 구름정도만 되면 충분하다.
사실 물그림자 생기는건 해보고 싶다-_-a;;

갑자기 물효과는 만들어 놓고 개발자만 좋아한다는 소니군의 말이 생각난다..;
( 사실 경영진도 좋아한다-_-; )

어쨋건 게임클라이언트쪽보다는 계속 엔진관련일을 하다보니
구현해보고 싶은것들이 줄줄줄줄 쌓여간다.
개인적으로 해보고 싶은것들도 있고 넣으면 꽤 게임이 괜찮아 보이는것들도 있다.
머 프레임이 뚝뚝 떨어질게 아니라면 그래픽팀이나 AD님이 요구하는것들 다 넣고 내가 하고 싶은것도 다 하고 싶다.
왜 안그러겠는가.

하지만 아직 개발기간이 2년도 안되고 엔진프로그래머는 나밖에 없는데 벌써 상용화한지 몇년씩 된 게임들에 있는 내용을 다 집어넣기는 좀 무리가 있다....;;
게다가 경영진 보여주기용 땜빵작업들과 몇번씩 뒤집히는 기획으로 이미 반절도 넘게 날아갔는데..;

이를 악물고 개인적인 욕심은 쓰레기통에 가져다 버리고 다른팀 요청사항은 안돼요~ 아니면 언젠가는 되겠죠~ 메인시스템들 다 잡히고 시간이 나면 해야죠~ ( 시간이 날 리가 있나-_- ) 라고 말하며 버티는 수밖에 없다.

머 대략 두서없는 글이기는 했지만 추가기능 개발해야될것들 정리하다 보니 너무 스펙타클한 항목들이 줄줄줄 나오길래 써봤다.
이 내용들을 다 넣을 수 있는 날이 과연 올까..;

ps. 한참 글쓰다 보니 개그야를 안봤다는게 생각났다..;; 받아서 보는 건 화질 별론데...헤엥~

'게임개발 > 생각' 카테고리의 다른 글

ONE OUTS 2권 중..  (4) 2006.10.21
사실은  (4) 2006.10.21
TypeTraits  (0) 2006.05.10
공개 UI모듈  (0) 2006.01.03
자꾸 IK가 하고 싶어진다-_-;  (0) 2005.12.12

+ Recent posts