게임 프로그래머

게임 프로그래머는 프로그래밍을 통해 맵 디자인, 캐릭터 디자인, 사운드, 각종 시스템 등을 뒤섞어, 게임이라는 하나의 결과물을 만드는 직군이다. 게임을 만드는 데 있어 가장 귀중한 인력이다. 실제로도 게임 업계에서 프로그래머의 연봉이 기획자나 그래픽 디자이너보다 높은 경우가 많다.

2. 유형

수십, 수백명의 개발자들이 필요한 AAA 게임들은 다양한 분야의 전문가들을 필요로 한다. 아직도 수많은 사람들이 게임 프로그래밍의 대해서 착각하는 것 중 하나인데, 같은 게임 프로그래머라고 해도 전문 분야가 다르면 필요한 지식, 경력, 성격, 등등이 완벽하게 달라진다.

게임플레이 프로그래머 (Gameplay Programmer)

이쪽은 만능형 프로그래머 (Generalist Programmer)가 많다. 간단한 설명은 다른 프로그래머들은 게임 엔진 쪽으로 더 가깝고 게임플레이는 말 그대로 "유저들이 게임이라고 느끼는" 부분. 카운터 스트라이크를 예로 들면 플레이어의 움직임, 총기의 작동 원리, 폭탄이 폭파하면 테러리스트가 승리한다는 규칙 등이 다 게임플레이다. 게임을 사랑해서 게임 프로그래머가 됐다면 웬만하면 이쪽으로 간다.
게임 규모가 작으면 난이도가 다른 분야보다 낮다. 수학의 경우 방향 관련 계산을 하기 위한 선형대수학의 기초만 대충 알면 괜찮다. 하지만 게임 규모가 커지면 접하게 되는 코드의 분야가 너무 넓어지기 때문에 다른 분야보다 쉽지 않다. 이러면 전혀 모르는 분야라도 대충 공부해서 대강 이해를 할줄 알아야 한다. 그러려면 '컴퓨터 게임'을 이해를 하고 사랑을 해야만 일이 된다. AAA 규모쯤 가보면 어느 날은 NPC의 비행 능력을 위해서 팔진트리로 3D 최단 경로 찾기 알고리즘을 공부하고, 그 다음 날은 두명의 플레이어 캐릭터들의 잡기 공격을 어떻게 코딩해야 렉이 있는 상태에서 두명이 동일한 상황을 보게 만드나[1] 생각해야 한다. 결론은 특정 분야에 많은 지식이 필요하지는 않지만, 프로그래머로서의 눈치랑 해석력이 많이 요구된다.

물리 엔진 프로그래머 (Physics Programmer)

게임에 필요한 물리 계산을 빠르게, "필요한 만큼 정확하게[2]" 하는 개발을 한다. 프로그래머 항목에 프로그래머들은 거창한 알고리즘 연구를 안한다고 하지만, 이쪽은 그런 짓을 할만한 인간들이 필요하다. 유저들은 매년 상향되는 그래픽, 물리 엔진을 보고 싶어하고, 만족할만한 게임을 만들기 위해서 더 새로운 그래픽 기술들의 효율적인 계산이 필요하다. 그래서 이쪽은 컴공보다 물리학자, 수학자들이 더 많이 보인다. 수학의 경우 사원수, 오일러 각 등의 3D 수학을 기초로 알아야 인턴쉽이 잡힌다.

그래픽 / 렌더링 프로그래머 (Graphics / Rendering Programmer)

3D 그래픽이나 애니메이션을 빠르게 계산하고, 효율적으로 유저의 모니터로 출력하는 개발을 한다. 위와 비슷하게 순수한 프로그래밍보다 수학, 물리쪽 지식을 더 많이 필요로 한다. 위와 비슷하게 비쥬얼적으로 나쁘지 않다라고 생각될정도면 계산을 단순화하거나 수학적인 알고리즘으로 최적화를 한다.[3] 난이도가 높아질 수록 최소 수학과 또는 물리학과 3~4학년 수준 지식을 요구하기도 한다. 인터넷에 친절하게 알려주는 기법도 왕왕 있지만 최신기술을 사용하거나, 최신기술이라고 보긴 힘들지만 구현 난이도가 상당히 높은 축에 해당하는 기술, 또는 색다른 느낌의 비실사주의 쉐이더의 최신기법을 구현하고자 할려면 인터넷 검색으로는 답이 없다. 영어로 된 논문과 인용된 논문을 읽어가며 그 논문에서 말하고자 하는 수학 물리공식을 이해하고 그것을 프로그래밍적으로 구현할 줄 알아야 한다. 정말 독특하고 유니크한 것은 논문으로도 발표된 사례가 없어 바닥부터 직접 만드는 경우가 왕왕 존재한다. 수학이 싫거나 자신이 없다면 가장 멀리해야 하는 분야. 그런고로, 여기 나열 된 분야중에, 독보적으로 난이도가 높으며, 그에 비례해 대우가 좋다. 규모가 작은 곳에서는 상용 엔진을 쓰기 때문에 비주얼 셰이더 툴을 이용해 적당히 셰이더 만들어서 쓰는 경우가 많아 이 포지션이 없는 경우도 많다. 다만 AAA급으로 가면 반드시 필요하며, 제대로만 하면 여기저기서 모셔가려고 용을 쓴다. 유독 이 분야의 사람들이 다른 포지션의 일을 겸하는 경우가 많은데, 그 만큼 다른 기술의 밑바탕이 확실해야 할 수 있는 분야라는 뜻.

개발 도구 프로그래머 (Tools Programmer)

"게임" 개발에서는 동떨어져 있는 직무로, 대규모 회사 아니면 절대 못 볼 직무이다. 대부분 프로그래머가 아닌 개발자들이 프로그래머들의 도움이 없이 개발에 참여를 하게 해주는 도구들을 개발한다. 아티스트 직군을 위한 배치 툴을 짜기도 한다. 그게 아니면 엔진을 뜯어고치는 경우도 있다. 무엇이 되건간, 비 프로그래머 직군과의 융화를 보다 윤택하기 위한 목적이 있다. 게임 디자이너들이 아주 기초적인 코딩 실력으로 게임을 완벽하게 바꿀수 있게 하는게 주 목적이다. 회사 규모가 더 크면 게임이랑 전혀 관련 없는 직원, 빌드 관리 소프트웨어도 만들게 된다. 이 정도까지 되면 상당히 고수준의 프로그래밍 지식이 필요한 경우.

