해시넷
"게임 개발"의 두 판 사이의 차이
| 5번째 줄: | 5번째 줄: | ||
=== 요구 능력과 담당 직무 === | === 요구 능력과 담당 직무 === | ||
기획자에게 요구되는 역량은 게임마다 달라진다. 기본적으로 프로젝트 관리 역량을 갖추어야 하며, 추가적으로 개발할 게임에 필요한 능력 전반에 대해 알아야 한다. | 기획자에게 요구되는 역량은 게임마다 달라진다. 기본적으로 프로젝트 관리 역량을 갖추어야 하며, 추가적으로 개발할 게임에 필요한 능력 전반에 대해 알아야 한다. | ||
| − | + | * '''시스템''' : 게임에 기반이 되는 시스템 및 프로그램적으로 개발되는 요소를 책임진다. 프로그래밍 관련 지식이 필요하다. | |
| − | 게임에 기반이 되는 시스템 및 프로그램적으로 개발되는 요소를 책임진다. 프로그래밍 관련 지식이 필요하다. | + | * '''시나리오''' : 게임에 기반이 되는 스토리, 캐릭터, 퀘스트 등 텍스트와 등장할 캐릭터요소를 책임진다. 문화 예술 관련 지식이 필요하다. |
| − | + | * '''레벨 디자인''' : 게임에 기반이 되는 맵에 사이즈, 배치요소를 담당한다. 건축과 크기에 따른 공간적 지식과 플레이타임 등을 계산할 게임적 지식이 필요하다. | |
| − | 게임에 기반이 되는 스토리, 캐릭터, 퀘스트 등 텍스트와 등장할 캐릭터요소를 책임진다. 문화 예술 관련 지식이 필요하다. | + | * '''운영''' : 게임내 운영 업무로 기획한 내용에 반영 되었을때 운영에 관련 내용을 담당한다. 라이브 기획자가 주로 다른 기획업무와 병행하는 업무이다. |
| − | + | * '''밸런싱''' : 게임에 수치들을 담당하며, 데이터와 수학지식, 게임룰에 따른 수치화에 대한 통찰력이 필요한다.<ref name = "나무위키"></ref> | |
| − | 게임에 기반이 되는 맵에 사이즈, 배치요소를 담당한다. 건축과 크기에 따른 공간적 지식과 플레이타임 등을 계산할 게임적 지식이 필요하다. | + | * '''게임 내 경제''' : 게임 내 경제를 시뮬레이션 할 능력과 지식이 필요하다. 게임 내 몬스터 드랍, 획득 게임머니 등 요소를 담당한다. |
| − | |||
| − | 게임내 운영 업무로 기획한 내용에 반영 되었을때 운영에 관련 내용을 담당한다. 라이브 기획자가 주로 다른 기획업무와 병행하는 업무이다. | ||
| − | |||
| − | 게임에 수치들을 담당하며, 데이터와 수학지식, 게임룰에 따른 수치화에 대한 통찰력이 필요한다.<ref name = "나무위키"></ref> | ||
| − | |||
| − | 게임 내 경제를 시뮬레이션 할 능력과 지식이 필요하다. 게임 내 몬스터 드랍, 획득 게임머니 등 요소를 담당한다. | ||
| − | |||
== 게임 그래픽 디자이너 == | == 게임 그래픽 디자이너 == | ||
게임 그래픽 디자이너는 컴퓨터 게임 등에 등장하는 각종 캐릭터와 배경, 아이템 등을 디자인하는 역할을 한다. | 게임 그래픽 디자이너는 컴퓨터 게임 등에 등장하는 각종 캐릭터와 배경, 아이템 등을 디자인하는 역할을 한다. | ||
| 24번째 줄: | 17번째 줄: | ||
=== 배경, 캐릭터 모델러 === | === 배경, 캐릭터 모델러 === | ||
배경 캐릭터 모델러는 캐쥬얼이냐 반실사냐 실사냐에 따라 제작방식이 조금씩 달라질 뿐 다룰 줄알아야되는 프로그램은 거의 동일하다. 쓰리디맥스 또는 마야, 바디페인터, 제트브러쉬가 기본적이며 최근 실사풍이 중요해지면서 서브스텐스 쓰리디오 등 피비비 쪽도 어느정도 알아야 한다. 다른 파트에 비해 새로운 프로그램과 트렌드가 등장했을때 심하게 타격 받는 파트이다. 모델러는 원화에 있는 캐릭터, 아이템, 건물, 배경 등 게임에서 보이는 모든 것들을 3D 이미지로 구현한다. 이른바 게임의 뼈대(원화)에 쓰리디로 살을 붙이는 작업이라 할 수 있다. 배경 모델러는 원화에 있는 제품, 건물, 도로나 전체적인 지형을 그래픽으로 만들며 원화의 전체구도 및 원근감 등의 관련된 부분을 3D로 만들어야 한다. 캐릭터 모델러는 인체 구조를 기반으로 모델링을 진행해야 한다. 따라서 구조 이해도를 위한 정물, 인물 등을 잘 그려야 하며 원화가 못지않은 이해도를 가져야 한다. 게임 툴인 쓰리디 스튜디오 맥스와 애니메이션 툴인 마야등을 다룰 줄 알아야하며 포토샵으로 컬러, 질감, 표정들을 입히는 맵핑 작업 및 다양한 맵핑 소스들을 활용할 수 있어야 한다. 또, 세밀한 표현을 위해 2D 와 3D의 중간을 표현할 수 있는 지브러시 머드박스와 같은 프로그램을 다룰 수 있으면 좋다. 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로 만들어야 한다. 캐릭터 모델러는 인체 구조를 기반으로 모델링을 진행해야 한다. 따라서 구조 이해도를 위한 정물, 인물 등을 잘 그려야 하며 원화가 못지않은 이해도를 가져야 한다. 게임 툴인 쓰리디 스튜디오 맥스와 애니메이션 툴인 마야등을 다룰 줄 알아야하며 포토샵으로 컬러, 질감, 표정들을 입히는 맵핑 작업 및 다양한 맵핑 소스들을 활용할 수 있어야 한다. 또, 세밀한 표현을 위해 2D 와 3D의 중간을 표현할 수 있는 지브러시 머드박스와 같은 프로그램을 다룰 수 있으면 좋다. 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로 구현해야 하기 때문에 구조의 움직이는 부분이 따로 필요하며, 다양한 시점으로 표현된 원화또한 필요하다. 모델러는 넘겨받은 원화에서 만들어야 할 이미지의 컨셉을 파악하고 특징을 어떻게 표현할 것인지 결정한다. | + | * '''모델링''' : 원화를 3D로 조형한다. 최대한 원화의 느낌을 살리는 것이 중요하지만 3D로 구현할 수 없거나, 고쳐야 할 부분이 있을 경우 수정해 가며 모양을 만든다. |
| − | + | * '''텍스쳐 작업''' : 완성된 모델링 이미지는 색이 존재하지 않거나 단색이다. 여기에 색과 표면의 질감을 살리기 위해 텍스쳐를 입힌다.<ref name = "게임 그래픽"></ref> | |
| − | 원화를 3D로 조형한다. 최대한 원화의 느낌을 살리는 것이 중요하지만 3D로 구현할 수 없거나, 고쳐야 할 부분이 있을 경우 수정해 가며 모양을 만든다. | + | * '''게임엔진 적용''' : 텍스쳐를 마무리하고 완성된 3D 이미지를 게임에서 쓰기 위해 게임엔진에 적용한다.<ref name = "게임 그래픽"></ref> |
| − | |||
| − | 완성된 모델링 이미지는 색이 존재하지 않거나 단색이다. 여기에 색과 표면의 질감을 살리기 위해 텍스쳐를 입힌다.<ref name = "게임 그래픽"></ref> | ||
| − | |||
| − | 텍스쳐를 마무리하고 완성된 3D 이미지를 게임에서 쓰기 위해 게임엔진에 적용한다.<ref name = "게임 그래픽"></ref> | ||
=== 이펙터 === | === 이펙터 === | ||
이펙터의 주 업무는 타격, 스킬, 움직임, 유아이(UI) 등 게임 화면상의 나타나는 모든 효과를 다루는 일이다. 대부분 먼저 만들어 놓고 차후에 타이밍이나 색감, 길이 등을 맞춰보는 튜닝 작업으로 이루어진다. 이펙터는 원화를 참고하여 그리기도 하지만 이미지가 전부 제시된 것은 아니기 때문에 어느 정도 감각이 있어야 한다. 이펙터는 단순히 효과만을 만드는 것이 아니라 캐릭터의 동작과 연계된 효과도 생각해야 하기에 애니메이션과 모델링 등 전반적인 작업을 모두 할 수 있어야 한다. 포토샵 애프터 이펙트 쓰리디맥스의 초,중급은 되어야 되며 추가로 각 회사에서 요구하는 엔진의 이펙트 툴도 같이 알아야 된다. 어찌보면 이펙터가 다룰 줄 알아야되는 프로그램은 제일 많을 것이다. 그만큼 귀한 직업군 이기도하고 제일 화려하고 게임의 타격감에 지대한 영향을 끼치는 분야이기도 하다.<ref name = "게임 그래픽"></ref> | 이펙터의 주 업무는 타격, 스킬, 움직임, 유아이(UI) 등 게임 화면상의 나타나는 모든 효과를 다루는 일이다. 대부분 먼저 만들어 놓고 차후에 타이밍이나 색감, 길이 등을 맞춰보는 튜닝 작업으로 이루어진다. 이펙터는 원화를 참고하여 그리기도 하지만 이미지가 전부 제시된 것은 아니기 때문에 어느 정도 감각이 있어야 한다. 이펙터는 단순히 효과만을 만드는 것이 아니라 캐릭터의 동작과 연계된 효과도 생각해야 하기에 애니메이션과 모델링 등 전반적인 작업을 모두 할 수 있어야 한다. 포토샵 애프터 이펙트 쓰리디맥스의 초,중급은 되어야 되며 추가로 각 회사에서 요구하는 엔진의 이펙트 툴도 같이 알아야 된다. 어찌보면 이펙터가 다룰 줄 알아야되는 프로그램은 제일 많을 것이다. 그만큼 귀한 직업군 이기도하고 제일 화려하고 게임의 타격감에 지대한 영향을 끼치는 분야이기도 하다.<ref name = "게임 그래픽"></ref> | ||
| 56번째 줄: | 45번째 줄: | ||
[[유니티]]는 [[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> | [[유니티]]는 [[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> | ||
=== 언리얼4 === | === 언리얼4 === | ||
| − | 초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진 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> | + | 초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진 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> | + | 흔히 착각하는 것이 두 엔진을 그저 퀄리티나 언어만 다른 비슷한 도구로 생각하는 것인데, 두 엔진의 개발 방식 접근성은 극명하게 다르다. 대표적인 예시로 유니티는 기본 기능이 비교적 빈약하고, 소스를 고칠 수 없는 대신, 기능이 매우 가볍고 사용하기 간편하며 에셋 및 패키지를 구매하거나 덧붙여 보강이 원활하여 추가 모듈을 부착하거나 떼는 식으로 대응한다. [[언리얼 엔진]]은 엔진 자체에서 대부분의 강력한 기능을 제공하지만, 개발사(에픽)의 방향성에 맞춘 기성품에 더 가까워 상대적으로 확장성이 제한된다. 엔진의 성능을 제대로 활용하기 위해서는 고급 인력 또는 방대한 규모의 팀이 필요하다. 당연히 언리얼에도 에셋에 대응하는 플러그인이 존재하지만 이것으로 기능을 늘려나가기에는 한계가 있는데다, [[플러그인]]을 정리하지 않으면 프로젝트 전체가 크래시가 나기 쉬워 적용할때도 상당히 많은 주의를 요한다. 유니티의 경우 입력 메시지의 흐름이나 렌더링 구조를 포함한 엔진의 대부분이 나뉘어져 제각기 접근하고 조립할 수 있다. 예를 들어 렌더링의 경우 쉐이더를 편집한다고 할 때 게임 데이터의 모든 단계를 쉐이더에 사용하고 대부분의 경우 원하는 만큼 충분한 큐잉과 컬링 분류를 할 방법을 제공한다. 대신 그 각각의 기능을 조립하고 옵션을 짜맞추는 것은 개발자의 몫이며, 점점 하이퀄리티로 올라갈수록 코스트 또한 장난 아니게 높아진다. 후반부로 갈수록 퀄리티 상승을 위해 처리해야될 문제들이 산더미처럼 쌓이며, 이는 프로젝트 중후반부에 진입한 게임사들이 언리얼로 전환하는 원인이 되기도 한다. 반면 언리얼의 경우는 회사에서 사용된 엔진으로 시작하였으므로, 상용게임에서 원하는 고도의 추상화가 원래 다 이루어진 상태에서 자유도를 확장시키는 방식으로 범용 엔진으로 만든 것이기 때문에 기본적으로 에픽 사에서 만든 게임의 아키텍처대로 만들도록 되어 있다. 마찬가지로 렌더링의 예를 들자면 원래 주어진 렌더링 파이프라인의 퀄리티는 좋고 원래 제공된 옵션들 중에서 골랐을 대의 편의성은 좋지만 이것을 수정해서 원하는 것을 창조하려고 한다면(예를 들어 카툰 렌더링) 유니티처럼 [[쉐이더]]를 갈아끼우는 방식으로는 불가능하고 [[렌더링]]된 결과를 후처리 가공해서 (사실상의 가짜) 효과를 주거나 아예 엔진 소스를 고쳐서 방식을 우회시켜야 한다. 구체적으로는 쉐이더를 바꾸기 위해서 쉐이더를 생성해주는 엔진의 기능인 머터리얼 에디터의 입력인 머터리얼을 변경하는 식으로 간접적으로 변경하고, 그 결과로 렌더링된 최종 결과물을 포스트프로세싱해야 한다. |
| + | |||
| + | 유니티처럼 '렌더링 자체를 카툰 쉐이더로' 하려면 엔진에서 머터리얼->쉐이더의 생성 코드를 수정해 사용자가 원하는 라이팅 정보를 참조할 수 있도록 만들어야 하며, 라이팅와 연관된 엔진의 다른 여러 부분의 코드들도 그에 맞게 수정해 주어야 한다. 이러려면 당연하게도 쉐이더와 렌더링 파이프라인에 관련하여 프로그래머로서의 상당한 지식을 필요로 하게 된다. 1인칭으로 환경 위에서 캐릭터를 컨트롤하는 구조를 만들려고 할 때, 언리얼이 이미 제공되는(그리고 바꾸기 매우 어려운) 입력->입력 컨트롤러->플레이어 컨트롤러->페르소나 구조를 사용하여 거의 건드릴 것도 없이 상용 수준으로 다양하고 풍부한 조종이 가능한 결과물을 뚝딱 만들어 낼 수 있으나, 그냥 키보드의 W키가 눌릴 때 박스 하나의 좌표가 X방향으로 1미터 바뀌었으면 좋겠다는 근원적인 제어를 원할 때 다른 모든 오브젝트 필요 없이 박스 하나를 놓고 스크립트에서 W키->X좌표 +1 이라는 직결구조를 만들 수 있는 것은 유니티이다. 언리얼 엔진 4 초기 버전의 이슈였던 '반투명 물체를 만들기 힘들다' 역시 이러한 구조적 차이 때문이다. 반투명 물체의 품질유무가 가장 극명하게 드러나는 것이 머리카락 부분인데, 이 때문에 언리얼 엔진에서 높은 퀄리티로 제작된 여러 작품들이 머리카락 부분만 튀거나 고생고생 해서 여러 우회기법을 적용한 모습을 볼 수 있다. 이러한 차이 때문에, 양 엔진의 에셋 스토어에서 뭔가 고급 기능들을 보면 유니티의 경우 엔진에서 돌아가는 [[스크립트]] 코드 혹은 엔진과 함께 돌아가는 플러그인 형태로 제공되는 반면 언리얼의 경우 엔진의 특정 기능을 커스텀한 것 이 에셋으로 제공되는 경우도 있다. 언리얼 엔진이 소스코드를 완전히 제공하는데 반해 유니티 엔진은 제한적(코어 부분은 라이센스가 필요하나 요즘엔 대부분의 패키지는 [[깃허브]]에 개발 소스코드가 공개되어 있다.)인 것을 보고 전자는 개방적, 후자는 폐쇄적이라고 생각하기 쉽지만 이 역시 엔진의 기초 구조 자체가 다르기 때문이다. 언리얼의 경우 엔진 그 자체는 기성품처럼 제약되고 다듬어진 기능들만을 제공하면서 어느 이상 기능 자체를 확장하고 싶으면 필연적으로 엔진의 C++ 소스 코드 자체를 수정하고 다시 빌드를 하는 쪽으로 나아가게 된다. 엔진 개발사에서도 그쪽을 염두에 두고 권장하고 있다. 반면 유니티의 경우 엔진에서 제공하는 인터페이스만을 가지고도 충분히 확장해 나갈 수 있도록 확장 가능성과 범용성을 목표로 처음부터 설계되어서 엔진 자체를 수정해서 기능을 늘려야 할 필요성이 거의 없다. 유니티는 이러한 취지에서 유알피(URP), 에이치디알피(HDRP) 등 렌더링 파이프라인 자체를 사용자가 구성할 수 있는 추가 옵션을 제공하는 등 엔진 자체에서 제공하는 가능성을 확장하는 방향으로 발전해 나가고 있다. 이렇게 유니티와 언리얼은 두가지 엔진에서 이 기능을 할 수 있느냐 없느냐, 단순히 결과물이 멋지느냐 아니냐의 단순한 문제가 아니라, 어떤 엔진, 어떤 결과물을 원하느냐의 조합에 따라 개발자가 학습해야 하는 정보와 개발하는 경로가 완전히 달라진다는 것을 알 수 있다. 엔진 자체의 보안성에 대해서는 둘 모두 큰 차이가 없다. 일단 유니티는 .NET 기반에 다이나믹 로더를 사용하지만, 그 부분은 게임 로직을 만드는 스크립팅 언어로써 [[C#]]를 활용하는 것이지, 엔진 자체는 C++ 이라서 유니티와 비교해도 큰 차이가 없다. 하지만 게임 로직 코드는 넷(NET)을 사용하는 유니티가 압도적으로 털리기 쉽다. 반면 C++을 이용하는 언리얼 엔진은 게임 로직도 어셈블리로 컴파일 되기 때문에 상대적으로 안전하다. 하지만 요즘은 유니티 역시 C++로 번역 후 컴파일하는 아이엘2씨피피(IL2CPP)를 지원하고 있고, 최근의 대규모 개발들은 대부분 중요한 비지니스 로직은 서버에 두고, 클라이언트는 서버에서 데이터를 얻어와서 사용하는 구조로 만들어지기 때문에 보안수준은 결정적으로 프로그래머가 보안요소를 얼마나 적용하느냐가 결정한다. 하지만 싱글 플레이어 게임을 만든다면 언리얼을 쓰거나, 유니티를 쓴다면 중요 코드를 C++로 작성하는 것이 보안에 도움이 될 수도 있다. 그래도 털릴 코드는 뭘로 만들어도 털린다.<ref name = "게임 엔진"></ref> | ||
== 게임 개발 프로세스 == | == 게임 개발 프로세스 == | ||
개발 프로세스는 크게 준비 단계와 개발 단계 2단계로 분류할 수 있다. | 개발 프로세스는 크게 준비 단계와 개발 단계 2단계로 분류할 수 있다. | ||
=== 준비 단계 === | === 준비 단계 === | ||
| − | + | * '''게임 콘셉트 회의''' : 개발하고자 하는 게임의 전반적이 사항들을 결정하는 데 목적이 있으며 개발팀에서 진행한다. 참가자는 기획자, 프로그램 팀장(클라이언트, 서버), 그래픽 팀장(원화, 캐릭터, 배경) 정도가 될 수 있다. | |
| − | 개발하고자 하는 게임의 전반적이 사항들을 결정하는 데 목적이 있으며 개발팀에서 진행한다. 참가자는 기획자, 프로그램 팀장(클라이언트, 서버), 그래픽 팀장(원화, 캐릭터, 배경) 정도가 될 수 있다. | + | * '''게임 시스템 기획''' : 개발하고자 하는 게임에 들어갈 핵심적인 시스템들을 개발자들이 이해할 수 있도록 결정하는 데 목적이 있으며 기획팀에서 진행한다. 참가자는 기획자, 시나리오 작가, 시스템 디자인, 레벨 디자인 정도가 될 수 있다. |
| − | + | * '''일정 및 리소스 관리''': 실질적 게임 구현에 필요한 리소스 양과 개발 일정, 그에 따른 인력구성 등의 세부적인 계획을 수립하는 데 목적이 있다. 참가자는 기획자, 프로그램 팀장, 그래픽 팀장 정도가 될 수 있다.<ref name = "프로세스"></ref> | |
| − | 개발하고자 하는 게임에 들어갈 핵심적인 시스템들을 개발자들이 이해할 수 있도록 결정하는 데 목적이 있으며 기획팀에서 진행한다. 참가자는 기획자, 시나리오 작가, 시스템 디자인, 레벨 디자인 정도가 될 수 있다. | ||
| − | |||
| − | 실질적 게임 구현에 필요한 리소스 양과 개발 일정, 그에 따른 인력구성 등의 세부적인 계획을 수립하는 데 목적이 있다. 참가자는 기획자, 프로그램 팀장, 그래픽 팀장 정도가 될 수 있다.<ref name = "프로세스"></ref> | ||
=== 개발 단계 === | === 개발 단계 === | ||
==== 그래픽 작업 ==== | ==== 그래픽 작업 ==== | ||
| − | + | * '''시나리오 작업''' : 게임의 세계관 설정, 캐릭터 설정, 엔피씨(NPC) 설정, 몬스터 설정, 작업 일정 결정 등을 한다. | |
| − | + | * '''원화 작업''' : 시나리오 결과물을 가지고 원화 작업을 진행한다. | |
| − | + | * '''CG 작업''' : 원화 결과물을 가지고 그래픽 디자이너가 원화를 그래픽 툴을 이용하여 3D 또는 2D로 모델링 한다. | |
| − | 시나리오 결과물을 가지고 원화 작업을 진행한다. | + | * '''애니메이션 작업''' : 시나리오 결과물을 애니메이션(캐릭터 이동, 몬스터 피격, 이동) 작업을 진행한다.<ref name = "프로세스"></ref> |
| − | |||
| − | 원화 결과물을 가지고 그래픽 디자이너가 원화를 그래픽 툴을 이용하여 3D 또는 2D로 모델링 한다. | ||
| − | |||
| − | 시나리오 결과물을 애니메이션(캐릭터 이동, 몬스터 피격, 이동) 작업을 진행한다. | ||
==== 시스템 기획 ==== | ==== 시스템 기획 ==== | ||
| − | + | * '''시스템 디자인''' : 시스템을 어떻게 기획할 지 생각하고 구현이 가능한지에 대해 생각하여 기획서를 만든다. | |
| − | 시스템을 어떻게 기획할 지 생각하고 구현이 가능한지에 대해 생각하여 기획서를 만든다. | + | * '''레벨 디자인''' : 최종 기획서를 바탕으로 수치 디자인을 수정, 보완한다. |
| − | + | ==== 레벨 디자이너, 서버 프로그래머 작업 ==== | |
| − | 최종 기획서를 바탕으로 수치 디자인을 수정, 보완한다. | + | * '''스탯 및 테이블 구성''' : 게임에 적용되는 모든 스탯 및 테이블을 구현 가능한지에 대해 파악하고 최종적으로 스탯 및 테이블을 완성시키는 단계이다.<ref name = "프로세스">artistyang82, 〈[https://artistyang83.tistory.com/1230 게임 개발 프로세스 :: 크리에이티브 아티스트]〉, 《티스토리》, 2019-01-06</ref> |
| − | |||
| − | * 스탯 및 테이블 구성 : 게임에 적용되는 모든 스탯 및 테이블을 구현 가능한지에 대해 파악하고 최종적으로 스탯 및 테이블을 완성시키는 단계이다.<ref name = "프로세스">artistyang82, 〈[https://artistyang83.tistory.com/1230 게임 개발 프로세스 :: 크리에이티브 아티스트]〉, 《티스토리》, 2019-01-06</ref> | ||
{{각주}} | {{각주}} | ||
2021년 7월 20일 (화) 11:54 판
게임 개발이란 게임을 만들고 춢시 하는것을 의미한다. 분야로는 게임 기획자, 게임 디자이너, 게임 프로그래머 등 3가지 직종이 있다. 이 세 가지 분야팀들이 협력을 통해 게임이라는 하나의 결과물을 만들어 내는 것을 게임 개발이라고 한다.
게임 기획자
게임은 다양한 분야의 영역들이 믹스된 영화의 영역에서 보다 진보된 현대적 프러덕션이라고도 할수있다. 그래픽, 음악, 연기, 스토리, 촬영, 컴퓨터 사이언스, 경제등 다양한 영역이 필요에 따라 게임에 반영된다. 이러한 영역들이 서로 잘 섞여 게임이라는 결과물로 바뀌도록 관리해나가는 사람이 기획자다.[1]
요구 능력과 담당 직무
기획자에게 요구되는 역량은 게임마다 달라진다. 기본적으로 프로젝트 관리 역량을 갖추어야 하며, 추가적으로 개발할 게임에 필요한 능력 전반에 대해 알아야 한다.
- 시스템 : 게임에 기반이 되는 시스템 및 프로그램적으로 개발되는 요소를 책임진다. 프로그래밍 관련 지식이 필요하다.
- 시나리오 : 게임에 기반이 되는 스토리, 캐릭터, 퀘스트 등 텍스트와 등장할 캐릭터요소를 책임진다. 문화 예술 관련 지식이 필요하다.
- 레벨 디자인 : 게임에 기반이 되는 맵에 사이즈, 배치요소를 담당한다. 건축과 크기에 따른 공간적 지식과 플레이타임 등을 계산할 게임적 지식이 필요하다.
- 운영 : 게임내 운영 업무로 기획한 내용에 반영 되었을때 운영에 관련 내용을 담당한다. 라이브 기획자가 주로 다른 기획업무와 병행하는 업무이다.
- 밸런싱 : 게임에 수치들을 담당하며, 데이터와 수학지식, 게임룰에 따른 수치화에 대한 통찰력이 필요한다.[1]
- 게임 내 경제 : 게임 내 경제를 시뮬레이션 할 능력과 지식이 필요하다. 게임 내 몬스터 드랍, 획득 게임머니 등 요소를 담당한다.
게임 그래픽 디자이너
게임 그래픽 디자이너는 컴퓨터 게임 등에 등장하는 각종 캐릭터와 배경, 아이템 등을 디자인하는 역할을 한다.
배경, 캐릭터 원화가
배경, 캐릭터 원화가는 기본적으로 포토샵만 알고 있으면 되는 분야라 알아야 되는 툴은 제일 적지만 본인 실력과 디자인에 취업이 크게 결정되는 파트 원화가는 컨셉 아티스트(concept artist)라고도 불리며 컨셉, 즉 게임에서 드러내려는 이미지를 그려내는 직업군이다. 배경 원화가는 건물, 자연 등의 도안과 디자인을 담당하며 배경을 그릴 때 설계 구도가 굉장히 중요한 요소로 작용한다. 캐릭터 원화가는 캐릭터의 전반적인 설정을 담당하는 역할을 하며 무기 원화가, 몬스터 원화가 등으로 나뉘기도 한다. 캐릭터 원화가에게는 기본적으로 드로잉 실력이 요구되며 이를 위해 인체구조에 대한 이해가 필요하다. 또 캐릭터 원화가는 인체만 그리는 것이 아니라 의복, 몬스터, 무기 등 다양한 영역의 그림들을 그려야 하므로 다양한 자료들을 바탕으로 보다 많은 것들을 그릴 수 있는 능력을 키워야 한다.[2]
배경, 캐릭터 모델러
배경 캐릭터 모델러는 캐쥬얼이냐 반실사냐 실사냐에 따라 제작방식이 조금씩 달라질 뿐 다룰 줄알아야되는 프로그램은 거의 동일하다. 쓰리디맥스 또는 마야, 바디페인터, 제트브러쉬가 기본적이며 최근 실사풍이 중요해지면서 서브스텐스 쓰리디오 등 피비비 쪽도 어느정도 알아야 한다. 다른 파트에 비해 새로운 프로그램과 트렌드가 등장했을때 심하게 타격 받는 파트이다. 모델러는 원화에 있는 캐릭터, 아이템, 건물, 배경 등 게임에서 보이는 모든 것들을 3D 이미지로 구현한다. 이른바 게임의 뼈대(원화)에 쓰리디로 살을 붙이는 작업이라 할 수 있다. 배경 모델러는 원화에 있는 제품, 건물, 도로나 전체적인 지형을 그래픽으로 만들며 원화의 전체구도 및 원근감 등의 관련된 부분을 3D로 만들어야 한다. 캐릭터 모델러는 인체 구조를 기반으로 모델링을 진행해야 한다. 따라서 구조 이해도를 위한 정물, 인물 등을 잘 그려야 하며 원화가 못지않은 이해도를 가져야 한다. 게임 툴인 쓰리디 스튜디오 맥스와 애니메이션 툴인 마야등을 다룰 줄 알아야하며 포토샵으로 컬러, 질감, 표정들을 입히는 맵핑 작업 및 다양한 맵핑 소스들을 활용할 수 있어야 한다. 또, 세밀한 표현을 위해 2D 와 3D의 중간을 표현할 수 있는 지브러시 머드박스와 같은 프로그램을 다룰 수 있으면 좋다. 3D 그래픽 디자이너들의 작업 과정을 간략히 설명하자면 다음과 같다.[2]
- 원화 분석: 먼저 원화가로부터 컨셉 원화를 받아 분석한다. 참고로 3D로 구현해야 하기 때문에 구조의 움직이는 부분이 따로 필요하며, 다양한 시점으로 표현된 원화또한 필요하다. 모델러는 넘겨받은 원화에서 만들어야 할 이미지의 컨셉을 파악하고 특징을 어떻게 표현할 것인지 결정한다.
- 모델링 : 원화를 3D로 조형한다. 최대한 원화의 느낌을 살리는 것이 중요하지만 3D로 구현할 수 없거나, 고쳐야 할 부분이 있을 경우 수정해 가며 모양을 만든다.
- 텍스쳐 작업 : 완성된 모델링 이미지는 색이 존재하지 않거나 단색이다. 여기에 색과 표면의 질감을 살리기 위해 텍스쳐를 입힌다.[2]
- 게임엔진 적용 : 텍스쳐를 마무리하고 완성된 3D 이미지를 게임에서 쓰기 위해 게임엔진에 적용한다.[2]
이펙터
이펙터의 주 업무는 타격, 스킬, 움직임, 유아이(UI) 등 게임 화면상의 나타나는 모든 효과를 다루는 일이다. 대부분 먼저 만들어 놓고 차후에 타이밍이나 색감, 길이 등을 맞춰보는 튜닝 작업으로 이루어진다. 이펙터는 원화를 참고하여 그리기도 하지만 이미지가 전부 제시된 것은 아니기 때문에 어느 정도 감각이 있어야 한다. 이펙터는 단순히 효과만을 만드는 것이 아니라 캐릭터의 동작과 연계된 효과도 생각해야 하기에 애니메이션과 모델링 등 전반적인 작업을 모두 할 수 있어야 한다. 포토샵 애프터 이펙트 쓰리디맥스의 초,중급은 되어야 되며 추가로 각 회사에서 요구하는 엔진의 이펙트 툴도 같이 알아야 된다. 어찌보면 이펙터가 다룰 줄 알아야되는 프로그램은 제일 많을 것이다. 그만큼 귀한 직업군 이기도하고 제일 화려하고 게임의 타격감에 지대한 영향을 끼치는 분야이기도 하다.[2]
애니메이터
애니메이터는 완성된 캐릭터나 몬스터 등에게 행동력을 주는 사람이다. 모든 입력 장치에 들어가는 애니메이션을 각각 만들고 이 애니메이션을 부드럽게 연결하는 작업을 한다. 애니메이터는 작업할 때 포즈와 타이밍이 서로 어긋나지 않도록 연결해야 하며 모든 동작은 기획서, 세계관, 캐릭터의 성격에 맞게 각각 구현 되어야 한다. 때리는 동작과 사운드, 리액션을 타격감이라고 하는데, 타격감을 맞춰 주는 것도 애니메이터의 역할이다. 게임 애니메이터는 원화가가 작업한 작업물을 바탕으로 모델링한 각각의 캐릭터에 움직임을 줄 수 있는 부분(관절과 표정 등)을 넣어 명령에 맞춰 움직일 수 있도록 만드는 작업을 한다고 볼 수 있다. 애니메이터의 역량을 키우려면 크로키를 통해 순간적으로 인체의 구조를 파악하는 훈련을 하면 좋다. 2D냐 3D냐에 따라 그리고 회사에서 어떤 엔진으로 게임을 제작해느냐에 따라 다룰 줄 알아야되는 툴이 조금씩 틀리다. 2D는 라이브2D, 스파인이 기본적이라 봐야되며 3D는 쓰리디맥스가 제일 압도적이며 그다음 마야를 알아야 한다. 캐릭터와 배경의 소품 등 움직이는 것들을 움직이게 해준다.[2]
게임 프로그래머
게임 프로그래머는 프로그래밍을 통해 맵 디자인, 캐릭터 디자인, 사운드, 각종 시스템 등을 뒤섞어, 게임이라는 하나의 결과물을 만드는 직군이다. 게임을 만드는 데 있어 가장 귀중한 인력이다. 실제로도 게임 업계에서 프로그래머의 연봉이 기획자나 그래픽 디자이너보다 높은 경우가 많다. 수십, 수백명의 개발자들이 필요한 트리플에이 게임들은 다양한 분야의 전문가들을 필요로 한다. 아직도 수많은 사람들이 게임 프로그래밍의 대해서 착각하는 것 중 하나인데, 같은 게임 프로그래머라고 해도 전문 분야가 다르면 필요한 지식, 경력, 성격, 등등이 완벽하게 달라진다.[3]
게임플레이 프로그래머
게임플레이 프로그래머는 만능형 프로그래머(Generalist Programmer)가 많다. 간단한 설명은 다른 프로그래머들은 게임 엔진 쪽으로 더 가깝고 게임플레이는 말 그대로 "유저들이 게임이라고 느끼는" 부분. 카운터 스트라이크를 예로 들면 플레이어의 움직임, 총기의 작동 원리, 폭탄이 폭파하면 테러리스트가 승리한다는 규칙 등이 다 게임플레이다. 게임을 사랑해서 게임 프로그래머가 됐다면 웬만하면 이쪽으로 간다. 게임 규모가 작으면 난이도가 다른 분야보다 낮다. 수학의 경우 방향 관련 계산을 하기 위한 선형대수학의 기초만 대충 알면 괜찮다. 하지만 게임 규모가 커지면 접하게 되는 코드의 분야가 너무 넓어지기 때문에 다른 분야보다 쉽지 않다. 이러면 전혀 모르는 분야라도 기초적인 부분을 공부해서 대강 이해를 할 줄 알아야 한다. 그러려면 '컴퓨터 게임'을 이해를 하고 사랑을 해야만 일이 된다. 트리플 에이 규모쯤 가보면 어느 날은 엔피씨(NPC)의 비행 능력을 위해서 팔진트리로 3D 최단 경로 찾기 알고리즘을 공부하고, 그 다음 날은 두명의 플레이어 캐릭터들의 잡기 공격을 어떻게 코딩해야 렉이 있는 상태에서 두 명이 동일한 상황을 보게 만드나 생각해야 한다. 결론은 특정 분야에 많은 지식이 필요하지는 않지만, 프로그래머로서의 눈치와 해석력이 많이 요구된다.[3]
물리 엔진 프로그래머
게임에 필요한 물리 계산을 빠르게, "필요한 만큼 정확하게" 하는 개발을 한다. 프로그래머 항목에 프로그래머들은 거창한 알고리즘 연구를 안한다고 하지만, 이쪽은 그런 짓을 할만한 인간들이 필요하다. 유저들은 매년 상향되는 그래픽, 물리 엔진을 보고 싶어하고, 만족할만한 게임을 만들기 위해서 더 새로운 그래픽 기술들의 효율적인 계산이 필요하다. 그래서 이쪽은 컴공보다 물리학자, 수학자들이 더 많이 보인다. 수학의 경우 사원수, 오일러 각 등의 3D 수학을 기초로 알아야 인턴쉽이 잡힌다.[3]
그래픽/랜더링 프로그래머
3D 그래픽이나 애니메이션을 빠르게 계산하고, 효율적으로 유저의 모니터로 출력하는 개발을 한다. 위와 비슷하게 순수한 프로그래밍보다 수학, 물리쪽 지식을 더 많이 필요로 한다. 위와 비슷하게 비쥬얼적으로 나쁘지 않다라고 생각될정도면 계산을 단순화하거나 수학적인 알고리즘으로 최적화를 한다. 난이도가 높아질 수록 최소 수학과 또는 물리학과 3~4학년 수준 지식을 요구하기도 한다. 인터넷에 친절하게 알려주는 기법도 왕왕 있지만 최신기술을 사용하거나, 최신기술이라고 보긴 힘들지만 구현 난이도가 상당히 높은 축에 해당하는 기술, 또는 색다른 느낌의 비실사주의 셰이더의 최신기법을 구현하고자 할려면 인터넷 검색으로는 답이 없다. 영어로 된 논문과 인용된 논문을 읽어가며 그 논문에서 말하고자 하는 수학 물리공식을 이해하고 그것을 프로그래밍적으로 구현할 줄 알아야 한다. 정말 독특하고 유니크한 것은 논문으로도 발표된 사례가 없어 바닥부터 직접 만드는 경우가 왕왕 존재한다. 수학이 싫거나 자신이 없다면 가장 멀리해야 하는 분야. 그런고로, 여기 나열 된 분야중에, 독보적으로 난이도가 높으며, 그에 비례해 대우가 좋다. 규모가 작은 곳에서는 상용 엔진을 쓰기 때문에 비주얼 셰이더 툴을 이용해 적당히 셰이더 만들어서 쓰는 경우가 많아 이 포지션이 없는 경우도 많다. 다만 AAA급으로 가면 반드시 필요하며, 제대로만 하면 여기저기서 모셔가려고 용을 쓴다. 유독 이 분야의 사람들이 다른 포지션의 일을 겸하는 경우가 많은데, 그 만큼 다른 기술의 밑바탕이 확실해야 할 수 있는 분야라는 뜻이다.[3]
개발 도구 프로그래머
게임 개발에서는 동떨어져 있는 직무로, 대규모 회사 아니면 절대 못 볼 직무이다. 대부분 프로그래머가 아닌 개발자들이 프로그래머들의 도움이 없이 개발에 참여를 하게 해주는 도구들을 개발한다. 아티스트 직군을 위한 배치 툴을 짜기도 한다. 그게 아니면 엔진을 뜯어고치는 경우도 있다. 무엇이 되건간, 비 프로그래머 직군과의 융화를 보다 윤택하기 위한 목적이 있다. 게임 디자이너들이 아주 기초적인 코딩 실력으로 게임을 완벽하게 바꿀수 있게 하는게 주 목적이다. 회사 규모가 더 크면 게임이랑 전혀 관련 없는 직원, 빌드 관리 소프트웨어도 만들게 된다. 이 정도까지 되면 상당히 고수준의 프로그래밍 지식이 필요한 경우이다.[3]
네트워크/서버 프로그래머
온라인 게이밍의 핵심이라고 볼수 있다. 클라이언트와 서버 간의 데이터 송수신을 다루고, 렉을 줄이기 위해서 최소한의 정보를 보낼 방법과, 심한 렉, 서버 다운, 디도스 공격 등의 문제를 해결할 방법을 연구한다. 데이터 사용량을 줄이는 동시에 클라이언트의 시점에서 렉이 안보여야 하는데, 잘못된 디자인은 0.1초의 렉으로도 유저와 유저 밖의 세상이 따로 노는 느낌을 줄 수 있다. 한국사람으로서 상상하기 어려울수도 있겠지만 세계의 평균 인터넷 속도는 낮은 편이고, 구형 모뎀 인터넷으로 지구 반대쪽에 있는 서버를 통해서 게임을 해야 할 사람도 있으니, 세계적인 온라인 게임을 만들기 위해서는 1바이트의 추가 데이터도 신중히 다뤄야 한다. 또한 대부분의 게임 개발사는 디비(DB)를 따로 두지 않으므로, 사실상 데이터베이스 지식까지 요구되는 직군이다.[3]
게임 엔진
각자 회사마다 다른 엔진들을 사용하고 어떤 회사들은 자체엔진을 사용하기도 한다. 하지만 대표적으로 유니티나 언리얼 엔진 둘중에 하나를 기반으로 게임을 제작하는 회사가 대부분이다. 그럼 이 두 개의 엔진을 소개하고 차이점을 알아보도록 하겠다.
유니티3D
유니티는 C#를 기본 스크립트 언어로 사용한다. C# 언어 자체가 C++에 비해 적응이 빠른편이라 비 프로그래밍 직군도 많이 접근하게 된다. 유니티의 경우 스크립트 생성시 모노비헤이비어(Monobehaviour) 만을 상속받아 스크립팅을 하게 만들었다. 해당 파이프라인을 하나로 통일한 덕에 추가적인 기능은 언리얼에 비해 부족해 컴포넌트 애드온을 필요한 분량만큼 추가해주어야 하지만, 그 대신 컴포넌트를 붙이는데 제약이 적고 수정시 에디터상에 즉각 반영이 되는 핫 리로드 기능이 굉장히 강력하게 구비 되어있다. 주 언어가 C#인것도 한 몫 하는데, 어느 객체를 만들었으면 해당 객체에 대해서만 컴파일이 완료되면 바로 실행이 가능하다. 그렇기에 스크립트의 추가가 굉장히 자유롭고 에디터상에서 직관적이고 즉각적으로 반영이 가능하다. 보통 왠만큼 크지 않는 이상 스크립트를 수정하면 바로 에디터 창으로 돌아와 실행이 가능할정도라 자체 피드백 순환과 매우 빠르게 처리할 수 있다는 이점이 있다. 이러한 강점은 개별 오브젝트에 눈에 보이는대로 컴포넌트를 붙이면 사용자가 모르는 새 컴파일 되면서 사용 가능한 상태로 바꾸기 때문에, 필요한 요소는 그때그때 만들어 쓸 수 있다는 강점을 가지고 있다. 문제는 비 프로그래밍 직군 작업자에 대한 편의는 적은편이다. 언리얼을 따라 비주얼 스크립트를 개발했지만 사실상 유명무실하며 결국에는 비 프로그래밍 직군의 인원도 코드를 알아야 정확한 작업을 진행할수 있다. 이는 하단에 유니티 비주얼 스크립팅 문단에 후술한다. 유니티는 엔진 소스 코드를 제공하지 않아 소스 코드를 제공받기 위해서는 별도로 고가의 계약 체결이 필요하다. 때문에 고수준의 작업에서는 자잘한 문제가 발생하고, 이를 피하고 개선하기위해 우회를 반복하다가 어느새 엔진내 소스를 스파게티처럼 만드는 경우도 더러 있다.[4]
언리얼4
초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진 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)과 비슷한 문법 구조를 채택하고 있어 해외 커뮤니티에서는 배우기 쉽고 블루프린트를 대체해 줄 것으로 예상하고 있다.[4]
두 엔진의 본질적 차이
흔히 착각하는 것이 두 엔진을 그저 퀄리티나 언어만 다른 비슷한 도구로 생각하는 것인데, 두 엔진의 개발 방식 접근성은 극명하게 다르다. 대표적인 예시로 유니티는 기본 기능이 비교적 빈약하고, 소스를 고칠 수 없는 대신, 기능이 매우 가볍고 사용하기 간편하며 에셋 및 패키지를 구매하거나 덧붙여 보강이 원활하여 추가 모듈을 부착하거나 떼는 식으로 대응한다. 언리얼 엔진은 엔진 자체에서 대부분의 강력한 기능을 제공하지만, 개발사(에픽)의 방향성에 맞춘 기성품에 더 가까워 상대적으로 확장성이 제한된다. 엔진의 성능을 제대로 활용하기 위해서는 고급 인력 또는 방대한 규모의 팀이 필요하다. 당연히 언리얼에도 에셋에 대응하는 플러그인이 존재하지만 이것으로 기능을 늘려나가기에는 한계가 있는데다, 플러그인을 정리하지 않으면 프로젝트 전체가 크래시가 나기 쉬워 적용할때도 상당히 많은 주의를 요한다. 유니티의 경우 입력 메시지의 흐름이나 렌더링 구조를 포함한 엔진의 대부분이 나뉘어져 제각기 접근하고 조립할 수 있다. 예를 들어 렌더링의 경우 쉐이더를 편집한다고 할 때 게임 데이터의 모든 단계를 쉐이더에 사용하고 대부분의 경우 원하는 만큼 충분한 큐잉과 컬링 분류를 할 방법을 제공한다. 대신 그 각각의 기능을 조립하고 옵션을 짜맞추는 것은 개발자의 몫이며, 점점 하이퀄리티로 올라갈수록 코스트 또한 장난 아니게 높아진다. 후반부로 갈수록 퀄리티 상승을 위해 처리해야될 문제들이 산더미처럼 쌓이며, 이는 프로젝트 중후반부에 진입한 게임사들이 언리얼로 전환하는 원인이 되기도 한다. 반면 언리얼의 경우는 회사에서 사용된 엔진으로 시작하였으므로, 상용게임에서 원하는 고도의 추상화가 원래 다 이루어진 상태에서 자유도를 확장시키는 방식으로 범용 엔진으로 만든 것이기 때문에 기본적으로 에픽 사에서 만든 게임의 아키텍처대로 만들도록 되어 있다. 마찬가지로 렌더링의 예를 들자면 원래 주어진 렌더링 파이프라인의 퀄리티는 좋고 원래 제공된 옵션들 중에서 골랐을 대의 편의성은 좋지만 이것을 수정해서 원하는 것을 창조하려고 한다면(예를 들어 카툰 렌더링) 유니티처럼 쉐이더를 갈아끼우는 방식으로는 불가능하고 렌더링된 결과를 후처리 가공해서 (사실상의 가짜) 효과를 주거나 아예 엔진 소스를 고쳐서 방식을 우회시켜야 한다. 구체적으로는 쉐이더를 바꾸기 위해서 쉐이더를 생성해주는 엔진의 기능인 머터리얼 에디터의 입력인 머터리얼을 변경하는 식으로 간접적으로 변경하고, 그 결과로 렌더링된 최종 결과물을 포스트프로세싱해야 한다.
유니티처럼 '렌더링 자체를 카툰 쉐이더로' 하려면 엔진에서 머터리얼->쉐이더의 생성 코드를 수정해 사용자가 원하는 라이팅 정보를 참조할 수 있도록 만들어야 하며, 라이팅와 연관된 엔진의 다른 여러 부분의 코드들도 그에 맞게 수정해 주어야 한다. 이러려면 당연하게도 쉐이더와 렌더링 파이프라인에 관련하여 프로그래머로서의 상당한 지식을 필요로 하게 된다. 1인칭으로 환경 위에서 캐릭터를 컨트롤하는 구조를 만들려고 할 때, 언리얼이 이미 제공되는(그리고 바꾸기 매우 어려운) 입력->입력 컨트롤러->플레이어 컨트롤러->페르소나 구조를 사용하여 거의 건드릴 것도 없이 상용 수준으로 다양하고 풍부한 조종이 가능한 결과물을 뚝딱 만들어 낼 수 있으나, 그냥 키보드의 W키가 눌릴 때 박스 하나의 좌표가 X방향으로 1미터 바뀌었으면 좋겠다는 근원적인 제어를 원할 때 다른 모든 오브젝트 필요 없이 박스 하나를 놓고 스크립트에서 W키->X좌표 +1 이라는 직결구조를 만들 수 있는 것은 유니티이다. 언리얼 엔진 4 초기 버전의 이슈였던 '반투명 물체를 만들기 힘들다' 역시 이러한 구조적 차이 때문이다. 반투명 물체의 품질유무가 가장 극명하게 드러나는 것이 머리카락 부분인데, 이 때문에 언리얼 엔진에서 높은 퀄리티로 제작된 여러 작품들이 머리카락 부분만 튀거나 고생고생 해서 여러 우회기법을 적용한 모습을 볼 수 있다. 이러한 차이 때문에, 양 엔진의 에셋 스토어에서 뭔가 고급 기능들을 보면 유니티의 경우 엔진에서 돌아가는 스크립트 코드 혹은 엔진과 함께 돌아가는 플러그인 형태로 제공되는 반면 언리얼의 경우 엔진의 특정 기능을 커스텀한 것 이 에셋으로 제공되는 경우도 있다. 언리얼 엔진이 소스코드를 완전히 제공하는데 반해 유니티 엔진은 제한적(코어 부분은 라이센스가 필요하나 요즘엔 대부분의 패키지는 깃허브에 개발 소스코드가 공개되어 있다.)인 것을 보고 전자는 개방적, 후자는 폐쇄적이라고 생각하기 쉽지만 이 역시 엔진의 기초 구조 자체가 다르기 때문이다. 언리얼의 경우 엔진 그 자체는 기성품처럼 제약되고 다듬어진 기능들만을 제공하면서 어느 이상 기능 자체를 확장하고 싶으면 필연적으로 엔진의 C++ 소스 코드 자체를 수정하고 다시 빌드를 하는 쪽으로 나아가게 된다. 엔진 개발사에서도 그쪽을 염두에 두고 권장하고 있다. 반면 유니티의 경우 엔진에서 제공하는 인터페이스만을 가지고도 충분히 확장해 나갈 수 있도록 확장 가능성과 범용성을 목표로 처음부터 설계되어서 엔진 자체를 수정해서 기능을 늘려야 할 필요성이 거의 없다. 유니티는 이러한 취지에서 유알피(URP), 에이치디알피(HDRP) 등 렌더링 파이프라인 자체를 사용자가 구성할 수 있는 추가 옵션을 제공하는 등 엔진 자체에서 제공하는 가능성을 확장하는 방향으로 발전해 나가고 있다. 이렇게 유니티와 언리얼은 두가지 엔진에서 이 기능을 할 수 있느냐 없느냐, 단순히 결과물이 멋지느냐 아니냐의 단순한 문제가 아니라, 어떤 엔진, 어떤 결과물을 원하느냐의 조합에 따라 개발자가 학습해야 하는 정보와 개발하는 경로가 완전히 달라진다는 것을 알 수 있다. 엔진 자체의 보안성에 대해서는 둘 모두 큰 차이가 없다. 일단 유니티는 .NET 기반에 다이나믹 로더를 사용하지만, 그 부분은 게임 로직을 만드는 스크립팅 언어로써 C#를 활용하는 것이지, 엔진 자체는 C++ 이라서 유니티와 비교해도 큰 차이가 없다. 하지만 게임 로직 코드는 넷(NET)을 사용하는 유니티가 압도적으로 털리기 쉽다. 반면 C++을 이용하는 언리얼 엔진은 게임 로직도 어셈블리로 컴파일 되기 때문에 상대적으로 안전하다. 하지만 요즘은 유니티 역시 C++로 번역 후 컴파일하는 아이엘2씨피피(IL2CPP)를 지원하고 있고, 최근의 대규모 개발들은 대부분 중요한 비지니스 로직은 서버에 두고, 클라이언트는 서버에서 데이터를 얻어와서 사용하는 구조로 만들어지기 때문에 보안수준은 결정적으로 프로그래머가 보안요소를 얼마나 적용하느냐가 결정한다. 하지만 싱글 플레이어 게임을 만든다면 언리얼을 쓰거나, 유니티를 쓴다면 중요 코드를 C++로 작성하는 것이 보안에 도움이 될 수도 있다. 그래도 털릴 코드는 뭘로 만들어도 털린다.[4]
게임 개발 프로세스
개발 프로세스는 크게 준비 단계와 개발 단계 2단계로 분류할 수 있다.
준비 단계
- 게임 콘셉트 회의 : 개발하고자 하는 게임의 전반적이 사항들을 결정하는 데 목적이 있으며 개발팀에서 진행한다. 참가자는 기획자, 프로그램 팀장(클라이언트, 서버), 그래픽 팀장(원화, 캐릭터, 배경) 정도가 될 수 있다.
- 게임 시스템 기획 : 개발하고자 하는 게임에 들어갈 핵심적인 시스템들을 개발자들이 이해할 수 있도록 결정하는 데 목적이 있으며 기획팀에서 진행한다. 참가자는 기획자, 시나리오 작가, 시스템 디자인, 레벨 디자인 정도가 될 수 있다.
- 일정 및 리소스 관리: 실질적 게임 구현에 필요한 리소스 양과 개발 일정, 그에 따른 인력구성 등의 세부적인 계획을 수립하는 데 목적이 있다. 참가자는 기획자, 프로그램 팀장, 그래픽 팀장 정도가 될 수 있다.[5]
개발 단계
그래픽 작업
- 시나리오 작업 : 게임의 세계관 설정, 캐릭터 설정, 엔피씨(NPC) 설정, 몬스터 설정, 작업 일정 결정 등을 한다.
- 원화 작업 : 시나리오 결과물을 가지고 원화 작업을 진행한다.
- CG 작업 : 원화 결과물을 가지고 그래픽 디자이너가 원화를 그래픽 툴을 이용하여 3D 또는 2D로 모델링 한다.
- 애니메이션 작업 : 시나리오 결과물을 애니메이션(캐릭터 이동, 몬스터 피격, 이동) 작업을 진행한다.[5]
시스템 기획
- 시스템 디자인 : 시스템을 어떻게 기획할 지 생각하고 구현이 가능한지에 대해 생각하여 기획서를 만든다.
- 레벨 디자인 : 최종 기획서를 바탕으로 수치 디자인을 수정, 보완한다.
레벨 디자이너, 서버 프로그래머 작업
- 스탯 및 테이블 구성 : 게임에 적용되는 모든 스탯 및 테이블을 구현 가능한지에 대해 파악하고 최종적으로 스탯 및 테이블을 완성시키는 단계이다.[5]
각주
참고자료
- 〈게임 기확자〉, 《나무위키》
- 〈게임 그래픽 디자인〉, 《나무위키》
- 〈게임 프로그래머〉, 《나무위키》
- artistyang82, 〈게임 개발 프로세스 :: 크리에이티브 아티스트〉, 《티스토리》, 2019-01-06
- 〈언리얼 엔진 vs 유니티 엔진〉, 《나무위키》
같이 보기
