Dev.Mag - 11 Tips for making a fun platformer (링크)
플랫포머는 공중에 떠 있는 플랫폼들을 포함하는 레벨을 캐릭터가 달리고 점프하면서 돌아다니는 류의 게임이다.
이 글은 플랫포머 게임에 집중하고 있지만, 각각의 아이디어에 있는 배후의 철학은 2D나 3D의 어떤 다른 게임에도 적용될 수 있다.
이 리스트는 제품(재미있는 게임)뿐만 아니라 개발 프로세스를 위한 팁을 포함한다.
1. 유저 인터페이스(UI, user interface)를 단순하게 유지하라.
플레이어는 점프를 하기 위해 점프 버튼을 누른다.
이것이 바로 단순한 유저 인터페이스이다.
플레이어의 과제는 게임을 완료하기 위해 정확한 타이밍에 점프 버튼을 누르는 것이다.
즉, 플레이어의 과제는 인터페이스를 사용하는 것이 아니라, '정확한 타이밍에' 인터페이스를 사용하는 것이다.
가장 투명(명백, transparent)하고 직관적인 인터페이스일수록 좋다.
만약 도로의 운전사들이 그들의 차량을 돌리는 방법에 집중해야 한다면, 더 많은 사고가 일어날 것이다.
단순한 인터페이스는 게임의 메뉴나 다른 모든 상호작용 영역에 적용된다.
메뉴 항목들을 탐색하거나 항목을 선택하는 것은 쉬워야 한다.
2. 중요한 정보는 보이기 쉽게 만들어라.
플레이어가 게임의 중요한 것들을 보기에 쉽게 만들어라.
플레이어가 그 위로 걸을 수 있는 플랫폼들은 배경보다 눈에 띄어야 한다.
수집 가능한 아이템들은 인지하기에 쉬워야 한다.
HUD를 한 번 슬쩍 보는(glance) 것만으로도 필요한 모든 정보를 얻을 수 있어야 한다.
쉽게 읽을 수 있는 폰트는 필수적이다.
플레이어는 메뉴에서 무슨 일이 일어나고 있는지 알아야 한다.
3. 충돌 경계를 주의하라.
플레이어에게 우호적인(friendly) 오브젝트의 충돌 경계(collision boundary, 충돌 영역)는 오브젝트보다 커야 한다.
해로운(harmful) 오브젝트의 충돌 경계는 오브젝트보다 작아야 한다.
- 충돌 경계(collision boundary)의 다른 말들
collision rectangle, collision bounding box, collision sphere, collision region, collision polygons 등 - 플레이어의 충돌 경계가 다른 오브젝트의 충돌 경계와 겹쳤을 때 플레이어는 오브젝트와 충돌한다.
우호적인 오브젝트에는 파워업(power-ups), 사다리, 그리고 로프 등이 있다.
해로운 오브젝트에는 적, 적의 투사체, 그리고 회전하는 칼날(함정) 등이 있다.
큰 충돌 경계는 상호작용하기에 쉽게 만들거나, 우호적인 오브젝트를 수집하기에 쉽게 만든다.
작은 충돌 경계는 해로운 오브젝트를 피하기 쉽게 만든다.
4. 간격을 쉽게 뛰어넘을 수 있게 만들어라.
전통적으로, 그리고 현실적으로 게임에서 플레이어는 어떤 것 위에 서 있을 때에만 점프를 시작할 수 있다.
플레이어가 플랫폼의 끄트머리에서 막 발을 디뎌 허공에 있을 때 점프를 시작할 수 있게 만들어라.
플레이어가 점프를 시작할 수 있는 1초 가량의 자유를 주어라.
(이 1초 후에 플레이어는 더 이상 점프를 할 수 없고, 아래로 떨어지게 된다.)
이것은 한 플랫폼에서 다른 플랫폼으로 점프하는 것을 조금 더 쉽게 만들어준다.
5. 언제, 어디서나 애니메이션 상태를 바꿀 수 있게 만들어라.
캐릭터의 애니메이션은 플레이어의 움직임을 따라가야만 한다.
즉, 플레이어의 움직임은 애니메이션에 의해 제약되어서는 안 된다.
이상적으로, 어떤 애니메이션은 언제나 다른 애니메이션으로부터 시작될 수 있어야 한다.
플레이어는 달리고, 점프하고, 허공에서 사다리를 붙잡고, 기어오르고, 총을 쏘고, 사다리에서 뛰어내리고 싶어 한다.
애니메이션은 플레이어가 그렇게 할 수 있게 해야 한다.
또한, 플레이어는 다시 움직이기 전에 캐릭터의 애니메이션이 끝나길 기다려서는 안 된다.
애니메이션이 재생되고 있을 때 플레이어의 인풋을 제한하지 말라.
이는 플레이어가 다시 움직일 수 있게 되기 전에 애니메이션이 끝날 때까지 기다리게 만든다.
6. 충분한 파워업과 수집 가능한 아이템을 제공하라.
많은 아이들이 순수하게 재미있다는 이유로 물건을 모은다.
컴퓨터 게임에서도 무엇을 수집할 때, 비슷한 기쁨의 감정이 발생한다.
수집 가능한 것들을 게임에 넣어라. 많을 수록 좋다.
여기에 다른 논리적인 이유는 없다. 그저 재미있기 때문이다.
7. 포괄적(generic)이지만 다용도(versatile)의 AI를 작성하라.
각각 적은 수의 변수를 포함하고 있는 적은 수의 AI 동작체(agent)를 디자인하고 만들어라.
변수들에는 매우 다양한 AI 동작체를 만들 수 있는 다른 값들이 부여된다.
베이스 AI의 사례들
Walking AI (걸어다니는 AI)
수평의 평면 위를 걸어다닌다.
| Variables (변수) | |||
| Health (체력) | Speed (속도) | Jump Height (점프 높이) | Attack style (전투 방식) |
| 1 = Easy (쉬움) 3 = Medium (보통) 5 = Difficult (어려움) |
0 = Static (정적, 한 장소에 머무름) 1 = Slow (느림) 2 = Medium (보통) 3 = Fast (빠름) 5 = Super Fast (매우 빠름) 10 = Slow, but fast when the player is nearby (느리지만 플레이어가 가까이에 있을 때 빠름) |
0 = Cannot jump (점프 불가능) 1 = Low (낮게) 2 = Medium (보통) 3 = Hight (높게) 10 = High when the player is directly above (플레이어가 바로 위에 있을 때 높게) |
0 = None (전투 불가능, 그저 돌아다님) 1 = Near range melee (근거리) 2 = Medium range melee (중거리) 3 = Shoot projectiles (투사체 발사) |
사례: 기사, 궁수, 불의 정령(elemental), 거대한 파리지옥, 엘프
Flying AI (날아다니는 AI)
하늘을 날아다닌다.
| Variables (변수) | |||
| Health (체력) | Speed (속도) | Fly diagonal (사선 비행) | Attack style (전투 방식) |
| 1 = Easy (쉬움) 3 = Medium (보통) 5 = Difficult (어려움) |
1 = Slow (느림) 2 = Medium (보통) 3 = Fast (빠름) 5 = Super Fast (매우 빠름) 10 = Slow, but fast when the player is nearby (느리지만 플레이어가 가까이에 있을 때 빠름) |
0 = Cannot fly diagonally (사선 비행 불가능) 1 = Can fly diagonally (사선 비행 가능) |
0 = None (전투 불가능, 그저 돌아다님) 1 = Near range melee (근거리) 2 = Medium range melee (중거리) 3 = Shoot projectiles (투사체 발사) |
사례: 매, 그리핀, 유령, 공기의 정령(elemental), 자이로콥터(gyrocopter)를 탄 드워프
Crawling AI (기어다니는 AI)
어떤 표면이든지 걸어다닌다. : 수평, 수직, 사선 및 거꾸로
| Variables (변수) | |||
| Health (체력) | Speed (속도) | Drop down (떨어지다) | Attack style (전투 방식) |
| 1 = Easy (쉬움) 3 = Medium (보통) 5 = Difficult (어려움) |
1 = Slow (느림) 2 = Medium (보통) 3 = Fast (빠름) 5 = Super Fast (매우 빠름) 10 = Slow, but fast when the player is nearby (느리지만 플레이어가 가까이에 있을 때 빠름) |
0 = Cannot drop from the ceiling (천장에서 떨어질 수 없음) 1 = Drop from the ceiling randomly (천장에서 무작위로 떨어짐) 2 = Drop from the ceiling when the play is beneath (플레이어가 아래에 있을 때 천장에서 떨어짐) |
0 = None (전투 불가능, 그저 돌아다님) 1 = Near range melee (근거리) 2 = Medium range melee (중거리) 3 = Shoot projectiles (투사체 발사) |
사례: 거대한 거미, 벌레(worm), 킬러 달팽이, 슬라임
8. 스토리와 분위기를 염두에 두라.
게임의 스토리를 개발 초기에 정의하라.
스토리는 게임의 전반적인 분위기, 아트 스타일, 그리고 목표의 가이드라인이 된다.
스토리는 복잡하거나 글 한 줄일 수도 있다.
스토리를 플레이어에게 컷 신 형태나 대화로 보여줄 수도 있고, 혹은 게임을 제작하고 있는 모두가 게임의 스토리가 무엇인지 알고 있는 한 그냥 플레이어에게 보여주지 않을 수도 있다.
예시 스토리: 고독한 해병이 달 기지에서 좀비 무리와 악마에 맞서 싸운다.
이 스토리로부터 우리는 게임이 무엇에 관한 것인지에 대해 알 수 있다.
- 고독한: 싱글 플레이어, 한 명의 캐릭터
- 해병: 전사(fighter), 군인, 군대, 건장한(tough-as-nails), 총, 투척물
- 싸운다: 액션, 전투
- 무리: 많은 적, 수그러들지 않는(relentless)
- 좀비: 고어(gore, 피), 총에 맞아 죽은 사람(gun fodder)
- 악마: 초자연적, 어둠
- 달기지: 공상과학, 미래적인, 외딴(remote)
9. 범위와 시간을 명확하게 정의하라.
게임을 완성하기 위해 필요한 모든 것의 리스트를 만들어라.
그리고 리스트의 각 아이템을 시행할 때 얼마나 걸릴 지 추산하라.
이렇게 추산한 시간의 양은 게임을 완성하기 위해 필요한 최소한의 시간이다.
만약 게임의 기획 문서가 50페이지 분량이라면, 그리고 각 페이지의 피쳐를 시행하는 데에 평균적으로 2일이 걸린다면,
게임을 만드는 데에 최소 100일이 걸린다는 뜻이다.
최초의 디자인 문서가 결국 게임에 있게 될 모든 것을 포함하지 않는 게 당연하다.
개발 과정에서 더 많은 페이지들이 추가될 것이다.
아티스트가 캐릭터를 만들고 애니메이팅하는 데에 2주가 걸린다면, 10명의 캐릭터를 만드는 데에 20주가 걸릴 것이다.
이는 5달, 거의 반 년이다.
만약 아티스트가 두 명이라면, 캐릭터를 완성하는 데에 필요한 시간이 반으로 줄어들 것이다.
하지만 실제 작업은 20주가 걸릴 것으로, 당신은 20주 분의 급여를 지급해야 한다.
개발 과정에서 게임에 추가할 새로운 피쳐들을 생각하는 것은 매우 쉽다.
하지만 매번 새로운 피쳐를 추가할 때마다, 출시일은 멀어진다.
기반이 되는 게임에 피쳐를 계속해서 추가한다면 당신의 게임은 절대 완성되지 않을 것이다.
새로운 피쳐를 추가할 때, 데드라인을 지키기 위해 다른 것을 뺄 준비를 하라.
최초의 피쳐 리스트를 우선으로 해서, 시간이 없을 경우(혹은 때) 덜 중요한 것은 뺄 수 있도록 하라.
아주 한정된 수의 피쳐만 가지고 있는 게임을 만드는 것을 부끄러워 하지 말라.
당신을 비웃는 사람들은 아마도 완성에 15년이나 걸릴 MMO를 작업하고 있을 것이다.
기억하라, 세상에서 가장 보람 있는(rewarding) 느낌 중 하나는 '프로젝트를 완성하는' 것이다.
10. 이론적인 재미를 완성하기 전에 프로토타입을 제작하라.
컴퓨터 게임을 위한 수천개의 좋은 아이디어가 있지만, 그들 모두가 재미있는 것은 아니다.
무엇이 재미있는지 찾는 가장 좋은 방법은, 게임을 프로토타이핑하는 것이다.
프로토타입은 당신이 아이디어를 테스트하는 것을 도울 빠르게 만들고 빠르게 수정할 수 있는 버전이다.
왜 프로토타입인가?
장기적으로 이는 시간을 단축해준다.
게임이 재미있지 않아서 기획을 변경하는 바람에 아트를 다시 만들거나 시스템을 다시 제작해본 적 있는가?
시간을 절약하기 위해, 이미 존재하는 게임 엔진을 사용하고 인터넷에서 프로토타입을 만들기 위한 무료 리소스들을 다운받아라.
프로토타입은 최종 게임을 제작하기 위해 사용될 엔진과 같은 것으로 작업될 수도 있고, 몇몇 코드들은 재사용될 수도 있다.
프로토타입은 최종 게임이 완전히 개발되면 폐기될 완전히 별개의 프로그램(혹은 프로그램들)일 수도 있다.
이런 이유로, 프로토타이핑을 좋아하지 않는 사람들도 있다.
그들은 최종 프로토타입 '프로덕트(product)'가 폐기되기 때문에 시간과 자원의 낭비라고 믿는다.
프로토타이핑을 개발의 또 다른 아이디어 단계라고 생각해보라.
이 단계에서 당신은 재미있어질 때까지 아이디어를 시험하고, 바꾸고, 교체하고, 비튼다.
이 프로토타입 '프로덕트'는 그러므로, 아이디어를 시험하기 위해 사용된 도구이다.
기억하라: 프로토타이핑은 당신의 해야할 일에 포함되어 있어야 한다. 그러므로, 당신의 일정(schedule)의 일부여야 한다.
11. 기획에 팀의 전원을 참여시켜라.
아티스트가 캐릭터를 기획하는 과정에 참여하거나 직접 떠올린 아이디어로 캐릭터를 작업하면 더 나을까?
프로그래머가 시스템을 기획하는 과정에 참여했던 시스템을 코딩한다면 더 나을까?
답은 '그렇다'이다. 이는 게임을 위해서도 더 좋을 것이다.
게임은 창의적인 공동 작업이다.
만약 한 명이나 두 명이 게임을 기획한다면, 창의성에 제약이 있을 것이다.
사람들은 일반적으로 기획 과정에 포함되었을 때 더 기뻐하고 프로젝트에 더 헌신한다.
그러므로, 모든 사람이 기획 과정에 참여하도록 장려하라.
그리고 이는 항상 형식적인 절차가 될 필요는 없다.
즉, 항상 모두가 참여하는 회의를 잡을 필요는 없다는 것이다.
사람들은 이메일을 보내거나, 주방에서 이야기를 나누거나, 방을 가로질러 소리칠 수도 있다.
'기획 > 게임디자인' 카테고리의 다른 글
| [게임기획/번역] 플랫포머 게임을 위한 레벨을 기획하는 방법 (0) | 2022.11.15 |
|---|---|
| [게임기획/번역] 재미있는 플랫포머 게임을 만들기 위한 13가지 추가 팁 (1) | 2022.11.14 |
| [게임기획] 크리스토퍼 보글러 - 영웅의 여정 12단계 (0) | 2022.11.10 |
| [게임기획] 칙센트미하이 - 몰입(Flow) 이론 (0) | 2022.11.09 |
| [게임기획] 로제 카이와 - 놀이의 4가지 범주 (0) | 2022.11.08 |
