SelectingRightFeatures

원문: http://www.gamasutra.com/features/20010926/luban_01.htm

올바른 시기에서의 올바른 판단 : 새 게임 프로젝트를 위한 적절한 기능 선택

개요

Many of us can certainly relate to the situation when the studio is almost done with a new game and it's time to think about the next project. The company management assembles a small team of contributors including programmers, artists, designers, a project manager, and of course the studio executives. A brainstorming session is called together to outline the key features of the upcoming project. Everyone, eager to share ideas at once, eventually turns the meeting into anarchy. This scenario usually happens because everyone has their own agenda and individual priorities. A game designer will fancy an innovative game mechanism, a programmer will push for some technological breakthrough, while managers will look for concepts that can sell to publishers or fit the studio's budget.

많은 이들이 한 게임프로젝트가 거의 끝나갈 무렵 다음 프로젝트에 대해 고려해야 될 때가 오게된다. 회사관리자는 프로그래머, 아티스트, 디자이너, 프로젝트 관리자 그리고 물론 회사 관리자를 포함한 핵심 인원을 집합시킬것이다. 상호 차기 프로젝트의 핵심 골자에 대한 아이디어를 서로 이야기할 것이다. 모두들 자기 생각을 한꺼번에 토해내는데 열중할 것이며 회의는 끝내 수렁속으로 빠져들것이다. 모두들 나름대로의 의제와 자신감이 있기 때문에 이런 시나리오가 (불운하게도) 일반적으로 벌어지곤한다. 게임 기획자는 혁신적인 게임 구조를 공상하며 프로그래머는 기술적으로 눈부신 시도를 하고자 할 것이며 그러는 동안 매니저들은 경영 대차대조표에 들어 맞거나 좀더 잘 팔 수 있는 컨셉을 찾으려 할 것이다.

Then, everyone has their own pet projects, that one game which is close to their heart that they would just love to develop. Amidst all the enthusiasm, management soon finds it very difficult to take a number of contrasting suggestions and turn them into valid and ideas. An alternative way to work out a project is to limit the number of contributors. A group of two to three people from among company management will focus on a small number of personal ideas, or will concentrate on key imperatives for the studio.

그렇다면, 모두가 그들 나름대로 가장 개발하고 싶은, 비장한 프로젝트를 개발해야되는 것인가? 이런 분투속에서 관리자들은 여러 개의 대비되는 제의를 수락하고 거절할 것인지 결정하는 일이 매우 어려운 것이라는 것을 알게 될 것이다. 회사 관리인들 중 2에서 3에 속하는 무리들은 소수의 견해에 초점을 맞추거나 권력을 이용한 난국타개를 시도할 것이다.

Indeed, this approach will make it easier to define a project, but will the result be any better? Decision makers, whether in a brainstorming session or in a limited committee, face the same problem: too many parameters that must be merged into a single concept. Furthermore, this kind of decision-making process is not truly motivating to the rank-and-file employees, who are forced to go with a project without being consulted.

사실 이런 접근방식은 새로운 프로젝트를 좀더 쉽게 정의할 수 있지만 결과물이 최선의 것이라 장담할 수 없다. 결정권자는 열린 브레인 스토밍 방식을 취하든 폐쇄된 이사회방식을 취하든 같은 문제를 직면하게 된다. : 너무 많은 변수들을 단일한 컨셉으로 묶어야한다는 것! 더욱이 이런 종류의 과정을 실무자(졸병)들과 일체의 협의 없이 결정한다는 것은 그들의 작업동기를 유발하기 어렵다.

The method presented in this article is designed to foster creativity and build a consensus. It is by no means a magical formula or turn-key concept, but rather a decision making aid, used to identify better choices. It helps select the best project ideas regardless of the number of parameters involved. This method also makes it easy to establish a consensus around a project, and more importantly, produce equally good results for large as well as small teams.

