E D R , A S I H C RSS

레벨 디자인

last modified: 2015-02-21 00:18:10 by Contributors

Contents

1. 레벨의 정의
2. 레벨 디자인의 정의
3. 레벨 디자이너
3.1. 컨셉 디자이너
3.2. 공간 디자이너
3.3. 배경 디자이너
3.3.1. 텍스처 디자이너
3.3.2. 배경 오브젝트(프롭) 디자이너
3.3.3. 조명 디자이너
3.4. 스크립트 디자이너
4. 레벨 일을 병행하는 다른 직군들
4.1. 게임 기획자가 맡는 경우
4.1.1. 퀘스트, 콘텐츠 디자이너
4.1.2. 시스템 디자이너, 밸런서 (밸런스 디자이너)
4.1.3. 시나리오 라이터
4.2. 그래픽 디자이너가 맡는 경우
4.3. 프로그래머가 맡는 경우
5. 레벨(맵)을 만드는 기준
6. 레벨(맵) 제작방식
7. 레벨 디자이너로 취직하기 위해선?
8. 관련 항목
9. 관련 개념 및 용어들
10. 관련 커뮤니티 사이트/카페
11. 관련 SNS (추가바람)
12. 관련 문서

1. 레벨의 정의

여기에서 언급할 으로서의 레벨이란 D&D 등 초창기 RPG에서 던전의 깊이(Level)를 게임 난이도와 테마로 구분했던 것에서 유래된 것이며, 흔히 RPG에서 캐릭터의 등급을 나타내는 레벨과는 동음이의어로 그 뜻이 전혀 다르다.

실제 국내에서 MMORPG 붐이 일었고 레벨 디자인이란 개념이 생소하던 2000년대 초중반까진 '레벨'이라 하면 캐릭터의 레벨부터 연상시켜, 레벨 디자인이나 디자이너를 시스템/벨런싱 쪽에서 레벨을 디자인(기획 및 수정)하는 사람을 칭하는 용어로 쓰인 적이 있으며, 지금도 그런 의미로 간간히 쓰이곤 한다.

2. 레벨 디자인의 정의


레벨 디자인이란 쉽게 말해 스테이지(맵) 디자인이라 할 수 있으며, 좁게는 FPS, TPS, RPG, RTS, 슈팅 게임에서 퀘스트나 이벤트까지 포괄한 맵 디자인을, 넓은 의미로는 보드 게임에서의 칸 설정이나 배치까지 레벨 디자인으로 쳐주지만 통상적으로 전자에서의 의미로 많이 쓰이며, 배경이나 환경 디자인(environment design) 또한 원래 레벨 디자인의 범주에 들어갔었으나 근래들어 이 둘을 분업화 해 운용하는 곳도 꽤 된다.

하지만 전문적 분업화가 이루어져도 레벨 디자인을 프로그래밍이나 기획, 그래픽 같은 전문화된 영역이라 구분짓는것은 아직 시기상조다. 일부 개발사가 레벨의 중요성이나 비중을 높게 잡고 레벨 기획과 배경을 포괄한 독립된 팀이나 파트를 운용하긴 하지만 퍼즐 게임, 캐주얼 게임처럼 레벨의 중요성이 낮은 게임 개발에선 기획(= 콘텐츠 디자인)이나 그래픽 등의 일부로 보고 그 팀에서 병행 혹은 알바인턴에게 맡기는 등, 게임이나 제작사 따라 제각각 다르기 때문이다.

또한 비슷한 주제의 건축 쪽과 엮는 이들도 적잖아 있지만 인간 생존 본능을 통한 더 좋은 레벨 디자이닝에 따르면 레벨은 건축과는 달리 삶, 죽음, 그리고 그 사이의 모든 걸 탐험함으로서 얻을 수 있는 긴장감(과 거기에서 파생되는 보람, 성취감)을 위한 기계여야만 한다고 한다. 때문에 게임의 성격과 주제를 살리면서도 재미있게 만드는 것이 목적인 기본에 충실하는 게 좋다. 물론 여기에 도달하고자 비현실적이고 작위적 요소들을 넣어도 애당초 이걸 하는 이들 대다수가 가상현실에서 재미를 느끼려 하는 것이라 재미만 있다면야 어느 정도는 용인해 주는 편이다.

