게임 제작 Chapter 31. Prototype 4: Prospector Solitaire - 1

Prospector Solitaire는 프럼프 카드를 이용한 게임으로 XML을 이용하여서 카드의 문장정보를 읽어와서 트럼프카드 모든그림을 저장하는것 보다 훨씬 경제적으로 구성할수 있게 해준다.

위 그림에서는 카드배경Sprite1개와 10 글자(Letter)2개 그리고 12개의 Spade문장(pip+decorator)의 배치가 XML파일에서 정의되어 있다.

XML파일의 정보를 불러오기 위해서 처음에 C#파일 3개를 만듭니다.

Card, Deck, Prospector를 만드는데 각각의 역할을 살펴보자면

Card : 덱에 있는 각각의 카드 정보를 담고 있습니다 CardDefinition(Sprite의 위치와 무슨종류의 카드인지) 클래스를 포함하며 Decorator (각각의 모양, 문자의 위치정보)클래스 포함

Deck : DeckXML의 정보를 불러옵니다 그리고 그안에 있는 카드의 정보를 불러옵니다.

Prospector : 전체적인 게임관리와 메세지 전달을 맡는다

이걸 플레이 해보면 

xml[0] decorator[0] type=letter x=-1.05 y=1.42 scale=1.25 

콘솔창에 이 문장이 뜨게된다. ReadDeck()의 XML에서 가져온 정보를 보여준다.

여기서 나온 직렬화(Serialize), XML에 관해서 살펴보면

먼저 객체의 직렬화는 객체의 내용을 바이트 단위로 변환하여 파일 또는 네트워크를 통해서 스트림(송수신)이 가능하게 하는것을 의미한다.

객체 전송의 단계

1) 직렬화된 객체를 바이트 단위로 분해한다. (marshalling)

2) 직렬화 되어 분해된 데이터를 순서에 따라 전송한다.

3) 전송 받은 데이터를 원래대로 복구한다. (unmarshalling)

직렬화가 가능한 객체의 조건

1) 기본형 타입(boolean, char, byte, short, int, long, float, double)은 직렬화가 가능

2) Serializable 인터페이스를 구현한 객체여야 한다.

3) 해당 객체의 멤버들 중에 Serializable 인터페이스가 구현되지 않은게 존재하면 안된다.

XML에 대해서 살펴보면

각각의 데이터를 종류별로 태그하고 계층적으로 분류한다 라고 써있는게 제일 쉬운말인거같은데 그냥 다른 여러 언어나 형식으로 이루어진 것들을 하나의 언어로 분류를 해서 서로서로 소통을 도와주는 언어라고 생각하는게 맞는거같다.

게임 인공지능 Chap.02 상태구동형 에이전트의 디자인 - 유한상태기계

유한 상태기계(FSM)은 인공지능 기법중 하나로 유한한 개수의 상태를 가지는 추상기계이다.

한번에 보통 하나의 상태(state)만을 가지며 어떤 사건(event),입력에 따라서 다른 상태로 전환(Transition)되거나 출력이나 액션이 일어나게 하는 장치 또는 기계이다.

AI프로그래밍에서는 이러한 방법을 많이 사용하는데 복잡한 행동을 간단하게 할수있고, AI의 행동과 외부 사건등을 동기화 하는데에 유용하다

FSM의 특징을 정리해보자

- 빠르고 코딩하기가 쉽다.
 FSM을 프로그래밍하는 방법은 많이 있으며 대부분 설치가 쉽다.

- 오류수정이 용이하다.
 행동들이 덩어리로 분할되기 때문에 잘못된 행동에 선행되는 사건들의 순서를 쉽게 따라  갈 수 있고 그에 따른 조치를 취할 수 있다.

- 계산 부단이 없다.
 코드화된 규칙들을 따르기 때문에 계산이 필요가없다.

- 직관적이다.
 그림으로도 그려서 나타낼수가 있기때문에 프로그래밍을 몰라도 이해하기 쉽다.

- 유연성이 있다.
 여러 간단한 조성을 통해서 (새로운 규칙을 추가시킨다거나) 행동의 범위를 간단하게 조절  할 수 있다.

이러한 FSM의 가장 간단한 형태로 책에서는 이러한 예시를 보여준다

켜짐(on)과 꺼짐(off)의 두 개의 상태를 가지고 있으며 상태들 간의 전환은 손가락동작에 의해서 이뤄진다.

FSM을 구현하기 위한 가장 간단한 방법은 switch, if-else를 사용하여 구현하는 것이다.

 그럴듯해 보이지만,  가장 간단한 게임 객체보다 조금이라도 더 복잡한 것에 적용해보면 이 방법은 헝클어진 구조가 되어버리고 프로그램의 흐름을 이해하기 어렵게 만들고 유연성도 없으며, 초기에 디자인한 범위 이상으로 확장하는 것이 쉽지않다.

그래서 책에는 또다른 방법을 제시하고 있다. 바로 상태전환표(state transition table)을 사용하여서 만드는 것이다. 이 표는 위에서 보여준 상태들과 조건들을 사상(mapping)하는 예이다.

에이전트는 이 표를 정기적으로 질의하여 상태를 전환 시킨다.
예를들어 만약 현재상태가 도망가기 이고 조건이 안전하다 이면 순찰하기로 전환해라
이런식으로 매 단계마다 표에 있는 모든규칙들을 조사해서 그에 따라 명령이 전달된다.
이러한 테이블은 에이전트 외부에 존재하며 (기본코드 + 상태전환표)라는 구조를 가진다.

이러한 방법이 더욱 진화된것이 책에서 나오는 내장된 규칙들을 이용하는 방법이다.
상태들 자신의 내부에 상태 전환을 위한 규칙들을 내장시키는 것이다.
이것을 비디오게임 환경에서 살펴보도록하면

 이런 구조는 상태 디자인 패턴으로 알려진 것으로, 상태구동형(state-driven)행동을 구현화한다. 직관적이고 코딩하기 간단하며 확장이 용이하다. Enter와 Exit메소드를 생성하고 그에따라 에이전트의 ChangeState메소드를 조정하는 일뿐이다.