이 글은 창의력을 촉진하고 의견일치를 유도하기위한 방식을 기술하고자 한다. 그것은 모든지 해결할 수 있는 마법 공식이나 당장 사용할 수 있는 완성품 형태의 개념이 아닌 좀더 의사 결정에 도움이되며 좀더 나은 선택을 내릴 수 있을 것이라 확인된 형태의 것들이다. 수많은 변수를 가지고 있다 하더라도 최선의 결정을 내릴 수 있는데 좀더 도움이 될 수 있을 것이다. 그리고 좀더 중요한 것은 회사의 규모가 크든 작든지 간에 좀더 좋은 결과를 산출할 수 있다는 것이다.

첫 단계: 목표의 정의와 조직화

한계의 설정

The method discussed in this article could be used by a workgroup that looking to develop a new project from scratch. However, in most cases studio managers often have a few imperatives already in mind. For the sake of our example, we will assume the management has determined to build a racing game for the new generation of consoles (XBox, PS2 or Game Cube).

이 글에서 논의될 방식은 새로운 프로젝트를 처음부터 시작하는 작업그룹에서 사용할 수 있다. 그러나 대부분의 관리인들은 종종 머리속에 이미 명령할 것들을 가지고 있기도 하다. 이러한 일례로 우리는 매니저가 Xbox나 PS2, 게임큐브와 같은 레이싱 콘솔게임을 만들기로 결정하였다고 가정하자.

작업그룹

Before going ahead with this article, a few words should be said about the people who make up the team. They must be members of the studio. They should come from a different setting such as computer graphics, programming, etc. The main criterion is that they have a good knowledge of the gaming world. It is equally important to have several people with a manager's vision such as a development director or studio manager.

시작하기 전에 팀을 구성하고 있는 사람들에 관한 몇가지 이야기를 해야할 것 같다. 그들은 실무자 이어야 한다. 그래픽 디자이너 또는 프로그래머와 같이 여러 직종으로 구성된 사람들이어야 한다. 이때의 기준은 그들이 게임을 만드는 것에 대해 잘 알아야 한다는 것이다. 이것은 개발 감독 또는 스튜디오 매니저와 같은 관리자들이 관리인의 비젼을 토의 하는 것 만큼 중요한 일이다.

The group must include a person knowledgeable in this method, who will guide the team's musings into constructive hypotheses. The size of the group is of little importance. The method discussed is designed to consider everyone's ideas, therefore making it applicable even to even large groups.

2nd stage - Identifying parameters and their values

두번째 단계 - 파라미터의 식별과 가치 산정

파라미터란 무엇인가?

Parameters are the characteristics of a game. For instance, the parameter called 'background' can have the following values: contemporary, heroic-fantasy, science fiction, middle ages, etc.

파라미터들은 게임의 특징이 되는 것들이다. 일예로 “배경”라는 파라미터는 다음과 같은 요소들을 갖는다. 동시대, 영웅서사적 판타지, SF, 중세 등등

A game project can therefore be defined as a set of parameters, and the values selected for each of them. Choosing parameters and their values is therefore an important step. In the method presented in this article, the first stage is defining such parameters and their associated values. For instance, here are some of the possible parameters that could have been used when creating Alone in the Dark — The New Nightmare:

따라서 한게임 프로젝트는 파라미터의 묶음중 각각에 해당하는 요소들을 선택되어진 것으로 정의할 수 있다. 따라서 파라미터를 선택하고 그것들의 요소를 결정하는 일은 중요한 일이다. 이 장에서 논의될 방법 중 첫번째 단계는 그런 파라미터를 정의하고 관련 요소들을 뽑아내는 것이다. 예를 들어 아래는 Alone in the Dark – The New Nightmare와 같은 게임을 만들 때 사용될만한 파라미터를 정의하였다.

Values that are assigned to each parameter. The values describing the game are highlighted