3. 레벨 디자이너


자동차를 예를 들면 프로그래머는 엔진을(정확히 말하면 섀시), 아티스트는 외관을, 레벨 디자이너는 국도 드라이브의 경험을 제공한다 - Lee Perry
사실 게임 기획 최종 테크 & 끝판왕이라 카더라

회사나 커뮤니티마다 그 정의나 칭호가 다르다. 예를 들면 그림을 그리는 화가 등을 그림쟁이로 낮춰 칭하듯, MOD쪽 커뮤니티나 관련자들이 많은 회사에선 이들을 매퍼(Mapper: 맵쟁이)라 부르기도 하지만 (기술자를 존중하는 의미에서) 장이를 칭하는 용어로도 쓰이니 그리 기분 나빠할 일은 없다. 대체적으로 맵의 구조와 동선, 외형을 디자인하지만 경우에 따라선 맵의 텍스처나 NPC / 이벤트 스크립트 등도 담당한다.

그리고 이들의 긍극적 목표이자 소망(?)은 이걸 하는 사람들이 좋은 경험을 갖게 만드는 것이다. 예를 들면 진행이나 연출, 아이템 등이 적재적소에 있어 너무 쉽지도, 어렵지도 않고 또한 밸런스가 잘 잡혀 상대에게 일방적으로 당하지 않고 그들과 호각을 이루는 것. 그런데 이론과 현장에서의 실전은 다르듯, 이들은 거의 필수적으로 수십, 수백, 수천번의 테스트를 거쳐 만인 대부분이 만족할 적정선을 찾아나간다.

아래는 분야별 전문화된 직종이며, 맵 제작에 관여하는 순서대로 나열.

3.1. 컨셉 디자이너




이 직종은 문서 및 그것만으론 설명하기엔 한계가 있는 예컨데 조명의 강도, 이벤트가 벌어지는 위치 같은 것에 대해 각종 자료를 수집하거나게임 원화가에 준하는 그림 실력을 통해 (작업할 혹은 작업중인) 레벨의 성격을 좀 더 구체화한다. 그림 실력이 딸리면 사진으로 떼우거나 배경 원화가나 그림 감각이 있는 다른 디자이너에게 이 일을 맡기기도 한다. 외부 공개가 아닌 내부 이미지를 정하기 위해서라면 그림의 디테일은 크게 상관없다.

국내에선 게임 기획자 직종 중 하나인 '레벨 기획'이 이 위치를 대체하며, 엑셀 등으로 레벨의 구조나 주제 등을 문서화해 다른 디자이너에게 넘기는 일을 하는데, 물론 후술하겠지만 이것만 하면 상당히 땡보인지라 배경을 오가며 자신이 상상하는 이미지에 걸맞게 이것저것 간섭하거나 시스템이나 밸런스 디자인까지 맡기도 한다.

3.2. 공간 디자이너


공간이나 구조 계획가 등 부르는건 제각각이나 공통적으로 위에서 구체화된 레벨의 대략적인 구조나 설정을 따르되, 여기에 각종 사물이나 요소 등을 적절한 위치나 타이밍에 배치한 프로토타입 레벨을 제작, 여기서 그 자체가 인지 재미가 있고 밸런스도 나름 맞아 고추장(세부 요소) 등을 가미하면 쌈장이 될 된장인지를 판별하고 어느정도 개선됐다 싶으면 배경 쪽으로 넘기거나 직접 살을 붙이기도 한다.