네트워크 프로그래머 (Network Programmer)

온라인 게이밍의 핵심이라고 볼수 있다. 클라이언트와 서버와의 데이터 송수신을 다루고, 렉을 줄이기 위해서 최소한의 정보를 보낼 방법과, 심한 렉, 서버 다운, DDoS 공격 등의 문제를 해결할 방법을 연구한다. 데이터 사용량을 줄이는 동시에 클라이언트의 시점에서 렉이 안보여야 하는데, 잘못된 디자인은 0.1초의 렉으로도 유저와 유저 밖의 세상이 따로 노는 느낌을 줄 수 있다. 한국사람으로서 상상하기 어려울수도 있겠지만 세계의 평균 인터넷 속도는 낮은 편이고, 구형 모뎀 인터넷으로 지구 반대쪽에 있는 서버를 통해서 게임을 해야 할 사람도 있으니, 세계적인 온라인 게임을 만들기 위해서는 1바이트의 추가 데이터도 신중히 다뤄야 한다.

그 외에 인공지능, UI, 사운드 프로그래머가 있다.
위처럼 한 분야를 깊게 파고든 프로그래머를 '''스폐셜 리스트'''라고 부르며, 스폐셜 리스트만큼 깊게는 아니라도 다양한 분야를 손댄 프로그래머를 '''제너럴 리스트'''라고 부른다. 2013년쯤부터 IT업계에서는 커뮤니케이션과 작업의 효율을 위해 스폐셜 리스트보다 제너렐 리스트를 선호하는 편.

3. 게임 프로그래밍의 특징

3.1. 게임 엔진 사용 현황

2000년대까지는 스마트폰이 대중화되기 이전인데다 상용 게임 엔진에 대한 진입 장벽이 남아 있었기 때문에 자체 게임 엔진을 사용하는 곳이 제법 많았으나, 2010년 스마트폰 대중화 이후로 유니티 엔진의 낮은 진입 장벽 덕분에 모바일 플랫폼을 장악하고 대동단결하기 시작하더니, 2015년 언리얼 엔진과 유니티 엔진의 조건부 무료 정책이 발표된 이후로 모바일 플랫폼이든 PC 플랫폼이든 상용 게임 엔진 사용이 아예 기본이 되었다.
이는 상용 게임 엔진들의 거듭 발전됨에 따라, 프로그래밍 할 줄 모르는 타 분야의 게임 개발자들도 어느 정도 사용할 수 있을 만큼 편의성 면에서 진입 장벽이 크게 낮아졌기 때문이다. 편의성 뿐만 아니라 개인 한정으로 무료로 사용할 수 있는 상용 게임 엔진들이 많아져서 1인 개발자들에게도 비용과 시간을 크게 줄일 수 있는 여건이 마련된 파격적인 가격 정책이 결정적이었다.

3.2. 프로그래밍 언어

프로그래밍 언어로써는 최적화가 중요한 대규모 고사양 게임의 경우 C++가 아직도 주류로 쓰인다. 생산성은 비교적 떨어지지만, 성능과 객체지향을 동시에 잡은 언어로서는 이만한 게 없기 때문이다. 그 외에 게임플레이 로직 등을 빠르게 변경하기 위해 [Lua], [Python] 등의 스크립트 언어도 사이드로 사용하는 경우가 있다. (예: 이브 온라인이나 심즈 등은 파이썬을 일부 사용) 이때 스크립트 코드 변경은 게임 기획자가 맡기도 한다. 안드로이드 개발은 kotlin을 이용하고 있다.
로우 레벨이거나 근접한 언어의 중수 ~ 고수가 되면 다른 언어로 갈아타는 것은 어렵지 않다. 특히 C 계열 언어들은 다 그게 그거다! 실제로 회사 환경에서도 새로운 언어의 사용이 필요하면 관련된 책 하나만 던져주고 1주일 내로 일하기를 기대한다.

3.3. 라이브러리

프로그래밍 언어 이외에 그래픽 라이브러리에 대한 이해도 필요하다. 보통 많은 기능을 제공해주고 품질이 높은 DirectX나 OpenGL를 사용해서 만든다. 옛날에는 이런 것 없이 하기도 하였는데 이는 성능이 매우 떨어지는 과정이었다. 당장 Windows API 과정에서는 이 둘 없이 게임을 만들어야 한다. 라이브러리 쓰는 것과 비교해보면 퍼포먼스가 상당히 많이 떨어진다.
또한 요즘은 2D 게임도 3D 게임을 기반으로 만들기 때문에 3D에 대한 지식이 필수다. 이미지를 합치는 방식이나 라이트맵핑 등이 있다. 자료구조와 알고리즘의 로직은 한번씩 구현해보는 것이 좋다. 만들어 본 것과 알기만 하는 것의 차이는 크며, STL과 Boost를 쓴다고 해도 예외는 아니다.

3.4. 네트워크

네트워크 연동이 필수인 온라인 게임 쪽에서는 크게 클라이언트와 서버로 나뉜다. 클라이언트나 서버나 괜찮은 실력을 가진 사람은 언제나 구하기 힘들다.

3.5. 멀티코어 및 멀티스레드

