게임프로그래머가 되기위해 0~1 본문

Programming/프로그래밍 일반

게임프로그래머가 되기위해 0~1

쩡호 2017. 4. 13. 12:42
0. "노력 해보자! 게임 프로그래머가 되기위해!"를 쓰며.
 
우선 이 글은 Pandora Cube 를 만든 프로그래머 출신 게임 개발자가 졸업하기전, 매번 와서 썰을 풀수 없으니, 후배들에게 남기는 글이다.
 
대학생활을 하며 가장 아쉬운것이 게임에대한 전문적인 팀이 없었다는것, 전문적인 지식을 가르쳐줄만한 사람이 거의 없었다는것이다.
 
첫번째는 내가 팀을 만들어버려서 어느정도 해결했지만, 두번째는 해결하지 못하고 스스로 해보면서 터득했다.
 
노력의 부족과 능력의 한계때문일수도 있겠지만 언제나 막힐때면 물어볼사람이 없어 몇일씩 날을 샌다거나, 어디까지 공부했을때 어느정도의 무언가를 해야 할지 모르는 답답함이란 참 심했다.
 
게임 제작이란 모를수록 고난이 따르기때문에 내가 졸업을 한후에 가르쳐 줄수 없는 나의 후배들은 그런일들이 없었으면 한다라는 작은 소망에서 이런 글을 쓴다.
 
이런글을 쓰는 나도 이런 글을 쓰기 많이 부족하다. 그러나 이 글은 내스스로 공부하는 방법의 하나의 종류였고, 여지것 수많은 후배들을 가르치고 이끌어온 결론이다.
 
물론 이방법이 맞지 않을수도 있고, 시간이 흐르면 내가 썼던 절대적일것같은 것도 바뀔수도 있다. 그것들을 다음 후배들이 열심히 공부해서 바꿔주고 보충해줬으면 한다.
 
한가지 더 당부하자면 이 글을 읽는 후배던 혹은 어떤 사람이던 하나 부탁할것은 프로그래밍이라는건 최대한 많이 부딧쳐 봐야 한다라는거다. 어떤 완벽한 세미나를 듣거나 어떤 강의를 들어도 직접 사용해보지 않거나 사용해보지 않으면 자신의 것이 되지 않는다. 이것만은 확실하다.
 
내가 지금 말하는 방법론에서 직접 코드와 부딧쳐봤으면 하는 부분들은 명시해놓겠다. 처음으로 짜보면 좋을 게임도 명시해놓겠다. 그냥 보고 넘기지말고 시도해보라! 시도가 성공하던, 실패하던 반드시 실력은 뛰어있을것이다.
 
위에서도 말했지만 나의 방법론은 절대적이지 않다. 하지만 참고해줬으면 한다.
 
 
 

1. 게임 프로그래밍이라는것은 어떤것인가?
 
우선 막연히 게임프로그래밍이라고 하면 떠오르는 생각은 무엇인가? 실제로 나는 화면에 그래픽을 찍으면 게임을 만들수 있을꺼라 생각했다. 나의 고등학교 2학년때 최고의 목표는 화면에 PCX 파일을 찍는것이였고, 고3말엽 최고의 목표는 DirectX 를 이용해서 BMP 파일을 찍는것이였다.
 
그것만 하면 게임을 만들수 있을꺼라고 생각했다! 참 리얼 리얼 순진하다.
 
지금 생각해보면 어이없지만 많은 사람들이 그렇게 생각하고 있다. 후배들중 가끔 최대 목표를 그림찍는걸로 잡는 사람도 있고 하다.
 
BMP파일의구조가 이해 안되고 화면에 이미지가 찍히는 구조가 이해가 안되면 그게 가장 어려워보이지만 사실 이미지를 찍고 뭔가 해보려는 순간 스스로 깨닫게 된다. "이게 시작이구나."
 
간단한 상용게임 제작진을 살펴보더라도 엄청난 숫자의 제작인원이 참여했다는것을 알 수 있는데, 간단하게 나눠서 3D 엔진이나 2D 엔진을 가장 상위에 두고, 툴 프로그래밍과 게임 프로그래밍으로 나눠 작업을 하게된다.
 
엔진 프로그래밍에는 실제로 게임의 내부 깊숙한 부분인 물리와 렌더링(화면에 보이는것)을 프로그래밍 하게 된다. 이것을 가지고 툴에 접목시켜 게임 툴을 만들게 되며, 물론 이것을 접목시켜 게임을 만들게된다.
 