한국에선 레벨 디자이너라 하면 위 기획자나 그 팀에서 이걸 하는 사람들을 떠올리며 그 외의 부분들은 배경 그래픽 쪽으로 따로 나누는 경향이 있으나 해외의 전문화된 팀에선 기획이나 배경(그래픽)으로 가르지 않고 레벨이라는 하나의 독립된 직군으로 다루기도 한다.

3.3. 배경 디자이너

환경 아티스트 등으로도 불리우며, 주로 맵에 쓰이는 사물 모델(오브젝트)(상자나 차량, 배관 등등) 및 텍스처를 전문적으로 제작하는(이 경우 텍스쳐러라고도 부름) 디자이너다. 이것도 본디 레벨 디자이너의 일이지만, 팀이 분업화된 곳에선 이러한 별개의 직업으로 분화되고 또한 이것도 배경 전문 텍스처러와 모델러 등으로 나뉜다.

3.3.1. 텍스처 디자이너

텍스쳐러 항목 참조.

3.3.2. 배경 오브젝트(프롭) 디자이너


배경 모델러라고도 부르며, 모델러프롭 항목 참조.

3.3.3. 조명 디자이너


맵의 조명을 전문적으로 다루는 이들. 배경과 마찬가지로 하프라이프 당시만 해도 조명을 잘 잡는 레벨 디자이너가 이걸 했지만, 배경과 마찬가지로 조명 역시 전문화가 필요해 별개의 직업으로 분류됐다. 다만 소규모 팀이나 한국에선 아직까지 이 직업의 개념이나 중요성이 낮아 보기 힘들다.

3.4. 스크립트 디자이너

스크립터 등으로도 부르며, 공간이나 배경과 별도로 특정 조건 만족시 맵에서 발생되는 각종 효과나 이벤트(대개 Lua같은 프로그래밍 언어, 스타나 하프라이프, UDK의 경우처럼 별도의 스크립트 체계에 따라 짠다)와 관련된 스크립트(트리거도 이 범주에 포함)를 담당한다. 하지만 그 특성상 코더나 그런 기술을 갖고 있는 디자이너가 이 일을 자주 겸업하기에 이 직종은 어지간한 경우가 아닌 한 보기 힘들다. 어찌 보면 한직 같지만 복잡한 스크립트를 전문적으로 자주 짜거나 다룰 일이 생기면 필요하다.

4. 레벨 일을 병행하는 다른 직군들

게임에서 레벨 디자인의 비중이 적거나 여건이 안돼 디자이너를 채용하기 어려운 경우, 아래와 같은 이들이 레벨 일을 병행하기도 한다.

4.1. 게임 기획자가 맡는 경우

위에서 상술했듯, 특히 한국이나 소규모 팀에, 기획의 일부로 보는 쪽에서 자주 행하며, 본인이 직접 프로토타입을 만들고 테스트하지 않아도 대략적인 맵의 성격이나 수치 등이 기재된 문서를 배경 디자이너 등에게 전달만 해줘도 레벨 디자이너(정확히는 레벨 기획)로 쳐주는 곳도 있는 듯 하다.

4.1.1. 퀘스트, 콘텐츠 디자이너

말 그대로 퀘스트콘텐츠 즉, 레벨을 포괄한 이벤트 등등을 기획&디자인하는 이들이다. 큰 팀의 경우 분업화로 별도의 레벨 팀이 있어 레벨보다는 문서 작업할 일이 많아 연관이 없을 수 있지만 작은 팀일수록 이들이 레벨 일도 겸하는 경우도 흔하다.

4.1.2. 시스템 디자이너, 밸런서 (밸런스 디자이너)