멀티코어 프로세싱 및 멀티스레딩의 경우, 플레이어들은 성능 향상을 위해서 원하고 있지만 보통의 게임 프로그래머는 게임 개발 과정에서 활용하고 싶어하지 않는다. 그 이유는 단적으로 말하면, 너무 어렵고 귀찮은 일이 더 많아지기 때문.
게임에서는 멀티코어 프로세싱 및 멀티스레딩을[4] 세간에 알려지는 것과는 다르게 잘 쓰지 않는다. 왜냐하면 프로그래머 입장에서 득보다 실이 많기 때문이다. 데드락, 레이스 컨디션, 코드 이해의 어려움 등 각종 문제가 있는데 반해 성능의 상승은 제대로 처리했을 경우 병렬 처리를 적용한 부분에서 평균 5~8% 정도만 향상된다.
어렵게 구현하더라도 렌더링 퍼포먼스는 코어 하나의 퍼포먼스를 넘을 수 없다. 왜냐하면 렌더링은 코어 하나만이 하기 때문이다. 아무리 화면을 빨리 그려도 코어 하나의 성능 이상은 나올 수 없다. 따라서 대부분의 프로그래머들은 멀티코어 프로세싱 및 멀티스레딩을 지원하지 않는 것을 선호한다. 이 경우 렌더링을 몇 프레임 덜 하더라도 위에서 발생할 문제들이 대폭 줄기 때문이다. 렌더링 횟수 기준을 보통 1초에 60번을 기준으로 삼는데 컴퓨터 성능에 따라서 더 많은 횟수가 나온다. 프레임을 약간 희생하기만 하면 위의 문제들이 해결되어 수월한 개발, 시간 절약, 인건비 절약, 개발자들 스트레스 감소 등의 다양한 장점이 생긴다. 초당 60프레임을 48프레임으로 낮춰도 사람 눈으로 구분하기도 힘들고 프레임이 끊겨서 게임 못할 정도도 아니기 때문에 자주 이용되는 방법이다.
렌더링을 여러 '''잡''' 또는 '''태스크'''으로 쪼개 여러 코어 혹은 스레드에서 처리하게 하는 기술인 태스크 시스템은 이미 오래전에 개발되었다. 다만 구현이 복잡하고, 이를 잘 다룰 수 있는 프로그래머가 적어 몸값이 비싸다. 게다가 게임 루프에는 렌더링만 존재하는 것이 아니다. 사용자 입력 처리, 객체 업데이트, 애니메이션, 물리, 사운드에 AI까지 모두 처리해야 한다. 게임에 따라 렌더링이 전체 게임루프에서 1/4이하의 자원만 소모하는 경우도 있다. 렌더링만 다른 스레드에 할당해도 엄청난 성능향상을 이룰 수 있다.
1번 스레드에서 나머지 모든 것을 처리하는 동안 2번 스레드는 이전 루프에서 1번 스레드가 처리한 데이터를 기반으로 렌더링을 진행하고, 모든 스레드에서 작업이 끝나면 버퍼를 교환해 완성된 이미지를 보여준다. 그 뒤로는 계속 반복 이 가장 간단한 멀티코어 프로세싱 및 멀티스레딩 게임 루프의 기본이다. 물론 실제 구현은 말처럼 간단하지 않다.
그리고 모든 게임들의 게임 루프가 모두 태스크 시스템을 이용한 병렬 처리로만 구현할 수 있는 것도 아니고, 때로는 스레드끼리 서로 통신하면서 모두 똑같은 일을 동시에 동작하는 병렬 처리가 아닌 서로 다른 일들을 동시에 동작하는 병행 처리로 구현해야 할 때도 있으며, 안정성을 위해 부득이 각 스레드마다 스레드 하나씩 컨텍스트 스위칭을 통해 퍼포먼스를 희생해서라도 시분할 단위로 번갈아가면서 처리하는 임시 멀티스레딩(Temporal Multithreading)[5][6] 방식으로 구현해야 할 수도 있다. 게임 자체가 가지고 있는 이러한 복잡성 때문에 게임의 모든 구간에서 100% 병렬 + 병행 처리 구현이 어렵다는 것.

3.6. 상용 게임 엔진

현세대 게임 개발 트렌드는 2015년에 발표된 언리얼 엔진과 유니티 엔진의 파격적인 가격 정책으로 인한 폭발적인 사용자 증가의 연장선인데, 이미 자체 개발 엔진보단 상용 게임 엔진 사용이 대세가 된 것도 모자라서 유니티, 언리얼 엔진 외의 수단으로 개발하는 업체는 2010년대 후반에 들어서 거의 없어졌다.[7] 각각의 게임 엔진은 정해 놓은 룰이 있다. 엔진의 규칙(포맷)이 있는데 이에 맞추어서 게임을 만들어야 한다.[8] 따라서 엔진을 잘 골라서 배워야 한다.
유니티는 C\#을 사용하고 언리얼 엔진은 C++를 사용한다. 하지만 유니티도 C#을 스크립팅용으로 사용될 뿐, 내부는 전부 C++ 혹은 그보다 더 한 로우 레벨 언어로 이루어져 있다. 최근엔 개발 기간 단축을 위해 유니티를 쓰는 경우도 잦지만 언리얼 엔진보다 여러모로 부족하다. 그리고 게임 엔진을 사용하더라도 로직을 짜는 실력 정도는 갖추고 있어야 한다.
중규모 이상의 온라인 게임을 개발하는 업체에서는 대부분 C++ 기반의 언리얼 엔진 3나 언리얼 엔진 4를 사용한다. 이런 회사는 고정 유저를 확보하고 안정적으로 수익을 내는 타이틀을 가진 회사이므로 안정적으로 경력도 쌓고 실력도 쌓으며 일할 수 있는 좋은 회사다. 그런 회사는 유니티만 다룰 수 있는 사람은 선호하지 않는다.
유니티만 배웠다면 현재로써는 모바일 게임 회사 밖에 갈 수 없다. 유니티 엔진 기반의 PC 플랫폼 게임이 언리얼 엔진 기반 게임에 비해 영향력이 크지 않기 때문. 그걸 원하지 않는다면 취미인 유니티보다 직업으로서의 언리얼 엔진을 우선시하길 바란다. 안정적인 회사 다니면서 유니티로 아이디어 게임 만들어서 대박이 나면 나와서 회사를 차리는 케이스가 종종 있긴 하지만 처음부터 유니티로 시작한다면 좀 어렵고 힘든 길을 걷게 될 것이다.
학원 중에는 유행하는 엔진 갖고 잠시 만져보는 수준 정도로 교육해주는 학원이 많은데 이는 실력 향상에 도움이 별로 안된다. 요즘으로 치면 유니티만 가르쳐준다.
왜 유니티만 알고 있으면 모바일 게임 회사밖에 갈 수 없는가? 유니티로 대규모 게임을 만들지 않는건 플랫폼의 문제다. 유니티가 멀티플랫폼에 굉장히 뛰어난 대신 퍼포먼스를 희생했기 때문에 모바일 등에 매우 적합한 인터페이스를 가지고 있어 죄다 모바일은 유니티로 만들고 있다. 대형 게임은 언리얼 엔진이 훨씬 유리하기 때문에 유니티를 안 쓴다.
유니티의 경우는 무조건 스테이지 시작전에 미리 로딩을 끝마쳐야 한다. 그런데 중규모 이상의 온라인 게임들은 카메라를 자유 자재로 움직여야 하거나, 시점이 1인칭에서 3인칭으로 변경이 자주 된다거나, 스킬 트리가 복잡하고 사용되는 이펙트들도 무거워서 미리미리 로딩을 해야 하다가도 실시간으로 로딩을 해야 하는 등 게임 내의 메모리 관리를 캐릭터의 특성에 따라서 맘대로 했다 안했다가 하는 유연성이 필요한데 유니티는 그것이 상대적으로 부족하다. 메모리 관리를 유연하게 할 수 없기에 유니티로는 중규모, 대규모 MMORPG를 잘 만들지 않는다. 존(zone) 이동을 예를 들면 이동할 것을 대비하여 지금 보이는 존 주위의 존을 메모리에 올려 놓아야 하는데, 이걸 실시간으로 할 수 없다. 유니티가 지원하지 않는다. 유니티는 무조건 씬 단위로만 게임을 구성해야 한다. 중규모, 대규모 MMORPG는 씬 단위로 구성되지 않는 게임이라서 엔진 특성 자체가 안 맞는 것이다.
그나마 다행인 점은 유연성 문제가 2015년에 발표된 유니티 5에 이르면서 대부분 해결되고 오히려 견고하고 안정되어 언리얼 엔진 4에 필적하는 우수한 엔진이 되어 이제는 엔진 숙련도의 문제이지 엔진 퍼포먼스의 문제가 아닌 단계로 발전되었다는 것이지만, 아직까지는 중~대규모 MMORPG 개발로 잘 활용되지 않는 편이다.