파라미터 설명
마켓 구분(장르) 이것은 게임의 어떤 분류인가
멀티플레이 영역 멀티플레이가 된다면 어떤 방식을 채택할 것인가?
사고 영역 이게임이 사용자의 지능적인 플레이를 전제한다면 어떤점에서 그러한 것들을 제공할 것인가?
액션영역 사용자의 어떤 형태의 액션이 요구될것인가?
배경 연대, 문화, 문명등 어떠한 배경속에 사용자를 위치시킬것인가?
시점 일인칭시점, 2인칭시점, 3인칭시점
파라미터 설명
마켓 구분(장르) 액션/어드벤쳐, 1인칭슈팅, 아케이드
멀티플레이 영역 없음, 협동, 결투
사고 영역 퍼즐, 전술
액션영역 슈팅, 모험, 결투
배경 20세기 초, 동시대
시점 일인칭시점, 2인칭시점, 3인칭시점

요소가 각 파라미터에 할당되고 이 게임을 표현하는 요소들은 진하게 표시됨.

The Choice of Parameters

파라미터의 선택

In our racing game example, after some decision-making, the group determines to focus on the following parameters:

이 레이싱 게임의 예에서, 몇 가지 결정 과정을 거친 후 다음과 같은 파라미터들에 집중하기로 했다고 하자.

A few comments are in order, such as:

How do we select the parameters? It is a delicate task. It is best to prepare a preliminary list and then submit it not to the workgroup but to the studio management. The latter will usually come up with new ones including parameters specific to the studio. I must remind you that one of the goals of this tool is to build consensus around a single project and that falls in the area of responsibility of upper-level management.

몇가지 설명을 하자면 아래와 같다

  1. 어떻게 파라미터를 결정했는가? 그것은 섬세한 작업이다. 발단단계의 리스트를 준비한후 실무자들이 아닌 관리인에게 그것을 감수케 한다. 대부분 조금 지나 새로운 파라미터들이 추가될 것이다. 이런 방식은 하나의 프로젝트를 진행하는데 있어서 의견의 일치를 이루고자 함을 상기시키고자 한다. 그럼으로 책임소재가 상위 관리자에게 귀속되어 있다.

You can have as many parameters as you want, but for practical purposes, I recommend to limit it to about 10. If you need to use more, it is always possible to split the work into several sub-systems.

  1. 아마도 이것들 이외에 스스로 원하는 다른 많은 파라미터가 있을 수 있다. 하지만 연습의 목적으로서는 10개 이하로 그수를 줄일 것을 권한다. 만일 좀더 많은 파라미터를 써보고 싶다면 작업을 몇단계의 서브항목으로 나눌수있음으로 언제나 가능하다.

The parameters all have to be independent from each other.

  1. 파라미터들은 모두 각기 서로 독립되어 있다.

The Choice of Values

요소들의 선택

Once the parameters are selected, proper values must be identified. Let's look at our list of parameters and some of the values.

일단 파라미터가 선택되었으면 요소들이 결정되어야 한다. 이제 우리가 고른 파라미터와 요소들을 살펴보자.

파라미터 설명
게임플레이 유형 시뮬레이션, 아케이드
'액션' 영역 드라이빙, 슈팅, 항해, 없음
'사고' 영역 건설, 팀 관리, 자원 관리, 전술, 없음
'모험' 영역 중요하지 않음, 매우 중요함
게임 영역 레이스 트랙, 열린 공간
차량 육지, 공중, 물 위, 물 밑
마켓 구분 RTS, FPS, 자동차 경주, 어드벤쳐/ 액션

A few questions will certainly come up: How do we go about a composite value, that is, a value that combines more than one sub-value? For instance, the 'vehicles' parameter can assume combined values such as ground-air, ground-air-water, etc. There are two possible hypotheses: with a small number of combinations, a simple enumeration will suffice, and when combinations are numerous, make a preliminary analysis of the parameter in question. The best ideas found here will then serve in the final analysis. What if there are too many values? Again, start with a focused analysis of this specific parameter.

몇가지 질문들이 떠오를 것이다 :
즉 1개이상의 하부 단위들을 가지고 있는 요소들을 어떻게 조합하려 애를 썼을까? 예를 들어 차량이라는 파라미터는 지상-공중, 지상-공중-수중 등의 요소들과 결합된다고 가정할 수 있다. 여기에는 적은 수의 조합과, 단순한 열거라는 두가지 전제가 따른다. 여기서 발견되는 최상의 아이디어들은 곧 최종단계의 분석에 도움이 될 것 이다. 만일 너무많은 요소들이 있다면 어떻게 할 것인가? 다시한번 초점이 맞춰진 특정한 패러미터들을 분석하라.