이것은 겉으로 보이는 프로그래밍들이고 실제로는 너무 많은 분야가 있다. 물리 프로그래밍, 3D 프로그래밍, 스크립트 프로그래밍, 이펙트 프로그래밍, 네트웍 프로그래밍, 서버 클라이언트프로그래밍, 데이터 베이스 프로그래밍 등등등...
 
실제로 게임 프로그래밍이라는것은 수많은 프로그래밍 기술들의 집합이다. 게임에서는 실존하는 대부분의 프로그래밍 기술을 접목시키게되는 종합 프로그래밍 어플리케이션이라고 할 수 있다.
 
다른 말로하면 게임 프로그래밍은 게임이라는 어플리케이션을 만드는 모든 프로그래머를 게임 프로그래머라고 할 수 있을것이다.
 
이 이야기는 극단적으로 설명하면, 게임 프로그래머라는것은 따로 존재 하지 않는다라는 결론도 나올수 있다. 그렇다면 일반적인 어플리케이션을 제작하는 프로그래머라면 누구나 게임 프로그래머가 될수 있다는 말인가?
 
어떤의미에서는 그렇다고 말할수 있을것이다. 즉 다른 프로그래밍경력이 있는 사람이 게임 쪽에 들어오게되면 재빠르게 게임 프로그래밍을 익힐수 있다.
 
하지만 분명 게임프로그래밍은 다른 프로그래밍하고는 완전히 같지 않다.
 
게임프로그래밍은 다른 여타 프로그래밍 기술이 총 망라하고 또 게임 프로그래밍만의 기술들이 수없이 들어간다.
 
(그리고 당연한것이겠지만 게임프로그래밍을 한사람이라면 다른 어디에서도 손쉽게 적응할수 있으리라 생각한다.)
 
그렇다면 게임 프로그래밍을 하기 위해서 무엇을 해야 할까?
 
각각의 분야들에 대한 설명은 칼럼의 마지막 부분에 하자. 이곳에서는 게임 프로그래머를 지망하는 사람들의 소양정도만 알아보자.
 
아래의 내용들은  나의 사견이라는 것을 전재하겠다. 물론 사견이라고는 하지만 많은 후배들을 만나본 결과 또 나의 예전을 생각해봤을때 나온 결론이기도 하다.
 
첫번째는 게임프로그래머는 아티스트가 아니라는것이다.
 
"프로그래밍은 '아트'다." 이것은 내가 아는 게임 프로그래머에대한 생각중 가장 '멍청한'  생각이다.
 
이것은 기획자도 마찬가지라고 생각한다. 게임에는 예술적 요소가 있다는것은 당연한 사실이니 절대 부정할수 없지만, '게임' = '예술' 이냐라고 묻는다면 그건 위험하다고 생각한다.(이건 논외의 문제이니 다음이회에 썰을 풀어보자)
 
하물며! 프로그래밍은 더더욱 아니다. '아티스트적' 생각은 모두 버려라. 모든것을 '자기 손'(혹은 팀안에서)으로 만들겠다는 말도 안되는 생각도 버려라. 그런 게임이 더 숭고하다는 생각은 그냥 접어라.
 
프로젝트 중이 아니면 자신의 실력배양을 위해 할 수도 있지만, 프로젝트 중에는 자신이 만들수 있어도, 혹은 만들어놨어도, 더 좋은것 혹은 검증되어있는 라이브러리가 있다면 무조건 그것을 쓰라.
 
게임 프로그래머는 무슨 프로그래밍 기계가 아니기 때문에 남들에게서 찾을수 없는 부분만 스스로 해도 힘들고 지치는것이 당연하다.(특히 아마추어 팀은 그것이 배가된다!)
 
더욱이 게임 프로그래머는 게임을 만드는것이 목표인 사람이지, 코드를 만드는 것이 목표인 사람이 아니라는 인식을 반드시 해야 한다.
 
물론 코드가 심도 있어지고, 디자인을 하게되면 직관적인 부분이 필요로 해진다. 그러나 그런 몇가지 부분을 제외하고는 철저하게 공학적인 시점으로 바라봐야 한다.
 
예술적으로 바라보게 되면 예술에서 생기는 객관성의 결여, 시간의 제약등이 그대로 프로그래밍에 적용될수 있다. 절대 프로그래밍에 그런 예술적 관념들이 들어가선 안된다.
 