3.7. 기타

컴퓨터 공학

얕은 정도의 공학적 지식이 필요하며, 운영체제에 대한 이해를 포함한다. 기초가 되는 부분이며 가장 중요하다. 이것은 디버깅할 때 많은 도움이 된다.

수학

고등학교 수준 이상이 필요하다. 3D 그래픽은 선형대수학과 미적분을 기반으로 하여 정의되고, 통계학과 유한 상태 기계(Finite State Machine)의 개념이 없으면 내부 로직을 짤 때 애로사항이 꽃피게 된다.

영어

프로그램 코드에 영어가 사용되는 만큼 읽기, 쓰기 능력이 필요하다. 머리에 설계된 구조를 영어로 풀어서 전개하는 것이 프로그래밍이다. 영어가 안 되는 양산형 프로그래머(코더 혹은 코드몽키)는 로직에 적합한 단어나 문장을 쓰지 못하고 단순한 약자나 관련이 없는 단어로 코딩을 하는 경우가 많은데, 이 경우 취직 자체가 어렵다. 코더는 코딩을 할 때 어휘가 부족해 다른 사람들이 읽기가 어려운, 자신만이 이해할 수 있는 어휘를 사용한다. 이런 사람들과는 함께 일하기 어렵다. 프로그래밍 담당 인원이 혼자가 아닌 이상 다른 인원들과 협업으로 완성하는 것이라서 모든 인원들이 같은 의미로 이해할 수 있도록 일종의 규칙에 적응하기 어려울 수 있기 때문이다. 게다가 깊이가 있거나 디테일한 업무를 진행하기 위한 참고자료는 대부분 영어로 되어 있다. 이런 메뉴얼을 해석해서 얼추 이해할 수준이 되어야 고급 업무를 진행할 수 있다.

4. 되는 방법

동인 인디게임, 모바일 중소 개발사, 대형 게임 개발사 중 어느 쪽을 원하는지에 따라 다르다.

4.1. 대형 게임 개발사

알고리즘, 자료구조 중심의 코딩 테스트 준비해서 취업/SW와 똑같이 준비하면 된다. 컴퓨터공학적 지식을 쌓기 위해서는 컴퓨터공학과가 다른 어떤 학과보다도 유리하다.
수학능력시험 성적이 중위권 이상이면 컴퓨터 공학과를 가는게 낫다. 게임 프로그래밍에 필요한 수학적인 지식은 1, 2학년때 배우게 된다. 선형대수학, 미적분학, 통계학을 배우기 때문에 게임학과와는 달리 수학적인 지식에서 훨씬 강세를 보인다. 프로그래밍쪽 학습은 일단 Java와 C언어를 기본적으로 습득한 후, 알고리즘 구조, 파일 입출력 같은 시스템 프로그래밍을 게임학과에 비해 훨씬 심화적이고 어려운 레벨까지 접근하기 때문에 배우는 학생들에게는 지옥이지만 오히려 나중에는 그것이 득으로 다가오게 된다.
고학년으로 올라가면 필수과목이건 선택과목으로건 수리 알고리즘 시뮬레이션 같은 선형대수적인 문제에 대해서 프로그래밍으로 구현하는 능력을 배우게 되며 이는 1, 2학년때 단지 수학적인 접근에서만 배웠던 수학을 프로그래밍 적인 시야에서 접근하는 방법을 배우게 된다.
다중 접속 온라인 게임 서버 [9] 개발 같은 건 학원이나 독학으로 배우기 극히 어렵다. 그런 면에서도 컴공이 낫다.
게임 회사의 채용 전형은 상시채용과 공채로 나뉜다. 회사별로 공채 시기는 다르지만, 보통 1년에 1~2회 정해진 기간에 공고가 나간다. 전형 단계는 보통 서류→필기→기술면접→인성면접의 순으로 가게 되는데. 이 부분은 일반적인 회사와 크게 다르지 않다. 상시 채용은 대부분 회사에서 진행하며, 입사지원서를 보내면 검토 후, 회사에 따라 필기, 면접 전형을 보게 하여 채용한다. 다만, 상시채용은 거의 포트폴리오를 요구하기 때문에 실력적인 부분을 더 많이 요구하는 전형이라고 할 수 있다.

4.2. 중소 모바일 게임 개발사

유니티 엔진과 안드로이드/iOS 프로그래밍에 대해 잘 알고 있고 실제 제작 게임이 있는 게 유리하다. 대기업처럼 코딩 테스트를 보지는 않는다.
모바일 게임 회사는 아주 큰 규모의 회사면 몰라도 중소규모의 회사는 망하기도 쉽고 사업 철수도 쉽게 하기 때문에 어느 순간 실업자가 되는 경우가 비일비재하다. 그런 회사에 모바일 팀이 있더라도 마찬가지로 수익이 안 난다는 이유로 얼마든지 팀을 해체할 수 있다. 유니티를 배워서 모바일 회사에 다니다가 회사가 망해서 짤리고 다른 회사를 갔는데 월급이 밀리고 그래서 다른데 갔더니 거기는 사업을 접고... 여기 저기 모바일 회사만 전전하고 싶지 않는 것이 대다수의 바람이다.