3rd Stage - Filtering Ideas and Defining Preferences

3번째 단계 - 아이디어 걸러내기 그리고 선호도 윤곽잡기

As we have seen, a concept is defined by a set of parameters and the values chosen for each of them. For instance, the solution for concept number one is as follows:

앞에서 살펴보았듯이 추상적인 개념은 각각의 요소와 파라미터 셋으로 정의된다.추상적인 생각은 각각의 요소와 파라미터 셋으로 정의된다.

파라미터 설명
게임플레이 유형 시뮬레이션, 아케이드
'액션' 영역 드라이빙, 슈팅, 항해, 없음
'사고' 영역 건설, 팀 관리, 자원 관리, 전술, 없음
'모험' 영역 중요하지 않음, 매우 중요함
게임 영역 레이스 트랙, 열린 공간
차량 육지, 공중, 물 위, 물 밑
마켓 구분 RTS, FPS, 자동차 경주, 어드벤쳐/ 액션

The solution for concept number one.

Combining all values, we find 2560 possible configurations:

2X4X5X2X2X4X4

Rest assured, we are not going to examine every one of them. We have a method narrowing the field down to just a few.

모든 요소들을 결합했을 때 우리는 2560개의 경우의 수가 생긴다.

2*4*5*2*2*4*4

안심해도 좋을 것은 우리는 이모든 것을 시험해볼 필요가 없다는 것이다. 우리는 단지 몇가지의 영역으로 범위를 좁히는 방식을 택할 것이다.

Narrowing the Scope

범위 좁히기

The method of reducing the number possible configurations for a given parameter with values is to define exclusions and preferences.

주어진 패러미터와 요소들에서 가능한 조합의 수를 줄이는 방법은 취할것과 취하지 않을 것을 분명히 하는 것이다.

The exclusions

제외

Exclusions are pairs of values which are incompatible and therefore of no interest. Here are a few examples for our racing game concept:

제외할 것들은 적합하지 않거나 흥미를 끌지 않은 몇쌍의 요소들을 의미한다. 우리가 가정한 레이싱 게임의 컨셉에서 제외할 몇가지 샘플은 아래와 같다.

파라미터 그리고.. 파라미터
게임플레이 유형 시뮬레이션 차량 물 밑
'사고' 영역 자원 관리 마켓 구분 레이싱
게임 영역 트랙 모두 모두

Examples for a racing game concept.

The first pair of values are ruled out since a realistic underwater racing game makes little sense. The pair 'resource management' and 'racing' is also eliminated since a consumer who buys a racing game expects a credible universe. Resource management is usually a far cry from reality. The entire value, titled track racing, is also ruled out because this marketing segment is already saturated with titles. In all, 45 exclusions are made in this example.

첫번째 요소들은 리얼한 수중 게임이 조금 상식에 벗어나기 때문에 제외되었다. 자원관리와 레이싱은 이 게임을 살만한 사람들이 좀더 확실한 세계를 원할거라 여기기 때문에 제외됐다. 자원 관리는 대체로 현실적인 느낌에서 조금 멀게 느껴진다. 트랙 레이싱이라 붙은 모든 요소들은 마케팅 영역이 이미 그 이름에서 확실한 의미를 전달하고 있기 때문에 모두 제외 시켰다. 이 예제에서 총 45개의 제외 품목이 만들어졌다.

The preferences

선호요소

Preferences are values and pairs of values that appear particularly promising for various reasons: internal know how, lack of competition, control of a suitable license, etc. Here are a few preferences for our racing game:

선호요소는 여러 이유에서 특별히 전도유망함을 보이는 요소들을 의미한다. 내부의 노하우와, 경쟁의 결여, 적당한 라이센스의 관리 등등

파라미터 그리고.. 파라미터
게임플레이 유형 아케이드 모두 모두
'모험' 영역 매우 중요 모두 모두
차량 육지 모두 모두

