게임밸런스
- 게임 밸런스에는 다음과 같이 크게 세 가지의 유형으로 나누어서 생각해 볼 수 있다.
1. 플레이어/플레이어 밸런스는 게임을 공평하게 만들어서, 승패를 겨루는 플레이어에게 실력을 제외한 모든 조건이 동등하게 주어지도록 구성하는 것이다. 게임에 운이 작용할 수도 있지만, 이것은 모든 플레이어에게 동일하게 적용되어야 한다.
2. 플레이어/게임플레이 밸런스는 플레이어의 학습곡선에 따라 그에 상응하는 보상을 주어서 계속 게임을 플레이하도록 유도하는 것을 말한다. 플레이어가 게임을 적으로 인식할 정도로 게임 진행의 난이도가 너무 높거나 임의적이어서는 안된다.
3. 게임플레이/게임플레이 밸런스는 게임 안의 요소들간의 밸런스를 맞추는 것이다. 예를 들어 '타부의 검' 이 다른 무기에 비해 2배의 공격력을 갖는다면, 그 가격을 다른 무기의 2배로 설정하는 식으로 다른 요소들이 보정되어서 밸런스가 맞춰져야 한다.

*역자노트 5.1 학습곡선
-학습량, 학습시간, 반응시간, 정밀도, 오류 등을 측도로 하여 행동의 변화를 표시한 그래프. 게임에서는 플레이어의 게임에 대한 숙련도가 향상되는 과정을 뜻한다. 즉 게임 초반에는 플레이어의 숙련도가 늦지만 게임이 진행될수록 점점 숙련도가 높아지는 것을 말한다.

1) 플레이어/플레이어 밸런스
- 하나의 캐릭터가 다른 캐릭터보다 조금 더 쎄다고 해서 너무나도 큰 문제가 되진 않는다. WOW를 예로 든다면, 도적이 PVE에서 엄청난 데미지를 보인다고 해서 흑마들이 좌절하거나 하기싫거나 이런 면보단, 흑마로써 도적을 이기고 싶다 라는 도전이나 새로운 목표와 같은 점이 생길 것이다.

 1. 대칭
 - 게임에서는 플레이어가 제어하지 못하는 요인 때문에 승패가 결정되어서는 안된다.

 2. 레벨 디자인에서의 대칭성
 - 각 플레이어가 똑같은 입장이 되도록 만들면, 대칭성을 유지하기가 쉽다. 하지만 너무 뻔하기 때문에 플레이어들이 쉽게 질릴 수 있다. 조금 더 바람직한 방법으로는 레벨이 기능적으로는 대칭을 이루지만, 그것이 대칭이라는 사실이 한눈에 드러나지 않도록 구성하는 것이 가장 바람직하다.

 3. 게임 디자인에서의 대칭성
 - 게임 디자인에서의 대칭성이란 모든 플레이어에게 주어지는 선택사항이 기능적으로 동일하다는 것을 뜻한다. 이것은 공정한 게임을 만들기 위한 가장 쉬운 방법이다. 더 어려운 방법으로는, 플레이어들에게 서로 다른 선택사항을 제공하되 그 선택사항들 간의 밸런스를 잡아서 각 플레이어가 우승할 확률을 비슷하게 만드는 것이다.

ex)
워크레프트 2 : 기본적으로 대칭구조를 이루고 있지만, 오크쪽의 오우거메이지는 광전사의 분노와 폭발 부적을 사용하지만, 인간쪽에서는 동료들을 치료하거나 언데드 유니트를 파괴할 수 있는 능력을 가진 팔라딘이 있다.

2) 플레이어/게임플레이 밸런스
- 플레이어/게임플레이 밸런스는 게임의 상호작용 요소에 관련된 일이다. 게임이라면 당연히 모든 플레이어에게 공정하고, 그 안의 모든 요소와 기능들이 의미를 갖어야겠지만, 동시에 플레이어와 게임 간의 관계에 대해 생각해보아야 한다. 게임이 보상을 얻기 위해 너무 많은 고생을 요구한다면, 플레이어의 관심은 그리 오래가지 못 할 것이다.

- 플레이어/게임플레이 밸런스 조정은 다음 세 가지의 간단한 규칙을 따른다.
>플레이어에게 보상을 주어라
>잡일은 컴퓨터에게 시켜라
>플레이어가 즐길 게임을 만들어야지, 적이 되어서는 안된다

 1. 플레이어에게 보상을 주어라
 - 일단은 게임 하는 법을 익히며 시작할 것이다. 하지만 완벽하게 게임 조작을 익힐 때까지 플레이어는 자주 실수를 저지를 것이며, 그 때마다 힘이 빠질 것이다. 따라서 플레이어가 무언가 새로운 것을 배울 때마다 약간의 보상을 제공해서 실수 때문에 생긴 실망감을 상쇄시켜야만 한다.
 - 단순히 수치가 높아지는 보상보다는, 게임 안에서의 선택의 폭이 넓어지는 보상이 바람직하다. "가위차기 기술을 배우려고 무진장 노력했지. 이제 드디어 익혔어. 멋진 기술이지." 라고 말하면 단순히 사용가능한 기술의 갯수가 늘어난 것이지만, "가위차기를 배우고 나니까, 그것과 연계시켜서 리버스 펀치를 활용할 방법이 생각났어." 라고 말한다면 새로운 기술을 배웠을 뿐 아니라 기존의 기술들까지도 새롭게 활용할 수 있게 된 것이다.

 2. 잡일은 컴퓨터에게 시켜라
 - 예를 들어 예전 CRPG게임 패키지 안에 모눈종이와 연필이 들어 있어, 던전을 탐험할 때마다 지도를 그려야 했다. 판단력을 요구하는 의사결정 이외의 다른 작업은 컴퓨터의 AI가 알아서 처리하도록 만들어야 한다. 플레이어를 귀찮게 하면 안된다.

 3. 플레이어가 즐길 게임을 만들어야지, 적이 되어서는 안된다
 - 세이브라는 것은 현실에서 일이 생겨서 저장을 하는 도구가 되어야 하지, 게임을 공략하기 위한 도구가 되어서는 안된다. 만약 세이브가 없이 공략하기 어려운 게임이라면, 그 게임은 밸런스가 제대로 잡혀 있지 않은 게임이다.