대개 플레이어나 몹의 체력과 공격 기술, 게임 내 경제나 보상 등을 수치화해 계산 및 조정하는 이들이지만, 디펜스류나 RPG 등에선 스테이지나 던전을 등급별로 정한 다음 상대할 몬스터 능력치와 그걸 때려 잡아 얻어지는 경험치아이템 등이 진행에 중요한 만큼 이들 또한 레벨 디자이너와 동격이 되기도 한다. 물론 RPG 개발사 전부가 이렇지는 않고 공간이나 연출 디자이너 등을 따로 두기도 한다.

4.1.3. 시나리오 라이터

드물지만 자신의 시나리오와 그것이 반영된 맵 제작을 관리, 보조하거나 겸업하는 식으로 있긴 있는 모양.

4.2. 그래픽 디자이너가 맡는 경우

배경 원화나 모델러(=배경 디자이너) 쪽에서 겸업하는 경우가 많다. 물론 아트 없는 레벨은 화장 안 한 쌩얼과도 같아 나름 필연적이라고도 볼 수 있고 물론 아트보다 구조나 재미면으로 승부보는 레벨도 드물지만 존재한다. 금삐까적 아름다움을 추구하는 종특(?)상 고유의 재미나 밸런스적인 측면을 다듬는데 소흘해질 수 있다.

4.3. 프로그래머가 맡는 경우


주로 소규모에 레벨의 비중도 적고, 그 레벨조차 별도의 에디터를 제작하고 만지작 거리는 것보다 코드 몇줄 짜는게 나은 팀들에게서 심심찮게 찾아 볼 수 있다. 또한 A.I나 그래픽적 효과 담당일 경우 자신의 결과물이 원하는 수준에 도달했는지 등을 파악하기 위해 디자이너와 협업하거나 직접 테스트 맵을 만들어 테스트 하기도 한다.

5. 레벨(맵)을 만드는 기준

게임마다 제각각 특색이 있고 내세울게 다른 것처럼, 이것도 공통적으로 어느 장르에 딱 집어서 어디에 어딜 둬라...식의 기준이나 규정은 없다. 물론 같은 장르에 한해 선구자들이 작성/발표한 자료나 게임을 하고나서의 경험을 좋은 참고 자료로 활용할 수 있기는 하다. '''다만, 확실한건 플레이어가 좋은 경험을 하도록 만드는 것이다. 말 그대로 시각 심리적으로 디자인을 잘 해야 하고, 반대로 버그(예를들어 스크립트 에러나 틈 사이에 끼어 진행이 안됨)로 인해 진행이 막히는것뿐만 아니라 난이도가 의도치 않게 사람이 할 수준이 아니게 될 때가 있다. 이런 이유로 레벨 제작 도중이나 완성 이후에 사전 플레이테스트도 필수다.

동시에 게임의 성격 또한 잘 드러나도록 해야 한다. 예를 들어 같은 싱글 FPS라도 시리어스 샘하프 라이프는 전혀 다른 레벨의 법칙을 가지고 있다. 전자의 경우 레벨이 초 단순 알기쉬운(?) 직사각형 통로나 광활하게 펼쳐진 평야에서 최대 중대 규모의 적들과 한바탕 피바람을 일으키며 싸우기 적합하도록 해놓은데 반해, 후자의 경우 처음부터 끝까지 1인칭으로 이어지는 게임의 흐름이나 이야기를 전달하는 주요 수단으로 택했다. 소닉 더 헤지호그 시리즈의 스테이지 개념인 Zone은 초창기엔 플레이어 캐릭터의 무지막지하게 빠른 스피드를 고려하지 않고 (혹은 간과하고) 디자인된 결과 심하면 1분 이내로 존 하나가 돌파되는 사태가 벌어지자 정식 버전 후속작인 소닉 더 헤지혹 3에서부턴 여타 게임보다도 크고 아름다운''' 맵 분량을 자랑한다.