References for the racing game.

In the example above, a simulation is ruled out because priority is given to an 'arcade' type of gameplay. More importance is placed on 'adventure' dimension parameters, which in our opinion will produce a rare mix of genres. On the other hand, we will stick with a classical type of vehicle, namely land vehicles. In all, I have identified 50 preferences here.

위의 예에서 시뮬레이션이라는 항목은 아케이드형의 게임타입의 우선순위에 의해 위의예에서 시뮬레이션이라는 항목은 제외되었다. 우리의 견해로는 다소 드문 복합 장르를 생성할 것이라고 믿어지는 모헙의 영역이 좀더 중요하다 할 수 있다. 다른 한편으로는 우리는 소위 지상 차량이라 불리는 전형적인 차량들과 겨루게 될 것이다. 모든면에서 50%정도는 여기서 구분될 것이다. (?)

The Table of Retained Ideas

사용될 아이디어의 목록

We now have all the elements necessary to draft a table containing all of our hypotheses. It is best to use dedicated software such as Morphol, published by French software house Heurisco. Once I have all the exclusions and preferences in place, the software works out the remaining hypotheses. Thanks to software filtering, we are down from 2560 combinations to about sixty. Hypotheses will appear as code. For example, solution 2.3.2.2.1.1.3 corresponds to arcade, navigation, team management, very important ('adventure' dimension), race track, ground (vehicle), and car racing respectively.

이제는 우리는 우리의 모든 전제를 포함한 일람을 작성하기 위한 모든 구성요소를 얻었다. 휴리스코라는 프랑스 회사에 의해 만들어진 몰폴과 같은 소프트웨어를 활용하는 것도 좋은 방법다. 일단 취할것과 취하지 않을 것을 선택한다면 이 프로그램은 남아있는 전제들을 밝혀낼 것이다. 이 프로그램이 걸러준 덕분으로 우리는 2560개의 조합에서 60여개로 그 수를 줄였다. 가정들은 부호로 나타날것이다. 예를 들어 2.3.2.2.1.1.3 이라는 결과는 각각 아케이드, 항해술, 팀관리, 매우중요한 탐험영역, 궤도 레이싱, 지상 차량과 자동차 레이싱이라는 것과 연결된다.

4th Stage - Analyzing Hypotheses According to Priorities

4단계 - 우선순위에 따른 가정분석

Once the valid hypotheses are identified, they are classified in order to isolate the best possible concept.

일단 불필요한 가정이 식별된다면 가능한 최상의 아이디어로 격리시키기 위해 범주화 되어야 할 것이다.

Selecting Criteria and Assigning Weights

기준설정과 중요도 배정

To determine the interest of a particular concept, we need to establish a set of criteria. Let us select the following:

특정한 컨셉의 흥미도를 결정하기 위해 우리는 몇가지의 기준을 설정할 필요가 있다. 아래의 예중에서 몇가지를 선택하자.

독창성
리플레이성
풍부함
개발사의 내부 노하우와의 호환성
개발 비용

Set of criteria

The list of such criteria is established by the whole team. You are free to use as many criteria as you feel necessary, but experience shows that the maximum should be around ten. This creative thinking is particularly beneficial because it motivates the group to consider what is truly important for the game and for the studio. In the next stage, weights are attributed to each criterion:

위와 같은 기준들은 팀전원에 의해 결정되었다. 어떠한 기준이든 필요하다고 여겨지는 것은 상관없지만 경험에 비추어볼 때 10여개정도가 적정하다고 여겨진다. 게임과 회사를 위해 정말 중요하다고 여겨지는 것들을 고려하는 것은 팀원들에게 동기부여를 하기 때문에 이런 창조적인 발상은 특별히 매우 유용하다. 다음 단계는 각 기준의 중요도를 설정하는 것이다.

독창성 4
리플레이성 3
풍부함 3
개발사의 내부 노하우와의 호환성 6
개발 비용 4
총합 20

Rating each criterion

선택된 기준에 의해 가정에 등급 매기기