3) 게임플레이/게임플레이 밸런스
- 게임플레이에서의 밸런스를 위해서 해결해야 될 문제로는 다음의 세 가지를 생각해 볼 수 있다.
>절대우위의 단일한 의사결정보다는 다양한 의사결정이 가능하도록 해야 한다
>상대방의 의사결정에 따라 자신이 내릴 수 있는 최적의 의사결정을 제공하기란 생각만큼 쉽지 않다
>각각의 선택가능한 결정들 중에서 각각이 채택되는 빈도수를 파악하기 힘들다.그럼에도 불구하고 게임의 밸런스를 잡기 위해서는 그것을 알아내야만 한다

 1. 구성요소와 속성 밸런스
 - 게임을 이루는 요소들 간의 밸런스 조정은 두 가지 수준에서 이루어져야 한다.
 >구성요소 밸런스, 속성 밸런스

 2. 비순차적인 게임 규칙은 밸런스를 보장한다
 - 가위, 바위, 보가 최고의 예
  가위  바위  보 
 바위  -1 0
 보  1 -1 
 가위  0 -1 

- 가위, 바위, 보와 비슷한 예로, 하단차기, 상단차기, 내려찍기가 있다.
- 위의 타격기를 더욱 재미있게 추가할 수 있는 것은 콤보기를 넣고, 보상값을 더 크게 구성하면 된다.

 3. 지나치게 복잡한 조합
 - 너무 많은 가위바위보의 관계를 유지 한다면, 경험에 입각한 전략을 세우기가 불가능한 게임이 되고 만다.

 4. 게임 디자인의 규모. 그리고 또 다른 비순차적 관계
 - 가위바위보의 규칙에 확장을 한다면, 홀수가 되어야 한다. (3, 5, 7, 9..)
 - 한가지 예를 들어 보자. 아래의 5방향 가위바위보 보상값을 보았을 때, 5가지의 캐릭터중에 한가지의 캐릭터만 제외 한다고 하면, 바로 밸런스의 차이가 생긴다. 1가지의 캐릭터는 매우 강하게 특화될 것이고, 1가지의 캐릭터는 매우 쓸모가 없어질 것이다.

ex)가위바위보의 예

- 3방향 가위바위보 보상값 표
  가위  바위  보 
 바위  -1 0
 보  1 -1 
 가위  0 -1 

- 4방향 가위바위보 보상값 표(홀수 방향 보상값과는 달리 비대칭이라 어떻게 보면 더 매력적이다)
   궁수(a) 전사(w) 야만인(b)  마법사(s) 
 궁수(a)  0   +1  -1  0
 전사(w)  -1  0  +1  +1
 야만인(b)  +1  -1  0  -1
 마법사(s)  0  -1  +1  0
 위의 표를 정리해보자면,
 1. a + w + b + s = 1
 2. A = w - b
 3. W = b + s
 4. B = a - w - s
 5. S = b = w
 6. A + W + B + S = 0

 - 5방향 가위바위보 보상값 표
   무사 승려  보병   궁수 자객 
 무사 +1  +1  -1  -1 
 승려 -1  +1  +1  -1 
 보병 -1 -1  +1  +1 
 궁수 +1  -1  -1  +1 
 자객 +1 +1  -1  -1 


- 5방향이지만 유저의 눈에 보이지 않는 가위바위보 보상값 표
 (탱크는 탱크킬러를 제외한 모든 유니트에게 이기고, 탱크킬러는 탱크를 제외한 모든 유니트에게 패배한다.
  또한 보병, 장갑차, 포병은 일반적인 가위바위보 관계를 이룬다.)
   탱크  보병  포병  장갑차  탱크 킬러
 탱크  0  +1  +1  +1  -1
 보병  -1  0  +1  -1  +1
 포병  -1  +1  0  +1  +1
 장갑차  -1  +1  -1  0  +1
 탱크킬러  +1  -1  -1  -1  0

 겉으로 보기에는 많은 사용자들이 탱크와 탱크 킬러의 게임이 유지될거라 보이겠지만,
 줄여 본다면,
 
   탱크  그 외  탱크 킬러
 탱크  0  +1  -1
 그 외(가위바위보유지)  -1  0(평균값)  +1
 탱크 킬러  +1  -1  0

이렇게 된다면, 각 유니트의 사용 빈도는
 유니트 종류  탱크  보병  포병  장값차  탱크 킬러
 사용 빈도  1/3  1/9  1/9  1/9  1/3

 이 예는 각 유니트들의 가격이 동일하다는 전제하에 이런 빈도가 나오지만,
 만약 탱크의 값을 다른 유닛에 비해 2배로 올린다면? 탱크와 보병의 수치와 결과에 따라 보상값을 조정한다면, 이 공식은 알맞는 밸런스를 맞출 수 있고, 게임을 만들기도 쉬울 것이다.

4) 게임밸런스 체크리스트
- 플레이어/플레이어 밸런스에서의 황금률 : 실수를 범하지 않은 플레이어가 이길 수 없는 상황에 놓이는 경우가 없어야 한다.
- 플레이어/게임플레이 밸런스의 황금률 : 게임을 플레이하는 것만큼이나 게임을 배우는 과정 또한 재미있어야 한다. 그리고 게임에 숙달될수록 점점 더 재미있어져야 한다.
- 게임플레이/게임플레이 밸런스의 황금률 : 게임 내의 모든 옵션은 이따금이라도 쓸모가 있어야 하며, 각 옵션을 사용할 때의 순 비용은 그것을 사용했을때 얻는 보상값에 비례해야 한다.




'게임아키텍처디자인' 120p~154p




Posted by 생선날개
gamE/C2010. 1. 20. 15:10




함수란?
ex)

3X + 4 = Y

인자 전달 - 입력 X를 전달하는 행위
함수 호출 - 입력 X를 전달하면서 정의된 함수의 실행을 요구하는 행위

main
- 주 프로그램임을 의미. 함수의 이름