4.3. 인디 게임 개발자가 되고 싶은 경우

성공하면 '''인생이 달라질 만큼 좋다.''' 성공한 케이스가 몇 명 있다! 하지만 대부분은 성공을 못 하고, 성공을 못 하는 기간이 길어지면 매우 어렵고 힘든 길이 된다. 아이디어는 있지만 구현할 실력이 안 된다면 아예 시작도 하지 않는 것이 좋다.
자신이 생각하는 게임을 구현할 수 있는 실력이 있는 사람이어야 도전할 만 하다. 물론 아주 반짝이는 아이디어로 빠르게 만들어서 잘 될 수도 있지만 그런 경우는 정말 희박하다.
팀을 만들어서 하는 것도 힘들고 혼자서 하는 것은 더더욱 힘들다. 팀을 만들면 의견 조율이 잘 되지 않으며, 금전적인 문제와 이권다툼이 생길 가능성 또한 있다. 개발기간이 길어지면 길어질 수록 팀원들의 사정 때문에 그만두거나 와해되는 경우가 비일비재하고, 혼자 하면 모든 것을 혼자 다 감당해야 하는데 기획은 그냥 머릿속으로 해도 프로그래머는 그래픽이, 그래퍼는 프로그램으로 구현이 문제다. 어찌어찌 게임을 만들었다 치자. 돈을 못벌면 팀원들이 그런 사정을 감안해서 얼마나 참아 줄까? 팀원들도 경제적으로 힘들다고 회사를 다시 가야겠다고 빠지면 구멍난 인력을 자리를 대신해줄 인력을 과연 쉽게 구할 수 있을까? 인디게임을 팀으로 만들었다면 팀원 자체가 몇 명 안되고 한 자리라도 구멍이 나면 내가 메꾸지 않는 이상 그 파트 일은 올 스톱이 된다. 인디게임은 만들기도 힘들지만 성공하기란 더 힘들다.
거기다 작품성보다 운이 더 중요하다는게 업계의 통설이기 때문에 아무리 게임을 잘 만들었어도 운이 따라주질 못하면 범람하는 게임들 속에 그대로 묻힐 가능성이 높다. 예를 들어 대학생들이 모여 만든 인디 게임인 던그리드는 그다지 특출날 것 없는 게임이라는 평가를 받지만 몇 없는 국산 인디 게임이라는 버프를 받고 스트리머들이 적극 홍보를 해줘서 대박을 터트릴 수 있었다. 그러니 운과 함께 마케팅 능력과 타이밍을 볼 줄 아는 사업가적 능력도 필요한다.
인디 게임 만들다가 대기업에 취업하는 경우도 많다.

4.3.1. 홀로 서기

혼자 하기는 매우 힘들다. 최근에는 게임 엔진들이 매우 다양한 기능과 높은 직관성을 갖추고 있기에 프로그래밍 자체는 그럭저럭 수월하지만, 평범한 개발자가 그래픽, 사운드 관련 소양까지 갖춘 경우는 매우 드물기 때문에 이는 어쩔 수 없이 외주를 통해 진행하게 될 것이다.
물론 완전한 1인 개발이 아주 불가능한 것은 아니다. 미국이나 유럽 등지에서도 심심찮게 혼자 만든 게임들이 틈틈히 출시되고 있다. 그리고 개중엔 정발도 안 한 한국에서도 유명할만큼 인지도 높은 명작들도 많다. Dust: An Elysian Tail, 지오메트리 대시, 언턴드 [10]등이 대표적이다. 마인크래프트는 이 분야에서 가장 성공한 케이스라 볼 수 있다. [11]
북미나 유럽의 경우 물론 여긴 저작권에 빡세서 일본처럼 남의 아이디어를 갖다 쓰는게 불가능한 문제가 있는 등 여건이 널널하지만은 않지만, 자기 회사 일 하면서 취미로 틈틈이 만드는 겸업 프로그래머도 있을 만큼 생활에 여유가 많은 경우가 대부분이라 나쁘지 않다. 심지어는 그냥 전업으로 게임 개발에 전념하는 개인들도 많다.
다만 한국에서 1인 게임 개발자로 살아가는데 있어선 사회적인 인식과 제도적인 어려움도 뒤따른다는 점을 감안해야 한다. 위에 적은 예시로 든 게임들은 대략 3년여 정도 걸렸는데, 한국에서 3년 씩이나 혼자 게임 개발한다고 하면 곱게 볼 사람은 거의 없을 것이다. 그렇다고 북미처럼 회사를 다니면서 틈틈이 하기엔 월화수목금금금의 압박이... 게다가 어떻게 만들어도 그 다음엔 게등위의 심사를 거쳐야 하는데 심사비의 압박이 덮쳐오고, 그것도 다 통과해 어찌어찌 내놓아도 복돌이 문제도 있어서 인디개발자의 앞날은 어둡다.
프로그래머는 지속적으로 배우고 피드백 받고 연구하면서 문제를 해결하고 자신만의 노하우를 축적하면서 실력이 향상된다. 그런데 1인 개발은 팀작업을 할 수 없고 프로그래밍적인 테크닉과 스킬을 익히고 단련할 기회가 없다. 자신의 코드를 평가받고 수정해 나가면서 좀 더 깊이있는 코드를 설계하고 작성할 수 있는데 그게 안 되다보니 몇 년을 해도 실력은 늘지 않는다. 실력이 늘지 않으니 게임회사 취업도 매우 힘들게 된다. 다른 파트와는 달리 프로그래밍 파트는 기술면접이 상당한 비중이 있으며 설령 취업을 했다고 하더라도 수습기간에 역량 부족으로 퇴출되는 경우도 비일비재 하다. 게임 프로그래밍은 기획이나 아트와는 달리 역량이 안 되면 팀 전체의 작업에 크나큰 문제를 일으킬 수 있기 때문에 대단히 까다로운 업무 프로세스를 가지고 있다.
오직 혼자서 완성도 높은 게임을 만들어 성공한 대표적인 예로 스타듀 벨리가 있다. 또한 발디의 수학교실처럼 오히려 작정하고 저퀄리티로 만들어 유명해진 게임도 있다.
일본은 혼자 만들었다는 동인 게임이 수두룩하다. 뱅가드 프린세스 등이 그 예이다. 다만 주의해야 할 점은 일본계 동인 게임들은 그 배경의 특수성, 그러니까 대부분 기존에 존재하는 창작물들의 아이디어를 그대로 가져다 쓴(냉정히 말해 무단도용한) 2차 창작물들이 대부분인데 어지간하면 원작자들이 그걸로 돈을 벌어도 '동인이니까' 하며 넘어가주는 환경이 조성되어 있어서 가능하다는 점을 유념할 필요가 있다. 즉 기존에 있던 아이디어들을 그냥 그대로 가져다 썼기 때문에 아이디어 구상, 홍보 전략 구상 등 몇몇 면에서 시간과 예산을 절약하는게 가능했기에 혼자서도 충분히 만들 수 있었고 또 코믹 마켓 같은 안정적인 판매처가 존재해서 그걸로 수익을 벌 수 있으니 존속이 가능한 케이스이다.