그밖에도 장르별로 혼자서 하는 싱글플레이어 게임, 여러명이 협동해 한 레벨을 클리어하는 코옵(Co-op), 여러 명이 한 맵에서 격돌하는 리그나 데스매치같은 경우에도 거기에 맞는 법칙을 가지고 있어야 한다. 참고로 여러 명이 한 맵에서 격돌하는 리그의 경우 축구 경기장처럼 양쪽이 균등하게 제작된 맵은 데칼코마니처럼 한쪽만 만들고 Ctrl CV나 약간 노가다만 뛰면(?) 더이상 상호 밸런스 조절할거 없이 끝이니, 동등한 조건에서 두 팀이 경기를 하는 용도와 제작비 절감(...) 용도로 자주 쓰인다.

이 분야의 선구자 중 하나인 밸브의 경우, #처럼 '양보다 질'의 법칙을 내새우며 양판소같이 똑같은 전개, 비슷비슷한 구성이나 구조의 40개보단 잘 짜여진 10개가 더 눈에 잘 들어옴을 강조하기도 했다. 무기의 경우를 예로 들었지만 사실 맵에도 적용되는 사실이다. 인간의 경우에도 비슷비슷한 부류보다 튀어나온 못처럼 튀는 개성의 부류가 더 잘 띄니.

본격적으로 이쪽의 실력을 갈고 닦겠다면 모작 뿐만 아니라 선대 디자이너들이 후세(?)를 위해 작성한 제작 과정 문서나 코멘터리들을 찾아 참고하는것도 좋은 방법이다. 주의할게 여기에서 자기만의 색을 첨가하거나 세부적으로 파고들지 않고 그저 겉보기로 그럴듯하게 따라만 하다보면 특색없는 판박이가 될 뿐더러, 이를 자기 것으로 우기거나 영리적 목적으로 쓰면 표절 시비로까지 이어진다

무조건 거기에 적힌대로만 따라하기보단 거기에서 자기에게 맞는걸 찾아내야한다. 앞선 작품의 대다수는 해당 게임이나 개발자의 성격(제작 방식) 등에 맞춰 레벨 디자인이 그런 식으로 제작되었음을 전제로 서술되어 있으므로, 그 말대로만 따르다 보면 (고유의 특정 법칙을 가질수록) 게임 성격을 제대로 못 살리고, 나온다 하더라도 클리셰처럼 고만고만한게 나오기 쉽다. 그러므로 모든 게임에게 적용되어야 하는 절대적 법칙이 아닌 참고 수준에서 그쳐야 한다

백문이 불여일견이라고, 시행착오도 두려워 않고 이것저것 시도해야한다. 그러면서 작품을 즐긴 유저(테스터, 고객)들의 의견, 개중에는 맵 분위기나 컨셉을 트집삼은 비평가들의 비평일지라도 귀 기울이며 이를 피드백으로 활용, 차기 버전에 반영하며 디자인적 공감대를 늘리는 것도 중요하다. 컨셉이나 전개 자체가 개발자나 지인들이 보기엔 그다지 문제가 없어 보이더라도 당사자가 보기엔 적응이나 납득 자체가 어려워 혹평을 듣는 경우가 많다. 특히 각기 다른 문화와 가치관에 솔까말 경향도 강한 Moddb 등지에서 심상찮게 찾아볼 수 있는데 비평들을 읽다보면 스스로가 길치라 수없이 헤메던 와중에 때려쳤거나 릴리즈 일자, 장르, 플레이 타임같이 사소한 문제를 트집잡아 10점 만점 1점을 줘버리는 유저들도 간혹 있지만 상당수가 공통적인 문제를 제기한다면 이것은 거의 유저가 아니라 맵 고유의 문제라 봐야 한다. 여튼 이러한 비평을 허용하거나 흘러넘기지 않고 욱하는 성질을 못이겨 유저를 상대로 "애당초 그딴 비평을 왜 함? 님이 잘못했음!" 식의 대응을 해주는 것도 무난하나, 도를 넘으면 본인이 오히려 어그로를 끄는데다 중립 성향의 유저들에게도 트러블 메이커로도 비춰지게 만드니 어지간한 경우가 아니라면 괜히 긁어 부스럼 만들지 말고 침묵으로 일관하자.