Rating Hypotheses According to Selected Criteria We must now rate each solution on a scale of 1 to 5 for each individual criterion. For instance, for solution 2.3.2.2.1.1.3:

각 개별 기준에 따라 1부터 5까지의 단계로 각 결과물에 등급을 매겨야 한다. 예를 들어 2.3.2.2.1.1.3 은 아래와 같다.:

독창성 2
리플레이성 4
풍부함 3
개발사의 내부 노하우와의 호환성 3
개발 비용 2

Rating Hypotheses According to Selected Criteria

Reconciling Opposite Views

반대 견해를 만족시키기

There is one problem, however, when rating hypotheses. How can the studio come to terms with contradicting opinions — for instance, from management and players? The solution is to assign more than one weight to each criterion. In our example, we identify two groups that judge the interest of a concept from different angles: management and players. Management will be preoccupied with figures, while players will be less concerned with budget issues. A new table is necessary to take both groups into account:

그러나 가설의 등급을 매길 때 한가지 문제가 발생한다. 어떻게 예를 들어 경영관리 차원과 그에 반대되는 플레이어 측면에서에서 발생할 수 있는 반대의 의견들과 의견을 조율할 것인가 하는 것이다.결과는 각각의 기준에 하나이상의 중요도를 할당한다. 예에서도 우리는 두가지 다른 각도의 재미를 판단하였고 두 부류를 식별 하였다. 관리와 플레이어. 모양새에 의해 이미 관리가 선점당할 동안 플레이어들은 지출비용에 대해 그다지 고려를 하지 않을 것이다. 여기 이 두그룹을 고려한 새로운 형태의 일람이 있다.

조건 가중치(관리) 가중치(플레이어)
독창성 2 4
리플레이성 4 5
풍부함 3 2
개발사의 내부 노하우와의 호환성 3 0
개발 비용 2 0

Although this example uses only two weights per criterion, it can still be used.

Analyzing the New Ranking

새로운 랭킹의 분석

The new table is now much more informative. As we can see, the ranking of hypotheses varies significantly depending on which point of view is chosen.

새로운 목록이 이제 훨씬더 유용해졌다. 봐서 알 수 있듯이 가설의 등급일람은 어떤 관점으로 보느냐에 따라 두드러진 차이를 나타낸다.

http://www.gamasutra.com/features/20010926/luban_11.jpg

Analyzing the new ranking. Note: for technical reasons this table is extracted from a different analysis

Ultimately, how do we retain the lowest amount of possible variants? Priority is to be given to those hypotheses that will satisfy both groups.

궁극적으로 어떻게 가장 적은 양의 가능 이형을 유지할 것인가 하는 문제이다. 이 전제들중 우선순위가 주어진다면 이것은 양측의 그룹을 모두 만족 시킬 것이다.

http://www.gamasutra.com/features/20010926/luban_12.jpg

Here is an example of a configuration that creates a game concept that merges two genres: racing and adventure:

아래는 레이싱과 어드벤쳐라는 두가지 장르를 합쳐서 만든 게임컨셉의 조합이다.

http://www.gamasutra.com/features/20010926/luban_13.jpg

We can also identify a few hypotheses that did very well in one ranking but poorly in the other.

우리는 한쪽의 랭킹에서는 우선순위가 매우 높으나 다른쪽에서는 낮은 여러 개의 전제들을 식별할 수 있다.

http://www.gamasutra.com/features/20010926/luban_14.jpg

Here for instance, the following criteria translate into a rally racing game with a storyline, a concept that did not score that high.

여기 예를 들어 스토리가 있는 랠리레이싱 게임으로 해석될수 있는 아래의 기준들은 높은 점수를 받지 못한 컨셉이다.

http://www.gamasutra.com/features/20010926/luban_15.jpg

Finally, don't throw away ideas that are extremely original, and therefore hardly imaginable by the competition. Keep one or two hypotheses that rated average, but are dear to the heart of someone in the team, as possible concepts.