4.3.2. 동업하기

팀을 짜는 것은 쉬운 일이 아니다. 인디 게임을 실제로 출시할 수 있을 때까지 장기적으로 함께 할 수 있는 실력있는 사람을 구해야 한다. 나와 함께 하면 이 게임이 성공할 것이라는 믿음을 상대방이 가져야 한다. 즉, 나를 매우 실력있는 사람으로 보고 있고 인간적으로 무척 신뢰하고 있어야 한다.
인터넷으로 뜨내기 팀원을 구하면 저 두 가지 조건 모두 충족이 안 된다. 그래서 빠르게 많이 구한다 하더라도 갈등이 1~2개만 생기면 금새 흥미를 잃고 약속을 어기고 사라지는 경우가 흔하다. 인디게임의 성공이라는 건 객관적으로 판단할 수 있는 요건이 아니므로, '마음만 먹으면 어디서나 구할 수 있는 시시한 인간'과 굳이 싸워 가면서 끝까지 함께해야 할 이유가 없는 것이다.
그래서 학교 친구, 오래 교류해 오면서 서로를 신뢰하는 사람과 하는 것이 이상적이다. 하지만 이 경우에도 같이 '일'을 하다 보면 싸우게 되는 일이 생각보다 많다. 그리고 갈등이 심한 팀은 장기적으로 결국 공중분해된다. 거기다 주변인물과 함께 하면 실력을 보증하기 힘들다는 문제도 생긴다.
명확하고 논리적인 메뉴얼을 작성하지 못하는 게임 기획자, 기능 구현할줄 모르고 짜집기하는 프로그래머는 경계 대상이다. 그 전에 기획자와 개발자는 항상 충돌한다는게 함정이다. 의외로 이렇게 소규모로 만들어졌어도 유명한 팀이 제법 있다. Sugar Cube: Bittersweet Factory를 만든 터틀 크림이나 송 오브 더 월드를 개발중인 Team D.T.R. 등. 어려워 하지 않고 희망을 갖는 것도 좋다. 물론 위에서 지적한 문제들은 고려해가면서 말이다.
되도록이면 동업자는 나이차가 얼마 안나는 또래를 대상으로 구하는 것이 좋다.
굉장히 힘든 것이 동업인데 나는 프로그램을 하고 동업자1은 기획, 동업자2는 그래픽을 하기로 했다고 한다면 의견 조율이 힘들다.여럿이 게임을 만들기 때문에 누군가 리더의 역할을 해야 한다. 하지만 동업자이고 파트가 다르지만 거의 동등한 위치이기 때문에 누군가의 말에 의해서 내 의견을 굽히고 남의 의견을 반영해서 일을 해야한다는 것을 불만 없이 받아 들이기란 여간 힘들지 않기 때문이다. 사장이고 직원이라면 시키는 대로 해야하니까 별 문제가 없는데 동업은 그렇지 않다. 내가 만들고 싶은 게임과 동업자1, 동업자2가 만들고 싶은 게임이 같을까? 누군가 주도해서 팀을 꾸렸지만 누구의 명령을 받고 그대로 해야하는 위치들이 아니라서 처음에 주도했던 사람이 만들고자 했던 게임이 나올 확률이 제로에 가깝다.
그럼 처음에 주도했던 사람이 만들고자 했던 게임이 잘될 게임이냐고 반문할 수 있겠지만 답은 그럴수도 있고 아닐수도 있다. 처음에 생각했던 반짝하는 아이디어 그대로 게임이 나온 경우와 의견이 분분해서 서로 타협해서 반짝하는 아이디어가 사라진채 만들어진 게임 둘 중 어떤 게임이 성공확률이 높은가를 본다면 전자일 것이다. 후자의 경우는 유행을 따라가는 경우가 많을수 있고 혹은 너무 개인취향일 가능성도 높다. 유행을 따라가면 이미 철지난 게임이 될 가능성이 높고 개인 취향일 경우 호불호가 너무 극명하게 갈릴 수 있다. 모바일 게임은 물론 짝퉁 게임도 재미있게 만들면 성공하는 경우가 있지만 대부분은 반짝이는 아이디어로 성공한 경우가 많다. 예로 모뉴먼트 밸리, Tiny Wings, INKS, Doodle Jump, 앵그리 버드가 있다. 앵그리버드를 처음에 생각해서 만들자고 했는데 동업자들이 너무 재미없다고 해서 그들의 의견을 반영 게임성이 틀려졌다면 성공 못했을 가능성이 더 많다고 보여진다.

5. 컴공 외에서 배우기

독학하는 것은 매우 힘들다. 따라서 게임학원을 다니는 것도 방안이 될 수 있다. 국비 지원하는 학원이 많으니 잘 알아보자.[12]
유니티 엔진에서는 shaderLab에서 있는 스탠다드 쉐이더를 갖다가 쓸 수 있다. 실력을 쌓으려면 이것을 갖다 쓰는 대신 다이렉트x+HLSL조합으로 직접 쉐이더 구현을 해 볼 수 있다.
한편, 유니티의 스탠다드 쉐이더를 갖다 쓰는 대신 유니티 쉐이더를 커스터마이즈해서 쓰거나 직접 구현해볼 수 있다. 버텍스 쉐이터 프래그먼트 쉐이더 단계에서 직접 하드코딩을 해가며 스펙큘러 디퓨즈 노멀 메탈릭 등등을 구현해가며 실력을 쌓으면 기본적인 쉐이더 구현이 하드코딩으로 가능해졌다고 느끼는 단계에 올라올 것이다. 그 이후에는 디퍼드 쉐이딩이나 디퍼드 라이팅도 하드코딩으로 직접 구현 해 볼 수 있다. 그 후에는 직접 저널이나 논문을 영어로 읽어가며 LPV나 복셀 옥트리 같은 리얼타임 글로벌 일루미네이션을 구현해 볼 수 있다. 실시간 글로벌 일루미네이션을 구현 하는 단계까지 오게 되면 수학적인 지식이 엄청나게 요구되지만, 머리가 좋고 자력으로 난관을 해쳐나갈 근성이 있으면 학부생 수준에서도 시간을 많이 들이면 최소한은 구현 가능하다. 그러나 이런 유니티 쉐이더 커스터마이징은 생각보다 제한적인 느낌이 강해서 DirectX+HLSL 조합에 비해 독학에 안 좋다. 유니티는 기본적인 light관련 함수지원도 부실한 편이라 일일히 뜯어고치며 레고블럭 갖고 놀듯이 만들어가기가 매우 제약이 걸린다.