괄호{}
- 함수 main()의 실행 범위. main 몸체 시작과 종료.

printf()
- 문자열을 화면에 출력하기 위한 함수

return 0
- 함수를 빠져나온다는 의미
- 함수를 호출 한 영역으로 값을 반환한다는 의미

%d
- 서식 문자. 10진수 정수형으로 출력



특수 문자

기능

 \a

벨소리

 \b

왼쪽으로 1칸이동

 \f

한 페이지 전진

 \n

줄바꿈

 \r

Enter

 \t

Tab

 \v

수직 Tab

 \\

\를 출력

 \'

작은 따옴표 출력

 \"

큰 따옴표 출력

 \0

아무 동작하지 않음

 %%

% 기호 출력

 ;

문장 구별하기

 /* */

주석문(자신만의 문장.출력되지 않음)

 //

한줄 주석 


연습문제 1.

#include <stdio.h>
int main(void)
{
 printf("홍\n홍길\n홍길동\n");
  return 0;
}


결과


홍길
홍길동




연습문제 2.

#include <stdio.h>
int main(void)
{
 printf("이름\n아무개\n");
 printf("주소\n어딘가에\n");
 printf("전화번호\n123456789\n");
  return 0;
}


결과

이름
아무개
주소
어딘가에
전화번호
123456789




연습문제 3.


#include <stdio.h>

int main(void)
{
 printf("Hello Everybody \n");
 printf("%d\n", 1234);
 printf("%d %d \n", 10, 20);
 return 0;

}

결과

Hello Everybody
1234
10 20


연습문제 4.

#include <stdio.h>

int main(void)
{
 printf("my age : %d \n", 20);
 printf("%d is my point \n", 100);
 printf("good \nmorning \neverybody\n");

 return 0;

}

결과

my age : 20
100 is my point
good
morning
everybody





연습문제 5.

#include <stdio.h>

int main(void)
{
 printf("저의 이름은 홍길동입니다. \n");
 printf("저의 나이는 %d살이고요. \n", 20);
 printf("제가 사는 번지수는 %d-%d번지입니다.\n", 111, 222);

 return 0;

}

결과

저의 이름은 홍길동입니다.
저의 나이는 20살이고요
제가 사는 번지수는 111-222번지입니다.





연습문제 6.

#include <stdio.h>

int main(void)
{
 printf("%d * %d = %d\n", 2, 3, 6);
 printf("%d * %d = %d\n", 2, 4, 2*4);

 return 0;

}


결과

2 * 3 = 6
2 * 4 = 8




'C 프로그래밍' ~51P



'gamE > C' 카테고리의 다른 글

C - Chapter 3. 변수와 연산자  (0) 2010.01.22
C - Chapter1. 이것이 C언어다.  (1) 2010.01.19
Posted by 생선날개





일정계획서
- 사례연구 4.1에서는 실시간 전략 게임인 코푸스 Corpus 의 일정계획을 보여준다. 코푸스 (다른 이름으로 출시되었다)는 1990년대 후반에 개발된 게임이다. 요즘의 게임은 좀 더 긴 개발기간이 걸리곤 한다

1. 아이디어 내기
- 기간 : 1개월
- 진행 : 초기 아이디어를 내고 실험가능성에 대한 의견을 나누기. 그 결과를 개요서로 이끌어내기
- 인원 : 리드 디자이너. 떄때로 아키텍트와 기술진의 도움을 받는다
- 결과물 : 유통사가 프로젝트를 진행할지 결정을 내림

2. 컨셉짜기
- 기간 : 3개월
- 진행 : 세부 기획서 쓰기
- 인원 : 리드 디자이너 (2~4개월)
- 결과물 : 2가지의 문서. 게임기획서와 기획자 노트

3. 청사진
- 기간 : 2개월
- 진행 : 개발의 매 단계를 작은 문서들로 나눈 개발단계별 세부사양서를 기획하기. 각 문서들은 각 개발단계에서 해 내야 할 목표와 최선의 결과를 제시한다.
- 인원 : 리드 디자이너와 소프트웨어 기획
- 결과물 : 몇몇의 개발단계별 세부사양서

4. 기술적인 설계
- 기간 : 2개월
- 진행 : 아키텍쳐 그룹이 개발단계뿐 세부사양서에 기초해서 필요한 개발툴들과 프로그램 사양서를 준비한다. 리드 디자이너는 사람들에게 컨셉을 설명하고 프로젝트 리더의 손에 주 업무를 넘긴다. 코푸스의 프로젝트 매니저는 아키텍처 그룹의 맴버이고 프로젝트를 마지막까지 관리했다.
- 인원 : 프로젝트 리더. 미드 디자이너. 소프트웨어 기획
- 결과물 : 게임을 만들기 위한 기술적인 내용들이 정리된 프로그램 사양서와 개발단계별 세부사양서 이 문서와 기획서가 프로젝트 계획이 된다. 개발단계별 세부사양서는 유통사측과 협의한 마일스톤에 맞추어 설계된다 (이경우에는 4단계씩으로 나누어진다)

5. 개발 툴 만들기
- 기간 : 4개월
- 진행 : 게임 개발에 필요한 툴과 구성요소를 구축한다. 목표는 게임 아키텍처를 일정한 완성도에 도달하도록 함으로써 잘 이해되도록 하며 전체를 재 작업할 필요가 없도록 만드는것이다.
- 인원 : 프로젝트 리더와 4명의 툴개발 및 프로그래밍 그룹원
- 결과물 : 게임제작에 필요한 개발툴과 기능적으로는 완성되어 있지만 모든 요소가 다 들어가 있지는 않은 게임구성요소 코푸스의 경우 게임구성요소는 3D그래픽엔진. 화면 구성빌더. 유닛과 빌딩을 만들기위한 게임배경에디터가 그것이다.