6. 레벨(맵) 제작방식

통상적으로 아래와 같이 제작되나, 제작사&개발자 혹은 게임 성향에 따라 다소 차이가 있다.


1. 대략적인 레벨의 구조와 디자인&용도면에서 어떤 구조물임을 (예를 들면 창고, 연구소, 감옥 등등. 경우에 따라 사진 등이 그림에 첨부되기도 한다.) 설명&구체화하는 그림 제작. (이미 구체적으로 이미지화 되어 있다면 생략 가능)

2. 부분별로 따로 제작해 나중에 하나로 합치거나(기획이나 테스트를 하며 불가피하게 수정이 잦을때 쓰임) 그림 단계에서 구조까지 한번에 싹 해놓고 제작한다. 카운터 스트라이크 같은 하나의 맵으로 이뤄진 경우에서 종종 쓰인다. 이때 가장 기본적인 것들을 시험하기 위한 프로토타입 레벨이 제작되고 더미맵이라 칭하기도 한다. 프로토타입 답게(?) 디자인이나 플레이 자체가 전체적으로 어중간하며, 프로토타입 레벨은 통상적으로 아래와 같이 제작된다.

대체적인 핵심 구조나 분위기 등이 표현된 그림을 그려 대략적인 이미지를 사전에 정하기도 한다. 게임원화가 등에게 맡기기도 하고 레벨 디자이너가 그림 실력이 된다면 직접 그리기도 한다. 유의할 것은 분위기 등이 잘 담겨있거나 디자이너가 이미 작업할 레벨의 이미지를 잡은 상태라면 이러한 그림을 꼼꼼하게 그리지 않아도 무관하다.

아니면 일단 구조부터 만들고 텍스쳐를 입힐 즈음 이러한 세부 컨셉(구상이나 기획)을 잡는 경우도 있다. 사실 이 순서 때문에 레벨계에선 닭이 먼저냐 달걀이 먼저냐 수준으로 심심찮게 논의되지만 # 확실한 건 대부분 한쪽이 영감에 의해 추진 > 다른 쪽이 이를 보강하는 식으로 흘러간다.

일단 기초적인 구조를 완성. 경우에 따라 기초 플레이 테스트나 텍스쳐 입히는 작업을 병행하기도 함.

그 다음 각종 사물이나 NPC, 조명 등을 넣고 어느정도 플레이가 가능하게 완성.

영상은 유출된 하프라이프2 프로토타입 부분을 담은 MOD인 미싱 인포메이션이다.

3. 이후 수십, 수백번이 넘는 본격적인 플레이 테스트를 거쳐 미쳐 발견하지 못한 불필요한 사물, 버그등을 이 과정에서 쳐내 게임 진행이 용이하게 바꾼다. 이 결과에 따라 작게는 모델이나 텍스쳐 한두개, 많게는 쳅터 하나 이상 분량까지 갈려나가지만, 몇몇 개발자는 제작 시간 절감 차원에서 이 과정을 3번으로 끝냈음을 자랑스례(?) 밝히기도 했다. 그러니 플레이어들이 주변 사물들을 밟고 맵 밖으로 뛰쳐나가지

4. 정식 버전에 포함시켜 최종 릴리즈. 가끔 레벨이 크든 작든 한쪽에게 편중되어 변경의 필요성을 느끼면 다음 버전에서 패치시키기도 하지만, 귀찮아서 해당 문제를 방치하는 제작사도 있다.

7. 레벨 디자이너로 취직하기 위해선?