5.1. 게임학과

게임학과 문서에도 서술되어 있듯이 국내의 게임학과들은 10년이 넘은 과가 거의 없을 정도로 역사가 짧고, 커리큘럼 역시 제대로 정립되어 있지 않다. 게다가 대학 특유의 비효율적인 교육과정 때문에 실력만 따지자면 2-4년제 게임학과 졸업생보다 오히려 현업 출신 강사에게 알짜배기 교육만 받는 학원 출신이 더 잘하는 경우가 많다.[13] 아이러니하겠지만, 보통 대학교에서 게임학과에 있는 교수들은 게임업계 경력이 거의 없는 사람인 경우가 대부분이다. 심한 경우 컴퓨터공학과 출신 교수가 대신 맡는 경우도 비일비재하다.
이런 상황에는 나름 이유가 있는데, 대학 교수가 되기 위해서는 상당히 까다로운 과정을 거쳐야 하기 때문이다. 그렇기에 대학 교수가 될 정도로 노력한 사람은 현직 게임 프로그래머들에 비해 현업 경력이 상대적으로 적거나 없는 사람일 확률이 높다. 그렇다보니 교수들이 기본적인 OpenGL이나 DirectX의 지식도 별로 없고 게임 제작에 대한 지식도 별로 없다. 이렇게 가르치는 사람이 잘 모르는 채로 가르치는 상황이라 배우는 것 역시 별로 알차지 않다. 그나마 배우는 것도 학원을 다니거나 스스로 독학해가면서 알아가는 경우가 대부분이라서 현업에서 게임을 제작할때 사용하는 기법이나 노하우 같은걸 알 수도 없고 이해도 어렵다. 졸업작품을 보면 그럴듯하게 작품이 나오는 듯 하지만, 대부분의 경우는 날코딩하는 경우가 아니라 엔진을 쓰는 경우가 부지기수다. 얼핏 보면 결과물이 좋아 보여도 그건 엔진이 지원하는 기능이 좋아서 그렇고 작품이 학생들의 실력을 크게 반영하지 못한다.[14]
그렇게 대학교에서 커리큘럼대로만 배우다 보면 실상 현업에서 쓰이는 기술은 거의 배우지 못한 상태가 되는데, 이 상태로 취업하면 부족한 실력이 드러나는 경우가 많다. 학교에 다닐 것이라면 현업에서 일하고 있는 졸업한 선배나, 동기 친구들과의 스터디를 통해 학교에서 제공하는 커리큘럼 이외의 방법으로도 실력을 쌓을 방법을 모색해야 한다. 별 생각없이 머리를 비우고 주어지는 것만 받아들이면서 몇년을 다니는 것은 학원에 1년 다닌 것보다 못할 수 있다.
다행히 시간이 지나면서 경험이 축적되고 체계가 점점 잡혀지면서 교육 여건 및 학습 여건이 나아지긴 했으나, 현업 개발 경력과 대학 교수 자격 과정을 모두 갖추는 것이 어려운 이상 이론적으로 배우면서 실무 경험에 도움이 되는 실습까지 제대로 학습하는데 한계가 있으므로, 결국엔 학교 커리큘럼에 없거나 미흡한 내용이 무엇인지 학생 스스로 찾아서 공부하고 익히려는 노력은 필요하다는 점은 변함이 없다.

6. 콘솔 게임 프로그래밍

게임에서의 멀티코어 프로세싱 기술은 2005년부터 등장한 7세대 콘솔 게임기인 엑스박스 360와 PS3부터 멀티코어 CPU를 달고 있었다. 메이저 콘솔 게임 개발사는 이미 7세대 콘솔 게임기 시절부터 한정된 CPU 자원을 거의 100% 다 쓰도록 프로그래밍 했다. 3코어 6스레드의 PPE를 가진 XBOX 360이나[15][16] 1코어 2스레드의 PPE + 7코어 7스레드의 SPE를 가진 PS3 시절부터[17] 게임 루프를 많게는 6스레드로 쪼개서 효율적으로 처리하도록 프로그래밍 하는 것이 가능했다.
2012년부터 등장한 8세대 콘솔 게임기 중에 고성능인 PS4, PS4 Pro, 엑스박스 원, 엑스박스 원 X도 역시 멀티코어 CPU로 모두 8코어 8스레드 CPU를 달고 있다. 당시 고전력인 대신 고성능 태생이었던 7세대와는 다르게 초저전력 태생의 CPU라 싱글스레드 성능이 크게 향상되진 않았지만, 독립적인 사운드 프로세서가 탑재되어 게임용으로 할당 가능한 스레드 개수가 많아졌다.
하드웨어 사양에 소프트웨어 환경까지 천차만별인 PC와는 다르게, 다음 세대 콘솔이 나올 때까지 동일하고 고정되어있는 하드웨어에 맞춰 개발한다는 점 등, 콘솔 개발만의 이점은 분명히 있다. 안타깝게도 한국은 콘솔 게임의 인기가 상대적으로 적어 콘솔 게임 쪽 개발 경험을 가진 프로그래머가 매우 적은 편이다.

7. 기타