6. 제작
- 기간 : 12개월
- 과정 : 프로젝트 리더와 개발툴 프로그래머 한명이 팀을 맞는다 (예를 들어 4명의 프로그래머와 네명의 아티스트) 프로젝트 리더는 게임플레이를 정교하게 마무리 짓는다. 툴 프로그래머는 개발툴을 지원하여 개발툴 및 프로그래밍 그룹이 요청할경우 개발툴을 수리한다 (이론적으로 리드 디자이너는 모든 계층이 마지막 단계의 테스트와 테스트레벨에 대한 고문을 맞는다. 언제나 함꼐 일할 필요는 없고 다음 게임의 디자인을 해도 괜찮다)
- 인원 : 프로젝트 매니져 12개월. 툴 프로그래머 9개월. 12달 동안 9명의 프로그래머. 마지막으로 8~9달 동안 네명의 아티스트
- 결과물 : 다음단계를 프로그래머 없이 조정할 수 있기에 충분한 게임과 완성된 툴

7. 레벨 디자인
- 기간 : 4개월
- 과정 : 프로젝트 리더의 지시하에 게임의 레벨을 제작한다 (경험적으로 프로젝트 리더는 과로로 앓아 누웠을 것이므로 그의 짐을 덜어줄, 유능하고 창조적인 리드 레벨디자이너가 꼭 필요해진다. 그래서 프로젝트 리더는 리드 레벨 디자이너와 레벨 디자인 기간동안에 역할을 나눠가지게 된다)
- 인원 : 프로젝트 리더와 3명의 레벨 디자이너
- 결과물 : 모든 장면들과 게임안에서의 도움말이 들어간 완성된 게임.매뉴얼에 들어갈 글과 그림도 이 시점에서 완성된다

8. 리뷰
- 기간 : 3개월 (레벨 디자인동안에 같이 진행될수도 있다)
- 과정 : 일반적으로 레벨을 만드는 것과 평행하게 진행된다. 외주를 주기로 한다. 또는 일반적으로는 (코푸스의 예에서도 보이듯이) 유통사가 제품의 버그테스트 팀을 발족시킨다.
- 인원 : 테스터 4명
- 결과 : 버그를 찾아 고친다. 게임플레이를 할떄에 기본적인 문제가 발생되었다면 (그런일이 생겨서는 안되지만) 게임은 수정을 위해 개발자들에게 돌려보내지지만 아무튼 이 단계는 생산직전 마지막 단계다



*비효율적인 과정에서는 모든 팀이 첫날부터 함께 프로젝트에 투입된다. 게임 디자이너가 게임을 기획하는 작업을 끝내면 개발팀이 일을 시작한다. 마무리단계에서 디자이너는 팀 멤버 중의 몇 명만을 데리고 막판 수정을 한다. 이런 식으로는 팀원들이 할 일이 없어 빈둥대는 동안에도 시간과 돈이 계속 들어간다.
*컨셉부터 완성까지의 시간 대 결과의 비율이 중요하다. 코푸스의 일정계획서를 들여다보면 어떻게 전체 비용을 낮추었는지 알 수 있을 것이다. 처음 6개월간은 프로젝트에 소수의 사람만이 투입되었다. 이 팀의 실제 제작팀의 규모는 12개월동안만 유지되었다.



Posted by 생선날개




4. 세부기획
- 이번 Chapter.4 에서는 세부기획을 어떻게 나아가는지에 대해 알아본다.
- 세부 기획에 끝날 즈음에는 '게임기획서'와 '기획자노트' 두 개의 문서가 완성될 것이다.
- 게임기획서는 만들어질 게임에 대해 설명하고 모든 사람들이 해야 하는 목표를 설명하여 비전을 제시하는 역할을 하는 글이다.
- 기획자노트는 게임 기획서와 같이 읽는 문서인데, 기획자의 생각을 설명하고 다른 사람들이 기획자가 제안한 게임에 함께 도전하도록 이끄는 역할을 한다.

1) 디자이너의 역할
- 팀원이 함께 브레인스토밍하는 두 시간이 한 사람이 평생 생각할 수 있는 것보다 좋은 아이디어들을 쏟아낼 수 있다.

2) 기획 문서
 1. 게임 기획서
 - 게임에 대해 자세히 설명한 문서로, 잘 읽고 이해하기만 한다면 읽는 사람이 완성된 제품의 모든 것을 눈앞에 그려낼 수 있을 정도로 쓰여 있어야 한다.
 2. 기획자 노트
 - 기획자 노트는 기획서를 구상하는 동안 머리에서 굴러다닌 많은 생각들에 대해서 써내려간 문서이다.
 - 기획자 노트는 2가지 이유에서 쓸모가 있다. 첫 번째로 제작팀에게는 모든 문서들은 가치가 있다. 그리고 프로그래밍 코드에 대한 도큐멘트 비슷한 방식으로 유용하게 쓰인다.

3) 기획 문서 이용하기
- 2가지를 기억하라
>게임 기획서는 프로그래머들이 읽을 수 있도록 준비되어 있어야 한다
>프로그래머들은 게임 기획서를 읽지 않을 것이다
그러나 프로그래머들은 몇 가지 이유에서 기획문서들을 읽을 필요가 있다. 첫 번째 이유는 목표도 모르고 일을 맡아서 하면 사기도 저하되고 능률이 오르지 않기 때문이다. 두번째 이유는 일을 진행하면서 질문이 생길 때마다 디자이너가 대답하기 위해 묶여있는 것보다 이쪽이 더 효율적이라는 것이다. 세 번째 경제적인 이유 때문에 몇 명 안 되는 사람들이 기획서를 쓰기는 하지만 여전히 모든 사람들의 좋은 아이디어를 모아 발전시키는 것이 완벽을 기하기에 더 좋은 방법이기 때문이다. 마지막으로 프로젝트의 비전을 그룹에서 함께 나누는 것은 전체적인 단결력을 강화하고 사기를 올리는 결과를 가져오게 된다.

4) 기획을 개발에 맞추기
 1. 개발단계 Tier와 테스트베드 Testbeds
 - 개발단계에 대한 세부사양서는 다음 사항들을 제시한다.
 > 목표 - 이 단계에서 기획자가 바라는 요소들의 목롱
 > 철학 - 이 단계는 무엇을 테스트하는 것인가
 > 기대하는 결과 - 테스트를 하고 변화시킨 후에 얻고자 하는 것
 > 대안 - 이 아이디어나 컨세빙 변해야 한다면 다른 좋은 대안




