게임 프로그래머 (덤프버전으로 되돌리기)

[목차]
== 개요 ==
게임 [[프로그래머]]는 프로그래밍을 통해 맵 디자인, 캐릭터 디자인, 사운드, 각종 시스템 등을 뒤섞어, 게임이라는 하나의 핵심 결과물을 만드는 직군이다. 소프트웨어 엔지니어라고도 불린다.

기본적으로 게임은 일종의 프로그램이다. 다른 부분은 연관성이 없어도 열정으로 떼울 수는 있는데, 물론 완성도는 매우 떨어지겠지만 프로그래밍은 다른 개발자로 대체가 불가능하다. 그래서 게임을 만드는 데 있어서 핵심의 핵심을 만들기에 가장 귀중한 인력이다. 게임 프로젝트에서 가장 먼저 투입되고 프로젝트가 망한 후에도 가장 나중에 짤리는 직업으로 인식된다. 실제로도 게임 업계에서 프로그래머의 연봉이 기획자나 그래픽 디자이너보다 높은 경우가 많다.[* 당연히 게임마다 다르지만 한국 게임 산업에서는 [[3D 그래픽]] 쪽이 더 연봉이 높은 편.]

== 유형 ==
수십, 수백명의 개발자들이 필요한 [[AAA 게임]]들은 다양한 분야의 전문가들을 필요로 한다. 아직도 수많은 사람들이 게임 프로그래밍의 대해서 착각하는 것 중 하나인데, 같은 게임 프로그래머라고 해도 전문 분야가 다르면 필요한 지식, 경력, 성격, 등등이 완벽하게 달라진다. 여기서는 [[넥슨]][* [[https://career.nexon.com/user/recruit/member/jobInfo?joinCorp=NX&oJobGroupCd=5|넥슨 채용사이트 프로그래밍 직군 소개]]]의 분류를 참고하여 서술했다.

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

 * '''네트워크 / 서버 프로그래머 (Network / Server Programmer)'''
 온라인 게이밍의 핵심이라고 볼수 있다. 클라이언트와 서버 간의 데이터 송수신을 다루고, 렉을 줄이기 위해서 최소한의 정보를 보낼 방법과, 심한 렉, 서버 다운, [[DDoS]] 공격 등의 문제를 해결할 방법을 연구한다. 데이터 사용량을 줄이는 동시에 클라이언트의 시점에서 렉이 안보여야 하는데, 잘못된 디자인은 0.1초의 렉으로도 유저와 유저 밖의 세상이 따로 노는 느낌을 줄 수 있다. 한국사람으로서 상상하기 어려울수도 있겠지만 세계의 평균 인터넷 속도는 낮은 편이고, 구형 모뎀 인터넷으로 지구 반대쪽에 있는 서버를 통해서 게임을 해야 할 사람도 있으니, 세계적인 온라인 게임을 만들기 위해서는 1바이트의 추가 데이터도 신중히 다뤄야 한다.[* 다만 이는 장르에 따라 다르다. 간단한 캐주얼/퍼즐 게임들은 일반적인 웹 서버를 사용하는 경우가 많기 때문에, 이 때는 로우레벨 소켓 디자인보다는 웹 프로그래밍에 가까운 개발이 이루어진다.] 또한 대부분의 게임 개발사는 DBA[* Database Administrator의 약자로 데이터베이스 관리자를 뜻한다.]를 따로 두지 않으므로[* 대형 온라인 게임에서는 구조가 매우 복잡해지기 때문에 DBA가 있긴 하다. 다만, 구조를 어느정도 알아야하기에 데이터베이스 지식이 필요한건 여전하다. ], 사실상 [[데이터베이스]] 지식까지 요구되는 직군이다.

 * '''게임 엔진 프로그래머 (Game Engine Programmer)'''
 게임 개발에 필요한 핵심 기술인 게임 엔진을 제작한다. 크게 물리와 그래픽스 두 분야에 대한 깊은 이해도를 요구한다. 유저들은 매년 상향되는 그래픽, 물리 엔진을 보고 싶어하고, 만족할만한 게임을 만들기 위해서 최신 기술들의 효율적인 계산이 필요하다.
 물리의 경우 게임에 필요한 물리 계산을 빠르게, "필요한 만큼 정확하게[* 정석으로 해결하려고 하면 되는 일이 없다! 당장 3D 공간상에는 공기가 없다. 대표적으로 "마법의 숫자" 하나로 엄청나게 힘든 계산을 "필요한 만큼 정확하게" 계산하는 [[https://ko.wikipedia.org/wiki/%EA%B3%A0%EC%86%8D_%EC%97%AD_%EC%A0%9C%EA%B3%B1%EA%B7%BC|고속 역 제곱근]]([[https://www.dogdrip.net/430069083|원리 설명]])이 1999년 12월에 발매된 [[퀘이크 3 아레나]]에 사용되었다.]" 하는 개발을 한다. [[프로그래머]] 항목에서 프로그래머들은 거창한 알고리즘 연구를 안한다고 하지만, 이쪽은 그런 짓을 할만한 인간들이 필요하다.
 그래픽스의 경우 3D 그래픽이나 애니메이션을 빠르게 계산하고, 효율적으로 유저의 모니터로 출력하는 개발을 한다. 위와 비슷하게 순수한 프로그래밍보다 수학, 물리쪽 지식을 더 많이 필요로 한다. 위와 비슷하게 비주얼적으로 타협이 가능하면 최적화를 한다.[* image based lighting의 경우, 고속연산화를 위해 spherical harmonics를 퓨리에급수를 이용해 [[이산수학]]적으로 유도한 다음 계산한다. 삼각함수 항등식 등을 통해 계산 과정을 단순화 하거나, 각종 합성행렬을 만드는 식.]
 난이도가 높아질 수록 최소 수학과 또는 물리학과 3~4학년 수준 지식을 요구하기도 한다. 그 이유인 즉슨 직접 논문을 읽고 구현하거나, 또는 논문으로도 발표된 사례가 없어 바닥부터 직접 만드는 경우가 잦기 때문이다. 따라서 독보적으로 난이도가 높으며, 그에 비례해 대우가 좋다. AAA급으로 갈수록 반드시 필요하며, 제대로만 하면 여기저기서 모셔가려고 용을 쓴다. 유독 이 분야의 사람들이 다른 포지션의 일을 겸하는 경우가 많은데, 그 만큼 다른 기술의 밑바탕이 확실해야 할 수 있는 분야라는 뜻.
 수학의 경우 [[사원수]], [[오일러]] 각 등의 3D 수학을 기초로 알아야 하며 매우 높은 수준의 코딩 테스트 지식을 요구한다. 

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

그 외에 [[인공지능]], [[UI]], 사운드 프로그래머가 있다.

통상적으로 한국의 게임사들은 위 분류대로 간소화하여 구분한다. 한국에서는 물리 엔진 프로그래머, 렌더링 프로그래머에 대응되는 직무는 존재하지 않거나 훨씬 간소화된 규모로 존재하여[* 대부분 상용 게임 엔진을 사용하기 때문이다.] 게임 클라이언트 프로그래머의 일부가 해당 직무를 맡는 경우가 많다.

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

== 게임 프로그래밍의 특징 ==
=== [[게임 엔진]] 사용 현황 ===
2000년대까지는 스마트폰이 대중화되기 이전인데다 상용 [[게임 엔진]]에 대한 진입 장벽이 남아 있었기 때문에 자체 게임 엔진을 사용하는 곳이 제법 많았으나, 2010년 스마트폰 대중화 이후로 [[유니티 엔진]]의 낮은 진입 장벽 덕분에 모바일 플랫폼을 장악하고 대동단결하기 시작하더니, 2015년 [[언리얼 엔진]]과 유니티 엔진의 조건부 무료 정책이 발표된 이후로 모바일 플랫폼이든 PC 플랫폼이든 상용 게임 엔진 사용이 아예 기본이 되었다. 특히 모바일 에서는 앱스토어 게임의 70% 는 유니티 게임. 크로스플래폼 2D 엔진으로는 [[Godot]]엔진, [[Cocos2d]]엔진, [[SDL|SDL2]] 엔진들이 많이 쓰인다.

이는 상용 게임 엔진들의 거듭 발전됨에 따라, 프로그래밍 할 줄 모르는 타 분야의 게임 개발자들도 어느 정도 사용할 수 있을 만큼 편의성 면에서 진입 장벽이 크게 낮아졌기 때문이다. 편의성 뿐만 아니라 개인 한정으로 무료로 사용할 수 있는 상용 게임 엔진들이 많아져서 1인 개발자들에게도 비용과 시간을 크게 줄일 수 있는 여건이 마련된 파격적인 가격 정책이 결정적이었다.
=== [[프로그래밍 언어]] ===
[[프로그래밍 언어]]로써는 최적화가 중요한 대규모 고사양 게임의 경우 [[C++]]가 쓰이며, 캐주얼 또는 모바일 게임의 경우 [[C\#]]이 많이 쓰인다. 전자는 [[언리얼 엔진]], 후자는 [[유니티(게임 엔진)|유니티 엔진]]에서 사용하는 언어이기도 하다. 그 외에 게임플레이 로직 등을 빠르게 변경하기 위해 [[Lua]], [[Python]] 등의 스크립트 언어도 사이드로 사용하는 경우가 있다. (예: 이브 온라인이나 심즈 등은 Python을 일부 사용) 이때 스크립트 코드 변경은 게임 기획자가 맡기도 한다.

서버 사이드의 경우 전통적인 실시간 서버를 사용한다면 IOCP 기술이 필요하므로 [[C++]]나 [[C\#]]을 사용하고, 데이터베이스도 ODBC를 이용해서 접근한다. 작은 규모의 캐주얼 게임의 경우 웹 서버를 많이 사용하기 때문에 [[JavaScript]] 기반의 [[Node.js]]가 많이 쓰인다. 예전에는 [[PHP]]를 썼지만 요즘은 사양되는 추세. 이 케이스에서는 ORM 라이브러리를 통해 간편하게 DB를 사용하기도 한다. [[Java]]를 쓰는 경우가 있기는 하나 웹 애플리케이션 분야에 비하면 상당히 적다.

=== [[라이브러리]] ===
프로그래밍 언어 이외에 그래픽 [[라이브러리]]에 대한 이해도 필요하다. 보통 많은 기능을 제공해주고 품질이 높은 [[DirectX]]나 [[OpenGL]]를 사용해서 만든다. 옛날에는 이런 것 없이 하기도 하였는데 이는 성능이 매우 떨어지는 과정이었다. 당장 [[Windows API]] 과정에서는 이 둘 없이 게임을 만들어야 한다. 라이브러리 쓰는 것과 비교해보면 퍼포먼스가 상당히 많이 떨어진다.

또한 요즘은 2D 게임도 3D 게임을 기반으로 만들기 때문에[*  3D 게임에서 카메라를 측면 뷰로 고정시키면 사실상 2D 게임과 같게 된다. [[블러드스테인드: 리추얼 오브 더 나이트]]의 경우 이 방식을 적용하여 3D 게임이면서도 2D 악마성 시리즈의 느낌을 준다.] 3D에 대한 지식이 필수다. 이미지를 합치는 방식이나 라이트맵핑 등이 있다. [[자료구조]]와 [[알고리즘]]의 [[로직]]은 한번씩 구현해보는 것이 좋다. 만들어 본 것과 알기만 하는 것의 차이는 크며, [[STL]]과 [[Boost]]를 쓴다고 해도 예외는 아니다.

최근에는 상용 엔진의 점유율이 거의 대다수를 차지하고, 이런 엔진들은 [[DirectX]]나 [[Metal(API)|Metal]] 등의 로우레벨 API들을 래핑해서 제공하기 때문에 그래픽 라이브러리를 많이 알지 못해도 클라이언트 개발은 가능해진 시대가 됐다. 물론 엔진 코어단을 개발하고 수정하는 개발자들은 그래픽 라이브러리에 대한 이해가 필수이며, 상대적으로 높은 연봉과 대우를 받는다.

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

=== 멀티코어 및 멀티스레드 ===
[[멀티코어 프로세싱]] 및 멀티스레딩의 경우, 플레이어들은 성능 향상을 위해서 원하고 있지만 보통의 게임 프로그래머는 게임 개발 과정에서 활용하고 싶어하지 않는다. 그 이유는 단적으로 말하면, 멀티쓰레드는 프로그래머 본인들도 제대로 알고 쓰는 프로그래머가 흔치 않으며,[* 학교에서 배운 개념(데드락, 스핀락, 암달의 법칙 등)을 읊는 것은 쉬우나 그걸 실제 코드에 녹여 넣는 것은 베테랑 프로그래머들도 많은 고민을 하게 만든다. 특히 멀티쓰레드 환경에서의 오브젝트 라이프사이클 관리는 난이도가 헬급이다.] 그로 인해 버그의 가능성이 급격히 증가하기 때문이다. CPU 활용도를 극한으로 짜내야 하는 [[AAA 게임]]이 아니면 사실 이 작업을 그리 철저하게 하진 않는다.

싱글 게임 및 온라인 게임 클라이언트에서는 멀티코어 프로세싱 및 멀티스레딩을[* 멀티코어 프로세싱이나 멀티스레딩이나 둘 다 복수의 스레드들을 활용하는 멀티태스킹 기술이라는 점은 유사하지만, 멀티코어 프로세싱은 코어가 1개가 아닌 2개 이상으로 존재해야 성립되는 용어이고 멀티스레딩은 코어 2개 이상은 물론이고 코어 1개여도 성립되는 용어다.] 세간에 알려진 것과는 다르게 잘 쓰지 않는다. 왜냐하면 프로그래머 입장에서 득보다 실이 많기 때문이다. [[Deadlock|데드락]], [[레이스 컨디션]], 코드 이해의 어려움 등 각종 문제가 있는데 반해 성능의 상승은 제대로 처리했을 경우 병렬 처리를 적용한 부분에서 평균 5~8% 정도만 향상된다.

대부분의 프로그래머들은 멀티코어 프로세싱 및 멀티스레딩을 지원하지 않는 것을 선호한다. 이 경우 렌더링을 몇 프레임 덜 하더라도 위에서 발생할 문제들이 대폭 줄기 때문이다. 렌더링 횟수 기준을 보통 1초에 60번을 기준으로 삼는데 컴퓨터 성능에 따라서 더 많은 횟수가 나온다. 프레임을 약간 희생하기만 하면 위의 문제들이 해결되어 수월한 개발, 시간 절약, 인건비 절약, 개발자들 스트레스 감소 등의 다양한 장점이 생긴다. 초당 60프레임을 48프레임으로 낮춰도 사람 눈으로 구분하기도 힘들고 프레임이 끊겨서 게임 못할 정도도 아니기 때문에 자주 이용되는 방법이다.

싱글코어 성능이 낮은 PS4와 같은 콘솔 게임기가 등장하먼서 렌더링이나 게임플레이 연산을 '''잡''' 또는 '''태스크'''으로 쪼개 여러 코어 혹은 스레드에서 처리하게 하는 기술인 태스크 시스템을 언리얼 등의 게임엔진이 지원하기 시작했다. 둠 이터널 케이스처럼 제대로 사용하면 큰 성능 향상을 가져오지만 구현이 복잡하고, 이를 잘 다룰 수 있는 프로그래머가 아직 적어 몸값이 비싸다. 렌더링의 경우 정확히는 gpu 커맨드 버퍼가 사용하는 데이터 준비를 병렬화 할 수 있다. async compute을 지원하는 최신 gpu를 제외하면 gpu는 여러 작업을 동시에 수행할 수 없기 때문에 셰이딩같은 핵심 작업은 순차적으로 처리된다. 애초에 gpu가 빠를때는 같은 연산을 대량의 데이터(폴리곤 등)에 한번에 적용할 수 있는 경우가 대부분이라 병렬화를 할 이유가 적다. 

그리고 모든 게임들의 게임 루프가 모두 태스크 시스템을 이용한 병렬 처리로만 구현할 수 있는 것도 아니고, 때로는 스레드끼리 서로 통신하면서 모두 똑같은 일을 동시에 동작하는 병렬 처리가 아닌 서로 다른 일들을 동시에 동작하는 병행 처리로 구현해야 할 때도 있으며, 안정성을 위해 부득이 각 스레드마다 스레드 하나씩 컨텍스트 스위칭을 통해 퍼포먼스를 희생해서라도 시분할 단위로 번갈아가면서 처리하는 임시 멀티스레딩(Temporal Multithreading)[* 멀티코어가 아닌데다 SMT(동시 멀티스레딩)도 지원하지 않던 과거 일반 가정용 싱글코어 CPU 시절에도 멀티태스킹을 위해 구현했던 방식이기도 하다. 당연히 1스레드씩 처리할 수 있기 때문에 동시에 처리하는 것처럼 보이게끔 프로세스의 여러 스레드들을 매우 짧은 시간 단위로 번갈아가면서 처리하므로, 시간 순서 및 차이 없이 수행하는 동시 멀티스레딩이 아니다.][* 사실 임시 멀티스레딩은 싱글코어 시대에 나온 게임들이나 싱글코어 지원이라고 불려지는 게임들도 이미 구현된 방식이다. 이렇게라도 구현하지 않으면 그래픽이 렌더링되는 동안에 애니메이션, 물리, 입력, 사운드, 네트워킹, 파일 입출력 등과 함께 멀티태스킹할 수 없어 게임이 제대로 진행될 수 없는 끔찍한 상황이 될 수 있기 때문.] 방식으로 구현해야 할 수도 있다. 게임 자체가 가지고 있는 이러한 복잡성 때문에 게임의 모든 구간에서 100% 병렬 + 병행 처리 구현이 어렵다는 것.

이런 성향 때문에, [[게이밍 기어|게임용 PC]]에 들어가는 CPU는 [[인텔]]이 선호된다. [[AMD]]는 상대적으로 멀티코어 활용에 더 최적화되어 있는 편이다.

위 내용은 대체로 클라이언트 및 싱글 게임의 이야기이고, 온라인 게임의 서버는 당연히 멀티쓰레드 및 멀티코어 기반 지식이 필수로 요구된다. 서버 입장에서 캐릭터 하나하나가 요구하는 성능은 적으나[* 대부분 로직이며 최근 게임에서 가장 CPU자원을 많이 요구하는 물리계산 및 셰이더 계산 등은 없거나 축소된 구조이다.] 서버에 동시 입장하는 캐릭터의 수가 최소 수백에서 최대 1만명 이상[* 흔히 이 문제를 C10k 라고 한다]까지 요구되기 때문에 서버 프로그래머는 그 캐릭터들간의 상호작용 및 제한된 자원(몹, 땅에 떨어진 아이템 등등)에 대한 동시성 처리를 위해 서버머신에 설치된 CPU코어를 최대한 활용하는 코드를 작성하고(캐릭터들의 동작을 최대한 분산 처리하고), 그들이 상호작용할 때 데드락 및 오염된 데이터 문제, 라이프사이클 관리 실패로 인한 크래시가 발생하지 않도록 최선을 다한다. 그러면서도 반응성이 좋은 서버를 만들기 위해 노력한다.[* 리니지 1 등의 1세대 온라인게임의 반응성과 최신 온라인 게임의 반응성을 비교하면 극과 극이다. 옛날 온라인게임들이 1초당 1~2번 정도의 클릭에 응답한다면, 최신 온라인게임들은 초당 10~20번 정도까지 받아들일 수 있을만큼 반응성이 좋아졌다. 서버 머신의 성능 향상도 요인이지만, 거기에 서버 개발 단계에서 미리 최대 동시성 지연시간(틱)을 당기기 위한 코드 수준에서의 많은 노력(적절한 데이터 컨테이너(vector, map, unordered_map) 선택, 미리 계산할 수 있는 값들(삼각함수값 등)의 상수화, 반복문의 최소화, 복사생성자 호출을 줄이기 위한 std::move 사용, 메모리 delete를 막고 재사용성 늘리기 등등등)이 필요하다.] 특히 라이브서비스에서는 유저가 밀리초 단위로 들락날락하고 몹이 1초에 수백 수천마리씩 죽었다 깨어났다 하며 수많은 해커/크래커들이 이상한 패킷을 마구 보내오기 때문에 알파테스트에서 아무리 봇테스트를 거쳐도, 걸러내지지 않는 숨은 오류들이 무수히 발견된다. 따라서 그러한 오류들을 라이브 서비스 전에 미리 예견하거나, 애초에 그런 일이 발생하지 않는(가이드라인이 시킨 대로만 코드하면 실패하지 않는) 프레임워크를 구성하는 것이 매우매우 중요하므로 서버 개발은 이런저런 장애와 산전수전을 많이 겪어 본 베테랑 개발자가 필수로 요구되며, 경력이 쌓이면 쌓일수록 대우가 좋아지는 경향이 있다.

=== 상용 게임 엔진 ===
현세대 게임 개발 트렌드는 2015년에 발표된 [[언리얼 엔진]]과 [[유니티(게임 엔진)|유니티 엔진]]의 파격적인 가격 정책으로 인한 폭발적인 사용자 증가의 연장선인데, 이미 자체 개발 엔진보단 상용 게임 엔진 사용이 대세가 된 것도 모자라서 유니티, 언리얼 엔진 외의 수단으로 개발하는 업체는 2010년대 후반에 들어서 거의 없어졌다.[* 하지만 자체개발 엔진을 사용할 경우 상용 엔진 개발사에 지불하는 로열티가 절감되며, 필요에 따라 엔진을 커스터마이징하기가 수월하다. 이 때문에 블록버스터급 개발사는 여전히 자체개발한 엔진을 사용하는 경우가 많다. EA의 프로스트바이트 엔진, 캡콤의 RE엔진, 유비소프트의 엔빌넥스트 엔진이 대표적이다.] 각각의 게임 엔진은 정해 놓은 룰이 있다. 엔진의 규칙(포맷)이 있는데 이에 맞추어서 게임을 만들어야 한다.[* 다만 엔진 하나만 쓰라는 법은 없다! 자신이 있다면 엔진의 소스 라이센스를 얻어서 자신만의 엔진 개발을 하거나, 타 오픈소스 엔진 코드의 wrapper 제작을 해서 두개의 시스템을 융합하는 방법도 있다. 그러나 엔진 짬뽕이 너무 심해진다 싶으면 그냥 새로운 엔진을 찾자.] 따라서 엔진을 잘 골라서 배워야 한다.

유니티는 [[C\#]]을 사용하고 언리얼 엔진은 [[C++]]를 사용한다. 하지만 유니티도 C#을 스크립팅용으로 사용될 뿐, 내부는 전부 C++로 이루어져 있다. 최근엔 개발 기간 단축을 위해 유니티를 쓰는 경우도 잦지만 언리얼 엔진보다 여러모로 부족하다. 그리고 게임 엔진을 사용하더라도 로직을 짜는 실력 정도는 갖추고 있어야 한다.

중규모 이상의 온라인 게임을 개발하는 업체에서는 대부분 C++ 기반의 언리얼 엔진 3나 언리얼 엔진 4를 사용한다. 이런 회사는 고정 유저를 확보하고 안정적으로 수익을 내는 타이틀을 가진 회사이므로 안정적으로 경력도 쌓고 실력도 쌓으며 일할 수 있는 좋은 회사다. 그런 회사는 유니티만 다룰 수 있는 사람은 선호하지 않는다.

유니티만 배웠다면 현재로써는 모바일 게임 회사밖에 갈 수 없다. 유니티 엔진 기반의 PC 플랫폼 게임이 언리얼 엔진 기반 게임에 비해 영향력이 크지 않기 때문. 그걸 원하지 않는다면 취미인 유니티보다 직업으로서의 언리얼 엔진을 우선시하길 바란다. 안정적인 회사 다니면서 유니티로 아이디어 게임 만들어서 대박이 나면 나와서 회사를 차리는 케이스가 종종 있긴 하지만 처음부터 유니티로 시작한다면 좀 어렵고 힘든 길을 걷게 될 것이다.

학원 중에는 유행하는 엔진 갖고 잠시 만져보는 수준 정도로 교육해주는 학원이 많은데 이는 실력 향상에 도움이 별로 안된다. 요즘으로 치면 유니티만 가르쳐준다. 학원 수강생 출신들이 쏟아내는 틀에 박힌 유니티 기반 포트폴리오들이 넘쳐나서 이젠 학원을 다니는 것 정도로는 취업을 보장하기가 어려워졌다.

왜 유니티만 알고 있으면 모바일 게임 회사밖에 갈 수 없는가? 유니티로 대규모 게임을 만들지 않는건 플랫폼의 문제다. 유니티가 멀티플랫폼에 굉장히 뛰어난 대신 퍼포먼스를 희생했기 때문에 모바일 등에 매우 적합한 인터페이스를 가지고 있어 죄다 모바일은 유니티로 만들고 있다. 대형 게임은 언리얼 엔진이 훨씬 유리하기 때문에 유니티를 안 쓴다. 

유니티의 경우는 무조건 스테이지 시작전에 미리 로딩을 끝마쳐야 한다. 그런데 중규모 이상의 온라인 게임들은 카메라를 자유 자재로 움직여야 하거나, 시점이 1인칭에서 3인칭으로 변경이 자주 된다거나, 스킬 트리가 복잡하고 사용되는 이펙트들도 무거워서 미리미리 로딩을 해야 하다가도 실시간으로 로딩을 해야 하는 등 게임 내의 메모리 관리를 캐릭터의 특성에 따라서 맘대로 했다 안했다가 하는 유연성이 필요한데 유니티는 그것이 상대적으로 부족하다. 메모리 관리를 유연하게 할 수 없기에 유니티로는 중규모, 대규모 MMORPG를 잘 만들지 않는다. 존(zone) 이동을 예를 들면 이동할 것을 대비하여 지금 보이는 존 주위의 존을 메모리에 올려 놓아야 하는데, 이걸 실시간으로 할 수 없다. 유니티가 지원하지 않는다. 유니티는 무조건 씬 단위로만 게임을 구성해야 한다. 중규모, 대규모 MMORPG는 씬 단위로 구성되지 않는 게임이라서 엔진 특성 자체가 안 맞는 것이다.

그나마 다행인 점은 유연성 문제가 2015년에 발표된 [[유니티(게임 엔진)#s-2.5|유니티 5]]에 이르면서 대부분 해결되고 오히려 견고하고 안정되어 언리얼 엔진 4에 필적하는 우수한 엔진이 되어 이제는 엔진 숙련도의 문제이지 엔진 퍼포먼스의 문제가 아닌 단계로 발전되었다는 것이지만, 아직까지는 중~대규모 MMORPG 개발로 잘 활용되지 않는 편이다.

=== 기타 ===
 * '''[[컴퓨터 공학]]'''
 얕은 정도의 공학적 지식이 필요하며, 운영체제에 대한 이해를 포함한다. 기초가 되는 부분이며 가장 중요하다. 이것은 디버깅할 때 많은 도움이 된다. 서버 개발의 경우 깊은 수준의 컴퓨터 공학적 지식이 요구되기도 한다.[* 게임에 따라 서버는 정말 마른 걸레짜듯 성능을 쥐어짜기 때문에 캐시미스율이나 함수 호출 규약, TLS, 컴파일 후 어셈블리 생성 형태까지 보는 경우도 있다. 최근에는 언리얼 블루프린트등의 제공으로 필요성이 적어졌으나 예전에는 서버팀 자체적으로 스크립트 언어(!) 및 컴파일러(!)를 제작하여 기획데이터를 작성하도록 요구하기도 하였다.]

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

 * '''[[영어]]'''
 프로그램 코드에 영어가 사용되는 만큼 읽기, 쓰기 능력이 필요하다. 사실 프로그래밍 언어 자체는 영어를 빌려 표기되는 것일 뿐 영어 자체는 아니기에 프로그래밍 언어의 문법 자체만 이해하고 있다면 알파벳도 못 읽는 정도가 아니고서야 프로그램 작성에 문제는 발생하지 않는다. 문제는 영어를 못할 경우 협업에 있어 문제가 생길 소지가 높다는 것. 영어가 안 되는 양산형 프로그래머([[코더]] 혹은 [[코드몽키]])는 로직에 적합한 단어나 문장을 쓰지 못하고 단순한 약자나 관련이 없는 단어로 코딩을 하는 경우가 많은데, 이 경우 취직 자체가 어렵다. 코더는 코딩을 할 때 어휘가 부족해 다른 사람들이 읽기가 어려운, 자신만이 이해할 수 있는 어휘를 사용한다. 이런 사람들과는 함께 일하기 어렵다. 프로그래밍 담당 인원이 혼자가 아닌 이상 다른 인원들과 협업으로 완성하는 것이라서 모든 인원들이 같은 의미로 이해할 수 있도록 일종의 규칙에 적응하기 어려울 수 있기 때문이다.
 
 게다가 프로그램 작성에 있어 직접 작성하는 부분도 있지만 다른 사람이 작성한 자료나 오픈소스 코드를 가져다쓰거나 참고하는 경우도 많은데, 컴퓨터공학과 프로그래밍을 선두하는 분야가 영미권이다보니 이러한 자료의 99%는 영어로 되어 있다. 영어를 모를 경우 이러한 자료를 찾는 데 있어 심각한 문제가 발생하기에 이런 메뉴얼을 해석해서 얼추 이해할 수준이 되어야 고급 업무를 진행할 수 있다.

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

=== 대형 [[게임 개발사]] ===
[[알고리즘]], [[자료구조]] 중심의 코딩 테스트 준비해서 [[취업/SW]]와 똑같이 준비하면 된다. 컴퓨터공학적 지식을 쌓기 위해서는 [[컴퓨터공학과]]가 다른 어떤 학과보다도 유리하다.

수학능력시험 성적이 중위권 이상이면 컴퓨터 공학과를 가는게 낫다. 게임 프로그래밍에 필요한 수학적인 지식은 1, 2학년때 배우게 된다. 선형대수학, 미적분학, 통계학을 배우기 때문에 게임학과와는 달리 수학적인 지식에서 훨씬 강세를 보인다. 프로그래밍쪽 학습은 일단 Java와 C언어를 기본적으로 습득한 후, 알고리즘 구조, 파일 입출력 같은 시스템 프로그래밍을 게임학과에 비해 훨씬 심화적이고 어려운 레벨까지 접근하기 때문에 배우는 학생들에게는 지옥이지만 오히려 나중에는 그것이 득으로 다가오게 된다.

고학년으로 올라가면 필수과목이건 선택과목으로건 수리 알고리즘 시뮬레이션 같은 선형대수적인 문제에 대해서 프로그래밍으로 구현하는 능력을 배우게 되며 이는 1, 2학년때 단지 수학적인 접근에서만 배웠던 수학을 프로그래밍 적인 시야에서 접근하는 방법을 배우게 된다.

다중 접속 온라인 [[게임 서버]][* 수백 ~ 수천명이 실시간으로 상호작용 하는 방식의 게임 ] 개발 같은 건 학원이나 독학으로 배우기 극히 어렵다. 그런 면에서도 컴공이 낫다.

게임 회사의 채용 전형은 상시채용과 공채로 나뉜다. 회사별로 공채 시기는 다르지만, 보통 1년에 1~2회 정해진 기간에 공고가 나간다. 전형 단계는 보통 서류→필기→기술면접→인성면접의 순으로 가게 되는데. 이 부분은 일반적인 회사와 크게 다르지 않다. 상시 채용은 대부분 회사에서 진행하며, 입사지원서를 보내면 검토 후, 회사에 따라 필기, 면접 전형을 보게 하여 채용한다. 다만, 상시채용은 거의 [[포트폴리오]]를 요구하기 때문에 실력적인 부분을 더 많이 요구하는 전형이라고 할 수 있다.

=== 중형 게임 개발사 ===
분류상 중소기업이나 100~300명 내외의 규모일 경우. 자체 엔진보단 주로 상용 엔진을 사용하며 대부분은 유니티를, 대형 프로젝트라면 PC/모바일 구분없이 언리얼을 사용하기도 한다. 실제 제작 게임이 있는게 유리하지만, 대기업처럼 코딩 테스트와 기술면접을 많이 보므로 적당한 포트폴리오와 이론[* 대기업만큼 깊이 있게는 아니라도, 실무에서 쓰이는 자료구조와 알고리즘은 필수다. 분야에 따라 네트워크나 데이터베이스, 시스템 프로그래밍, 운영체제, 컴퓨터그래픽스 지식을 추가로 요구하기도 한다.] 공부가 필요하다.[* 운 좋게 뜬 경우는 인사팀에서 화려한 학원 포폴만 보고 이상한 사람을 뽑아오기도 한다(...)]

다른 직종의 중견기업이나 스타트업과 장단점이 비슷한데, 대기업과 중소기업의 장점을 합쳐 놓았을수도, 단점을 합쳐 놓았을수도 있으니 잘 알아보는게 중요하다. 돈이 어느정도 있고 개발인력은 항상 부족한데 이름이 덜 알려져서, 수요에 비해 입사자가 비교적 적다.[* 물론 지원자는 많다. 대부분이 코딩테스트에서 광탈하는 허수라 그렇지...] 늘 인력난에 시달리는 곳이라 본인이 실력만 있다면 좋은 회사를 찾아 대기업급 대우를 받으면서 다닐 수 있지만, 중소기업급 대우에 프로젝트만 크게 벌려 놔서 열악한 환경에 시달릴수도 있다.

크게 [[원 히트 원더]]인 경우와 특정 장르에 특화된 경우로 구분된다. 전자인 경우 히트작을 내놓은 지 오래 되었고 후속작이 줄줄이 망하고 있다면 중소기업처럼 다음 대형 프로젝트에 회사의 명운이 걸린 경우가 있다. 신입이라면 피하는 편이 좋고, 경력직이라면 자신의 능력으로 히트작에 기여한다면 개국공신급 대우를 받을 수 있다. 확실한 캐시카우가 있는 만큼 재정 문제가 적고, 짧은 주기로 실적 압박이 들어오는 일도 비교적 적다. 실제 개발력의 중추가 되는 시니어급 개발자라면 노려볼 만하다. 후자는 개발 환경이 안정적이며 주력 분야에 대한 노하우가 많지만, 비슷한 게임을 비슷한 프로세스로 개발하다보면 다른 환경에서 개발하는 능력은 자연히 저하되고 타 분야로의 이직이 어려워진다. 성과에 대한 부담이 비교적 크고 소규모 프로젝트를 적은 인원으로 개발하다가 접히는 일도 잦다. 아예 헤드급이 되어서 그 분야 게임들에 모두 적용되는 프레임워크를 만지거나 주니어급이 신규 프로젝트를 출시까지 만드는 경험[* 초기 [[애니팡]]의 개발 기간은 4개월, 클라이언트 프로그래머는 2명으로 알려져 있다. 대규모 협업 환경을 경험하지 못 하는건 단점이나 주도적으로 뭔가 개발해보기엔 좋다.]을 하기는 좋지만, 오랜 기간 일하는 것은 개발자 커리어에 악영향을 미칠 수 있다.[* 어느 정도의 경력이 있는 개발자가 주도적으로 기술을 활용해보기는 좋다. 대규모 프로젝트는 체계적이지만 개발자 개개인이 할 수 있는 역할은 제한적이기 때문. '이펙티브 엔지니어'의 저자 에드먼드 라우도 이런 이유로 구글에서 쿼라로 이직했다고 밝혔다. --물론 지금의 [[Quora|쿼라]]는 글로벌 대기업이지만--]

2023년 이후 주니어 개발자에게 소/중규모 프로젝트 출시 경험을 요구하는 기업이 많아졌다.
=== 중소 모바일 게임 개발사 ===
[[유니티 엔진]]과 안드로이드/iOS 프로그래밍에 대해 잘 알고 있고 실제 제작 게임이 있는 게 유리하다. 대기업처럼 코딩 테스트를 보지는 않는다.

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

=== [[인디 게임]] 개발자가 되고 싶은 경우 ===
성공하면 '''인생이 달라질 만큼 좋다.''' 성공한 케이스가 몇 명 있다![* 대표적인 사례로는 [[FNaF 시리즈]], [[언더테일]], '''[[마인크래프트]]'''가 있다.] 하지만 대부분은 성공을 못 하고, 성공을 못 하는 기간이 길어지면 매우 어렵고 힘든 길이 된다. 아이디어는 있지만 구현할 실력이 안 된다면 아예 시작도 하지 않는 것이 좋다.

자신이 생각하는 게임[* 일반적인 회사에서는 자기가 만들고 싶은 게임을 만들 기회가 잘 오지 않는다. 그래서 이런저런 경험을 축적해야 할 신입 시절에는 비교적 덜하지만, 어느 정도 연차가 쌓인 경력자가 되고 나면 자신만의 게임을 개발하고 싶은 욕구에 휩싸이는 경우가 적지 않다.]을 구현할 수 있는 실력이 있는 사람이어야 도전할 만 하다. 물론 아주 반짝이는 아이디어로 빠르게 만들어서 잘 될 수도 있지만 그런 경우는 정말 희박하다.

팀을 만들어서 하는 것도 힘들고 혼자서 하는 것은 더더욱 힘들다. 팀을 만들면 의견 조율이 잘 되지 않으며, 금전적인 문제와 이권다툼이 생길 가능성 또한 있다. 개발기간이 길어지면 길어질 수록 팀원들의 사정 때문에 그만두거나 와해되는 경우가 비일비재하고, 혼자 하면 모든 것을 혼자 다 감당해야 하는데 기획은 그냥 머릿속으로 해도 프로그래머는 그래픽이, 그래퍼는 프로그램으로 구현이 문제다.

어찌어찌 게임을 만들었다 하여도 문제는 끊이지 않는다. 일단 모두의 생계가 걸린만큼, 게임으로 돈을 벌 수 있어야 한다. 돈을 벌지 못하면 자연히 [[임금체불]]은 일어나며, 이로 인한 생활고를 버티지 못한 팀원이 나가버릴 수 있다. 그렇게 되면 그 팀원이 맡던 업무는 순식간에 멈추어버리는데, 인디 게임 개발 팀인 만큼 인력이 극도로 부족하다. 대체할 인력도 없는데, 새로운 사람을 고용하는 것조차 매우 어렵다. 결국 게임 완성 예정 시한은 대책없이 늘어나게 된다.

사실, 이렇게 별 말 없이 나가주는 것만 해도 고마운 일이다. 엄연한 임금체불이기 때문에 나가버린 팀원이 신고할 경우 바로 [[고용노동부]]에서 개입한다. 아예 노무사나 법무사, 변호사를 고용하여 소송전을 벌이며 다양한 법적 공세를 벌일 수 있다. 그나마 이길 수 있다면 모르지만 애당초 잘못은 임금을 안 준 쪽에 있기 때문에, 붙으면 무조건 지는 싸움이 된다. 게임 개발에 쏟아부어야 할 기력과 정력, 자원을 소송전과 법적 처분에서 낭비하게 되는 꼴이다.

게임 개발에서 중요한 것은 개발능력이지만, 그 이상으로 중요할 수 있는 것이 법무 관련 지식이다. 인디 게임 개발자의 경우, 정확히는 사업을 시도하는 전문가 모두가 사업에 필요한 기술적 지식만 있는 경우가 많아 문제가 된다. 대개의 인디 게임 개발자는 자금력이 부족하고, 그래서 게임 잘 만들어도 소송이나 고발에 휘말리면 한 방에 파산할 수도 있다.

당신이 [[베타 테스트]]를 진행한다고 가정한다. 이런 경우, 보상 및 경품 지급을 위해 베타 테스터의 개인정보를 수집하는 경우가 있다. 그래서 당신은 베타 테스터들의 이메일, 핸드폰 번호를 수집하였다. 그런데 어느날 경찰에서 전화가 왔다. 개인정보수집을 위한 필수적 고지[* 개인정보보호법 15조 2항의 내용을 의미한다.[BR]'''대한민국 개인정보보호법 제15조 ②항[BR]개인정보처리자는 제1항제1호에 따른 동의를 받을 때에는 다음 각 호의 사항을 정보주체에게 알려야 한다. 다음 각 호의 어느 하나의 사항을 변경하는 경우에도 이를 알리고 동의를 받아야 한다.[BR]1. 개인정보의 수집ㆍ이용 목적[BR]2. 수집하려는 개인정보의 항목[BR]3. 개인정보의 보유 및 이용 기간[BR]4. 동의를 거부할 권리가 있다는 사실 및 동의 거부에 따른 불이익이 있는 경우에는 그 불이익의 내용]를 하지 않아 [[개인정보보호법]] 15조를 위반하여 과태료 600만원이 부과되었다는 것이다.[* 법조문으로 설명하면, 인디 게임 개발자가 '개인정보보호법 15조 2항'을 어겼고, 그래서 '개인정보보호법 75조 2항 1목'에 따라 과태료 처분의 근거가 생겼으며, 이에 개인정보보호법 시행령 '별표 2. 과태료의 부과기준(제63조 관련)'에 근거, 600만원의 과태료가 부과되었다는 말이다.] 설상가상으로 이를 확인한 어떤 베타 테스터가 개인정보 파기가 제대로 되지 않는 것 같다며 고발하였고, 결국 압수수색까지 들어왔다...

600만원이면 어지간한 인디 팀들 해체될 수준의 큰 돈이다. 거기에 더해 개인정보 관련 압수수색이니 게임 개발에 써야 할 컴퓨터 장비도 압수당한다면, 그냥 개발팀 해체하고 과태료 벌기 위해 알바라도 뛰는 것이 유일한 방법이다. 이후 이루어질 지리멸렬한 소송전은 덤이다. 고작 개인정보수집 고지 하나 안 했다고 이런 처분을 받을 수 있고, 이를 구실로 상당한 법적 공격을 받을 수 있는 것이다.

특히 요즘 모바일 게임의 경우 [[뽑기]]를 이용한 '인앱 결제'가 활발하다. 이 경우 문제가 되는 것은 전자상거래법과, 근래 도입할 가능성이 높은 [[확률형 아이템 규제 법안]]이다. 이 경우, 정부 기관의 처분도 무서우나 그 이상으로 무서운 것이 '''피해자들의 민사소송이다'''. 벌어들인 돈만 뱉으면 다행이고 위자료를 더 뱉어야 하는 것이 일반적이다.

게임 외적 문제도 크게 존재한다. 가령 [[클로저스 아트 팀 트위터 논란]], [[이터널 클래시]]와 얽힌 [[일베저장소]] 논란이 있다. 기껏 게임 잘 만들었으나 직원들의 [[알바테러]]에 가까운 행위로 인해 매출이 꺾여버리는 사태가 발생하고 있으며, 2010년대 이후 기준으로는 절대 게임 제작자가 무시할 수 없는 리스크로 부각하였다. 이렇게 팀 혹은 회사에 피해를 준 개발 인력에게 어떤 근거를 적용하여 배상액을 산정하고 배상을 받아낼 것인지, 이를 막기 위해 근로계약서에 어떤 조항을 끼워넣을 것인지는 철저히 법무적인 영역에 있다.

그 외에, 작품성보다 운이 더 중요하다는게 업계의 통설이기 때문에 아무리 게임을 잘 만들었어도 운이 따라주질 못하면 범람하는 게임들 속에 그대로 묻힐 가능성이 높다. 예를 들어 대학생들이 모여 만든 인디 게임인 [[던그리드]]는 그다지 특출날 것 없는 게임이라는 평가를 받지만 몇 없는 국산 인디 게임이라는 버프를 받고 스트리머들이 적극 홍보를 해줘서 대박을 터트릴 수 있었다. 그러니 운과 함께 마케팅 능력과 타이밍을 볼 줄 아는 사업가적 능력도 필요한다.

[[인디 게임]] 만들다가 대기업에 취업하는 경우도 많다.

==== 홀로 서기 ====
혼자 하기는 매우 힘들다. 최근에는 [[게임 엔진]]들이 매우 다양한 기능과 높은 직관성을 갖추고 있기에 [[프로그래밍]] 자체는 그럭저럭 수월하지만, 평범한 개발자가 그래픽, 사운드 관련 소양까지 갖춘 경우는 매우 드물기 때문에 이는 어쩔 수 없이 외주를 통해 진행하게 될 것이다.

물론 완전한 1인 개발이 아주 불가능한 것은 아니다. 미국이나 유럽 등지에서도 심심찮게 혼자 만든 게임들이 틈틈히 출시되고 있다. 그리고 개중엔 정발도 안 한 한국에서도 유명할만큼 인지도 높은 명작들도 많다. [[Dust: An Elysian Tail]], [[지오메트리 대시]], [[언턴드]][* 이 쪽은 개발자가 '''고등학교 3학년''' 때부터 혼자 만든 게임이다.] 등이 대표적이다. [[마인크래프트]]는 이 분야에서 가장 성공한 케이스라 볼 수 있다.[* 현재는 [[마이크로소프트]] 산하에 인수되고 [[마르쿠스 페르손|본 개발자]]도 은퇴한 상태라 더 이상 인디 게임이 아니지만, 시작은 분명 인디 게임이 맞았다.]

북미나 유럽의 경우 물론 여긴 저작권에 빡세서 일본처럼 남의 아이디어를 갖다 쓰는게 불가능한 문제가 있는 등 여건이 널널하지만은 않지만, 자기 회사 일 하면서 취미로 틈틈이 만드는 겸업 프로그래머도 있을 만큼 생활에 여유가 많은 경우가 대부분이라 나쁘지 않다. 심지어는 그냥 전업으로 게임 개발에 전념하는 개인들도 많다.

다만 한국에서 1인 게임 개발자로 살아가는데 있어선 사회적인 인식과 제도적인 어려움도 뒤따른다는 점을 감안해야 한다. 위에 적은 예시로 든 게임들은 대략 3년여 정도 걸렸는데, 한국에서 3년 씩이나 혼자 게임 개발한다고 하면 곱게 볼 사람은 거의 없을 것이다. 그렇다고 북미처럼 회사를 다니면서 틈틈이 하기엔 [[월화수목금금금]]의 압박이... 게다가 어떻게 만들어도 그 다음엔 [[게등위]]의 심사를 거쳐야 하는데 심사비의 압박이 덮쳐오고, 그것도 다 통과해 어찌어찌 내놓아도 복돌이 문제도 있어서 인디개발자의 앞날은 어둡다.

프로그래머는 지속적으로 코딩 스킬을 배우고, 이에 대한 피드백을 받으며 자신만의 노하우를 축적하면서 실력이 향상된다. 그런데 1인 개발은 팀작업을 할 수 없고 프로그래밍적인 테크닉과 스킬을 익히고 단련할 기회가 없다. 자신의 코드를 평가받고 수정해 나가야 좀 더 깊이있는 코드를 설계하고 작성할 수 있는데 그게 안 되다보니 몇 년을 해도 실력은 늘지 않는다.[* 마인크래프트로 최고의 상업적인 성과를 이루어낸 노치도 이러한 문제에 부딪히면서 자신이 불가능하다고 공언한 기능을 일개 모드 개발자가 구현시키는 사례가 여러 차례 있었고, 결국 마이크로소프트가 모장을 인수하자 마인크래프트의 코드를 갈아엎기도 했다.] 실력이 늘지 않으니 게임회사 취업도 매우 힘들게 된다. 다른 파트와는 달리 프로그래밍 파트는 기술면접이 상당한 비중이 있으며 대형 개발사에서 자주 시행하는 코딩 테스트는 별도의 연습이 없으면 대응하기도 어렵다. 프로그래밍은 기획이나 아트와는 달리 역량이 안 되면 팀 전체의 작업에 크나큰 문제를 일으킬 수 있기 때문에 대단히 까다로운 업무 프로세스를 가지고 있다.

오직 혼자서 완성도 높은 게임을 만들어 성공한 대표적인 예로 [[스타듀 벨리]]가 있다. 또한 [[발디의 수학교실]]처럼 오히려 작정하고 저퀄리티로 만들어 유명해진 게임도 있다.

일본은 혼자 만들었다는 동인 게임이 수두룩하다. [[뱅가드 프린세스]] 등이 그 예이다. 다만 주의해야 할 점은 일본계 동인 게임들은 그 배경의 특수성, 그러니까 대부분 기존에 존재하는 창작물들의 아이디어를 그대로 가져다 쓴(냉정히 말해 무단도용한) 2차 창작물들이 대부분인데 어지간하면 원작자들이 그걸로 돈을 벌어도 '동인이니까' 하며 넘어가주는 환경이 조성되어 있어서 가능하다는 점을 유념할 필요가 있다. 즉 기존에 있던 아이디어들을 그냥 그대로 가져다 썼기 때문에 아이디어 구상, 홍보 전략 구상 등 몇몇 면에서 시간과 예산을 절약하는게 가능했기에 혼자서도 충분히 만들 수 있었고 또 코믹 마켓 같은 안정적인 판매처가 존재해서 그걸로 수익을 벌 수 있으니 존속이 가능한 케이스이다.

==== 동업하기 ====
팀을 짜는 것은 쉬운 일이 아니다. 인디 게임을 실제로 출시할 수 있을 때까지 장기적으로 함께 할 수 있는 실력있는 사람을 구해야 한다. 나와 함께 하면 이 게임이 성공할 것이라는 믿음을 상대방이 가져야 한다. 즉, 나를 매우 실력있는 사람으로 보고 있고 인간적으로 무척 신뢰하고 있어야 한다.

인터넷으로 뜨내기 팀원을 구하면 저 두 가지 조건 모두 충족이 안 된다. 그래서 빠르게 많이 구한다 하더라도 갈등이 1~2개만 생기면 금새 흥미를 잃고 약속을 어기고 사라지는 경우가 흔하다. 인디게임의 성공이라는 건 객관적으로 판단할 수 있는 요건이 아니므로, '마음만 먹으면 어디서나 구할 수 있는 시시한 인간'과 굳이 싸워 가면서 끝까지 함께해야 할 이유가 없는 것이다. 

그래서 학교 친구, 오래 교류해 오면서 서로를 신뢰하는 사람과 하는 것이 이상적이다. 하지만 이 경우에도 같이 '일'을 하다 보면 싸우게 되는 일이 생각보다 많다. 그리고 갈등이 심한 팀은 장기적으로 결국 공중분해된다. 거기다 주변인물과 함께 하면 실력을 보증하기 힘들다는 문제도 생긴다. 

명확하고 논리적인 메뉴얼을 작성하지 못하는 [[게임 기획자]], 기능 구현할 줄 모르고 짜집기하는 [[프로그래머]]는 경계 대상이다. 그 전에 기획자와 개발자는 항상 충돌한다는게 함정이다. 의외로 이렇게 소규모로 만들어졌어도 유명한 팀이 제법 있다. [[Sugar Cube: Bittersweet Factory]]를 만든 터틀 크림이나 [[송 오브 더 월드]]를 개발중인 Team D.T.R. 등. 어려워 하지 않고 희망을 갖는 것도 좋다. 물론 위에서 지적한 문제들은 고려해가면서 말이다.

되도록이면 동업자는 나이차가 얼마 안나는 또래를 대상으로 구하는 것이 좋다.

굉장히 힘든 것이 동업인데 나는 프로그램을 하고 동업자1은 기획, 동업자2는 그래픽을 하기로 했다고 한다면 의견 조율이 힘들다. 여럿이 게임을 만들기 때문에 누군가 리더의 역할을 해야 한다. 하지만 동업자이고 파트가 다르지만 거의 동등한 위치이기 때문에 누군가의 말에 의해서 내 의견을 굽히고 남의 의견을 반영해서 일을 해야한다는 것을 불만 없이 받아 들이기란 여간 힘들지 않기 때문이다. 사장이고 직원이라면 시키는 대로 해야하니까 별 문제가 없는데 동업은 그렇지 않다. 내가 만들고 싶은 게임과 동업자1, 동업자2가 만들고 싶은 게임이 같을까? 누군가 주도해서 팀을 꾸렸지만 누구의 명령을 받고 그대로 해야하는 위치들이 아니라서 처음에 주도했던 사람이 만들고자 했던 게임이 나올 확률이 제로에 가깝다.

그럼 처음에 주도했던 사람이 만들고자 했던 게임이 잘될 게임이냐고 반문할 수 있겠지만 답은 그럴수도 있고 아닐수도 있다. 처음에 생각했던 반짝하는 아이디어 그대로 게임이 나온 경우와 의견이 분분해서 서로 타협해서 반짝하는 아이디어가 사라진채 만들어진 게임 둘 중 어떤 게임이 성공확률이 높은가를 본다면 전자일 것이다. 후자의 경우는 유행을 따라가는 경우가 많을수 있고 혹은 너무 개인취향일 가능성도 높다. 유행을 따라가면 이미 철지난 게임이 될 가능성이 높고 개인 취향일 경우 호불호가 너무 극명하게 갈릴 수 있다. 모바일 게임은 물론 짝퉁 게임도 재미있게 만들면 성공하는 경우가 있지만 대부분은 반짝이는 아이디어로 성공한 경우가 많다. 예로 모뉴먼트 밸리, Tiny Wings, INKS, Doodle Jump, 앵그리 버드가 있다. 앵그리버드를 처음에 생각해서 만들자고 했는데 동업자들이 너무 재미없다고 해서 그들의 의견을 반영 게임성이 틀려졌다면 성공 못했을 가능성이 더 많다고 보여진다.

== 컴공 외에서 배우기 ==
[[독학]]하는 것은 매우 힘들다. 따라서 게임학원을 다니는 것도 방안이 될 수 있다. 국비 지원하는 학원이 많으니 잘 알아보자.[* 최근에는 아예 국비과정을 도입하는 것이 대세화되고 있어서. 국비 과정이 없는 학원을 찾는 게 더 힘들 정도다.] 초창기 컴퓨터공학과가 없던 시절에는 수학과, 물리학과, 전기과, 전자과 등 출신들이 독학해서 했었다. 현대에는 인터넷의 발달로 정보를 얻기 쉬워졌지만 그만큼 하드웨어 역시 발전했기에 만드는 난이도가 매우 높아졌다. 예전 게임기의 메모리 용량만 봐도 현대와 엄청난 격차가 난다. 

유니티 엔진에서는 ShaderLab에서 있는 스탠다드 셰이더를 갖다가 쓸 수 있다. 실력을 쌓으려면 이것을 갖다 쓰는 대신 DirectX+HLSL 조합으로 직접 셰이더 구현을 해 볼 수 있다.

한편, 유니티의 스탠다드 셰이더를 갖다 쓰는 대신 [[유니티(게임 엔진)|유니티]] 셰이더를 커스터마이즈해서 쓰거나 직접 구현해볼 수 있다. 버텍스 셰이터 프래그먼트 셰이더 단계에서 직접 하드코딩을 해가며 스펙큘러 디퓨즈 노멀 메탈릭 등등을 구현해가며 실력을 쌓으면 기본적인 셰이더 구현이 하드코딩으로 가능해졌다고 느끼는 단계에 올라올 것이다. 그 이후에는 디퍼드 셰이딩이나 디퍼드 라이팅도 하드코딩으로 직접 구현 해 볼 수 있다. 그 후에는 직접 저널이나 논문을 영어로 읽어가며 LPV나 복셀 옥트리 같은 리얼타임 글로벌 일루미네이션을 구현해 볼 수 있다. 실시간 글로벌 일루미네이션을 구현하는 단계까지 오게 되면 수학적인 지식이 엄청나게 요구되지만, 머리가 좋고 자력으로 난관을 헤쳐나갈 근성이 있으면 학부생 수준에서도 시간을 많이 들이면 최소한은 구현 가능하다.

그러나 이런 유니티 셰이더 커스터마이징은 생각보다 제한적인 느낌이 강해서 [[DirectX]]+HLSL 조합에 비해 독학하기가 안 좋다. 유니티는 기본적인 light 관련 함수지원도 부실한 편이라 일일이 뜯어고치며 레고블럭 갖고 놀듯이 만들어가기가 매우 제약이 걸린다. 실무적인 능력을 키우고 싶다면 유니티 셰이더보다는 DirectX를 깊게 파는 것을 권장한다.

=== [[게임학과]] ===
게임학과 문서에도 서술되어 있듯이 국내의 게임학과들은 10년이 넘은 과가 거의 없을 정도로 역사가 짧고, 커리큘럼 역시 제대로 정립되어 있지 않다. 게다가 대학 특유의 비효율적인 교육과정 때문에 실력만 따지자면 2-4년제 게임학과 졸업생보다 오히려 현업 출신 강사에게 알짜배기 교육만 받는 학원 출신이 더 잘하는 경우가 많다.[* 이것은 비단 게임 프로그래머만 그런 것이 아니라 그래픽 디자이너 같은 다른 업계 직종도 마찬가지이다.] 아이러니하겠지만, 보통 대학교에서 게임학과에 있는 교수들은 게임업계 경력이 거의 없는 사람인 경우가 대부분이다. 심한 경우 [[컴퓨터공학과]] 출신 교수가 대신 맡는 경우도 비일비재하다.

이런 상황에는 나름 이유가 있는데, 대학 교수가 되기 위해서는 상당히 까다로운 과정을 거쳐야 하기 때문이다. 그렇기에 대학 교수가 될 정도로 노력한 사람은 현직 게임 프로그래머들에 비해 현업 경력이 상대적으로 적거나 없는 사람일 확률이 높다. 그렇다보니 교수들이 기본적인 [[OpenGL]]이나 [[DirectX]]의 지식도 별로 없고 게임 제작에 대한 지식도 별로 없다. 이렇게 가르치는 사람이 잘 모르는 채로 가르치는 상황이라 배우는 것 역시 별로 알차지 않다. 그나마 배우는 것도 학원을 다니거나 스스로 독학해가면서 알아가는 경우가 대부분이라서 현업에서 게임을 제작할때 사용하는 기법이나 노하우 같은걸 알 수도 없고 이해도 어렵다. 졸업작품을 보면 그럴듯하게 작품이 나오는 듯 하지만, 대부분의 경우는 날코딩하는 경우가 아니라 엔진을 쓰는 경우가 부지기수다. 얼핏 보면 결과물이 좋아 보여도 그건 엔진이 지원하는 기능이 좋아서 그런거고 작품이 학생들의 실력을 크게 반영하지 못한다.[* 엔진을 써서 만든 [[포트폴리오]]의 경우, 보기에는 화려하지만 만든 사람의 실력은 영 좋지 못한 경우가 많다. 엔진을 안 쓰고 만드는 경우가 있기는 있지만 매우 찾아보기 힘들다.]

그렇게 대학교에서 커리큘럼대로만 배우다 보면 실상 현업에서 쓰이는 기술은 거의 배우지 못한 상태가 되는데, 이 상태로 취업하면 부족한 실력이 드러나는 경우가 많다. 학교에 다닐 것이라면 현업에서 일하고 있는 졸업한 선배나, 동기 친구들과의 스터디를 통해 학교에서 제공하는 커리큘럼 이외의 방법으로도 실력을 쌓을 방법을 모색해야 한다. 별 생각없이 머리를 비우고 주어지는 것만 받아들이면서 몇년을 다니는 것은 학원에 1년 다닌 것보다 못할 수 있다.

다행히 시간이 지나면서 경험이 축적되고 체계가 점점 잡혀지면서 교육 여건 및 학습 여건이 나아지긴 했으나, 현업 개발 경력과 대학 교수 자격 과정을 모두 갖추는 것이 어려운 이상 이론적으로 배우면서 실무 경험에 도움이 되는 실습까지 제대로 학습하는데 한계가 있으므로, 결국엔 학교 커리큘럼에 없거나 미흡한 내용이 무엇인지 학생 스스로 찾아서 공부하고 익히려는 노력이 필요하다는 점은 변함이 없다.

== 콘솔 게임 프로그래밍 ==
게임에서의 멀티코어 프로세싱 기술은 2005년부터 등장한 7세대 콘솔 게임기인 [[엑스박스 360]]와 [[PS3]]부터 멀티코어 CPU를 달고 있었다. 메이저 콘솔 게임 개발사는 이미 7세대 콘솔 게임기 시절부터 한정된 CPU 자원을 거의 100% 다 쓰도록 프로그래밍 했다. 3코어 6스레드의 PPE를 가진 XBOX 360이나[* [[하이퍼스레딩]]을 지원하는 [[인텔 코어 i 시리즈]], 코어당 2-way [[SMT]]를 지원하는 [[AMD 라이젠 시리즈]]와 유사한 메커니즘이라고 생각하면 된다.][* 보통은 OS용 1스레드 + 게임 사운드 처리용 1스레드 + 나머지 4스레드로 할당해서 프로그래밍 했었다.] 1코어 2스레드의 PPE + 7코어 7스레드의 SPE를 가진 PS3 시절부터[* 해당 마이크로아키텍처인 [[CELL-Broadband Engine]]에서는 본래 메인 코어인 PPE 1개와 보조 코어인 SPE 8개로 구성되어 있는데, 수율 문제로 SPE 1개가 비활성화된 채 PS3에 채택되었다. PPE는 보통 게임용과 OS용 각각 1스레드씩 할당하고, SPE는 OS용 1스레드 + 게임 사운드 처리용 1스레드 + 나머지 5스레드로 할당해서 프로그래밍 했었다.] 게임 루프를 많게는 6스레드로 쪼개서 효율적으로 처리하도록 프로그래밍 하는 것이 가능했다.

2012년부터 등장한 8세대 콘솔 게임기 중에 고성능인 [[PS4]], [[PS4 Pro]], [[엑스박스 원]], [[엑스박스 원 X]]도 역시 멀티코어 CPU로 모두 8코어 8스레드 CPU를 달고 있다. 당시 고전력인 대신 고성능 태생이었던 7세대와는 다르게 초저전력 태생의 CPU라 싱글스레드 성능이 크게 향상되진 않았지만, 독립적인 사운드 프로세서가 탑재되어 게임용으로 할당 가능한 스레드 개수가 많아졌다.

하드웨어 사양에 소프트웨어 환경까지 천차만별인 PC와는 다르게, 다음 세대 콘솔이 나올 때까지 동일하고 고정되어있는 하드웨어에 맞춰 개발한다는 점 등, 콘솔 개발만의 이점은 분명히 있다. 안타깝게도 한국은 콘솔 게임의 인기가 상대적으로 적어 콘솔 게임 쪽 개발 경험을 가진 프로그래머가 매우 적은 편이다. 다만 2020년대 이후 [[3N]]과 [[펄어비스]]를 필두로 국내 게임사들의 콘솔 게임 시장 진출이 점진적으로 진행되고 있는만큼 수는 점차 늘어날 것으로 보인다.
== 기타 ==
1980년대까지는 [[어셈블리어]]가 필수적이었다.[* 요즘도 대부분의 컴퓨터공학과가 배우기도 한다.] 그러나 PC에서는 1990년대 초, 하드웨어의 발달로 휴대용 게임기에서는 1990년대 말 즈음 퇴출되었다. 그 이후에는 게임 프로그래밍 업계에서 어셈블리어의 지분은 거의 없는 상태다.[* 하우스 엔진이나 개발 언어의 마개조가 필요할 때나 겨우 쓴다.] 단 90년대 말에 퇴출되었다는 것은 메인 프로그램 개발 언어에서 퇴출되었다는 얘기이고, 2001년에 GPU에 제한적인 프로그래머블 셰이더가 나왔을 때부터 한동안 셰이더 코드는 독자적인 어셈블리로 코딩해야 했다.[* 모두 그런 것은 아니고, 예를 들어 [[게임큐브]] 의 GPU 는 TEV 라고 하는 제한적으로 프로그래밍 가능한 유닛이 탑재되어 있었는데 이것을 일종의 원시적인 프로그래머블 셰이더라고 볼 수 있다. 이 TEV 를 제어하기 위해 닌텐도는 TEVSL 이라고 하는 언어를 제공했다. 이는 어셈블리보다는 고수준이었다.] 물론 이는 메인 CPU 로 흔히 쓰이는 x86, ARM, MIPS 등의 어셈블리가 아니라 GPU가 쓰는 별도의 명령에 대한 어셈블리를 말한다. 다행히 2002년 말에 MS가 DirectX 9.0과 함께 발표한 HLSL이 셰이더 프로그래밍의 사실상 표준으로 자리 잡게 되면서 더이상 GPU 제조사별로 일일이 따로 배울 필요가 없게 되었고, C와 비슷한 형태의 하이 레벨 언어라 학습 난이도가 낮아지면서 불편하기 짝이 없는 독자적인 셰이더 어셈블리어는 자연스럽게 사장되었다. 대부분의 게임 프로그래머에게는 어셈블리어가 크게 중요하지 않은 상황이 되었음에도 여전히 성능 상의 이슈 혹은 멀티쓰레드 이슈 등으로 인해 빌드 후 어떠한 어셈블리가 출력되는지 알아야 할 경우도 가끔이지만 있다. 서버 개발의 경우 커널레벨에서의 데드락(Rtl로 시작하는 Windows 커널 API수준에서의 데드락) 발생시에는 우리가 윈도우 소스코드가 없기 때문에... 어셈블리 보고 디버깅해야되는 골때리는 경우도 발생할 수 있다. 물론 이는 예시일 뿐이며 알면 좋다 수준이므로 뉴비 수준에서 심각하게 여길 필요는 없다.
== 관련 문서 ==
 * [[비디오 게임]]
 * [[게임 개발자]]
 * [[프로그래머]]
 * [[프로그래밍]]

[[분류:컴퓨터 공학]][[분류:게임 개발자]]
게임 프로그래머 (덤프버전으로 되돌리기)

캡챠