1980년대까지는 어셈블리어가 필수적이었다. 그러나 PC에서는 1990년대 초, 휴대용 게임기에서는 1990년대 말 즈음 퇴출되었다. 그 이후에는 게임 프로그래밍 업계에서 어셈블리어의 지분은 거의 없는 상태다.[18] 단 90년대 말에 퇴출되었다는 것은 메인 프로그램 개발 언어에서 퇴출되었다는 얘기이고, 2001년에 GPU에 제한적인 프로그래머블 셰이더가 나왔을 때부터 한동안 셰이더 코드는 독자적인 어셈블리로 코딩해야 했다.[19] 물론 이는 메인 CPU 로 흔히 쓰이는 x86, ARM, MIPS 등의 어셈블리가 아니라 GPU 가 쓰는 별도의 명령에 대한 어셈블리를 말한다. 다행히 2002년 말에 MS가 DirectX 9.0과 함께 발표한 HLSL가 셰이더 프로그래밍의 사실상 표준으로 자리 잡게 되면서 더이상 GPU 제조사별로 일일이 따로 배울 필요가 없게 되었고, C와 비슷한 형태의 하이 레벨 언어라 학습 난이도가 낮아지면서 불편하기 짝이 없는 독자적인 셰이더 어셈블리어는 자연스럽게 사장되었다.

8. 관련 문서

[1] 흔한 게임 리플리케이션 문제다. 나는 분명 다른놈을 붙잡고 있는데 다른놈은 못 움직이는 나를 신나게 패는 상황이 생기는게 흔한 일이다.[2] 정석으로 해결하려고 하면 되는 일이 없다! 당장 3D 공간상에는 공기가 없다. 대표적으로 "마법의 숫자" 하나로 엄청나게 힘든 계산을 "필요한 만큼 정확하게" 계산하는 고속 역 제곱근이 1999년 12월에 발매된 퀘이크 3 아레나에 사용되었다.[3] image based lighting의 경우, 고속연산화를 위해 spherical harmonics를 퓨리에급수를 이용해 이산수학적으로 유도한 다음 계산한다. 삼각함수 항등식 등을 통해 계산 과정을 단순화 하거나, 각종 합성행렬을 만드는 식.[4] 멀티코어 프로세싱이나 멀티스레딩이나 둘 다 복수의 스레드들을 활용하는 멀티태스킹 기술이라는 점은 유사하지만, 멀티코어 프로세싱은 코어가 1개가 아닌 2개 이상으로 존재해야 성립되는 용어이고 멀티스레딩은 코어 2개 이상은 물론이고 코어 1개여도 성립되는 용어다.[5] 멀티코어가 아닌데다 SMT(동시 멀티스레딩)도 지원하지 않던 과거 일반 가정용 싱글코어 CPU 시절에도 멀티태스킹을 위해 구현했던 방식이기도 하다. 당연히 1스레드씩 처리할 수 있기 때문에 동시에 처리하는 것처럼 보이게끔 프로세스의 여러 스레드들을 매우 짧은 시간 단위로 번갈아가면서 처리하므로, 시간 순서 및 차이 없이 수행하는 동시 멀티스레딩이 아니다.[6] 사실 임시 멀티스레딩은 싱글코어 시대에 나온 게임들이나 싱글코어 지원이라고 불려지는 게임들도 이미 구현된 방식이다. 이렇게라도 구현하지 않으면 그래픽이 렌더링되는 동안에 애니메이션, 물리, 입력, 사운드, 네트워킹, 파일 입출력 등과 함께 멀티태스킹할 수 없어 게임이 제대로 진행될 수 없는 끔찍한 상황이 될 수 있기 때문.[7] 하지만 자체개발 엔진을 사용할 경우 상용 엔진 개발사에 지불하는 로열티가 절감되며, 필요에 따라 엔진을 커스터마이징하기가 수월하다. 이 때문에 블록버스터급 개발사는 여전히 자체개발한 엔진을 사용하는 경우가 많다. EA의 프로스트바이트 엔진, 캡콤의 RE엔진, 유비소프트의 엔빌넥스트 엔진이 대표적이다.[8] 다만 엔진 하나만 쓰라는 법은 없다! 자신이 있다면 엔진의 소스 라이센스를 얻어서 자신만의 엔진 개발을 하거나, 타 오픈소스 엔진 코드의 wrapper 제작을 해서 두개의 시스템을 융합하는 방법도 있다. 그러나 엔진 짬뽕이 너무 심해진다 싶으면 그냥 새로운 엔진을 찾자.[9] 수백 ~ 수천명이 실시간으로 상호작용 하는 방식의 게임 [10] 이 쪽은 개발자가 '''고등학교 3학년''' 때부터 혼자 만든 게임이다.[11] 현재는 마이크로소프트 산하에 인수되고 본 개발자도 은퇴한 상태라 더 이상 인디 게임이 아니지만, 시작은 분명 인디 게임이 맞았다.[12] 최근에는 아예 국비과정을 도입하는 것이 대세화되고 있어서. 국비 과정이 없는 학원을 찾는 게 더 힘들 정도다.[13] 이것은 비단 게임 프로그래머만 그런 것이 아니라 그래픽 디자이너 같은 다른 업계 직종도 마찬가지이다.[14] 엔진을 써서 만든 포트폴리오의 경우, 보기에는 화려하지만 만든 사람의 실력은.. 영 좋지 못한 경우가 많다. 엔진을 안 쓰고 만드는 경우가 있기는 있지만 매우 찾아보기 힘들다.[15] 하이퍼스레딩을 지원하는 인텔 코어 i 시리즈, 코어당 2-way SMT를 지원하는 AMD 라이젠 시리즈와 유사한 메커니즘이라고 생각하면 된다.[16] 보통은 OS용 1스레드 + 게임 사운드 처리용 1스레드 + 나머지 4스레드로 할당해서 프로그래밍 했었다.[17] 해당 마이크로아키텍처인 CELL-Broadband Engine에서는 본래 메인 코어인 PPE 1개와 보조 코어인 SPE 8개로 구성되어 있는데, 수율 문제로 SPE 1개가 비활성화된 채 PS3에 채택되었다. PPE는 보통 게임용과 OS용 각각 1스레드씩 할당하고, SPE는 OS용 1스레드 + 게임 사운드 처리용 1스레드 + 나머지 5스레드로 할당해서 프로그래밍 했었다.[18] 하우스 엔진이나 개발 언어의 마개조가 필요할 때나 겨우 쓴다.[19] 모두 그런 것은 아니고, 예를 들어 게임큐브 의 GPU 는 TEV 라고 하는 제한적으로 프로그래밍 가능한 유닛이 탑재되어 있었는데 이것을 일종의 원시적인 프로그래머블 셰이더라고 볼 수 있다. 이 TEV 를 제어하기 위해 닌텐도는 TEVSL 이라고 하는 언어를 제공했다. 이는 어셈블리보다는 고수준이었다.

분류

게임 개발자