최종적으로 경쟁사에서 거의 상상하기 어려운 극도의 독창적인 아이디어는 버리지 말아야 한다. 팀의 누군가에게 선심을 쓰기위한 것이 아닌 가능한 컨셉으로 평균점을 획득한 한두가지의 가정들도 보관되어야 한다.

http://www.gamasutra.com/features/20010926/luban_16.jpg

________________________________________________________

Applications and Conclusions

응용과 결론

In the example used for this conference, I define the general mechanisms of a game project. Once the best hypotheses are selected, designers can take over and focus on concrete goals rather than just 'grope in the dark'. However, there is more than one application to this method. The following are a few examples.

이 글에서 쓰여진 예제에서 나는 게임 프로젝트에 있어서 상당히 일반적인 절차를 정의하였다. 일단 최상의 가설이 선택되었다면 기획자는 이를 인계받았다면 뜬구름 잡는 식이 아닌 구체적인 목표에 초점을 맞춰야 한다. 그러나 여기에는 다른 응용이 있다. 아래는 그 예를 나타낸다.

Evaluating a Game Project According to the Publisher's Expectations In this situation, the purpose is to seduce the publisher above all else. Suppose the studio is out pitching a game concept to a major publisher who owns a number of licenses. We can use the following parameters:

이 경우 배급자의 기대에 준해 게임 프로젝트를 검토할경우 다른 그무엇보다도 배급자(물주)를 반하게 만들어야 한다. 상당수의 판권을 쥐고 있는 주요 물주에게 게임 컨셉을 제의하는 상황이라고 가정할 때 우리는 아래와 같은 파라미터를 사용할 수 있다.

Once we have isolated our game hypotheses by means of exclusions and preferences, we can pick the best ones by applying the selection criteria that matter most to the publisher and the development studio.

일단 선호와 배제의 방식에 의해 가정들을 걸러냈다면 우리는 개발사와 유통사의 문제에 맞춰 선택한 최상의 것들을 골라낸다.

Designing an Original Game Mechanism

독창적인 게임구조 기획하기

Another application for this method is in researching a particular aspect of a game. In the following example, we will investigate a new interface for a strategy or tactical game for the console market. One of the reasons why this game category never caught on with consoles was because consoles lack a mouse. Therefore, the challenge is finding an interface that relies exclusively on the use of a pad. 이 방식의 또다른 응용은 게임의 특정 분야를 조사하는 것이다. 아래의 콘솔시장에서 전략 게임을 위한 새로운 인터페이스를 조사하려 할때의 예제이다. 이런 장르의 게임이 콘솔에서 히트한적이 없는 이유중 하나는 마우스가 없다는 것이다. 따라서 이 장르에 대한 도전은 오로지 패드를 이용한 인터페이스 방식을 찾는 것이다.

Parameters:

파라미터

Evaluation criteria:

평가기준

Conclusion

결론

This method is not a 'black box' that takes in data and produces a number of original concepts. What is important is the process it generates. The latter is just as significant as results proper. The use of this method cultivates exchange and encourages dialog. It lets everyone speak their mind and channels everyone's reflections.

In conclusion, our method helps achieve the following goals: 1/ put a large workgroup into creative motion by focusing collective ideas around a few major points; 2/ identify those combinations of features that no-one has previously thought of; and 3/ establish consensus around a result.

이 방식은 데이타를 주면 여러 개의 결과를 뽑아내는 기계장치는 아니다. 중요한것은 그것을 생성하는 과정인 것이다. 과정은 적합한 결과만큼 중요한 의미를 갖는다. 이 방식의 사용은 의견교환을 독려하는데에 있다. 모두의 심사숙고를 반영할 수 있는 통로이며 서로의 의견을 교환하게 한다.

결과적으로 우리의 방식은 아래와 같은 목적을 달성할 수 있게 한다.

  1. . 몇가지 중요한 포인트에 집합적인 아이디어를 뽑아냄으로 커다란 집단을 창조적인 활동으로 끌고간다.
  2. . 아무도 전에 생각하지 못한 새로운 형태의 조합을 식별하게 한다.
  3. . 결과에 대해 일치할 수 있는 기반을 형성한다.

분류:가마수트라 분류:번역