별거 없다. 아래 언급된 툴들을 마스터 해 적당한 기술을 갖춰 공채시 응시하거나, 게임 제작 동호회, 현업인들이 많은 레벨 디자인 카폐나 게기모, 디씨나 루리웹의 관련 게시판 등등 유명 커뮤니티서 잉여력 넘치는 자신의 작업물이나 제작 과정을 꾸준히 보여줌으로서 쓸만하다 판단되면 가끔 느닷없이 팀장이나 부사장 급에서 채용 제의가 들어오기도 한다.

사실 레벨 디자이너 직종 자체가 기획과 밀접한 데다 적어도 한국에선 해당 분야를 전문적으로 취급하는 이들이 아직 적다 때문에 몇몇 회사는 다른 파트서 자의 반 타의 반으로 전직하게 된다. 때문에 어찌보면 가장 만만한 블루 오션으로 비춰질 수 있겠지만, 회사마다 쓰는 엔진/툴이나 레벨 디자이너의 업무도 제각각이라 어려움이 있다. 배경 모델링과 구조 설계, 스크립트 담당을 나눈 곳도 있고, (팀이나 해당 파트의 비중이 작아) 이를 하나로 묶어버린 곳도 있다. 예컨대 3ds max스케치업, MS 엑셀, 유니티3D, Lua,[1] UDK크라이엔진, (희박하지만) 소스 엔진 등을 쓰는 여러 회사를 전전할때, 만약 이것들중 하나를 모른다면 해당 툴을 상당기간 마스터 해야 하는 안습함도 있다.

게다가 요즘은 불황인 업계에서 경영 악화로 방출된 구직자들을 고려한 듯 신입보다는 현업에서 나름 경험을 쌓은 경력자 위주로 채용하고 신입을 뽑는 곳도 몇몇 있지만 그곳은 대부분 단기 인턴 같은 비정규직이며, 설령 정직원을 뽑는들 위 기술들을 포함해 이것저것 따지기에 스펙이 높지 않는 한 기대 않는게 좋다. 여기에 게임학과를 갓 졸업한 구직자들도 설상가상으로 계속 유입돼 취업문은 갈수록 좁아지고 있다.

8. 관련 항목

  • 게임 난이도
  • 게임 제작자
  • 소스 엔진
  • 스케치업
  • 스타크래프트/맵
  • 유니티3D
  • 유즈맵
  • 크라이엔진
  • 콘텐츠 부족
  • 해머(하프 라이프)
  • 3ds max - 기능상으론 맵 만드는 것과 거리가 있어 보이지만, 배경용으로 쓸 모델 제작이나 자체적인 맵 제작 툴이 전무한 회사의 경우, 이걸 대용품으로 쓴다.
  • AVGN - 전혀 관련없을것 같지만 다소 어이없는 인과관계, 거지같은 조작, 그리고 사람 대놓고 엿먹이는 레벨 디자인을 문제작에서 꼬집어 신규 레벨 제작시 시행착오를 줄이기 위한 좋은 참고 자료가 되기도 한다.
  • MS 엑셀 - 비록 이걸 쓸 줄 몰라도 맵 만드는데 전혀 지장없지만, 레벨 팀이 기획 직속이거나 높으신 분에게 자신이나 속한 팀의 현황을 엑셀로 보고해야 하는 입장이라면 불가항력적으로 마스터 해야 하는 프로그램이다. 하지만 문서 작업이나 보고에 학을 뗐거나 엑셀 사용에 귀찮음을 토로하는 이들은 진짜 급하지 않는 한 자격요건에 '엑셀 숙련자'가 있다면 거길 2, 3순위로 미루기도 한다.
  • UDK

10. 관련 커뮤니티 사이트/카페

11. 관련 SNS (추가바람)

12. 관련 문서

----
  • [1] 그 프로그래밍 언어 맞다. C언어도 그렇고 필수는 아니나 채용시 가산점에 포함되는 업체들이 있지만 코더 출신 사장 선에서 필수로 못박은 곳도 있다 한다.
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2015-02-21 00:18:10
Processing time 0.2376 sec