'게임아키텍처디자인' 103p~119p



Posted by 생선날개
gamE/C2010. 1. 19. 16:36





프로그램이란?
-컴퓨터가 처리할 일련의 작업 처리 절차의 집합체

프로그래밍이란?
-프로그램을 만드는 행위를 말한다.

프로그래밍 언어란?
-사람과 컴파일러가 이해할 수 있는 약속된 언어를 의미한다. C언어도 이러한 프로그래밍 언어 중 하나.

컴파일러가 하는 역할
-프로그래밍 언어로 작성한 프로그램을 컴퓨터가 이해할 수 있도록 기계어로 번역해 주는 역할. 더불어 이렇게 번역하는 일 자체를 컴파일이라 한다.

코딩
-프로그램을 작성하는 과정

소스 코드
-컴파일되지 않은 코드

소스 파일
-소스 코드가 저장되어 있는 파일

오브젝트 파일
-소스 파일을 컴파일하면 새로운 파일이 하나 생성되는 것

C언어의 특징
-프로그램의 이식성이 높다
-저급 언어와 고급 언어의 구조를 모두 갖추고 있다
-예약어를 사용하여 표현이 간결하다
-함수의 집합이다
-프로그램의 모듈화가 가능하고, 분할 프로그래밍과 분할 컴파일 할 수 있다
-구조화 프로그래밍이 용이하다
-연산자가 풍부하며, 비트 연산, 쉬프트 연산, 번지 및 포인터 연산 등으로 시스템 프로그래밍을 하기 쉽게 한다
-Preprocessor의 매크로 기능이 있다
-포인터를 데이터로 사용할 수 있다
-모든 함수의 순환이 허용된다




'C 프로그래밍' ~34P



'gamE > C' 카테고리의 다른 글

C - Chapter 3. 변수와 연산자  (0) 2010.01.22
C - Chapter 2. 프로그램의 기본 구성  (0) 2010.01.20
Posted by 생선날개




3. 게임플레이
- 이번 Chapter.3 는 앞에서 언급한 것들 보다 자세히 살펴보도록 한다.

1) 게임 플레이란 무엇인가?
- 다양한 것들이 관계되고, 흥미로운 선택을 만드는 것

2) 게임 플레이를 구현하기
- "게임이란 흥미로운 선택의 연속이다"
- 게임 안의 전략은 각각의 장단점이 있어야 한다. 장점만 존재한다면 AI도 자동적으로 그 전략을 택할 것이다. 단점만 존재한다면 누구도 사용하지 않을 것이다.
- 결정이라는 요소는 장점과 단점, 그리고 다른 요소들에 영향을 받는 기회비용이 있을 때 게임플레이에 있어 가치를 갖는다
- 매 선택이 다음 결정에 영향을 미치는 흥미로운 선택의 연속
- 최고의 게임은 규칙은 적을수록 좋다는 원칙을 따라 만들어진다.
-
3) 절대 우세 전략의 문제점
- 어떤 상황에서도 쓸모없는 선택은 '절대열세전략'
- 너무 좋아 다른 것들이 쓸모없는 선택은 '절대우세전략'
- '절대열세전략'의 선택은 쓸모가 없고, 그것을 게임에 적용하는 데 쏟은 시간이 낭비일 뿐이다. 또한 '절대우세전략'은 다른 모든 선택을 쓰레기로 만들기 때문에 '절대열세전략'보다 더욱 좋지 않다.

4) 유사 우세 선택
- 특정한 상황에서만 쓸모 있는 전략
 ex)
 - 고블린에게 파이어볼 마법은 1방. 하지만 다른 적 유닛에겐 아주 극소수의 데미지

5) 무의미한 선택지 피하기
- 가위<바위<보 (X)  가위<바위<보<가위 (O)
- 나아가서, 가위2=바위 와 같은 새로운 변화와 변수가 필요함
- 한가지 규칙만을 도입하는 것으로 재미있는 게임플레이를 기대할 수는 없다.
 ex)
 - 같은 가격 질럿 2마리(200)와 저글링 8마리가 평지에서 싸우면 저글링이 이긴다. 하지만 입구에 막혀 질럿이 2마리를 세워 둔 변수가 생긴다면 저글링이 지게 된다. 이러한 변수

6) 흥미로운 선택지를 확보하기
- 게임에 넣을 만한 선택지의 예 (1번과 2번이 가장 좋다)
 1. 다른 요인들에 의해 하거나, 하지말아야 하는 선택
 2. 맥락에 따라 결정적인 타이밍이 있는 선택
 3. 해도, 하지않아도 차이가 없는 선택 (장식요소)
 4. 언제나 하는 것이 좋은 선택
 5. 아무 소용없는 선택