두번째는 기획에 대한 이해이다.
 
게임 프로그래머가 단순한 프로그래밍에 대한 지식만을 가지고 있으면 작업이 안되는 경우가 많이 있다. 물론 옆에 완벽한 기획자가 있고, 자신은 아무 생각도 안하고 시키는것만 할것이라면 기획에대한 이해나 소양 따위 없어도 된다. 그렇지만 그렇지 않고서는 반드시 기획에대한 이해가 있어야한다.
 
게임 제작의 전반에 대해서 적극적인 의견을 내고, 그 의견들을 수렴해서 기획자가 기획을 할수있도록 도와주는것은 좋은 게임을 만들수 있는 초석이된다.
 
또 기획자가 완벽한 데이터를 넘겨주지 못했을때 그것을 지적해주거나 기획자의 작업 초기부터 그런것들을 요구하는 노련함은 게임 제작에 딜레이를 줄이고 쓸대 없는곳에 정력낭비를 줄일수 있다.(작업늦어진게 누구책임이니 따위의 논쟁)
 
세번째는 궁극적으로는 기획자의 의견에 따라야 한다는것이다.
 
자신의 의견이 맞다고 생각하면 기획자를 설득시켜야 하겠지만 설득시킬수 없다면(혹은 왠지 아닌것 같지만 기획자의 논리가 더 앞선다면) 반드시 기획자의 의견에 따라야 한다. 특히 기획자에 의견이 A인데 이 A' 방법으로 하면 프로그래머가 더 편할것 같다는 논리로 A' 의 방법으로 관철시켜서는 안된다.
 
단지 프로그래밍을 하게되면 A' 와 A 의 차이가 어떤것인지(얼마나 더 힘든지에대해서) 명확하게 이야기해주고, 작업의 딜레이가 얼마나 걸릴지 등에대해서 이야기해주는 것에대해서는 정확하게 해줘야 한다.
 
만약 기획자나 총제작자의 뜻을 어기고 스스로 무언가 하려고 한다면 배는 산으로 가고 프로젝트는 실패한다.
 
네번째는 프로젝트중이 아닐경우 항상 널리 널리 퍼져있는 라이브러리들이나 소스들에대해서 분석하는 자세가 필요하다.
 
누군가가 만들어놓은 어떤 라이브러리나 소스코드를 단순하게 가져다가 쓰는것뿐아니라, 반드시 여유시간에 자신의 것으로 만들어야 한다. 그렇지 않으면 새로운 무언가가 나왔을때 그것에 쉽게 적응할수 있다.
 
더욱이 자기 스스로 구현해볼수 있는것은 구현해보도록 노력하는것이 좋다. 그런식으로의 구현은 자신이 쓰는 언어뿐 아니라 다른 언어의 내부구조를 정확하게 알수 있게 해주는 힘이 있다.
 
마지막으로는 책임감이 강해야 한다.
 
다른 어떤 프로그래밍을 하는 사람들도 다 마찬가지이겠지만, 책임감은 이곳에서도 막중하다. 특히 프로그래밍에서만 수없이 나누어지는 파트는 아무리 객체지향 프로그래밍을 한다고해도 한쪽이 늦어지만 다른쪽도 딜레이가 걸릴수 밖에 없고, 그렇게 되면 다른 프로젝트 팀원들이 지치게된다.
 
더욱이 그래픽 디자이너와 기획자까지 같이 하는 게임 프로그래밍은 더욱더 심하다. 계속 오더를 지키지 못하면 서로가 서로에게 신뢰를 잃고 말고 서로가 서로에게 지쳐버린다.
 
그런 문제들 때문에 프로젝트에 대한 기한은 반드시 지켜내려고 노력해야 하며, 또 지키지 못했다고 하더라도 최소한 신뢰를 잃지 않기 위해 자신이 열심히 했지만 실패 한것이라는 것을 보여줘야 한다.

이 정도가 내가 생각하는 게임 프로그래머가 되기 위한 소양이라고 생각한다. 물론 어쩌면 이 내용들은 세번째만 빼면 일반론 적이다.  하지만 게임도 어플리케이션의 일종이라고 생각한다면 너무나도 당연한 것이다.
 
다음 이야기는 2. 게임 프로그래밍을 하기위한 첫걸음 C 언어. 에대한 이야기를 할 예정이다.
Comments