위키원
"게임 개발"의 두 판 사이의 차이
잔글 |
|||
| (사용자 2명의 중간 판 18개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''게임 개발''' | + | '''게임 개발'''은 [[게임]]을 만들고 출시하는 것을 의미한다. 분야로는 [[게임 기획자]], [[게임 디자이너]], [[게임 프로그래머]] 등 3가지 직종이 있다. 이 세 가지 분야팀들이 협력을 통해 게임이라는 하나의 결과물을 만들어 내는 것을 게임 개발이라고 한다. |
| − | == 게임 기획자 == | + | == 프로세스 == |
| − | + | === 준비 단계 === | |
| − | === 요구 능력과 담당 직무 | + | * '''게임 콘셉트 회의''' : 개발하고자 하는 게임의 전반적이 사항들을 결정하는 데 목적이 있으며 개발팀에서 진행한다. 참가자는 기획자, 프로그램 팀장(클라이언트, 서버), 그래픽 팀장(원화, 캐릭터, 배경) 정도가 될 수 있다. |
| + | * '''게임 시스템 기획''' : 개발하고자 하는 게임에 들어갈 핵심적인 시스템들을 개발자들이 이해할 수 있도록 결정하는 데 목적이 있으며 기획팀에서 진행한다. 참가자는 기획자, 시나리오 작가, 시스템 디자인, 레벨 디자인 정도가 될 수 있다. | ||
| + | * '''일정 및 리소스 관리''': 실질적 게임 구현에 필요한 리소스 양과 개발 일정, 그에 따른 인력 구성 등의 세부적인 계획을 수립하는 데 목적이 있다. 참가자는 기획자, 프로그램 팀장, 그래픽 팀장 정도가 될 수 있다.<ref name = "프로세스"></ref> | ||
| + | |||
| + | === 개발 단계 === | ||
| + | ; 그래픽 작업 | ||
| + | * '''시나리오 작업''' : 게임의 세계관 설정, 캐릭터 설정, 엔피씨(NPC) 설정, 몬스터 설정, 작업 일정 결정 등을 한다. | ||
| + | * '''원화 작업''' : 시나리오 결과물을 가지고 원화 작업을 진행한다. | ||
| + | * '''CG 작업''' : 원화 결과물을 가지고 그래픽 디자이너가 원화를 그래픽 툴을 이용하여 [[3D]] 또는 [[2D]]로 모델링한다. | ||
| + | * '''애니메이션 작업''' : 시나리오 결과물을 애니메이션(캐릭터 이동, 몬스터 피격, 이동) 작업을 진행한다.<ref name = "프로세스"></ref> | ||
| + | |||
| + | ; 시스템 기획 | ||
| + | * '''시스템 디자인''' : 시스템을 어떻게 기획할 지 생각하고 구현이 가능한지에 대해 생각하여 기획서를 만든다. | ||
| + | * '''레벨 디자인''' : 최종 기획서를 바탕으로 수치 디자인을 수정, 보완한다. | ||
| + | |||
| + | ; 레벨 디자이너, 서버 프로그래머 작업 | ||
| + | * '''스탯 및 테이블 구성''' : 게임에 적용되는 모든 스탯 및 테이블을 구현 가능한지에 대해 파악하고 최종적으로 스탯 및 테이블을 완성시키는 단계이다.<ref name = "프로세스">artistyang82, 〈[https://artistyang83.tistory.com/1230 게임 개발 프로세스 :: 크리에이티브 아티스트]〉, 《티스토리》, 2019-01-06</ref> | ||
| + | |||
| + | == 사용 엔진 == | ||
| + | === 유니티 === | ||
| + | [[유니티]](Unity)는 [[C#]]를 기본 스크립트 언어로 사용한다. C# 언어 자체가 [[C++]]에 비해 적응이 빠른 편이라 비 [[프로그래밍]] 직군도 많이 접근하게 된다. 유니티의 경우 스크립트 생성 시 모노비헤이비어(Monobehaviour)만을 상속받아 스크립팅을 하게 만들었다. 해당 파이프라인을 하나로 통일한 덕에 추가적인 기능은 [[언리얼]]에 비해 부족해 컴포넌트 애드온을 필요한 분량만큼 추가해 주어야 하지만, 그 대신 컴포넌트를 붙이는 데 제약이 적고 수정 시 에디터 상에 즉각 반영이 되는 핫 리로드 기능이 굉장히 강력하게 구비되어 있다. 주 언어가 C#인 것도 한 몫 하는데, 어느 객체를 만들었으면 해당 객체에 대해서만 컴파일이 완료되면 바로 실행이 가능하다. 그렇기에 스크립트의 추가가 굉장히 자유롭고 에디터상에서 직관적이고 즉각적으로 반영이 가능하다. 보통 웬만큼 크지 않는 이상 스크립트를 수정하면 바로 에디터 창으로 돌아와 실행이 가능할 정도라 자체 피드백 순환과 매우 빠르게 처리할 수 있다는 이점이 있다. 이러한 강점은 개별 오브젝트에 눈에 보이는대로 컴포넌트를 붙이면 사용자가 모르는 새 컴파일되면서 사용 가능한 상태로 바꾸기 때문에, 필요한 요소는 그때그때 만들어 쓸 수 있다는 강점을 가지고 있다. 문제는 비 프로그래밍 직군 작업자에 대한 편의는 적은 편이다. 언리얼을 따라 비주얼 스크립트를 개발했지만 사실상 유명무실하며 결국에는 비 프로그래밍 직군의 인원도 코드를 알아야 정확한 작업을 진행할수 있다. 유니티는 엔진 소스 코드를 제공하지 않아 소스 코드를 제공받기 위해서는 별도로 고가의 계약 체결이 필요하다. 그렇기 때문에 고수준의 작업에서는 자잘한 문제가 발생하고, 이를 피하고 개선하기 위해 우회를 반복하다가 어느새 엔진 내 소스를 꼬아서 만드는 경우도 더러 있다.<ref name = "게임 엔진">〈[https://namu.wiki/w/%EC%96%B8%EB%A6%AC%EC%96%BC%20%EC%97%94%EC%A7%84%20vs%20%EC%9C%A0%EB%8B%88%ED%8B%B0%20%EC%97%94%EC%A7%84 언리얼 엔진 vs 유니티 엔진]〉, 《나무위키》</ref> | ||
| + | |||
| + | === 언리얼 엔진 === | ||
| + | [[언리얼 엔진]](Unreal Engine)은 미국의 [[에픽게임즈]]에서 개발한 3D [[게임엔진]]이다. 초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진 4는 스크립팅 언어로서 새로운 언어를 배워야 하는 부담을 없애기 위해 언리얼 엔진 3까지 써오던 [[자바]] 스타일의 언리얼 스크립트를 제거하고 보다 대중적으로 다가서기 위해서 게임 프로그래머들에게 익숙한 C++를 채용했다. [[언리얼 엔진]] 4는 아래에서 언급될 비주얼 스크립팅 언어인 블루프린트와 프로그래밍 스크립트 언어를 함께 사용하여 복잡한 구조나 퍼포먼스가 필요한 부분은 프로그래밍 언어로 구성하고, 가변성이 높은 부분은 디자이너가 간단히 변경할 수 있게 블루프린트로 구성하여 상호 보완적으로 활용 가능하다. 그렇기 때문에 타 직군과의 협업이 굉장히 원활하다. 한편, 언리얼 C++의 경우는 공식적으로 핫 리로드를 지원한다고는 하지만 실상은 유명무실하다. 일단 핫 리로드 자체에 문제가 많아 제대로 동작하지 않는 경우가 자주 발생한다. 또한 기존 엔진에서 상속받을 스크립트부터 찾아야 하기에 스크립트 추가 시 거의 반드시 엔진 컴파일 과정이 추가된다. 이는 C++ 각 객체별로 컴파일을 할 수 있는 것이 아니기 때문에, 엔진에서부터 시작한 상속받은 스크립트 전부 다 컴파일이 진행되어야 사용 가능하기 때문이다. 언리얼의 다양한 기능도 되려 핫 리로드를 구현할 수 없을 지경으로 분할되어 있는 것도 한 몫 한다. 간단하게 되어야 할 추가 모듈부터 엔진단에 포함되어야 실행되기 때문에 엔진을 통으로 컴파일을 진행해야 하는 불상사가 생긴다. 그래서 에디터상에서 컴포넌트를 즉각 붙이는 행위를 막아 놓았으며, 해당 문제를 에디터상에서 해결하기 위해서는 블루프린트로 재생성한 뒤 수정해야 한다. 즉, 블루프린트 기능은 유니티보다 타 직군과의 연계 작업을 우월하기 위해 만든 기능이 아니라, 실상은 컴파일 횟수를 조금이라도 줄이기 위해서 만든 수단으로써 출발했던 것이다. | ||
| + | |||
| + | 블루프린트 기능은 언리얼 엔진의 작업 속도를 늦추는 요인으로 꼽힌다. 또한 블루프린트 자체도 빠른 편이 아니다. C++로 코딩했을 때 20엠에스(ms)인 코드가 블루프린트로만 작성했을 때는 상황에 따라 5~15배 느린 100엠에스(ms)~300엠에스(ms)의 속도 차이가 발생하는 경우도 더러 있다. 그래픽 직군에서 쉐이더 적용이나 기획 쪽에서 프로토타입 적용에 유용하게 사용 가능하지만, 프로그래밍 직군에서는 100% 블루프린트 코드를 짠 게임은 있을 수도 없으며 정말 존재한다면 사실상 프로그래머를 뽑을 이유가 없고, 최적화를 위해 반드시 C++ 코딩이 필요한데 C++ 코딩은 상술했듯이 상당히 공과 시간을 많이 들여야 한다. 언리얼 엔진은 2015년 3월 이후 버전 4의 소스 코드 전체를 공개한다는 점은 굉장한 강점이다. 복잡한 코딩이 가능한 프로그래밍 전문가가 있는 팀의 경우에는 여러모로 언리얼 엔진이 훨씬 더 낫다. 언리얼 C++의 빌드 툴의 지속적인 개선과 엔진을 직접 건드릴 수 있는 강점이 있기 때문이다. 또한 엔진 자체에서도 제공하는 기능이 굉장히 많기 때문에 엔진에 있는 기능만 사용해도 유연하게 해결되는 경우가 상당수이다. 또한, 언리얼 엔진 4 문서에는 언급이 되어 있지 않지만 해외 커뮤니티에서는 C++ 대신 C#을, 혹은 스크립트 언어인 [[루아]](Lua)나 [[러디]](Rudy) 등을 언리얼에서 사용하는 방법에 대해 연구하기도 하고 실제로 그러한 스크립트 언어를 사용하여 개발하고 출시한 상용 게임도 있다. 언리얼 엔진 5와 더불어 벌스(Verse)라는 새로운 스크립팅 언어를 공개했다. [[파이썬]](Python)과 비슷한 문법 구조를 채택하고 있어 해외 커뮤니티에서는 배우기 쉽고 블루프린트를 대체해 줄 것으로 예상하고 있다.<ref name = "게임 엔진"></ref> | ||
| + | |||
| + | === 두 엔진의 본질적 차이 === | ||
| + | 흔히 착각하는 것이 두 엔진을 그저 퀄리티나 언어만 다른 비슷한 도구로 생각하는 것인데, 두 엔진의 개발 방식 접근성은 극명하게 다르다. 대표적인 예시로 유니티는 기본 기능이 비교적 빈약하고, 소스를 고칠 수 없는 대신, 기능이 매우 가볍고 사용하기 간편하며 에셋 및 패키지를 구매하거나 덧붙여 보강이 원활하여 추가 모듈을 부착하거나 떼는 식으로 대응한다. [[언리얼 엔진]]은 엔진 자체에서 대부분의 강력한 기능을 제공하지만, 개발사인 에픽게임즈의 방향성에 맞춘 기성품에 더 가까워 상대적으로 확장성이 제한된다. 엔진의 성능을 제대로 활용하기 위해서는 고급 인력 또는 방대한 규모의 팀이 필요하다. 당연히 언리얼에도 에셋에 대응하는 플러그인이 존재하지만, 이것으로 기능을 늘려나가기에는 한계가 있는 데다, [[플러그인]]을 정리하지 않으면 프로젝트 전체가 크래시가 나기 쉬워 적용할 때도 상당히 많은 주의를 요한다. [[유니티]]의 경우 입력 메시지의 흐름이나 렌더링 구조를 포함한 엔진의 대부분이 나뉘어져 제각기 접근하고 조립할 수 있다. 예를 들어 렌더링의 경우 쉐이더를 편집한다고 할 때 게임 데이터의 모든 단계를 쉐이더에 사용하고 대부분의 경우 원하는 만큼 충분한 큐잉과 컬링 분류를 할 방법을 제공한다. 대신 그 각각의 기능을 조립하고 옵션을 짜맞추는 것은 개발자의 몫이며, 점점 하이퀄리티로 올라갈수록 코스트 또한 장난 아니게 높아진다. 후반부로 갈수록 퀄리티 상승을 위해 처리해야 될 문제들이 산더미처럼 쌓이며, 이는 프로젝트 중후반부에 진입한 게임사들이 언리얼로 전환하는 원인이 되기도 한다. 반면 언리얼의 경우는 회사에서 사용된 엔진으로 시작하였으므로, 상용게임에서 원하는 고도의 추상화가 원래 다 이루어진 상태에서 자유도를 확장시키는 방식으로 범용 엔진으로 만든 것이기 때문에 기본적으로 에픽게임즈에서 만든 게임의 아키텍처대로 만들도록 되어 있다. 마찬가지로 렌더링의 예를 들자면 원래 주어진 렌더링 파이프라인의 퀄리티는 좋고 원래 제공된 옵션들 중에서 골랐을 대의 편의성은 좋지만 이것을 수정해서 원하는 것을 창조하려고 한다면 유니티처럼 [[쉐이더]]를 갈아 끼우는 방식으로는 불가능하고 [[렌더링]]된 결과를 후처리 가공해서 효과를 주거나 아예 엔진 소스를 고쳐서 방식을 우회시켜야 한다. 구체적으로는 쉐이더를 바꾸기 위해서 쉐이더를 생성해 주는 엔진의 기능인 머터리얼 에디터의 입력인 머터리얼을 변경하는 식으로 간접적으로 변경하고, 그 결과로 렌더링된 최종 결과물을 포스트 프로세싱해야 한다. | ||
| + | |||
| + | 유니티처럼 렌더링 자체를 카툰 쉐이더로 하려면 엔진 내에서 머터리얼에서 쉐이더의 생성 코드를 수정해 사용자가 원하는 라이팅 정보를 참조할 수 있도록 만들어야 하며, 라이팅와 연관된 엔진의 다른 여러 부분의 코드들도 그에 맞게 수정해 주어야 한다. 이러려면 당연하게도 쉐이더와 렌더링 파이프라인에 관련하여 프로그래머로서의 상당한 지식을 필요로 하게 된다. 1인칭으로 환경 위에서 캐릭터를 컨트롤하는 구조를 만들려고 할 때, 언리얼이 이미 제공되는 입력, 입력 컨트롤러, 플레이어 컨트롤러, 페르소나 구조를 사용하여 거의 건드릴 것도 없이 상용 수준으로 다양하고 풍부한 조종이 가능한 결과물을 뚝딱 만들어 낼 수 있으나, 그냥 키보드의 W키가 눌릴 때 박스 하나의 좌표가 X방향으로 1미터 바뀌었으면 좋겠다는 근원적인 제어를 원할 때 다른 모든 오브젝트 필요 없이 박스 하나를 놓고 스크립트에서 W키->X좌표 +1 이라는 직결 구조를 만들 수 있는 것은 유니티이다. 언리얼 엔진 4 초기 버전의 이슈였던 '반투명 물체를 만들기 힘들다' 역시 이러한 구조적 차이 때문이다. 반투명 물체의 품질 유무가 가장 극명하게 드러나는 것이 머리카락 부분인데, 이 때문에 언리얼 엔진에서 높은 퀄리티로 제작된 여러 작품들이 머리카락 부분만 튀거나 고생해서 여러 우회 기법을 적용한 모습을 볼 수 있다. 이러한 차이 때문에, 양 엔진의 에셋 스토어에서 뭔가 고급 기능들을 보면 유니티의 경우 엔진에서 돌아가는 [[스크립트]] 코드 혹은 엔진과 함께 돌아가는 플러그인 형태로 제공되는 반면 언리얼의 경우 엔진의 특정 기능을 커스텀 한 것이 에셋으로 제공되는 경우도 있다. 언리얼 엔진이 소스코드를 완전히 제공하는 데 반해 유니티 엔진은 제한적인 것을 보고 전자는 개방적, 후자는 폐쇄적이라고 생각하기 쉽지만, 이 역시 엔진의 기초 구조 자체가 다르기 때문이다. 언리얼의 경우 엔진 그 자체는 기성품처럼 제약되고 다듬어진 기능들만을 제공하면서 어느 이상 기능 자체를 확장하고 싶으면 필연적으로 엔진의 [[C++]] 소스 코드 자체를 수정하고 다시 빌드를 하는 쪽으로 나아가게 된다. 엔진 개발사에서도 그쪽을 염두에 두고 권장하고 있다. 반면 유니티의 경우 엔진에서 제공하는 인터페이스만을 가지고도 충분히 확장해 나갈 수 있도록 확장 가능성과 범용성을 목표로 처음부터 설계되어서 엔진 자체를 수정해서 기능을 늘려야 할 필요성이 거의 없다. | ||
| + | |||
| + | 유니티는 이러한 취지에서 유알피(URP), 에이치디알피(HDRP) 등 렌더링 파이프라인 자체를 사용자가 구성할 수 있는 추가 옵션을 제공하는 등 엔진 자체에서 제공하는 가능성을 확장하는 방향으로 발전해 나가고 있다. 이렇게 유니티와 언리얼은 두 가지 엔진에서 이 기능을 할 수 있느냐 없느냐, 단순히 결과물이 멋지느냐 아니냐의 단순한 문제가 아니라, 어떤 엔진, 어떤 결과물을 원하느냐의 조합에 따라 개발자가 학습해야 하는 정보와 개발하는 경로가 완전히 달라진다는 것을 알 수 있다. 엔진 자체의 보안성에 대해서는 둘 모두 큰 차이가 없다. 일단 유니티는 [[닷넷]](.NET) 기반에 다이나믹 로더를 사용하지만, 그 부분은 게임 로직을 만드는 스크립팅 언어로써 [[C#]]를 활용하는 것이지, 엔진 자체는 C++이라서 유니티와 비교해도 큰 차이가 없다. 하지만 게임 로직 코드는 넷(NET)을 사용하는 유니티가 압도적으로 털리기 쉽다. 반면 C++을 이용하는 언리얼 엔진은 게임 로직도 어셈블리로 컴파일되기 때문에 상대적으로 안전하다. 하지만 요즘은 유니티 역시 C++로 번역 후 컴파일하는 아이엘2씨피피(IL2CPP)를 지원하고 있고, 최근의 대규모 개발들은 대부분 중요한 비지니스 로직은 서버에 두고, 클라이언트는 서버에서 데이터를 얻어와서 사용하는 구조로 만들어지기 때문에 보안 수준은 결정적으로 프로그래머가 보안 요소를 얼마나 적용하느냐가 결정한다. 하지만 싱글 플레이어 게임을 만든다면 언리얼을 쓰거나, 유니티를 쓴다면 중요 코드를 C++로 작성하는 것이 보안에 도움이 될 수도 있다.<ref name = "게임 엔진"></ref> | ||
| + | |||
| + | == 직업군 == | ||
| + | === 게임기획자 === | ||
| + | [[게임기획자]]는 PC 게임, 네트워크 게임 등 게임용 소프트웨어 제작과 관련된 모든 사항들을 총괄적으로 지휘하고 감독하는 일을 담당한다. 주요 업무는 게임 시장 조사 등을 통해 소비자들이 좋아하고 원하는 게임이 무엇인지를 파악하고, 새로운 게임 제작을 위한 아이디어를 구상하여 이에 대한 기획안을 작성한다. 또한 게임의 장르와 대상 연령층, 게임 난이도, 게임의 각종 캐릭터의 역할 및 특징, 기본적인 스토리 전개 등을 설정하고, 그래픽 디자이너, 프로그래머 등과 함께 본격적으로 게임 프로그램을 제작한다. 게임소프트웨어에 대한 베타테스트를 하고 시연회에 참여하는 등 홍보 업무를 하기도 한다. 대사를 작성하는 등 세부적인 게임 시나리오를 작성하고, 기획의도를 이해하기 쉽게 그래픽디자이너나 프로그래머 등에게 전달한다. 그리고 게임이 제작되어 상품화가 되었을 때 시장 진입이나 판매고의 수익을 올릴 수 있을지를 판단,결정한다. 게임의 제작이 완료되면, 게임의 홍보와 마케팅 전략, 배급 등에 대한 계획을 수립하고 실행한다.<ref> 〈[https://www.career.go.kr/cnet/front/base/job/jobView.do?SEQ=923 게임기획자]〉, 《커리어넷》 </ref> | ||
| + | |||
| + | ;요구 능력과 담당 직무 | ||
기획자에게 요구되는 역량은 게임마다 달라진다. 기본적으로 프로젝트 관리 역량을 갖추어야 하며, 추가적으로 개발할 게임에 필요한 능력 전반에 대해 알아야 한다. | 기획자에게 요구되는 역량은 게임마다 달라진다. 기본적으로 프로젝트 관리 역량을 갖추어야 하며, 추가적으로 개발할 게임에 필요한 능력 전반에 대해 알아야 한다. | ||
| − | * 시스템: 게임에 기반이 되는 시스템 및 프로그램적으로 개발되는 요소를 책임진다. 프로그래밍 관련 지식이 필요하다. | + | * '''시스템''' : 게임에 기반이 되는 시스템 및 프로그램적으로 개발되는 요소를 책임진다. 프로그래밍 관련 지식이 필요하다. |
| − | * 시나리오: 게임에 기반이 되는 스토리, 캐릭터, 퀘스트 등 | + | * '''시나리오''' : 게임에 기반이 되는 스토리, 캐릭터, 퀘스트 등 텍스트와 등장할 캐릭터 요소를 책임진다. 문화 예술 관련 지식이 필요하다. |
| − | * 레벨 디자인: 게임에 기반이 되는 맵에 사이즈, | + | * '''레벨 디자인''' : 게임에 기반이 되는 맵에 사이즈, 배치 요소를 담당한다. 건축과 크기에 따른 공간적 지식과 플레이타임 등을 계산할 게임적 지식이 필요하다. |
| − | * 운영: 게임내 운영 업무로 기획한 내용에 반영 | + | * '''운영''' : 게임내 운영 업무로 기획한 내용에 반영 되었을 때 운영에 관련 내용을 담당한다. 라이브 기획자가 주로 다른 기획 업무와 병행하는 업무이다. |
| − | * 밸런싱: 게임에 수치들을 담당하며, 데이터와 수학지식, 게임룰에 따른 수치화에 대한 통찰력이 필요한다. | + | * '''밸런싱''' : 게임에 수치들을 담당하며, 데이터와 수학지식, 게임룰에 따른 수치화에 대한 통찰력이 필요한다. |
| − | * 게임 내 경제: 게임 내 경제를 | + | * '''게임 내 경제''' : 게임 내 경제를 시뮬레이션할 능력과 지식이 필요하다. 게임 내 몬스터 드랍, 획득 게임머니 등 요소를 담당한다.<ref name = "나무위키"> 〈[https://namu.wiki/w/%EA%B2%8C%EC%9E%84%20%EA%B8%B0%ED%9A%8D%EC%9E%90 게임 기확자]〉, 《나무위키》</ref> |
| + | |||
| + | === 게임그래픽디자이너 === | ||
| + | [[게임그래픽디자이너]]는 컴퓨터 게임 등에 등장하는 각종 캐릭터와 배경, 아이템 등을 디자인하는 역할을 한다. 게임기획자와 게임시나리오작가가 구상한 내용을 참고로 캐릭터와 배경화면 등을 구상한다. 그리고 스케치 작업을 거쳐 색을 입히는 컬러링 작업을 한다. 작업 계획을 세운 후 그래픽 소프트웨어를 이용해 캐릭터의 모습과 주요 움직임, 아이템, 배경화면을 구성하여 모니터에 그려 넣는다. 게임 제작이 완성된 후 캐릭터나 배경이 어색한 곳은 수정하고 보완한다. 게임 상에 보이는 메뉴, 창, 설정 창 등의 인터페이스(interface)를 제작한다. 그리고 나서 원화가가 그린 캐릭터나 배경을 3D프로그램을 이용하여 만든다. 모델러가 만들어 놓은 입체물에 색감이나 질감을 입히는 것이다. 또한 반복되는 동작들을 정교화하고, 마법이나 기술 등 각종 효과를 제작한다.<ref> 〈[https://www.saramin.co.kr/zf_user/cms/job-information/view?idx=08552&dtlGb=2 게임그래픽디자이너]〉, 《사람인》 </ref> | ||
| + | |||
| + | ==== 게임원화가 ==== | ||
| + | [[게임원화가]]는 게임 제작자의 한 종류로, 그래픽 파트에서 콘셉트 원화를 담당하고 그리는 사람이다. 게임 원화는 3D나 2D그래픽을 제작하기 전에 기초적인 도안, 즉 가이드라인이 되는 그림을 말하며, 색 지정과 의복, 아이템의 디자인이 주로 하는 작업이다. 게임원화가는 캐릭터원화가와 배경원화가로 나뉜다. 본인 실력과 디자인에 취업이 크게 결정되는 파트 원화가는 콘셉트 아티스트(concept artist)라고도 불리며, 게임에서 드러내려는 이미지를 그려내는 직업군이다. 배경 원화가는 건물, 자연 등의 도안과 디자인을 담당하며 배경을 그릴 때 설계 구도가 굉장히 중요한 요소로 작용한다. 캐릭터 원화가는 캐릭터의 전반적인 설정을 담당하는 역할을 하며 무기 원화가, 몬스터 원화가 등으로 나뉘기도 한다. 캐릭터 원화가에게는 기본적으로 드로잉 실력이 요구되며 이를 위해 인체구조에 대한 이해가 필요하다. 또 캐릭터 원화가는 인체만 그리는 것이 아니라 의복, 몬스터, 무기 등 다양한 영역의 그림들을 그려야 하므로 다양한 자료들을 바탕으로 보다 많은 것들을 그릴 수 있는 능력을 키워야 한다.<ref name = "게임 그래픽"></ref><ref> okydokymacintosh, 〈[https://m.blog.naver.com/okydokymacintosh/221237806533 게임원화가란?]〉, 《네이버 블로그》, 2018-03-26 </ref> | ||
| + | |||
| + | ==== 게임모델러 ==== | ||
| + | 게임모델러는 배경을 담당하는 배경 모델러와 캐릭터를 담당하는 캐릭터 모델러가 있다. 게임모델러는 캐쥬얼인지, 반실사인지, 실사인지에 따라 제작 방식이 조금씩 달라질 뿐 다룰 줄 알아야 되는 프로그램은 거의 동일하다. 쓰리디맥스 또는 마야, 바디페인터, 제트브러쉬가 기본적이며, 최근 게임 산업에서 실사풍이 중요해지면서 서브스텐스 쓰리디오 등 피비비 쪽도 어느 정도 알아야 한다. 다른 파트에 비해 새로운 프로그램과 트렌드가 등장했을 때 심하게 타격받는 파트이다. 모델러는 원화에 있는 캐릭터, 아이템, 건물, 배경 등 게임에서 보이는 모든 것들을 3D 이미지로 구현한다. 이른바 게임 디자인의 뼈대인 원화에 쓰리디로 살을 붙이는 작업이라고 할 수 있다. 배경 모델러는 원화에 있는 제품, 건물, 도로나 전체적인 지형을 그래픽으로 만들며 원화의 전체구도 및 원근감 등의 관련된 부분을 3D로 만들어야 한다. 캐릭터 모델러는 인체 구조를 기반으로 모델링을 진행해야 한다. 따라서 구조 이해도를 위한 정물, 인물 등을 잘 그려야 하며 원화가 못지 않은 이해도를 가져야 한다. 게임 툴인 쓰리디 스튜디오 맥스와 애니메이션 툴인 마야 등을 다룰 줄 알아야하며 포토샵으로 컬러, 질감, 표정들을 입히는 맵핑 작업 및 다양한 맵핑 소스들을 활용할 수 있어야 한다. 또, 세밀한 표현을 위해 2D와 3D의 중간을 표현할 수 있는 지브러시 머드박스와 같은 프로그램을 다룰 수 있으면 좋다. 3D 그래픽 디자이너들의 작업 과정을 간략히 설명하자면 다음과 같다. | ||
| − | + | * '''원화 분석''': 먼저 원화가로부터 콘셉트 원화를 받아 분석한다. 참고로 3D로 구현해야 하기 때문에 구조의 움직이는 부분이 따로 필요하며, 다양한 시점으로 표현된 원화 또한 필요하다. 모델러는 넘겨받은 원화에서 만들어야 할 이미지의 콘셉트를 파악하고 특징을 어떻게 표현할 것인지 결정한다. | |
| − | + | * '''모델링''' : 원화를 3D로 조형한다. 최대한 원화의 느낌을 살리는 것이 중요하지만 3D로 구현할 수 없거나, 고쳐야 할 부분이 있을 경우 수정해 가며 모양을 만든다. | |
| − | + | * '''텍스처 작업''' : 완성된 모델링 이미지는 색이 존재하지 않거나 단색이다. 여기에 색과 표면의 질감을 살리기 위해 텍스처를 입힌다.<ref name = "게임 그래픽"></ref> | |
| − | + | * '''게임엔진 적용''' : 텍스처를 마무리하고 완성된 3D 이미지를 게임에서 쓰기 위해 게임엔진에 적용한다.<ref name = "게임 그래픽"> 〈[https://namu.wiki/w/%EA%B2%8C%EC%9E%84%20%EA%B7%B8%EB%9E%98%ED%94%BD%20%EB%94%94%EC%9E%90%EC%9D%B8 게임 그래픽 디자인]〉, 《나무위키》</ref> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | * 원화 분석: 먼저 원화가로부터 | ||
| − | * 모델링: 원화를 3D로 조형한다. 최대한 원화의 느낌을 살리는 것이 중요하지만 3D로 구현할 수 없거나, 고쳐야 할 부분이 있을 경우 수정해 가며 모양을 만든다. | ||
| − | * | ||
| − | * 게임엔진 적용: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | + | ==== 이펙터 ==== |
| − | + | [[이펙터]]의 주 업무는 타격, 스킬, 움직임, [[사용자 인터페이스]](UI) 등 게임 화면상의 나타나는 모든 효과를 다루는 일이다. 대부분 먼저 만들어 놓고 차후에 타이밍이나 색감, 길이 등을 맞춰보는 튜닝 작업으로 이루어진다. 이펙터는 원화를 참고하여 그리기도 하지만 이미지가 전부 제시된 것은 아니기 때문에 어느 정도 감각이 있어야 한다. 이펙터는 단순히 효과만을 만드는 것이 아니라 캐릭터의 동작과 연계된 효과도 생각해야 하기에 애니메이션과 모델링 등 전반적인 작업을 모두 할 수 있어야 한다. 포토샵 애프터 이펙트 쓰리디맥스의 초급에서 중급은 되어야 되며 추가로 각 회사에서 요구하는 엔진의 이펙트 툴도 같이 알아야 된다. 어떻게 보면 이펙터가 다룰 줄 알아야되는 프로그램은 제일 많을 것이다. 그만큼 귀한 직업군이기도 하고 제일 화려하고 게임의 타격감에 지대한 영향을 끼치는 분야이기도 하다.<ref name = "게임 그래픽"></ref> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | + | ==== 애니메이터 ==== |
| − | + | [[애니메이터]]는 완성된 캐릭터나 몬스터 등에게 행동력을 주는 사람이다. 모든 입력 장치에 들어가는 애니메이션을 각각 만들고 이 애니메이션을 부드럽게 연결하는 작업을 한다. 애니메이터는 작업할 때 포즈와 타이밍이 서로 어긋나지 않도록 연결해야 하며 모든 동작은 기획서, 세계관, 캐릭터의 성격에 맞게 각각 구현되어야 한다. 때리는 동작과 사운드, 리액션을 타격감이라고 하는데, 타격감을 맞춰 주는 것도 애니메이터의 역할이다. 게임 애니메이터는 원화가가 작업한 작업물을 바탕으로 모델링한 각각의 캐릭터에 움직임을 줄 수 있는 부분(관절과 표정 등)을 넣어 명령에 맞춰 움직일 수 있도록 만드는 작업을 한다. 애니메이터의 역량을 키우려면 크로키를 통해 순간적으로 인체의 구조를 파악하는 훈련을 하면 좋다. [[2D]]인지, [[3D]]인지에 따라, 그리고 회사에서 어떤 엔진으로 게임을 제작해느냐에 따라 다룰 줄 알아야 되는 툴이 조금씩 틀리다. 2D는 라이브2D, 스파인이 기본적이라 봐야 되며 3D는 쓰리디맥스가 제일 압도적이며 그 다음 마야를 알아야 한다. 캐릭터와 배경의 소품 등 움직이는 것들을 움직이게 해 준다.<ref name = "게임 그래픽"></ref> | |
| − | === | + | |
| − | + | === 게임 프로그래머 === | |
| − | + | [[게임 프로그래머]]는 프로그래밍을 통해 맵 디자인, 캐릭터 디자인, 사운드, 각종 시스템 등을 뒤섞어, 게임이라는 하나의 결과물을 만드는 직군이다. 게임을 만드는 데 있어 가장 귀중한 인력이다. 실제로도 게임 업계에서 프로그래머의 연봉이 기획자나 그래픽 디자이너보다 높은 경우가 많다. 수십, 수백 명의 개발자들이 필요한 트리플에이 게임들은 다양한 분야의 전문가들을 필요로 한다. 아직도 수많은 사람들이 게임 프로그래밍의 대해서 착각하는 것 중 하나인데, 같은 게임 프로그래머라고 해도 전문 분야가 다르면 필요한 지식, 경력, 성격, 등등이 완벽하게 달라진다.<ref name = "게임 프로그래머"> | |
| − | + | 〈[https://namu.wiki/w/%EA%B2%8C%EC%9E%84%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8 게임 프로그래머]〉, 《나무위키》</ref> | |
| − | === | + | |
| − | ==== 그래픽 | + | ==== 게임플레이 프로그래머 ==== |
| − | + | [[게임플레이 프로그래머]]는 만능형 프로그래머(Generalist Programmer)가 많다. 다른 프로그래머들은 게임 엔진 쪽으로 더 가깝고 게임플레이는 말 그대로 '유저들이 게임이라고 느끼는' 부분을 뜻한다. 카운터 스트라이크를 예로 들면 플레이어의 움직임, 총기의 작동 원리, 폭탄이 폭파하면 테러리스트가 승리한다는 규칙 등이 다 게임플레이다. 게임을 사랑해서 게임 프로그래머가 됐다면 웬만하면 이쪽으로 간다. 게임 규모가 작으면 난이도가 다른 분야보다 낮다. 수학의 경우 방향 관련 계산을 하기 위한 선형대수학의 기초만 대충 알면 괜찮다. 하지만 게임 규모가 커지면 접하게 되는 코드의 분야가 너무 넓어지기 때문에 다른 분야보다 쉽지 않다. 이러면 전혀 모르는 분야라도 기초적인 부분을 공부해서 대강 이해를 할 줄 알아야 한다. 그러려면 '컴퓨터 게임'을 이해를 하고 분야를 좋아해야만 일이 된다. 트리플 에이 규모쯤 가보면 어느 날은 엔피씨의 비행 능력을 위해서 팔진트리로 3D 최단 경로 찾기 알고리즘을 공부하고, 그 다음 날은 두 명의 플레이어 캐릭터들의 잡기 공격을 어떻게 코딩해야 렉이 있는 상태에서 두 명이 동일한 상황을 보게 만드나 생각해야 한다. 결론은 특정 분야에 많은 지식이 필요하지는 않지만, 프로그래머로서의 눈치와 해석력이 많이 요구된다.<ref name = "게임 프로그래머"></ref> | |
| − | + | ||
| − | + | =====물리엔진 프로그래머===== | |
| − | + | [[물리엔진 프로그래머]]는 게임에 필요한 물리 계산을 빠르게, 필요한 만큼 정확하게 하는 개발을 한다. 프로그래머 항목에 프로그래머들은 거창한 알고리즘 연구를 하지 않는다고 하지만, 물리엔진 프로그래머는 거창한 알고리즘을 연구하는 사람들이 필요하다. 유저들은 매년 상향되는 그래픽, 물리엔진을 보고 싶어하고, 만족할 만한 게임을 만들기 위해서 더 새로운 그래픽 기술들의 효율적인 계산이 필요하다. 그래서 이 분야는 컴퓨터공학 전공자보다 물리학자, 수학자들이 더 많이 보인다. 수학의 경우 사원수, 오일러 각 등의 3D 수학을 기초로 알아야 인턴쉽이 잡힌다.<ref name = "게임 프로그래머"></ref> | |
| − | === | + | |
| − | + | =====그래픽 프로그래머 ===== | |
| − | + | [[그래픽 프로그래머]]는 3D 그래픽이나 애니메이션을 빠르게 계산하고, 효율적으로 유저의 모니터로 출력하는 개발을 한다. 위와 비슷하게 순수한 프로그래밍보다 수학, 물리쪽 지식을 더 많이 필요로 한다. 위와 비슷하게 비쥬얼적으로 나쁘지 않다고 생각될 정도면 계산을 단순화하거나 수학적인 알고리즘으로 최적화를 한다. 난이도가 높아질 수록 최소 수학과 또는 물리학과 3~4학년 수준 지식을 요구하기도 한다. 인터넷에 친절하게 알려주는 기법도 있지만 최신 기술을 사용하거나, 최신 기술이라고 보긴 힘들지만 구현 난이도가 상당히 높은 축에 해당하는 기술, 또는 색다른 느낌의 비실사주의 셰이더의 최신 기법을 구현하고자 할려면 인터넷 검색으로는 해결할 수 없다. 영어로 된 논문과 인용된 논문을 읽어가며 그 논문에서 말하고자 하는 수학 물리 공식을 이해하고 그것을 프로그래밍적으로 구현할 줄 알아야 한다. 정말 독특하고 유니크한 것은 논문으로도 발표된 사례가 없어 바닥부터 직접 만드는 경우가 왕왕 존재한다. 그래서 수학이 싫거나 자신이 없다면 가장 멀리해야 하는 분야이다. 그런고로, 게임 개발 프로그래머 중 독보적으로 난이도가 높으며, 그에 비례해 대우가 좋다. 규모가 작은 곳에서는 상용 엔진을 쓰기 때문에 비주얼 셰이더 툴을 이용해 적당히 셰이더를 만들어서 쓰는 경우가 많아 이 포지션이 없는 경우도 많다. 다만 AAA급으로 가면 반드시 필요하며, 제대로만 하면 여기저기서 러브콜을 받을 수 있다. 유독 이 분야의 사람들이 다른 포지션의 일을 겸하는 경우가 많은데, 그만큼 다른 기술의 밑바탕이 확실해야 할 수 있는 분야라는 뜻이다.<ref name = "게임 프로그래머"></ref> | |
| − | === | + | |
| − | + | ===== 개발도구 프로그래머 ===== | |
| + | [[개발 도구 프로그래머]]는 게임 개발에서는 동떨어져 있는 직무로, 대규모 회사가 아니라면 흔히 볼 수 없는 직무이다. 대부분 프로그래머가 아닌 개발자들이 프로그래머들의 도움이 없이 개발에 참여를 하게 해 주는 도구들을 개발한다. 아티스트 직군을 위한 배치 툴을 짜기도 한다. 그게 아니면 엔진을 뜯어고치는 경우도 있다. 무엇이 되든 비 프로그래머 직군과의 융화를 보다 윤택하기 위한 목적이 있다. 게임 디자이너들이 아주 기초적인 코딩 실력으로 게임을 완벽하게 바꿀 수 있게 하는 것이 주 목적이다. 회사 규모가 더 크면 게임이랑 전혀 관련 없는 직원, 빌드 관리 소프트웨어도 만들게 된다. 이 정도까지 되면 상당히 고수준의 프로그래밍 지식이 필요한 경우이다.<ref name = "게임 프로그래머"></ref> | ||
| + | |||
| + | ===== 네트워크·서버 프로그래머 ===== | ||
| + | [[네트워크·서버 프로그래머]]는 온라인 게이밍의 핵심이라고 볼 수 있다. [[클라이언트]]와 [[서버]] 간의 데이터 송수신을 다루고, 렉을 줄이기 위해서 최소한의 정보를 보낼 방법과, 심한 렉, 서버 다운, 디도스 공격 등의 문제를 해결할 방법을 연구한다. 데이터 사용량을 줄이는 동시에 클라이언트의 시점에서 렉이 안 보여야 하는데, 잘못된 디자인은 0.1초의 렉으로도 유저와 유저 밖의 세상이 따로 노는 느낌을 줄 수 있다. 대한민국 사람으로서 상상하기 어려울 수도 있겠지만 세계의 평균 인터넷 속도는 낮은 편이고, 구형 모뎀 인터넷으로 지구 반대쪽에 있는 서버를 통해서 게임을 해야 할 사람도 있으니, 세계적인 온라인 게임을 만들기 위해서는 1바이트의 추가 데이터도 신중히 다뤄야 한다. 또한 대부분의 게임 개발사는 [[데이터베이스]]를 따로 두지 않으므로, 사실상 데이터베이스 지식까지 요구되는 직군이다.<ref name = "게임 프로그래머"></ref> | ||
| − | {{각주}} | + | {{각주}} |
==참고자료== | ==참고자료== | ||
| + | * 〈[https://namu.wiki/w/%EA%B2%8C%EC%9E%84%20%EA%B8%B0%ED%9A%8D%EC%9E%90 게임 기확자]〉, 《나무위키》 | ||
| + | * 〈[https://namu.wiki/w/%EA%B2%8C%EC%9E%84%20%EA%B7%B8%EB%9E%98%ED%94%BD%20%EB%94%94%EC%9E%90%EC%9D%B8 게임 그래픽 디자인]〉, 《나무위키》 | ||
| + | * 〈[https://namu.wiki/w/%EA%B2%8C%EC%9E%84%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8 게임 프로그래머]〉, 《나무위키》 | ||
| + | * artistyang82, 〈[https://artistyang83.tistory.com/1230 게임 개발 프로세스 :: 크리에이티브 아티스트]〉, 《티스토리》, 2019-01-06 | ||
| + | * 〈[https://namu.wiki/w/%EC%96%B8%EB%A6%AC%EC%96%BC%20%EC%97%94%EC%A7%84%20vs%20%EC%9C%A0%EB%8B%88%ED%8B%B0%20%EC%97%94%EC%A7%84 언리얼 엔진 vs 유니티 엔진]〉, 《나무위키》 | ||
| + | * 〈[https://www.career.go.kr/cnet/front/base/job/jobView.do?SEQ=923 게임기획자]〉, 《커리어넷》 | ||
| + | * 〈[https://www.saramin.co.kr/zf_user/cms/job-information/view?idx=08552&dtlGb=2 게임그래픽디자이너]〉, 《사람인》 | ||
| + | * okydokymacintosh, 〈[https://m.blog.naver.com/okydokymacintosh/221237806533 게임원화가란?]〉, 《네이버 블로그》, 2018-03-26 | ||
==같이 보기== | ==같이 보기== | ||
* [[게임]] | * [[게임]] | ||
* [[개발]] | * [[개발]] | ||
| + | * [[게임 엔진]] | ||
| − | {{게임| | + | {{게임|검토 필요}} |
2021년 9월 30일 (목) 00:20 기준 최신판
게임 개발은 게임을 만들고 출시하는 것을 의미한다. 분야로는 게임 기획자, 게임 디자이너, 게임 프로그래머 등 3가지 직종이 있다. 이 세 가지 분야팀들이 협력을 통해 게임이라는 하나의 결과물을 만들어 내는 것을 게임 개발이라고 한다.
목차
프로세스[편집]
준비 단계[편집]
- 게임 콘셉트 회의 : 개발하고자 하는 게임의 전반적이 사항들을 결정하는 데 목적이 있으며 개발팀에서 진행한다. 참가자는 기획자, 프로그램 팀장(클라이언트, 서버), 그래픽 팀장(원화, 캐릭터, 배경) 정도가 될 수 있다.
- 게임 시스템 기획 : 개발하고자 하는 게임에 들어갈 핵심적인 시스템들을 개발자들이 이해할 수 있도록 결정하는 데 목적이 있으며 기획팀에서 진행한다. 참가자는 기획자, 시나리오 작가, 시스템 디자인, 레벨 디자인 정도가 될 수 있다.
- 일정 및 리소스 관리: 실질적 게임 구현에 필요한 리소스 양과 개발 일정, 그에 따른 인력 구성 등의 세부적인 계획을 수립하는 데 목적이 있다. 참가자는 기획자, 프로그램 팀장, 그래픽 팀장 정도가 될 수 있다.[1]
개발 단계[편집]
- 그래픽 작업
- 시나리오 작업 : 게임의 세계관 설정, 캐릭터 설정, 엔피씨(NPC) 설정, 몬스터 설정, 작업 일정 결정 등을 한다.
- 원화 작업 : 시나리오 결과물을 가지고 원화 작업을 진행한다.
- CG 작업 : 원화 결과물을 가지고 그래픽 디자이너가 원화를 그래픽 툴을 이용하여 3D 또는 2D로 모델링한다.
- 애니메이션 작업 : 시나리오 결과물을 애니메이션(캐릭터 이동, 몬스터 피격, 이동) 작업을 진행한다.[1]
- 시스템 기획
- 시스템 디자인 : 시스템을 어떻게 기획할 지 생각하고 구현이 가능한지에 대해 생각하여 기획서를 만든다.
- 레벨 디자인 : 최종 기획서를 바탕으로 수치 디자인을 수정, 보완한다.
- 레벨 디자이너, 서버 프로그래머 작업
- 스탯 및 테이블 구성 : 게임에 적용되는 모든 스탯 및 테이블을 구현 가능한지에 대해 파악하고 최종적으로 스탯 및 테이블을 완성시키는 단계이다.[1]
사용 엔진[편집]
유니티[편집]
유니티(Unity)는 C#를 기본 스크립트 언어로 사용한다. C# 언어 자체가 C++에 비해 적응이 빠른 편이라 비 프로그래밍 직군도 많이 접근하게 된다. 유니티의 경우 스크립트 생성 시 모노비헤이비어(Monobehaviour)만을 상속받아 스크립팅을 하게 만들었다. 해당 파이프라인을 하나로 통일한 덕에 추가적인 기능은 언리얼에 비해 부족해 컴포넌트 애드온을 필요한 분량만큼 추가해 주어야 하지만, 그 대신 컴포넌트를 붙이는 데 제약이 적고 수정 시 에디터 상에 즉각 반영이 되는 핫 리로드 기능이 굉장히 강력하게 구비되어 있다. 주 언어가 C#인 것도 한 몫 하는데, 어느 객체를 만들었으면 해당 객체에 대해서만 컴파일이 완료되면 바로 실행이 가능하다. 그렇기에 스크립트의 추가가 굉장히 자유롭고 에디터상에서 직관적이고 즉각적으로 반영이 가능하다. 보통 웬만큼 크지 않는 이상 스크립트를 수정하면 바로 에디터 창으로 돌아와 실행이 가능할 정도라 자체 피드백 순환과 매우 빠르게 처리할 수 있다는 이점이 있다. 이러한 강점은 개별 오브젝트에 눈에 보이는대로 컴포넌트를 붙이면 사용자가 모르는 새 컴파일되면서 사용 가능한 상태로 바꾸기 때문에, 필요한 요소는 그때그때 만들어 쓸 수 있다는 강점을 가지고 있다. 문제는 비 프로그래밍 직군 작업자에 대한 편의는 적은 편이다. 언리얼을 따라 비주얼 스크립트를 개발했지만 사실상 유명무실하며 결국에는 비 프로그래밍 직군의 인원도 코드를 알아야 정확한 작업을 진행할수 있다. 유니티는 엔진 소스 코드를 제공하지 않아 소스 코드를 제공받기 위해서는 별도로 고가의 계약 체결이 필요하다. 그렇기 때문에 고수준의 작업에서는 자잘한 문제가 발생하고, 이를 피하고 개선하기 위해 우회를 반복하다가 어느새 엔진 내 소스를 꼬아서 만드는 경우도 더러 있다.[2]
언리얼 엔진[편집]
언리얼 엔진(Unreal Engine)은 미국의 에픽게임즈에서 개발한 3D 게임엔진이다. 초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진 4는 스크립팅 언어로서 새로운 언어를 배워야 하는 부담을 없애기 위해 언리얼 엔진 3까지 써오던 자바 스타일의 언리얼 스크립트를 제거하고 보다 대중적으로 다가서기 위해서 게임 프로그래머들에게 익숙한 C++를 채용했다. 언리얼 엔진 4는 아래에서 언급될 비주얼 스크립팅 언어인 블루프린트와 프로그래밍 스크립트 언어를 함께 사용하여 복잡한 구조나 퍼포먼스가 필요한 부분은 프로그래밍 언어로 구성하고, 가변성이 높은 부분은 디자이너가 간단히 변경할 수 있게 블루프린트로 구성하여 상호 보완적으로 활용 가능하다. 그렇기 때문에 타 직군과의 협업이 굉장히 원활하다. 한편, 언리얼 C++의 경우는 공식적으로 핫 리로드를 지원한다고는 하지만 실상은 유명무실하다. 일단 핫 리로드 자체에 문제가 많아 제대로 동작하지 않는 경우가 자주 발생한다. 또한 기존 엔진에서 상속받을 스크립트부터 찾아야 하기에 스크립트 추가 시 거의 반드시 엔진 컴파일 과정이 추가된다. 이는 C++ 각 객체별로 컴파일을 할 수 있는 것이 아니기 때문에, 엔진에서부터 시작한 상속받은 스크립트 전부 다 컴파일이 진행되어야 사용 가능하기 때문이다. 언리얼의 다양한 기능도 되려 핫 리로드를 구현할 수 없을 지경으로 분할되어 있는 것도 한 몫 한다. 간단하게 되어야 할 추가 모듈부터 엔진단에 포함되어야 실행되기 때문에 엔진을 통으로 컴파일을 진행해야 하는 불상사가 생긴다. 그래서 에디터상에서 컴포넌트를 즉각 붙이는 행위를 막아 놓았으며, 해당 문제를 에디터상에서 해결하기 위해서는 블루프린트로 재생성한 뒤 수정해야 한다. 즉, 블루프린트 기능은 유니티보다 타 직군과의 연계 작업을 우월하기 위해 만든 기능이 아니라, 실상은 컴파일 횟수를 조금이라도 줄이기 위해서 만든 수단으로써 출발했던 것이다.
블루프린트 기능은 언리얼 엔진의 작업 속도를 늦추는 요인으로 꼽힌다. 또한 블루프린트 자체도 빠른 편이 아니다. C++로 코딩했을 때 20엠에스(ms)인 코드가 블루프린트로만 작성했을 때는 상황에 따라 5~15배 느린 100엠에스(ms)~300엠에스(ms)의 속도 차이가 발생하는 경우도 더러 있다. 그래픽 직군에서 쉐이더 적용이나 기획 쪽에서 프로토타입 적용에 유용하게 사용 가능하지만, 프로그래밍 직군에서는 100% 블루프린트 코드를 짠 게임은 있을 수도 없으며 정말 존재한다면 사실상 프로그래머를 뽑을 이유가 없고, 최적화를 위해 반드시 C++ 코딩이 필요한데 C++ 코딩은 상술했듯이 상당히 공과 시간을 많이 들여야 한다. 언리얼 엔진은 2015년 3월 이후 버전 4의 소스 코드 전체를 공개한다는 점은 굉장한 강점이다. 복잡한 코딩이 가능한 프로그래밍 전문가가 있는 팀의 경우에는 여러모로 언리얼 엔진이 훨씬 더 낫다. 언리얼 C++의 빌드 툴의 지속적인 개선과 엔진을 직접 건드릴 수 있는 강점이 있기 때문이다. 또한 엔진 자체에서도 제공하는 기능이 굉장히 많기 때문에 엔진에 있는 기능만 사용해도 유연하게 해결되는 경우가 상당수이다. 또한, 언리얼 엔진 4 문서에는 언급이 되어 있지 않지만 해외 커뮤니티에서는 C++ 대신 C#을, 혹은 스크립트 언어인 루아(Lua)나 러디(Rudy) 등을 언리얼에서 사용하는 방법에 대해 연구하기도 하고 실제로 그러한 스크립트 언어를 사용하여 개발하고 출시한 상용 게임도 있다. 언리얼 엔진 5와 더불어 벌스(Verse)라는 새로운 스크립팅 언어를 공개했다. 파이썬(Python)과 비슷한 문법 구조를 채택하고 있어 해외 커뮤니티에서는 배우기 쉽고 블루프린트를 대체해 줄 것으로 예상하고 있다.[2]
두 엔진의 본질적 차이[편집]
흔히 착각하는 것이 두 엔진을 그저 퀄리티나 언어만 다른 비슷한 도구로 생각하는 것인데, 두 엔진의 개발 방식 접근성은 극명하게 다르다. 대표적인 예시로 유니티는 기본 기능이 비교적 빈약하고, 소스를 고칠 수 없는 대신, 기능이 매우 가볍고 사용하기 간편하며 에셋 및 패키지를 구매하거나 덧붙여 보강이 원활하여 추가 모듈을 부착하거나 떼는 식으로 대응한다. 언리얼 엔진은 엔진 자체에서 대부분의 강력한 기능을 제공하지만, 개발사인 에픽게임즈의 방향성에 맞춘 기성품에 더 가까워 상대적으로 확장성이 제한된다. 엔진의 성능을 제대로 활용하기 위해서는 고급 인력 또는 방대한 규모의 팀이 필요하다. 당연히 언리얼에도 에셋에 대응하는 플러그인이 존재하지만, 이것으로 기능을 늘려나가기에는 한계가 있는 데다, 플러그인을 정리하지 않으면 프로젝트 전체가 크래시가 나기 쉬워 적용할 때도 상당히 많은 주의를 요한다. 유니티의 경우 입력 메시지의 흐름이나 렌더링 구조를 포함한 엔진의 대부분이 나뉘어져 제각기 접근하고 조립할 수 있다. 예를 들어 렌더링의 경우 쉐이더를 편집한다고 할 때 게임 데이터의 모든 단계를 쉐이더에 사용하고 대부분의 경우 원하는 만큼 충분한 큐잉과 컬링 분류를 할 방법을 제공한다. 대신 그 각각의 기능을 조립하고 옵션을 짜맞추는 것은 개발자의 몫이며, 점점 하이퀄리티로 올라갈수록 코스트 또한 장난 아니게 높아진다. 후반부로 갈수록 퀄리티 상승을 위해 처리해야 될 문제들이 산더미처럼 쌓이며, 이는 프로젝트 중후반부에 진입한 게임사들이 언리얼로 전환하는 원인이 되기도 한다. 반면 언리얼의 경우는 회사에서 사용된 엔진으로 시작하였으므로, 상용게임에서 원하는 고도의 추상화가 원래 다 이루어진 상태에서 자유도를 확장시키는 방식으로 범용 엔진으로 만든 것이기 때문에 기본적으로 에픽게임즈에서 만든 게임의 아키텍처대로 만들도록 되어 있다. 마찬가지로 렌더링의 예를 들자면 원래 주어진 렌더링 파이프라인의 퀄리티는 좋고 원래 제공된 옵션들 중에서 골랐을 대의 편의성은 좋지만 이것을 수정해서 원하는 것을 창조하려고 한다면 유니티처럼 쉐이더를 갈아 끼우는 방식으로는 불가능하고 렌더링된 결과를 후처리 가공해서 효과를 주거나 아예 엔진 소스를 고쳐서 방식을 우회시켜야 한다. 구체적으로는 쉐이더를 바꾸기 위해서 쉐이더를 생성해 주는 엔진의 기능인 머터리얼 에디터의 입력인 머터리얼을 변경하는 식으로 간접적으로 변경하고, 그 결과로 렌더링된 최종 결과물을 포스트 프로세싱해야 한다.
유니티처럼 렌더링 자체를 카툰 쉐이더로 하려면 엔진 내에서 머터리얼에서 쉐이더의 생성 코드를 수정해 사용자가 원하는 라이팅 정보를 참조할 수 있도록 만들어야 하며, 라이팅와 연관된 엔진의 다른 여러 부분의 코드들도 그에 맞게 수정해 주어야 한다. 이러려면 당연하게도 쉐이더와 렌더링 파이프라인에 관련하여 프로그래머로서의 상당한 지식을 필요로 하게 된다. 1인칭으로 환경 위에서 캐릭터를 컨트롤하는 구조를 만들려고 할 때, 언리얼이 이미 제공되는 입력, 입력 컨트롤러, 플레이어 컨트롤러, 페르소나 구조를 사용하여 거의 건드릴 것도 없이 상용 수준으로 다양하고 풍부한 조종이 가능한 결과물을 뚝딱 만들어 낼 수 있으나, 그냥 키보드의 W키가 눌릴 때 박스 하나의 좌표가 X방향으로 1미터 바뀌었으면 좋겠다는 근원적인 제어를 원할 때 다른 모든 오브젝트 필요 없이 박스 하나를 놓고 스크립트에서 W키->X좌표 +1 이라는 직결 구조를 만들 수 있는 것은 유니티이다. 언리얼 엔진 4 초기 버전의 이슈였던 '반투명 물체를 만들기 힘들다' 역시 이러한 구조적 차이 때문이다. 반투명 물체의 품질 유무가 가장 극명하게 드러나는 것이 머리카락 부분인데, 이 때문에 언리얼 엔진에서 높은 퀄리티로 제작된 여러 작품들이 머리카락 부분만 튀거나 고생해서 여러 우회 기법을 적용한 모습을 볼 수 있다. 이러한 차이 때문에, 양 엔진의 에셋 스토어에서 뭔가 고급 기능들을 보면 유니티의 경우 엔진에서 돌아가는 스크립트 코드 혹은 엔진과 함께 돌아가는 플러그인 형태로 제공되는 반면 언리얼의 경우 엔진의 특정 기능을 커스텀 한 것이 에셋으로 제공되는 경우도 있다. 언리얼 엔진이 소스코드를 완전히 제공하는 데 반해 유니티 엔진은 제한적인 것을 보고 전자는 개방적, 후자는 폐쇄적이라고 생각하기 쉽지만, 이 역시 엔진의 기초 구조 자체가 다르기 때문이다. 언리얼의 경우 엔진 그 자체는 기성품처럼 제약되고 다듬어진 기능들만을 제공하면서 어느 이상 기능 자체를 확장하고 싶으면 필연적으로 엔진의 C++ 소스 코드 자체를 수정하고 다시 빌드를 하는 쪽으로 나아가게 된다. 엔진 개발사에서도 그쪽을 염두에 두고 권장하고 있다. 반면 유니티의 경우 엔진에서 제공하는 인터페이스만을 가지고도 충분히 확장해 나갈 수 있도록 확장 가능성과 범용성을 목표로 처음부터 설계되어서 엔진 자체를 수정해서 기능을 늘려야 할 필요성이 거의 없다.
유니티는 이러한 취지에서 유알피(URP), 에이치디알피(HDRP) 등 렌더링 파이프라인 자체를 사용자가 구성할 수 있는 추가 옵션을 제공하는 등 엔진 자체에서 제공하는 가능성을 확장하는 방향으로 발전해 나가고 있다. 이렇게 유니티와 언리얼은 두 가지 엔진에서 이 기능을 할 수 있느냐 없느냐, 단순히 결과물이 멋지느냐 아니냐의 단순한 문제가 아니라, 어떤 엔진, 어떤 결과물을 원하느냐의 조합에 따라 개발자가 학습해야 하는 정보와 개발하는 경로가 완전히 달라진다는 것을 알 수 있다. 엔진 자체의 보안성에 대해서는 둘 모두 큰 차이가 없다. 일단 유니티는 닷넷(.NET) 기반에 다이나믹 로더를 사용하지만, 그 부분은 게임 로직을 만드는 스크립팅 언어로써 C#를 활용하는 것이지, 엔진 자체는 C++이라서 유니티와 비교해도 큰 차이가 없다. 하지만 게임 로직 코드는 넷(NET)을 사용하는 유니티가 압도적으로 털리기 쉽다. 반면 C++을 이용하는 언리얼 엔진은 게임 로직도 어셈블리로 컴파일되기 때문에 상대적으로 안전하다. 하지만 요즘은 유니티 역시 C++로 번역 후 컴파일하는 아이엘2씨피피(IL2CPP)를 지원하고 있고, 최근의 대규모 개발들은 대부분 중요한 비지니스 로직은 서버에 두고, 클라이언트는 서버에서 데이터를 얻어와서 사용하는 구조로 만들어지기 때문에 보안 수준은 결정적으로 프로그래머가 보안 요소를 얼마나 적용하느냐가 결정한다. 하지만 싱글 플레이어 게임을 만든다면 언리얼을 쓰거나, 유니티를 쓴다면 중요 코드를 C++로 작성하는 것이 보안에 도움이 될 수도 있다.[2]
직업군[편집]
게임기획자[편집]
게임기획자는 PC 게임, 네트워크 게임 등 게임용 소프트웨어 제작과 관련된 모든 사항들을 총괄적으로 지휘하고 감독하는 일을 담당한다. 주요 업무는 게임 시장 조사 등을 통해 소비자들이 좋아하고 원하는 게임이 무엇인지를 파악하고, 새로운 게임 제작을 위한 아이디어를 구상하여 이에 대한 기획안을 작성한다. 또한 게임의 장르와 대상 연령층, 게임 난이도, 게임의 각종 캐릭터의 역할 및 특징, 기본적인 스토리 전개 등을 설정하고, 그래픽 디자이너, 프로그래머 등과 함께 본격적으로 게임 프로그램을 제작한다. 게임소프트웨어에 대한 베타테스트를 하고 시연회에 참여하는 등 홍보 업무를 하기도 한다. 대사를 작성하는 등 세부적인 게임 시나리오를 작성하고, 기획의도를 이해하기 쉽게 그래픽디자이너나 프로그래머 등에게 전달한다. 그리고 게임이 제작되어 상품화가 되었을 때 시장 진입이나 판매고의 수익을 올릴 수 있을지를 판단,결정한다. 게임의 제작이 완료되면, 게임의 홍보와 마케팅 전략, 배급 등에 대한 계획을 수립하고 실행한다.[3]
- 요구 능력과 담당 직무
기획자에게 요구되는 역량은 게임마다 달라진다. 기본적으로 프로젝트 관리 역량을 갖추어야 하며, 추가적으로 개발할 게임에 필요한 능력 전반에 대해 알아야 한다.
- 시스템 : 게임에 기반이 되는 시스템 및 프로그램적으로 개발되는 요소를 책임진다. 프로그래밍 관련 지식이 필요하다.
- 시나리오 : 게임에 기반이 되는 스토리, 캐릭터, 퀘스트 등 텍스트와 등장할 캐릭터 요소를 책임진다. 문화 예술 관련 지식이 필요하다.
- 레벨 디자인 : 게임에 기반이 되는 맵에 사이즈, 배치 요소를 담당한다. 건축과 크기에 따른 공간적 지식과 플레이타임 등을 계산할 게임적 지식이 필요하다.
- 운영 : 게임내 운영 업무로 기획한 내용에 반영 되었을 때 운영에 관련 내용을 담당한다. 라이브 기획자가 주로 다른 기획 업무와 병행하는 업무이다.
- 밸런싱 : 게임에 수치들을 담당하며, 데이터와 수학지식, 게임룰에 따른 수치화에 대한 통찰력이 필요한다.
- 게임 내 경제 : 게임 내 경제를 시뮬레이션할 능력과 지식이 필요하다. 게임 내 몬스터 드랍, 획득 게임머니 등 요소를 담당한다.[4]
게임그래픽디자이너[편집]
게임그래픽디자이너는 컴퓨터 게임 등에 등장하는 각종 캐릭터와 배경, 아이템 등을 디자인하는 역할을 한다. 게임기획자와 게임시나리오작가가 구상한 내용을 참고로 캐릭터와 배경화면 등을 구상한다. 그리고 스케치 작업을 거쳐 색을 입히는 컬러링 작업을 한다. 작업 계획을 세운 후 그래픽 소프트웨어를 이용해 캐릭터의 모습과 주요 움직임, 아이템, 배경화면을 구성하여 모니터에 그려 넣는다. 게임 제작이 완성된 후 캐릭터나 배경이 어색한 곳은 수정하고 보완한다. 게임 상에 보이는 메뉴, 창, 설정 창 등의 인터페이스(interface)를 제작한다. 그리고 나서 원화가가 그린 캐릭터나 배경을 3D프로그램을 이용하여 만든다. 모델러가 만들어 놓은 입체물에 색감이나 질감을 입히는 것이다. 또한 반복되는 동작들을 정교화하고, 마법이나 기술 등 각종 효과를 제작한다.[5]
게임원화가[편집]
게임원화가는 게임 제작자의 한 종류로, 그래픽 파트에서 콘셉트 원화를 담당하고 그리는 사람이다. 게임 원화는 3D나 2D그래픽을 제작하기 전에 기초적인 도안, 즉 가이드라인이 되는 그림을 말하며, 색 지정과 의복, 아이템의 디자인이 주로 하는 작업이다. 게임원화가는 캐릭터원화가와 배경원화가로 나뉜다. 본인 실력과 디자인에 취업이 크게 결정되는 파트 원화가는 콘셉트 아티스트(concept artist)라고도 불리며, 게임에서 드러내려는 이미지를 그려내는 직업군이다. 배경 원화가는 건물, 자연 등의 도안과 디자인을 담당하며 배경을 그릴 때 설계 구도가 굉장히 중요한 요소로 작용한다. 캐릭터 원화가는 캐릭터의 전반적인 설정을 담당하는 역할을 하며 무기 원화가, 몬스터 원화가 등으로 나뉘기도 한다. 캐릭터 원화가에게는 기본적으로 드로잉 실력이 요구되며 이를 위해 인체구조에 대한 이해가 필요하다. 또 캐릭터 원화가는 인체만 그리는 것이 아니라 의복, 몬스터, 무기 등 다양한 영역의 그림들을 그려야 하므로 다양한 자료들을 바탕으로 보다 많은 것들을 그릴 수 있는 능력을 키워야 한다.[6][7]
게임모델러[편집]
게임모델러는 배경을 담당하는 배경 모델러와 캐릭터를 담당하는 캐릭터 모델러가 있다. 게임모델러는 캐쥬얼인지, 반실사인지, 실사인지에 따라 제작 방식이 조금씩 달라질 뿐 다룰 줄 알아야 되는 프로그램은 거의 동일하다. 쓰리디맥스 또는 마야, 바디페인터, 제트브러쉬가 기본적이며, 최근 게임 산업에서 실사풍이 중요해지면서 서브스텐스 쓰리디오 등 피비비 쪽도 어느 정도 알아야 한다. 다른 파트에 비해 새로운 프로그램과 트렌드가 등장했을 때 심하게 타격받는 파트이다. 모델러는 원화에 있는 캐릭터, 아이템, 건물, 배경 등 게임에서 보이는 모든 것들을 3D 이미지로 구현한다. 이른바 게임 디자인의 뼈대인 원화에 쓰리디로 살을 붙이는 작업이라고 할 수 있다. 배경 모델러는 원화에 있는 제품, 건물, 도로나 전체적인 지형을 그래픽으로 만들며 원화의 전체구도 및 원근감 등의 관련된 부분을 3D로 만들어야 한다. 캐릭터 모델러는 인체 구조를 기반으로 모델링을 진행해야 한다. 따라서 구조 이해도를 위한 정물, 인물 등을 잘 그려야 하며 원화가 못지 않은 이해도를 가져야 한다. 게임 툴인 쓰리디 스튜디오 맥스와 애니메이션 툴인 마야 등을 다룰 줄 알아야하며 포토샵으로 컬러, 질감, 표정들을 입히는 맵핑 작업 및 다양한 맵핑 소스들을 활용할 수 있어야 한다. 또, 세밀한 표현을 위해 2D와 3D의 중간을 표현할 수 있는 지브러시 머드박스와 같은 프로그램을 다룰 수 있으면 좋다. 3D 그래픽 디자이너들의 작업 과정을 간략히 설명하자면 다음과 같다.
- 원화 분석: 먼저 원화가로부터 콘셉트 원화를 받아 분석한다. 참고로 3D로 구현해야 하기 때문에 구조의 움직이는 부분이 따로 필요하며, 다양한 시점으로 표현된 원화 또한 필요하다. 모델러는 넘겨받은 원화에서 만들어야 할 이미지의 콘셉트를 파악하고 특징을 어떻게 표현할 것인지 결정한다.
- 모델링 : 원화를 3D로 조형한다. 최대한 원화의 느낌을 살리는 것이 중요하지만 3D로 구현할 수 없거나, 고쳐야 할 부분이 있을 경우 수정해 가며 모양을 만든다.
- 텍스처 작업 : 완성된 모델링 이미지는 색이 존재하지 않거나 단색이다. 여기에 색과 표면의 질감을 살리기 위해 텍스처를 입힌다.[6]
- 게임엔진 적용 : 텍스처를 마무리하고 완성된 3D 이미지를 게임에서 쓰기 위해 게임엔진에 적용한다.[6]
이펙터[편집]
이펙터의 주 업무는 타격, 스킬, 움직임, 사용자 인터페이스(UI) 등 게임 화면상의 나타나는 모든 효과를 다루는 일이다. 대부분 먼저 만들어 놓고 차후에 타이밍이나 색감, 길이 등을 맞춰보는 튜닝 작업으로 이루어진다. 이펙터는 원화를 참고하여 그리기도 하지만 이미지가 전부 제시된 것은 아니기 때문에 어느 정도 감각이 있어야 한다. 이펙터는 단순히 효과만을 만드는 것이 아니라 캐릭터의 동작과 연계된 효과도 생각해야 하기에 애니메이션과 모델링 등 전반적인 작업을 모두 할 수 있어야 한다. 포토샵 애프터 이펙트 쓰리디맥스의 초급에서 중급은 되어야 되며 추가로 각 회사에서 요구하는 엔진의 이펙트 툴도 같이 알아야 된다. 어떻게 보면 이펙터가 다룰 줄 알아야되는 프로그램은 제일 많을 것이다. 그만큼 귀한 직업군이기도 하고 제일 화려하고 게임의 타격감에 지대한 영향을 끼치는 분야이기도 하다.[6]
애니메이터[편집]
애니메이터는 완성된 캐릭터나 몬스터 등에게 행동력을 주는 사람이다. 모든 입력 장치에 들어가는 애니메이션을 각각 만들고 이 애니메이션을 부드럽게 연결하는 작업을 한다. 애니메이터는 작업할 때 포즈와 타이밍이 서로 어긋나지 않도록 연결해야 하며 모든 동작은 기획서, 세계관, 캐릭터의 성격에 맞게 각각 구현되어야 한다. 때리는 동작과 사운드, 리액션을 타격감이라고 하는데, 타격감을 맞춰 주는 것도 애니메이터의 역할이다. 게임 애니메이터는 원화가가 작업한 작업물을 바탕으로 모델링한 각각의 캐릭터에 움직임을 줄 수 있는 부분(관절과 표정 등)을 넣어 명령에 맞춰 움직일 수 있도록 만드는 작업을 한다. 애니메이터의 역량을 키우려면 크로키를 통해 순간적으로 인체의 구조를 파악하는 훈련을 하면 좋다. 2D인지, 3D인지에 따라, 그리고 회사에서 어떤 엔진으로 게임을 제작해느냐에 따라 다룰 줄 알아야 되는 툴이 조금씩 틀리다. 2D는 라이브2D, 스파인이 기본적이라 봐야 되며 3D는 쓰리디맥스가 제일 압도적이며 그 다음 마야를 알아야 한다. 캐릭터와 배경의 소품 등 움직이는 것들을 움직이게 해 준다.[6]
게임 프로그래머[편집]
게임 프로그래머는 프로그래밍을 통해 맵 디자인, 캐릭터 디자인, 사운드, 각종 시스템 등을 뒤섞어, 게임이라는 하나의 결과물을 만드는 직군이다. 게임을 만드는 데 있어 가장 귀중한 인력이다. 실제로도 게임 업계에서 프로그래머의 연봉이 기획자나 그래픽 디자이너보다 높은 경우가 많다. 수십, 수백 명의 개발자들이 필요한 트리플에이 게임들은 다양한 분야의 전문가들을 필요로 한다. 아직도 수많은 사람들이 게임 프로그래밍의 대해서 착각하는 것 중 하나인데, 같은 게임 프로그래머라고 해도 전문 분야가 다르면 필요한 지식, 경력, 성격, 등등이 완벽하게 달라진다.[8]
게임플레이 프로그래머[편집]
게임플레이 프로그래머는 만능형 프로그래머(Generalist Programmer)가 많다. 다른 프로그래머들은 게임 엔진 쪽으로 더 가깝고 게임플레이는 말 그대로 '유저들이 게임이라고 느끼는' 부분을 뜻한다. 카운터 스트라이크를 예로 들면 플레이어의 움직임, 총기의 작동 원리, 폭탄이 폭파하면 테러리스트가 승리한다는 규칙 등이 다 게임플레이다. 게임을 사랑해서 게임 프로그래머가 됐다면 웬만하면 이쪽으로 간다. 게임 규모가 작으면 난이도가 다른 분야보다 낮다. 수학의 경우 방향 관련 계산을 하기 위한 선형대수학의 기초만 대충 알면 괜찮다. 하지만 게임 규모가 커지면 접하게 되는 코드의 분야가 너무 넓어지기 때문에 다른 분야보다 쉽지 않다. 이러면 전혀 모르는 분야라도 기초적인 부분을 공부해서 대강 이해를 할 줄 알아야 한다. 그러려면 '컴퓨터 게임'을 이해를 하고 분야를 좋아해야만 일이 된다. 트리플 에이 규모쯤 가보면 어느 날은 엔피씨의 비행 능력을 위해서 팔진트리로 3D 최단 경로 찾기 알고리즘을 공부하고, 그 다음 날은 두 명의 플레이어 캐릭터들의 잡기 공격을 어떻게 코딩해야 렉이 있는 상태에서 두 명이 동일한 상황을 보게 만드나 생각해야 한다. 결론은 특정 분야에 많은 지식이 필요하지는 않지만, 프로그래머로서의 눈치와 해석력이 많이 요구된다.[8]
물리엔진 프로그래머[편집]
물리엔진 프로그래머는 게임에 필요한 물리 계산을 빠르게, 필요한 만큼 정확하게 하는 개발을 한다. 프로그래머 항목에 프로그래머들은 거창한 알고리즘 연구를 하지 않는다고 하지만, 물리엔진 프로그래머는 거창한 알고리즘을 연구하는 사람들이 필요하다. 유저들은 매년 상향되는 그래픽, 물리엔진을 보고 싶어하고, 만족할 만한 게임을 만들기 위해서 더 새로운 그래픽 기술들의 효율적인 계산이 필요하다. 그래서 이 분야는 컴퓨터공학 전공자보다 물리학자, 수학자들이 더 많이 보인다. 수학의 경우 사원수, 오일러 각 등의 3D 수학을 기초로 알아야 인턴쉽이 잡힌다.[8]
그래픽 프로그래머[편집]
그래픽 프로그래머는 3D 그래픽이나 애니메이션을 빠르게 계산하고, 효율적으로 유저의 모니터로 출력하는 개발을 한다. 위와 비슷하게 순수한 프로그래밍보다 수학, 물리쪽 지식을 더 많이 필요로 한다. 위와 비슷하게 비쥬얼적으로 나쁘지 않다고 생각될 정도면 계산을 단순화하거나 수학적인 알고리즘으로 최적화를 한다. 난이도가 높아질 수록 최소 수학과 또는 물리학과 3~4학년 수준 지식을 요구하기도 한다. 인터넷에 친절하게 알려주는 기법도 있지만 최신 기술을 사용하거나, 최신 기술이라고 보긴 힘들지만 구현 난이도가 상당히 높은 축에 해당하는 기술, 또는 색다른 느낌의 비실사주의 셰이더의 최신 기법을 구현하고자 할려면 인터넷 검색으로는 해결할 수 없다. 영어로 된 논문과 인용된 논문을 읽어가며 그 논문에서 말하고자 하는 수학 물리 공식을 이해하고 그것을 프로그래밍적으로 구현할 줄 알아야 한다. 정말 독특하고 유니크한 것은 논문으로도 발표된 사례가 없어 바닥부터 직접 만드는 경우가 왕왕 존재한다. 그래서 수학이 싫거나 자신이 없다면 가장 멀리해야 하는 분야이다. 그런고로, 게임 개발 프로그래머 중 독보적으로 난이도가 높으며, 그에 비례해 대우가 좋다. 규모가 작은 곳에서는 상용 엔진을 쓰기 때문에 비주얼 셰이더 툴을 이용해 적당히 셰이더를 만들어서 쓰는 경우가 많아 이 포지션이 없는 경우도 많다. 다만 AAA급으로 가면 반드시 필요하며, 제대로만 하면 여기저기서 러브콜을 받을 수 있다. 유독 이 분야의 사람들이 다른 포지션의 일을 겸하는 경우가 많은데, 그만큼 다른 기술의 밑바탕이 확실해야 할 수 있는 분야라는 뜻이다.[8]
개발도구 프로그래머[편집]
개발 도구 프로그래머는 게임 개발에서는 동떨어져 있는 직무로, 대규모 회사가 아니라면 흔히 볼 수 없는 직무이다. 대부분 프로그래머가 아닌 개발자들이 프로그래머들의 도움이 없이 개발에 참여를 하게 해 주는 도구들을 개발한다. 아티스트 직군을 위한 배치 툴을 짜기도 한다. 그게 아니면 엔진을 뜯어고치는 경우도 있다. 무엇이 되든 비 프로그래머 직군과의 융화를 보다 윤택하기 위한 목적이 있다. 게임 디자이너들이 아주 기초적인 코딩 실력으로 게임을 완벽하게 바꿀 수 있게 하는 것이 주 목적이다. 회사 규모가 더 크면 게임이랑 전혀 관련 없는 직원, 빌드 관리 소프트웨어도 만들게 된다. 이 정도까지 되면 상당히 고수준의 프로그래밍 지식이 필요한 경우이다.[8]
네트워크·서버 프로그래머[편집]
네트워크·서버 프로그래머는 온라인 게이밍의 핵심이라고 볼 수 있다. 클라이언트와 서버 간의 데이터 송수신을 다루고, 렉을 줄이기 위해서 최소한의 정보를 보낼 방법과, 심한 렉, 서버 다운, 디도스 공격 등의 문제를 해결할 방법을 연구한다. 데이터 사용량을 줄이는 동시에 클라이언트의 시점에서 렉이 안 보여야 하는데, 잘못된 디자인은 0.1초의 렉으로도 유저와 유저 밖의 세상이 따로 노는 느낌을 줄 수 있다. 대한민국 사람으로서 상상하기 어려울 수도 있겠지만 세계의 평균 인터넷 속도는 낮은 편이고, 구형 모뎀 인터넷으로 지구 반대쪽에 있는 서버를 통해서 게임을 해야 할 사람도 있으니, 세계적인 온라인 게임을 만들기 위해서는 1바이트의 추가 데이터도 신중히 다뤄야 한다. 또한 대부분의 게임 개발사는 데이터베이스를 따로 두지 않으므로, 사실상 데이터베이스 지식까지 요구되는 직군이다.[8]
각주[편집]
- ↑ 1.0 1.1 1.2 artistyang82, 〈게임 개발 프로세스 :: 크리에이티브 아티스트〉, 《티스토리》, 2019-01-06
- ↑ 2.0 2.1 2.2 〈언리얼 엔진 vs 유니티 엔진〉, 《나무위키》
- ↑ 〈게임기획자〉, 《커리어넷》
- ↑ 〈게임 기확자〉, 《나무위키》
- ↑ 〈게임그래픽디자이너〉, 《사람인》
- ↑ 6.0 6.1 6.2 6.3 6.4 〈게임 그래픽 디자인〉, 《나무위키》
- ↑ okydokymacintosh, 〈게임원화가란?〉, 《네이버 블로그》, 2018-03-26
- ↑ 8.0 8.1 8.2 8.3 8.4 8.5 〈게임 프로그래머〉, 《나무위키》
참고자료[편집]
- 〈게임 기확자〉, 《나무위키》
- 〈게임 그래픽 디자인〉, 《나무위키》
- 〈게임 프로그래머〉, 《나무위키》
- artistyang82, 〈게임 개발 프로세스 :: 크리에이티브 아티스트〉, 《티스토리》, 2019-01-06
- 〈언리얼 엔진 vs 유니티 엔진〉, 《나무위키》
- 〈게임기획자〉, 《커리어넷》
- 〈게임그래픽디자이너〉, 《사람인》
- okydokymacintosh, 〈게임원화가란?〉, 《네이버 블로그》, 2018-03-26
같이 보기[편집]