7) 재미있는 선택지를 만드는 도구들
- 플레이어의 역할을 고려하기
 1. 전략적 선택지
 ex)
 - 상대 프로토스가 질럿체제로 발전하고 있다. 마린 업그레이드를 스팀팩을 할 것인가? 공격 업그레이드를 할 것인가?
 - 투해처리로 멀티를 가져가서 자원을 빠르게 모으면서 위험한 도박을 할 것인가? 아니면 빠른 저글링으로 상대를 압박할 것인가?
 2. 지원 투자
 ex)
 - 배럭스를 지어야만 아카데미를 지을 수 있다.
 - 마린을 만들어서 자신의 병력을 늘릴 것인가? 배럭을 더 지어서 생산량을 늘릴 것인가?

 3. 적응성
 - 게임플레이를 예측하는 유용한 방법은 사용자가 택할 수 있는 선택지 중 가장 좋은것과 가장 나쁜 것을 파악하는 것이다.
 ex)
 1. 최고의 피해를 입히지만 가장 느린 행동 (리버)
 2. 가장 빠르지만 방어력이 아주 나빠지는 행동 (레이스)
 3. 최고의 방어력을 주지만 피해를 거의 입힐 수 없는 행동 (울트라리스크)
 4. 최고도 최저도 아니지만 가장 적응성이 큰 행동 (히드라리스크)

 4. 보정인자
 - 전략게임에 어느 지형이든 건널 수 있는 비행 유니트를 추가했다고 해보자. 다른 유니트들이 모든 지형을 이동하지 못하기 때문에 비행 유니트는 굉장한 이점을 가지고 있다. 어떻게 하면 밸런스를 잘 맞출 수 있을까? 아래와 같은 예가 보정인자다.
 - 느리게 만든다
 - 약하게 만든다
 - 가시거리를 짧게 만든다
 - 비싸게 만든다 (별로 좋지 않다. 사용자가 재미있게 사용하는 데 도움이 되지 않기 때문)

 5. 비영구성
 - 새로운 자원이 있는 곳에 내가 확장기지를 지었다. 그 확장기지를 없앨 수 없다면 영구성. 하지만 다른 적군이 나의 확장기지를 파괴하고 새로운 확장기지를 지었다. 그렇다면 이것은 비영구성.
 - 우연이나 적의 행동에 따라 파괴될 수 있다.
 - 빼앗기거나 변형될 수 있다.
 - 항상 가질 수는 없는 무언가를 줄 수 있다.
 - 사용 회수에 제한이 있다 (10번 쓰면 없어지는 번개의 지팡이)
 - 일정 시간만 유지된다 (10시간이 지나면 사라지는 버프 주문)

 6. 숨은 비용
 - 저글링을 만들기 위한 비용은 50미네랄. 하지만 실질적으로 저글링을 만들기 위한 절차까지 생각해 본다면 200미네랄의 스포닝풀 + 50미네랄의 저글링 변태 비용 = 총 250미네랄. 여기서 200미네랄이 숨은 비용이 된다

 7. 시너지
 - 와우를 예를 들어 설명해보면 20명의 마법사 전체 데미지보다, 17명의 마법사와 1명의 조화드루(공대원 전체 마법치명타5%증가, 마법데미지13%증가), 1명의 정기술사(공대원 전체 치명타5%증가, 주문력280증가), 1명의 암흑사제(공대원 전체 적중도 3% 증가)가 더욱 데미지가 강하다.

8) 게임플레이에 대한 결론
-  좋은 게임이란 '적이 예상하지 못했던 일을 가능하게 함으로써 이기는 게임', 나쁜 게임이란 '어떻게 하면 되는지'를 알아버린 후에는 더 이상 어떤 선택도 필요하지 않는 게임

9) 상호작용
- 뒷마당에서 혼자 벽을 향해 축구공을 차는 것과 팀을 이뤄 골대로 달려가 골을 넣는 것의 차이
- 단지 자동차 운전 게임을 한다면 재미없겠지만, 소화전을 박고 그 소화전에서 물이 뿜어져 나오고, 그 물로 인해 물웅덩이가 생겨 다른 차들이 미끄러진다는 생각을 한다면 이해할 수 있을 것이다.



'게임아키텍처디자인' 78p ~ 103p



Posted by 생선날개




2. 핵심디자인
- 이번 Chapter.2 는 정리되지 않은 아이디어를 다듬어 1차 기획서로 만드는 방법에 대해 알아보도록 한다.

1) 게임이란 무엇인가
 1. 멋진 게임 요소들
  - 여러 아이디어들이 게임에 도움이 될 수도 있겠지만, 어느정도 선을 그어야 하는것도 알아야 한다
 ex)
 - 전사들에게 명령을 내릴 때 부대 내의 전사들이 각기 다른 행동을 하면 재미있을 것 같지 않아?
   (이런 작은 아이디어들이 한없이 생기다보면 결국 게임플레이가 망가지게 된다)
 
 2. 근사한 그래픽
 - 근사한 그래픽이 필요한 것은 맞지만, 이것에 신경을 너무 쓰면 개발팀이 자신의 게임을 만드는 데에 몰입도가 떨어질 수 있으니 주의해야 한다. 

 3. 재미있는 퍼즐들
 - 모든 게임에는 어떠한 형태로든 퍼즐이 있다. '성을 어느 방향으로 확장해야 할 것인가', '쉴 새 없이 몰려드는 저글링의 공격을 어떻게 막아낼 것인가' 도 퍼즐에 포함되는 범주라 보인다.

 4. 흥미로운 배경 설정과 스토리
 - 좋은 배경 설정은 플레이어의 몰입도를 증가시킨다. 또한 좋은 스토리는 사람들을 끌어들이고 게임 내 행동의 동기를 유발시킨다. But, 좋은 설정과 스토리로 게임과 어떻게 연관시키느냐가 중요하다.

2) 게임이 전부는 아니다.
ex)
 - 파이널판타지와 같은 경우를 예를 들어보자. 사용자들은 파이널판타지를 플레이하면서, 기획자가 의도한대로 따라가더라도, 혹은 반대로 진행하더라도, 같은 목적을 두고 이 게임을 구입했을 수도 있다. 그래픽에 대한 퀄리티를 눈으로 즐긴다. 혹은 이 게임이 너무 재미있어! 라고 할 수 도 있겠지.

3) 게임이란 곧 게임플레이다.
- 시중에 판매되고 있는 게임들을 관찰해보면, 게임이란 다음 중 한 가지 이상의 목표를 달성하는 것을 목적으로 하고 있다는 것을 알 수 있다.
 1. 무언가를 모은다 (점수 내기 게임 등)
 2. 영토를 확보한다 (바둑을 비롯한 고전 게임들)
 3. 목적지에 먼저 도착한다 (경주형 게임)
 4. 방해물(적군)을 제거한다 (새로운 영역으로 가기 위해 방해요인들을 제거한다)
 5. 발견 (탐험이나 추론)
 6. 다른 플레이어를 쳐부순다

- 자신의 아이디어를 게임 기획서에 옮기기 전 살펴보자
 1. 게임의 목적은?
 2. 목적을 어떠한 방법을 통해 이루는가?
 3. 어떠한 형태로 플레이하게 되는가?
 4. 게임플레이를 만들어내기 위한 기본 요소는?

4) 게임 기획서의 작성
- 게임 기획서에서 반드시 짚고 넘어가야 할 사항들 5가지
 1. 게임 요소
 - 지금 만들고 있는 게임을 다른 게임들과 구분 짓는 특징
 2. 게임플레이
 - 게임 요소들이 어떻게 게임플레이를 만들어내는지에 대해 작성
  #게임플레이에 대해 쓰는 3가지 목적
  `1. 다른 개발자들에게 게임이 어떻게 동작하는지를 설명
  `2. 개발 기간 중 방향을 잡아주는 기초
  `3. 게임 요소 중 어떤 것이 필수 요소이고 어떤 것이 장식 요소인지를 구분하는 기준 제시 
 3. 인터페이스
 - 인터페이스의 존재 이유는 플레이어들의 게임 플레이를 도와주기 위한 것이다. 인터페이스는 누구나 만족할만한 인터페이스가 나오기 힘들고 그로 인해 끊임없는 시행 착오를 반복하는 수 밖에 없다.
 4. 규칙
 - 게임 요소에서 나아가 더욱 명확하고 의도했던 게임이 어떻게 돌아가는지 정해주는 것
 5. 레벨 디자인
 - 레벨 디자인은 게임 디자인의 가장 중요한 부분 중 하나. 레델 디자인의 차이에 의해 전혀 다른 게임이 될 수 있다는 사실을 명심하자.
 ex)
 - 하프 라이프는 퀘이크 엔진을 거의 그대로 사용했지만 전혀 다른 재미를 주고 있다.




'게임아키텍처디자인' 54p ~ 77p



Posted by 생선날개





게임의 정석이라 불리우는 '게임아키텍처디자인'

한번 파고들어보자.

일단 오늘은 '게임아키텍처디자인' Chapter.1 - 초기구상에서 핵심요소들만 정리해보자.



1. 개요문서(=컨셉기획서)
- 개요문서란 아직 제대로 된 기획문서가 아닌 대여섯 장 분량의 짧은 문서로써 게임의 기본적인 컨셉을 전달하기 위한 것이며, 무엇보다도 어떤 느낌의 게임을 만들려고 하는지에 대해 게임 디자이너가 생각한 것을 다른 사람들에게 설명하는 역할을 한다.

1) 새로운 것의 놀라움
- 새로운 발상을 얻고 싶다면 남들이 좀처럼 하지 않는 일을 하자.

ex)
- 갑작스럽게 백과사전을 뒤져보자
- 오페라 구경을 해보자
- 피레네 산맥에서 산행을 해보자
- 영화 감독 '이안 리'는 모래와 돌로 되어있는 자신의 정원에서 영감을 얻는다


2) 창조적인 로드맵
- 창조적인 새로운 일을 시작하는 데에는 세 가지 기술이 필요하다. "독창성, 기능, 기교"
- 게임을 만드는 경우에는 위와 같지만 이 단계들을 "컨셉, 구조, 디자인" 이라고 한다.

ex)
- 아침에 일어났을 때 전쟁과 평화를 기초로 한 게임 아이디어가 생각났다. - 컨셉
- 컷 씬(Cut Scene)은 전쟁을 시작하기 전에 플래쉬백처럼 등장할 것이다. 이유는 게임의 줄거리를 심화시키는 것이 아니라 캐릭터의 배경 이야기를 조금씩 드러내고 게임의 분위기를 조성하기 위한 것이기 때문이다 - 구조
- 게임의 목적 구현, 게임을 하는 이유, 캐릭터가 어떤 행동을 취하게 할 것이다. - 디자인


3) 아이디어 구상하기
- 아이디어를 종이에 적기 전에 너무 서두르게 생각하지 말자. 무언가 망상이 생겼다면, 시간을 주고 아이디어가 무르익을 시간을 주도록 하자.
-창조적인 발상을 위한 4가지 단계

 1. 영감 - 아이디어를 얻는 것
- 아직까지 CRPG(Computer RPG)들은 1970년대의 던전 앤 드래곤(Dungeons and Dragons)의 게임 시스템에서 크게 벗어나지 못하고 있다.

ex)
- '메탈 오브 아너' 같지만 한국 전쟁이 배경입니다. 와 같은 안전한 모방작 들의 등장
- '해적선'이라는 소재와 '뱀파이어'를 조합한다면? 뱀파이어가 박쥐가 아니라 상어로 변신한다면?

 2. 종합 - 아이디어를 합치는 것
- 아이디어들을 섞어놓고 살펴보자. 각 아이디어들이 다른 아이디어에 어떤 도움을 줄 수 있는지

ex)
- 사람과 말이 합쳐진 켄타우로스
- 우주라는 장소와 뱀파이어라는 캐릭터의 만남으로 인한 드라큐라의 상황
(항상 어둡기 때문에 관속에 들어가지 않아도 된다. 혹은 항상 들어가야만 한다 등등)

 3. 공명 - 아이디어로부터 시너지를 만들기
-전체가 요소들의 집합보다 더 강한 호소력을 갖도록 만드는 방법 중의 하나.

 4. 수렴 - 구상하는 일을 끝내기
- 게임디자인의 기술적인 단계로 넘어가 이 아이디어가 실제 게임 안에서 실현 가능한지 점검해 볼 수 있어야 한다. 이런 좋은 분석적 판단력은 경험을 통해서만 터득할 수 있다.


4) 아이디어 발전시키기
 1. 스타일 - 게임의 스타일 결정 혹은 결합 (액션과 교육용의 결합 = 교육용 액션 게임)
 2. 줄거리 - 게임의 줄거리는 소설이 되어서는 안된다.
 3. 인물 - 인물설정
 4. 배경 - 울창한 숲, 전쟁으로 폐허가 된 황야. 플레이어들에게 이런 궁금증을 가지게 한다면, 이 게임에 끌어들이는 데 성공한 것이다.


5) 개요문서
- 첫 개요문서(컨셉기획서)를 쓸 때에는 가지고 있는 모든 아이디어를 무작정 적어 내려가자
- 일부로라도 기술적 사항을 생각하지 말고 적어가자.
- 프로그래머는 나무를 보느라고 숲을 보지 못하고, 게임디자이너는 숲을 보느라 나무를 보지 못한다.

6) 검토하기
 1. 분석
 - 자신의 게임 컨셉을 냉철하고 비판적인 안목으로 살펴보자
 - 게임의 장르는 무엇인가?
 - 이 게임 컨셉과 가장 비슷한 기존 게임에는 어떤 것이 있는가?
 - 기존의 게임과 이 게임이 비슷한 점은 무엇인가?
 - 기존의 게임과 이 게임이 다른 점은 무엇인가?

 2. 평가
 - 이 게임요소는 재미있을까? (핵심요소)
 - 이 요소가 전체 게임플레이에 재미를 더해줄까?
 - 왜 다른 게임들은 이 요소를 사용하지 않고 있는가?
 - 우리 회사의 제작팀이 이런 요소를 기술적으로 구현할 수 있을까?
 - 플레이어에 의해 조작가능한 요소일까? (키보드, 마우스, 컨트롤러 조작 가능한지)

7) 실현가능성
 1. 상업적 요인
 - 자신의 아이디어와 비슷한 게임이 출시되었는데도 그 아이디어를 밀고 나가 출시한다면 먼저 나온 게임을 Copy했다고 볼 수 밖에 없다.

 2. 기술적 요인
 - 회사 프로그래머가 자신이 생각한 요소를 구현하지 못한다면? 이런 일이 벌어질 거라는 예상을 미리 하고 계획을 잡아야 한다. 만약 절대로 만들어질 수 없는 게임이라면, 애초에 시작하지 말아야 한다.

 3. 개발과정에서 발생하는 문제
 - 각 단계에서 예상하지 못했던 이유로 버려야 할 게임 아이디어가 생기거나 예측하지 못한 요소들이 갑자기 생겨나기도 한다.

8) 검토하기




'게임아키텍처디자인' ~ 53p




 

Posted by 생선날개



 

Babyface - 9집 Playlist

얼마전, 친구에게서 메신저 메세지가 날라왔다,

'띠링 띠링'


자세히 보니,

메세지가 아니었다.


'파일전송 - Babyface 9th'

응?

babyface?



솔직히 들어보지도 못한 가수 이름이었기에,

거부반응을 일으키며 취소를 누르려는 순간!


"가을타는 너와 나의 운명을 가로지르는(?) 노래야"

라고 말하는 친구의 말에,

일단 한번 들어보기로 했다.


 

시작부터 울리는 기타 소리,

왠지 빠져들게 된다.




앨범 구성은

1.Shower The People
 2 Fire And Rain
 3 Not Going Nowhere
 4 Time In A Bottle
 5 Wonderful Tonight
 6 Knockin' On Heaven's Door
 7 Longer
 8 The Soldier Song
 9 Please Come To Boston
 10 Diary

이렇게 총 10곡


보통,

적어도,

나는 그렇다.


같은 목소리,

같은 악기소리를,

몇시간 동안 들으면 질린다고.



하지만 Babyface같은 경우는 조금 달랐다.

흑인이라 강한 음색일거라는 나혼자만의 고정관념을 깨버린

부드럽고 감미로운 목소리와, 기타소리가 어울려

나만의 계절같은 가을을 잡아주는것 같은 느낌.


그리고 괜시리

다시한번 'August Rush' 안의 어거스트의 부드럽고도 강렬한,

기타음색이 그리워 보고싶게 만든다.


물론 10곡 모두 부드럽게 내 귀를 타고 흘러 가지만,

7. Longer와, 10. Diary는 아침에 들으면

기분좋은 하루를 보내줄것 같은 느낌이다.





Posted by 생선날개


[엔터1팀_4주차 개인미션 - 장훈석]

Daum 영화 포토존.

많은 사용자들에겐 익숙하지 않은 이름이다.

이름만 들어보면,

'그냥 단지 영화에 관련된 이미지 페이지?'

정도로만 생각된다.


하지만 그렇게 생각하면 오산

함께 Daum 영화 포토존을 파고들어가보자.



일단 메인화면에 들어가보면

가장 먼저 눈에 확 들어오는

'테마가 있는 Photo' 이다.


다른 포털 영화 이미지 페이지처럼 단순한 이미지 제공이 아니다.

비vs강동원

즐거운주말 신나는 파티!!

등등 클릭을 하지 않을 수 없는 이 묘한 끌림은 뭘까.



확실히 들어가자마자

Daum 영화 포토존의 많은 변화가 일어났고,

많은 세세한 신경을 썼다는 것을 느낄 수 있었다.


또한 각 테마별로 나뉘어진 영화 포토존은,

많은 주제를 세세하게 분류시켜놓았고,



사용자들이 영화속 원하는 테마의 느낌 그대로의 이미지를

각 종류별로 유지시켰다는 점은 매우 새롭게 보인다.






하지만,

간간히 보이는 그리 썩 좋지 않은 화질의 이미지 제공,


메인화면과 테마가 있는 포토존만 바뀌었을뿐

변하지 않는 아래와 같은 실질적인 사진 보기 형식의 불편함은,

그대로 유지하고 있었다.


내가 생각하는 개선점은,

위와 같은 형식의 이미지 보기 형식이 바뀌어야 한다고 보인다.



실질적으로 사용자들이 가장 사진을 편하게 보는 방식은,

이런 작은 이미지로 1차적으로 본 후에,

선택을 해서 클릭 하는 형식이라 생각된다.


하지만 위와 같이 너무 작은 이미지로 1차적으로 보게 되어,

어떤 이미지인지 불분명하고 판단하기 힘들다.


"개인적인 나의 느낌으론, 이런식으론 이미지 보기 싫어"

라는 느낌만 강하게 들었던 것 같다.


지금과 같은 형태 보단

아래와 같은 우측, 혹은 좌측에 있는 그다지 페이지 주제와 필요없는 메뉴들을 없애고, 




아래와 같은 이미지 레이아웃을 크게 그리고 많이 잡고,

사용자들이 보기 편하도록 하는 것이 가장 중요한 점일것 같다.





한 페이지에 많은 것을 넣는 것보다,

사용자들이 무엇을 바라고 그 페이지에 들어왔는지를 알고,

그 페이지에 확실하고 정확한 레이아웃이 있다면 좋겠다.

 




Posted by 생선날개