www.I-stew.com

리그오브레전드(League of Legends)만의 독특한 상용화 전략

WinterMute — Thu, 09 Feb 2012 19:50:57 +0900

1. 1. 서문

최근 미국에서도 Free to Play가 유행처럼 번지고 있다. 무료로 게임을 즐기라고 명시하긴 했지만 당연히 수익구조는 따로 존재한다. 부분유료화 방식을 취하고 있는 것이다. 이러한 과금 방식이 기존의 정액요금제보다 많은 유저를 끌어 모을 수 있고 보다 많은 수익을 올린다는 것을 보여주면서 많은 게임들이 부분유료화 요금제로 바뀌어가고 있는 실정이다.

그러나 부분유료화 요금제의 문제점으로 항상 지적되는 부분들이 있었다. 그 중 하나가 유저간의 밸런스 문제다. 게임을 서비스하는 입장에선 무료로 즐기는 플레이어보다 돈을 낸 플레이어에게 더 이익이 되는 무언가를 보상해야 한다. 대체로 이러한 보상은 좀 더 우월한 능력치, 성장속도 등으로 이어진다. 이에 비해 무료로 즐기는 플레이어는 상대적인 박탈감을 느끼고, 유료 플레이어로 전환하거나 게임을 이탈한다. 때문에 게임을 즐기는 플레이어 수가 줄어들게 되고 이러한 감소세에 따라 게임의 수명이 단축되는 결과를 낳는다.

이러한 문제점은 부분유료화 정책이 갖는 피할 수 없는 해악으로 인식되어왔다. 그러나 몇몇 게임을 중심으로 이러한 틀을 깨기 시작했다. 블리자드의 와우(World of Warcraft)가 대표적인 예다. 이들은 정액요금제를 취하고 있음에도 불구하고 별도로 펫이라는 아이템을 팔았다. 펫은 단순한 장식용으로 자신이 감상하거나 남들에게 보여주는 용도로 밖에 사용할 수 없다. 기존의 유료화 아이템하고는 확연히 다른 차이였다.

그렇다고 하더라도 와우는 정액요금제를 통해 지속적인 수익을 올릴 수 있었다. 그러나 리그오브레전드(League of Legends)가 나타나면서 색다른 부분유료화 정책을 보여주었다. 리그오브레전드는 부분유료화 정책을 취하면서도 게임에 영향을 미치지 않는 아이템만을 판매하여 수익을 올리고 있다. 돈을 내지 않아도 게임을 즐기는 데는 전혀 무리가 없다. 유료화 아이템을 샀다고 해서 딱히 다른 플레이어보다 유리한 위치에 서는 것도 아니다. 그러나 유료화 아이템은 분명 잘 팔리고 있다. 수익만 보아도 알 수 있다. 이 게임으로 벌어들인 수익은 이미 연간 20억을 넘긴 것으로 추정되고 있다.[1]

분명, 보기 힘든 이변이다. 아무런 득이 되지 않을 법한 아이템을 돈을 주고 산다는 생각이 선뜻 들지 않기 때문이다. 그래서 이번 분석을 통해 어떻게 리그오브레전드가 유료아이템을 판매하는데 있어 어떠한 정책을 취하고 있고, 어떠한 방식으로 구매를 유도하는지 살펴 볼 생각이다.

2. 2. e스포츠의 특성

리그오브레전드는e스포츠 시장을 고려하여 제작되었다. e스포츠를 고려한 흔적은 게임 곳곳에서 보인다. 우선 매치 메이킹 시스템을 들 수 있다. 공평한 매치를 위해 레벨과 승률에 따라 게임을 붙여준다. 상대를 플레이어 임의로 정하는 것이 불가능하며, 게임 시작 전 까지 상대플레이어를 알 수 없다. 때문에 승률 어뷰징 또한 불가능하다. 따라서 최대한으로 공평한 경기를 진행할 수 있다. 경기가 끝난 뒤에는 통계를 제공한다. 이를 통해 플레이어는 자신의 경기내용을 수치를 통해 분석할 수 있다. 이러한 요소들이 게임을 하나의 스포츠로써 즐기게끔 하는 요소다.

<경기 종료 후, 경기의 내용을 분석할 수 있도록 통계를 제공한다.>

리그오브레전드의 e스포츠 대회 또한 곳곳에서 열리고 있다. 세계적인 e스포츠 대회인 WCG에선 2010년에 프로모션 경기로 선정되었고, 2011년에 공식경기로 채택되었다. 이처럼 리그오브레전드는새로운 e스포츠 종목으로 주목 받고 있다.

하나의 스포츠를 지향하는 만큼 게임의 공정성은 필수적으로 갖추어야 할 요소일 것이다. 그렇기 때문에 유료화 아이템을 기획하는데 있어서도 공정성을 해치는 요소를 넣어서는 안 된다. 리그오브레전드는 게임 공개 때부터 지금까지 서비스해오면서 그 기준을 명확히 지켜가고 있다.

3. 3. 판매 아이템

리그오브레전드의상용화 구조는 다른 게임들과 크게 다르지 않다. 리그오브레전드에서 화폐는 두 가지 종류가 있다. IP(Influence Point)와 RP(Riot Point)이다. IP는 게임 플레이를 통해 얻을 수 있는 화폐다. 반면에 RP는 현금으로 구매할 수 있는 게임화폐다. RP를 지불하여 상용화 아이템을 구매할 수 있다. 게임내의 상점페이지에서 아이템을 구매할 수 있다. 아이템마다 IP가격과 RP가격이 따로 공시되어있으며 RP로만 구매할 수 있는 아이템도 있다. 상점에서 구매할 수 있는 아이템 목록은 다음과 같다.

아이템 종류	IP 구매가능여부	RP 구매가능여부
챔피언	O	O
챔피언 스킨	X	O
룬	O	X
IP/XP 부스터	X	O
세트	X	O
추가 룬 페이지	O	O
소환사 이름 변경	X	O

여기서 주목할만한 부분은 룬을 RP로 구매할 수 없다는 부분이다. 룬은 경기 내 캐릭터가 받는 능력치를 향상해주는 효과를 가지고 있다. 그렇기 때문에 게임 아이템 중에서 유일하게 밸런스를 망가뜨릴 수 있는 요소가 될 수 있다. 그러나 룬의 능력들은 큰 차이를 보여주지 않는다. 레벨20이 되면 최고레벨의 룬을 장착할 수 있다. 룬의 능력치 향상효과도 눈에 띌 정도로 나타나는 것은 아니다. 게임의 특성상 플레이어의 컨트롤과 플레이어간의 협동이 승패에 가장 중요한 요인으로 작용하기 때문에 룬이나 챔피언의 차이로 졌다는 생각은 좀처럼 들지 않는다.

룬의 차이로 졌다고 해도 현금 구매로 바로 가질 수 있는 것이 아니다. IP로만 구매할 수 있기 때문에 플레이타임은 자연스럽게 연장된다. 현금구매로 좀더 쉽게 구매하고자 한다면 유일한 선택은 IP부스터를 구매하는 방법뿐이다. 그렇다고 하더라도 경기를 통해 IP를 벌어야 하는 것은 변하지 않는다. IP를 얻기 위한 시간이 약간 줄어들었을 뿐이다.

챔피언의 경우에도 굳이 현금으로 구매하지 않아도 된다. 챔피언은 경기 내에서 플레이어가 조종할 캐릭터이다. 챔피언의 종류에 따라 플레이 스타일과 사용할 수 있는 스킬이 변화한다. 하지만 비싼 챔피언이라고 해서 더욱 강력한 능력치를 가진 것은 아니다. 모든 챔피언은 모두 동등한 능력치를 갖고 있으며, 플레이어의 컨트롤에 의해 그 빛이 발한다. 챔피언의 가격이 매겨지는 방식을 보면 최신에 나온 챔피언일수록 비쌀 뿐이다.

경기에 직접적으로 영향을 미치지 않는 챔피언 스킨이나 부스터 같은 아이템은 현금으로만 구매할 수 있게 되어있다. 즉, 현금을 지불하여 아이템을 구매하더라도 무료이용자들보다 유리한 위치에 서는 것은 아니라는 말이다.

이러한 상황을 종합해봤을 때, 리그오브레전드에서는 <많은 구매 = 유리한 게임> 이라는 공식이 적용되지 않는다. 이러한 아이템판매 정책으로 무료이용자의 이탈을 예방하고 있으며, 현금구매를 통한 플레이타임 단축현상을 최소화 하고 있다.

4. 4. 판매전략

리그오브레전드에서는계속해서 플레이어의 기회비용을 노출시킨다. 여기서 말하는 기회비용이란 플레이어가 현금구매를 했을 때의 기회비용이다.

리그오브레전드에서는경기를 시작하기 전에 사용할 챔피언을 선택한다. 챔피언을 선택한 다음에는 화면 중앙에 챔피언 스킨을 선택할 수 있도록 나온다. 물론 현금으로 스킨을 구매하지 않은 플레이어는 기본스킨밖에 사용할 수 없다. 그럼에도 불구하고 사용할 수 없는 스킨이 무엇인지 노출시켜준다. 스킨에 따라 캐릭터 일러스트가 변화한다. 일러스트는 다른 플레이어와 판박이인 챔피언보다 자신의 개성을 드러낼 수 있는 스킨을 고르라며 유혹한다. 리그오브레전드의 스킨은 단순히 일러스트와 캐릭터의 텍스쳐만 변화시켜주는 것이 아니다. 비싼 스킨일수록 챔피언의 애니매이션이나 스킬 이펙트가 변화하기 때문에 다른 판박이 캐릭터들과는 확실히 다른 인상을 심어준다.

<선택할 수 없는 스킨을 계속 지켜봐야한다.>

경기종료 후에 플레이어는 IP와 XP를 획득한다. 일반적인 게임들은 자신이 획득한 IP가 얼마인지만 표시할 것이다. 그러나 리그오브레전드에서는 IP부스터를 구매했을 때 추가로 받을 수 있는 IP를 표시해준다. 게다가 모든 플레이어는 게임 시작부터 9레벨까지 공짜로 IP부스터 효과를 받는다. 이미 IP부스터 경험이 있었던 플레이어는 그 유혹에 보다 쉽게 넘어간다.

<얻지 못할 IP를 괜히 보여주는 건 아닐 것이다.>

게임을 켜고 로그인을하면 시작화면부터 화면 중앙과 우측 하단에 공지배너가 있다. 공지배너는 게임의 주요공지사항을 알려줄뿐만 아니라, 새로운 챔피언 광고나 세일광고도 띄운다. 이공지배너는 게임의 시작점이 되는 화면중앙에 위치하고 있기 때문에 플레이 하는 내내 지속적으로 노출된다. 많은게임들이 홈페이지의 로그인 페이지에만 광고배너를 띄우는 것과는 대조적이다.

<제일 잘보이는 위치, 제일 자주 보는 화면에 커다란 배너가 있다.>

리그오브레전드에서는꾸준히 세일이벤트를 진행한다. 물론, IP가격은 그대로이고현금가인 RP만 할인하여 판매한다. 세일판매품목은 챔피언과챔피언 스킨이다. 세일기간을 두어 그 동안 눈 여겨 봐왔던 챔피언과 스킨을 구매하도록 유도하는 것이다.

5. 5. 결론

라이엇게임즈의브랜던 벡 대표는 한 인터뷰에서 다음과 같이 말했다. “플레이어를 가장 우선으로 두겠다.”[2] 이한마디에 리그오브레전드의 상용화 전략이 요약된다. 플레이어에게 부담감을 지우지 않으며 존중 받는다는느낌이 들도록 서비스 하겠다는 것이다. 이를 위해 플레이어간에 불공평해질 수 있는 요소는 최대한으로배제했다고 볼 수 있을 것이다.

리그오브레전드의상용화 정책 기준은 다음과 같이 요약될 수 있다.

1) 현금으로 구매할 수 있는 아이템은 경기에 영향을 미치지 않는다.

2) 게임 내 능력치 영향을 줄 수 있는 유일한 아이템은 룬이다.

3) 룬은 IP를 통해서만 구매할 수 있으며, 이를 통해 사용자의 플레이를 유도한다.

4) 유료화 아이템으로 인해 플레이타임이 현저히 줄어서는 안 된다.

5) 최근에 발매한 챔피언, 스킨일수록 비싼 가격을매긴다.

이러한 정책은 게임오픈 이래 꾸준히 이어져 오고 있으며, 앞으로도 계속해서 유지될 것으로 보인다. 유료 아이템 판매 촉진을 위해 UI적으로 신경을 쓴 부분도 주목 할만 했다. 리그오브레전드는 지속적으로 유료아이템을 구매했을 때의 기회비용을 노출시켰다.

하지만 상용화 아이템의 매력이 감소하는 만큼, 수익도 그렇게 높은 편이 아닌 것은 분명하다. 세계적으로 순위권 안에 드는 게임임에도 불구하고 국내 유명한 부분유료화 게임들의 수익만큼은 못 내고 있다.

[3]

분명히 이용자 수에 비해 수익은 적다. 하지만 리그오브레전드는 기존의 부분유료화 정책에서 역으로 접근하였다. 부담 없는 유료화 정책으로 보다 많은 팬 층을 거느리게 되었다고 할 수 있다. 수많은 팬들을 상대로 OSMU를 활용한 판매전략을 내세울 수도 있을 것이며, 이 경우 2차적으로 부가가치를 낳게 될 것이다.

리그오브레전드는다른 부분유료화 게임들과는 조금 다른 방향으로 진행하고 있다. 이 때문에 오히려 걱정하는 유저도 있다. 그렇게 팔아서 뭐가 남느냐는 것이다. 하지만 리그오브레전드를서비스하는 라이엇게임즈(Riot Games)는 꾸준히 성장하고 있으며 주목 받는 디지털 기업이기도 하다. 리그오브레전드의 매출은 크지 않지만, 짧은 시간 안에 세계적으로 많은 팬을 거느린 게임이 되었다. 그렇기 때문에 앞으로 이러한 정책이 더욱 성공할지는 계속해서 지켜봐야 할 것이다.

[1] http://www.manta.com/c/mtxc7fs/riot-games-inc

[2] http://www.mud4u.com/gnews/news_view.php?mc=journal&sc=interview&seq=43049

[3] http://www.kocca.kr/knowledge/trend/stats/__icsFiles/afieldfile/2011/07/05/HnZ3LFz25HO5.pdf

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[OOP] 추상 팩토리 패턴

planar210 — Wed, 02 Feb 2011 23:16:53 +0900

추상 팩토리 패턴을 알아볼 시간인데요, 팩토리 메소드 패턴을 설명할 때 사용했던 피자 프랜차이즈 사업의 사례를 계속 이용해 보겠습니다.

사업이 나날이 번창하면서 사장은 이윤을 극대화시키기 위해 피자의 원재료를 본점에서 직접 공급하기로 결정했습니다. 그동안 피자의 원재료는 각 지점마다 따로 구입해서 사용했지만 원재료를 본점에서 공급하면 보다 안정적인 가격과 품질을 보장할 수 있을 것 입니다. 문제는 각 지점마다 지역 소비자의 기호에 맞는 피자를 만들어야 하기 때문에 같은 레드 소스라도 LA 지점 레드 소스와 뉴욕 지점 레드 소스가 다르다는 점 입니다. 어떻게 하면 이 문제를 해결할 수 있을까요?

먼저 제품군(Product Familiy)에 대한 개념부터 알아보겠습니다.
제품(Product)이 여러 개가 있고, 각 제품들은 또 다시 여러 종류로 나뉠 때 같은 종류의 제품들을 모아놓은 것을 제품군이라고 합니다.
피자를 예로 들면, 피자는 도우, 소스, 토핑, 치즈 같은 제품으로 이루어져 있고 LA 풍 피자와 뉴욕 풍 피자 같은 제품군으로 나뉘어집니다. 다시말하면 LA 풍 제품군은 LA 풍 도우, LA 풍 소스 등의 제품으로 이루어져있고, 뉴욕 풍 제품군은 뉴욕 풍 도우, 뉴욕 풍 소스 등의 제품으로 이루어져있겠죠.
그러면 각각의 제품을 추상화하고 제품의 생성 과정을 앞서 배웠던 팩토리 메소드 패턴을 이용해서 캡슐화 해봅시다.
(이 글에서 사용되는 코드는 모두 의사 코드 입니다.)

class Dough
{
public:
	virtual ~Dough() = 0;
};

Dough::~Dough() {}

class Sauce
{
public:
	virtual ~Sauce() = 0;
};

Sauce::~Sauce() {}

class Topping
{
public:
	virtual ~Topping() = 0;
};

Topping::~Topping() {}

class Cheese
{
public:
	virtual ~Cheese() = 0;
};

Cheese::~Cheese() {}

class ThinDough: public Dough {};
class ThickDough: public Dough {};

class TomatoSauce: public Sauce {};
class MarinaraSauce: public Sauce {};

class VeggieTopping: public Topping {};
class ClamsTopping: public Topping {};

class MozzarellaCheese: public Cheese {};
class ReggianoCheese: public Cheese {};

class PizzaIngredientFactory
{
public:
	virtual Dough* CreateDough() = 0;
	virtual Sauce* CreateSauce() = 0;
	virtual Topping* CreateToppings() = 0;
	virtual Cheese* CreateCheese() = 0;
};

class LaPizzaIngredientFactory: public PizzaIngredientFactory
{
public:
	// LA 풍 피자(제품군)에 맞는 원재료(제품)를 생성 합니다.
	virtual Dough* CreateDough() { return new ThinDough; }
	virtual Sauce* CreateSauce() { return new TomatoSauce; }
	virtual Topping* CreateToppings() { return new VeggieTopping; }
	virtual Cheese* CreateCheese() { return new MozzarellaCheese; }
};

class NyPizzaIngredientFactory: public PizzaIngredientFactory
{
public:
	// 뉴욕 풍 피자(제품군)에 맞는 원재료(제품)를 생성 합니다.
	virtual Dough* CreateDough() { return new ThickDough; }
	virtual Sauce* CreateSauce() { return new MarinaraSauce; }
	virtual Topping* CreateToppings() { return new ClamsTopping; }
	virtual Cheese* CreateCheese() { return new ReggianoCheese; }
};

원재료 공장을 만들었으니 기존의 피자 가게에 공급만 하면 되겠네요.

class PizzaStore
{
public:
	Pizza* Order(const std::string& pizzaName)
	{
		Pizza* pizza = CreatePizza(pizzaName);

		pizza->Prepare();
		pizza->Bake();
		pizza->Cut();
		pizza->Box();

		return pizza;
	}

	PizzaStore(PizzaIngredientFactory* pizzaIngredientFactory)
		:	m_PizzaIngredientFactory(pizzaIngredientFactory) {}

protected:
	PizzaIngredientFactory* m_PizzaIngredientFactory;

private:
	virtual Pizza* CreatePizza(const std::string& pizzaName) = 0;
};

이제 각 지점에서는 피자를 만들 때 원하는 원재료를 얻을 수 있습니다.

class LaPizzaStore: public PizzaStore
{
private:
	Pizza* CreatePizza(const std::string& pizzaName)
	{
		Pizza* pizza = NULL;

		if (pizzaName == "LA 치즈 피자")
		{
			pizza = new LaCheesePizza(m_PizzaIngredientFactory);
		}
		else if (pizzaName == "LA 페퍼로니 피자")
		{
			pizza = new LaPepperoniPizza(m_PizzaIngredientFactory);
		}
		else if (pizzaName == "LA 야채 피자")
		{
			pizza = new LaVeggiePizza(m_PizzaIngredientFactory);
		}

		return pizza;
	}
};

도우에다 소스를 바르고 토핑과 치즈를 얹는 일련의 작업들은 피자 객체의 Prepare() 메소드에서 이루어집니다.
자, 그럼 뉴욕 풍 치즈 피자가 어떻게 만들어지는 지 한 번 볼까요?

class NyCheesePizza: public Pizza
{
public:
	virtual void Prepare()
	{
		Dough* dough = m_PizzaIngredientFactory->CreateDough();
		Sauce* sauce = m_PizzaIngredientFactory->CreateSauce();
		Topping* topping = m_PizzaIngredientFactory->CreateToppings();
		Cheese* cheese = m_PizzaIngredientFactory->CreateCheese();

		// 준비된 재료로 피자를 굽기 좋게 준비
		// ...
		// ...

		std::cout << "NY 치즈 피자 준비" << std::endl;
	}
	virtual void Bake() { std::cout << "NY 치즈 피자 굽기" << std::endl; }
	virtual void Cut() { std::cout << "NY 치즈 피자 자르기" << std::endl; }
	virtual void Box() { std::cout << "NY 치즈 피자 포장" << std::endl; }

	NyCheesePizza(PizzaIngredientFactory* pizzaIngredientFactory)
		:	Pizza(pizzaIngredientFactory) {}
};

int main()
{
	NyPizzaIngredientFactory nyPizzaIngredientFactory;
	
	NyPizzaStore nyPizzaStore(&nyPizzaIngredientFactory);

	Pizza* pizza = nyPizzaStore.Order("NY 치즈 피자");

	return 0;
}

추상 팩토리 패턴이 가지는 장점은 팩토리 메소드 패턴과 동일합니다.
객체의 생성 과정을 캡슐화해서 클라이언트(코드 사용자 혹은 접근 영역의 코드 그 자체)가 객체의 구성이나 표현 방식에 의존적이지 않도록 만들어 줍니다. 다시말하면 객체의 생성 방식이나 종류가 바뀌더라도 클라이언트는 그 것에 대해 신경 쓸 필요가 없다는 뜻이죠. '수정이 예상되는 부분의 국지화' 팩토리 메소드 편에서 말씀드렸었죠?

추상 팩토리 패턴이 가지는 또 하나의 장점은 바로 제품과 제품군을 다룰 때 굉장히 편리하다는 점 입니다.
일단 제품군들이 실수로 섞여서 사용될 일이 자연스럽게 방지 되고, 각 제품군 간의 교체도 쉽습니다.
제품과 제품군이 팩토리 메소드 패턴과 추상 팩토리 패턴을 구분 짓는 핵심어라고 생각하시면 되겠네요.

참고/인용: Head First Design Patterns, GoF 디자인 패턴! 이렇게 활용한다

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[OOP] 팩토리 메소드 패턴

planar210 — Wed, 02 Feb 2011 23:14:37 +0900

팩토리 메소드는 객체 생성을 대행해주는 메소드를 말합니다.

그냥 선언하거나 new 하면 되는 것을 그딴 걸 대체 왜 대행하냐 싶지만 때로는 객체 생성 과정이 복잡한 애들도 종종 있습니다. 어떤 때는 그 과정이 너무 복잡해서 신경쓰기도 싫어질 때가 있는데, 바로 이 때문에 대행해주는 애가 필요한 거죠. OOP 기초 공부할 때 골백번도 더 들은 얘기지만 들을 때마다 뜬구름 잡는 소리 같았던 정보 은닉(Infomation Hiding)이란 것이 바로 이 건가 봅니다.

구현 상세를 객체 내부에 숨기는 것.
누구로부터? 클라이언트(코드 사용자 혹은 접근 영역의 코드 그 자체)로부터.
왜? 클라이언트는 그런 거 신경쓰지 않는 것이 좋으니까.

객체 내부의 수정에 대해 일일이 신경쓰지 않아도 된다는 말은 그 만큼 수정이 국지화 되었다는 뜻이고 수정이 국지화 되었다는 것은 수정에 대한 비용이 작아졌다는 뜻이죠. 이 것이 객체 지향 설계의 가장 핵심적인 접근 방법이자 모든 디자인 패턴의 목적입니다.

그렇다면 팩토리 메소드 패턴의 경우에는 어떻게 그 목적을 이루게 되는 것인가가 오늘 알아볼 내용인데 일단 사례부터 살펴보겠습니다.
역시 Head First Design Patterns 에 나와있는 예제를 인용하겠습니다.

여러분은 지금 막 개업한 LA 피자 가게의 총괄 관리자 입니다. 사장은 여러가지 피자를 팔려고 하고있는데, 일단 피자 가게의 규모가 그리 크지 않으므로 치즈, 페퍼로니, 야채 이렇게 세가지 메뉴만 판매할 겁니다. 모든 피자는 준비(소스와 토핑 얹기), 굽기, 자르기, 포장 이라는 동일한 작업 과정을 거치게 됩니다. 그럼 추상화를 해볼까요?
(이 글에서 사용되는 코드는 모두 의사 코드 입니다.)

#include <iostream>
#include <string>

class Pizza
{
public:
	virtual void Prepare() = 0;
	virtual void Bake() = 0;
	virtual void Cut() = 0;
	virtual void Box() = 0;
};

class CheesePizza: public Pizza
{
public:
	virtual void Prepare() { std::cout << "치즈 피자 준비" << std::endl; }
	virtual void Bake() { std::cout << "치즈 피자 굽기" << std::endl; }
	virtual void Cut() { std::cout << "치즈 피자 자르기" << std::endl; }
	virtual void Box() { std::cout << "치즈 피자 포장" << std::endl; }
};

class PepperoniPizza: public Pizza
{
public:
	virtual void Prepare() { std::cout << "페퍼로니 피자 준비" << std::endl; }
	virtual void Bake() { std::cout << "페퍼로니 피자 굽기" << std::endl; }
	virtual void Cut() { std::cout << "페퍼로니 피자 자르기" << std::endl; }
	virtual void Box() { std::cout << "페퍼로니 피자 포장" << std::endl; }
};

class VeggiePizza: public Pizza
{
public:
	virtual void Prepare() { std::cout << "야채 피자 준비" << std::endl; }
	virtual void Bake() { std::cout << "야채 피자 굽기" << std::endl; }
	virtual void Cut() { std::cout << "야채 피자 자르기" << std::endl; }
	virtual void Box() { std::cout << "야채 피자 포장" << std::endl; }
};

class PizzaStore
{
public:
	Pizza* Order(const std::string& pizzaName)
	{
		Pizza* pizza = NULL;

		if (pizzaName == "치즈 피자")
		{
			pizza = new CheesePizza;
		}
		else if (pizzaName == "페퍼로니 피자")
		{
			pizza = new PepperoniPizza;
		}
		else if (pizzaName == "야채 피자")
		{
			pizza = new VeggiePizza;
		}

		pizza->Prepare();
		pizza->Bake();
		pizza->Cut();
		pizza->Box();

		return pizza;
	}
};

int main()
{
	PizzaStore pizzaStore;

	Pizza* pizza = pizzaStore.Order("야채 피자");

	return 0;
}

사업이 번창해서 분점이 생겼습니다. 뉴욕에 지점을 차려야 하는데 문제는 LA 사람들과 뉴욕 사람들의 입맛이 조금 달라서 같은 치츠 피자라도 LA풍과 뉴욕풍으로 나눠서 만들어야 됩니다. 일단 생각나는 대로 해볼까요.

class PizzaStore
{
public:
	Pizza* Order(const std::string& pizzaName)
	{
		Pizza* pizza = NULL;

		if (pizzaName == "LA 치즈 피자")
		{
			pizza = new LaCheesePizza;
		}
		else if (pizzaName == "LA 페퍼로니 피자")
		{
			pizza = new LaPepperoniPizza;
		}
		else if (pizzaName == "LA 야채 피자")
		{
			pizza = new LaVeggiePizza;
		}
		else if (pizzaName == "NY 치즈 피자")
		{
			pizza = new NyCheesePizza;
		}
		else if (pizzaName == "NY 페퍼로니 피자")
		{
			pizza = new NyPepperoniPizza;
		}
		else if (pizzaName == "NY 야채 피자")
		{
			pizza = new NyVeggiePizza;
		}

		pizza->Prepare();
		pizza->Bake();
		pizza->Cut();
		pizza->Box();

		return pizza;
	}
};

뉴욕 지점에서 대체 왜 자신들이 LA풍 피자 만드는 법을 알아야하느냐고 항의가 들어왔지만 뭐 그리 큰 문제는 아니니 그냥 넘어갔습니다.
바로 다음 날 뉴욕 지점에서 자기네들이 개발한 '뉴욕풍 조개 피자'라는 신메뉴를 추가해주기를 원했습니다. 뭐 까짓거 추가해주지 하고 추가를 해줬는데 뭐가 잘못됐는지 피자가 엉망진창이 되서 나왔습니다. 문제는 뉴욕만 그런 것이 아니라 LA 지점 피자도 엉망진창이 되었습니다.
밤새도록 똥줄 타며 수정을 했더니 다음 날 사장이 와서 말했습니다. "시카고에 새로운 분점을 차릴 거야."

미칠 노릇이지만 짤리지 않으려면 PizzaStore 설계를 개선해야 합니다.
PizzaStorer 가 가지고 있었던 첫번째 문제는 쓸데없이 다른 지점의 피자를 만드는 법까지 알아야 된다는 점이었고 두번째는 수정에 대해 모든 지점이 영향을 받는다는 점이었습니다.

class PizzaStore
{
public:
	Pizza* Order(const std::string& pizzaName)
	{
		Pizza* pizza = CreatePizza(pizzaName);

		pizza->Prepare();
		pizza->Bake();
		pizza->Cut();
		pizza->Box();

		return pizza;
	}

private:
	virtual Pizza* CreatePizza(const std::string& pizzaName) = 0;
};

class LaPizzaStore: public PizzaStore
{
private:
	virtual Pizza* CreatePizza(const std::string& pizzaName)
	{
		Pizza* pizza = NULL;

		if (pizzaName == "LA 치즈 피자")
		{
			pizza = new LaCheesePizza;
		}
		else if (pizzaName == "LA 페퍼로니 피자")
		{
			pizza = new LaPepperoniPizza;
		}
		else if (pizzaName == "LA 야채 피자")
		{
			pizza = new LaVeggiePizza;
		}

		return pizza;
	}
};

class NyPizzaStore: public PizzaStore
{
private:
	virtual Pizza* CreatePizza(const std::string& pizzaName)
	{
		Pizza* pizza = NULL;

		if (pizzaName == "NY 치즈 피자")
		{
			pizza = new NyCheesePizza;
		}
		else if (pizzaName == "NY 페퍼로니 피자")
		{
			pizza = new NyPepperoniPizza;
		}
		else if (pizzaName == "NY 야채 피자")
		{
			pizza = new NyVeggiePizza;
		}

		return pizza;
	}
};

int main()
{
	LaPizzaStore pizzaStore;

	Pizza* pizza = pizzaStore.Order("LA 야채 피자");

	return 0;
}

팩토리 메소드 패턴을 이용한 피자 프랜차이즈 시스템이 완성되었네요. 피자 만드는 방법은 각 지점이 알아서 결정하기로 되어있기 때문에 자기 지점이 아닌 메뉴까지 알아야 되는 불편이 없어졌고, 한 지점에서 메뉴를 추가하다 실수를 한다고 해도 다른 지점에는 영향이 없도록 되어있습니다. 마찬가지로 시카고든 시애틀이든 새로운 지점을 차릴 때도 기존 다른 지점들은 신경 쓸 일이 전혀 없죠. 피자 만들기의 기본 틀(비가상 메소드)은 기본 클래스에서 제공하고 파생 클래스에서는 각 단계만 구현하기 때문에 일관된 공정으로 피자를 만들 수 있어 품질 관리에도 유리합니다.

기본 틀 제공, 각 단계만 구현. 어디서 많이 들어본 얘기 아닌가요? 맞습니다. 앞서 배웠던 템플릿 메소드 패턴이 품질 관리에 이용되었네요.
이렇듯 디자인 패턴을 이용하게 될 때는 여러가지 디자인 패턴을 혼합하는 형태로 적용하는 경우가 많이 있습니다. 그렇기 때문에 더더욱 정확한 이해와 응용력이 중요하죠.

다음 글에서는 또 다른 팩토리 패턴인 추상 팩토리 패턴에 대해서 알아 보겠습니다.

참고/인용: Head First Design Patterns, GoF 디자인 패턴! 이렇게 활용한다

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[게임 메이커] 간단한 슈팅게임 만들기 2

WinterMute — Thu, 12 Aug 2010 16:23:45 +0900

4. 총알을 만듭니다.

튜토리얼 리소스 폴더에서 총알을 선택합니다.
스프라이트의 원점을 중앙으로 하는 걸 잊지 맙시다.

총알 오브젝트를 생성하고, 방금 만든 스프라이트를 선택합니다.

주인공 오브젝트창에서 이벤트를 추가합니다.

주인공 비행기 오브젝트 창을 열고, 이벤트를 추가합시다.
키입력에서 총알 발사 버튼으로 쓸 버튼을 선택합니다.

액션에 메인1 탭에 있는 이동 오브젝트 생성을 끌어다 놓습니다.

오브젝트 칸에 총알 오브젝트를 선택하고,
속도는 10, 방향은 90으로 맞추어 줍니다.

디버그 모드로 실행시키고, 스페이스바를 누르면 총알이 나가는 것을 볼 수 있습니다.
이제 총알을 맞을 적을 만들어 봅시다.

5. 적 비행기를 만듭니다.

적 비행기 스프라이트를 등록하고,

적 오브젝트를 생성합니다.

적 오브젝트창에 충돌 이벤트를 추가합니다.

이벤트 추가에서 충돌을 선택하고, 충돌할 오브젝트로 총알 오브젝트를 선택합니다.

메인1 탭에있는 인스턴트 제거(쓰레기통 아이콘)액션을 끌어놓습니다.

자신을 선택하고 확인을 누릅니다.

룸 창을 열고, 적 오브젝트를 배치해봅시다.

이제 디버그 모드로 실행시켜 봅시다. 적이 총알을 맞으면 사라지는 것을 볼 수 있습니다.
하지만 게임에서 이대로 두면 너무나도 밋밋해 보입니다.
죽었을 때 폭발 이펙트를 추가해보도록 합시다.

6. 폭발 이펙트를 만듭니다.

폭발 오브젝트창에 애니메이션이 끝날시 이벤트 추가합니다.

기타 이벤트에 있는 애니메이션 끝날시를 선택합니다.

애니메이션 끝날시 이벤트에
<인스턴트 제거 액션>을 추가합니다.

적 오브젝트, 총알과의 충돌 이벤트에서 <오브젝트 생성 액션> 추가해봅시다.

오브젝트 생성 액션을 추가합니다.

생성할 오브젝트로 방금 만들었던 폭발 오브젝트를 선택하고,
현재기준에 체크합니다.

이제 디버그 모드로 실행시켜보면, 적이 죽을 때마다 폭발 이펙트가 나타나는 것을 볼 수 있습니다.
기본적인 슈팅게임의 구성을 갖추었습니다. 하지만 여전히 게임은 이상합니다.
주인공을 화면 바깥으로 몰고가면 화면 바깥으로 나가버립니다. 이를 막아보도록 합시다.

7. 주인공 비행기 화면 바운드 처리

주인공 오브젝트, 방향키 입력 이벤트에서 <변수체크> 액션을 추가를 합니다.

방향키 이벤트에 컨트롤 탭에 있는 변수체크 액션을 추가합니다.
좌표 점프 액션보다 위에 놓도록 합니다.

우선, Left 이벤트부터 추가해 보겠습니다.
변수: x, 값: 0, 설정: 초과 를 입력합니다.

이 말이 무슨 뜻이냐 하면, 주인공 비행기 오브젝트의 좌표 변수값인 x가 0보다 크면 아래의 액션을 작동시킨다는 말입니다.
즉, x좌표가 0보다 작아지면 아래 점프좌표 액션이 작동하지 않는다는 말입니다.

Up, Right, Down 이벤트에도 다음과 같이 추가해봅시다.

Up 변수체크 액션에는 위와 같이 설정합니다.

Right 변수체크 액션에는 위와 같이 설정합니다.
room_width는 이 오브젝트가 위치한 룸의 가로길이를 뜻하는 변수입니다.

Down 변수체크 액션에는 위와 같이 설정합니다.
room_height는 이 오브젝트가 위치한 룸의 세로길이를 뜻하는 변수입니다.

이제 주인공이 화면 바깥으로 나가지 않게 되었습니다.
하지만, 아까부터 주인공 총알이 쉬지 않고 나와, 레이저 빔 급의 파워를 가지고 있습니다. 이래서는 제대로 된 슈팅게임을 만들기 어렵겠죠?
이제 주인공의 총알 발사 속도를 조절해 봅시다.

8. 총알 발사 속도를 조절

주인공 오브젝트창에서 <생성될때>, <알람0> 이벤트추가해 봅시다.

주인공 오브젝트에 생성될때 이벤트와 알람0 이벤트를 추가하도록 합니다.
생성될때 이벤트는 오브젝트가 생성되면서 발생하는 이벤트이고,
알람0 이벤트는 우리가 임의대로 정한 타임에 맞추어 발생시키는 이벤트입니다.

생성될때 이벤트에 변수설정 액션을 추가합니다.
변수설정 액션은 컨트롤 탭에 있습니다.

위와 같이 설정하도록 합니다.
fire라는 변수에 true라는 값을 넣는다는 의미입니다.
fire는 우리가 임의로 만든 변수입니다. 앞으로 이 변수가 true값일 때만 총알이 발사하도록 만들 것입니다.
반대로 총알을 쏘지 못하는 경우, fire는 false값을 가지게 될 것 입니다.

총알을 발사하는 입력 이벤트 부분에 변수체크 액션을 맨 위에 추가합니다.
fire 변수가 true일 때만 총알을 발사해주기 위해 위와 같은 액션을 추가했습니다.

그 아래 변수설정 액션을 추가하고, 위와 같이 설정을 해줍니다.
alarm[0]은 알람0 이벤트 변수를 뜻합니다.
alarm[0]에 10를 설정한 것은
10프레임 후에 alarm[0] 이벤트를 실행시키겠다는 의미입니다.

alarm[0]변수는 1프레임마다 1씩 줄어듭니다. 그리고 alarm[0]변수가 0이되는 순간, 알람0 이벤트를 발생시킵니다.

게임메이커 기본설정 FPS(Frame Per Second)가 30으로 되어있으므로, 1초에 30프레임이니까.
1/3초 후에 alarm[0]을 실행시킨다는 말이 됩니다.

변수설정 액션을 추가하여 위와 같이 설정해줍니다.
fire변수에 false값을 넣어 계속해서 총알이 나가는 것을 방지해 줍니다.

시작 블럭과 앤드 블럭을 위와 같이 추가 해줍니다. 이 액션들은 컨트롤 탭에 있습니다.
시작 블럭과 앤드 블럭은 변수체크와 같이 쓰입니다.
변수 체크 액션에 작동하는 액션들을 묶을 때 위와 같이 씁니다.

즉, fire 변수 값이 true 일 경우, 블럭에 묶인 액션들을 실행시킨다는 의미입니다.

알람0 이벤트로 가서 변수설정 액션을 추가하고 위와 같이 설정 합니다.
알람0 이벤트가 발생하면 false 값이었던 fire변수를 true로 바꾸어 주겠다는 의미입니다.

이제 모두 완성되었습니다. 디버그 실행버튼을 눌러, 게임을 해봅시다!

이제야 제대로 된 슈팅게임 처럼 보입니다.하지만 적군들은 아직 움직이질 않습니다.
다음 시간에는 적군을 움직이고, 총알도 쏘는 간단한 AI를 넣어보도록 하겠습니다.

지금 까지의 예제 파일

shooting_ex.gmk

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[게임 메이커] 간단한 슈팅게임 만들기 1

WinterMute — Wed, 11 Aug 2010 22:25:22 +0900

준비물: 게임메이커8.0, 게임메이커 슈팅 튜토리얼
튜토리얼 다운 받는 곳 - http://www.yoyogames.com/downloads/tutorials/shooter.zip

이번에 만들어 볼 게임은 아주 간단한 슈팅게임 입니다. 슈팅게임을 만들면서 게임메이커의 기본 조작법을 익혀보도록 합시다.

1. 게임의 배경을 만들어 봅시다.
백그라운드 폴더에 마우스 커서를 데고 우클릭에서
<Create Background>를 선택하여 백그라운드를 생성합니다.

마음에 드는 이름으로 설정하고
열기를 누릅니다.

다운받은 튜토리얼 파일에서 바탕으로 쓸 그림파일을 열도록 합시다.

룸에 마우스를 데고 우클릭. <Create Room>을 선택하여 룸을 만듭시다.
룸은 게임의 스테이지와 같은 개념입니다.

왼쪽 상단에 있는 <백그라운드> 탭을 엽시다.

위의 버튼을 누르면 아까 등록한 백그라운드 이미지 목록이 뜹니다.
아까 등록한 백그라운드를 선택을 합시다.

수직속도 10으로 설정합시다.
수직속도는 수직으로 배경이 스크롤되는 속도를 말합니다.

위의 빨강색 화살표를 눌러봅시다.
이 버튼은 디버그 모드로 실행시켜 보는 것으로,
게임이 제대로 돌아가는지 실험해볼 때 사용합니다.

게임 화면이 뜨면서 배경이 스크롤 되는 모습을 볼 수 있을 겁니다.

2. 주인공이 될 비행기를 만듭니다.

이전과 마찬가지로 스프라이트에 마우스를 데고 우클릭한 후에
<Create Sprite>를 선택합니다.

스프라이트의 이름을 설정하고, 열기 버튼을 누릅니다.

튜토리얼 리소스 폴더에서 마음에드는 주인공 비행기를 선택합시다.

중앙 버튼을 눌러 원점을 중앙으로 맞춤니다.

스프라이트를 쓸 때 기본 좌표값은 스프라이트의
좌측상단(0,0)으로 되어있습니다.
이를 스프라이트의 중앙으로 맞추어주는 것입니다.

<Create Object>를 선택하여 오브젝트를 만듭시다.

다음과 같은 오브젝트 설정 창이 뜹니다.

이름을 설정하고, 아까 등록한 스프라이트를 선택합니다.

가끔 햇갈려 하시는 분들이 있는데,
오브젝트와 스프라이트는 별도의 개념입니다.

스프라이트는 단순히 겉포장지인 이미지일 뿐이고,
오브젝트가 진짜 주인공입니다.

오브젝트에서 모든 작동기제가 돌아갑니다.

아까 만든 룸을 열고, 오브젝트 탭을 엽니다.
생성에 아까 만든 주인공 기체를 선택합니다.

오른쪽 룸 화면에 클릭을 해봅시다.
주인공 비행기가 배치되는 것을 볼 수있습니다.

다시 디버그 모드로 실행시켜 봅시다.
스크롤 되는 배경 위에 주인공 기체가 떠있는 것을 볼 수 있습니다.
하지만 아직 키보드 조작을 설정하지 않았기 때문에 움직이지는 못합니다.

이제 방향키로 조작하여 움직이게 만들어 봅시다.

3. 키입력 이벤트를 추가합니다.

아까 만든 주인공 오브젝트 창을 엽니다.
여기에서 이벤트 추가 버튼을 눌러 봅시다.

위와 같은 창이 뜨는 것을 볼 수 있습니다.
이벤트는 해당 오브젝트가 어떠한 상황에 처했을 때,
어떠한 처리를 해줄 건지 설정해주는 것입니다.

입력시 버튼을 선택하고, 목록에서 맨 위에 화살표 입력을 모두 추가합니다.
화살표는 방향키 입력을 의미합니다.

키보드 방향키입력 이벤트를 모두 추가해주었으면, 오른쪽에 좌표 점프 액션을 추가해주도록 합니다.
좌표점프 아이콘을 액션 목록에 마우스로 끌어다 놓습니다.

다음과 같은 창이 뜰겁니다.
x는 이동할 x좌표값이고, y는 이동할 y좌표값입니다.

현재기준을 체크해주면 현재 오브젝트 좌표에서 설정해준만큼 이동하겠다는 의미입니다.

left키 는 x: -4
up키 는 y: -4
right키 는 x: 4
down키 는 y: 4
로 각각 설정해 줍시다.
(현재 기준 체크해주는 걸 잊지 맙시다!)

여기서 up키가 -4라는 데 의아해 하시는 분들이 있을 겁니다.
이는 윈도우 좌표계가 y축이 뒤집혀 있기 때문입니다.

다시 디버그 모드로 실행시켜 봅시다. 방향키로 주인공이 움직이게 되었습니다!
다음은 총알을 발사해보도록 할겁니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Game Maker 란?

WinterMute — Mon, 02 Aug 2010 14:37:59 +0900

<게임 메이커>는 <YoYo Games>에서 만든 게임 제작 툴입니다. 예전에 나왔던 게임만들기 툴인 '쯔꾸르'와는 달리 다양한 게임을 만들 수 있는 툴로 유명한데요, 2D게임은 물론이거니와 3D게임도 만들 수 있을 정도로 다양한 게임을 만들 수 있습니다.
프로그래밍을 몰라도 게임을 제작할 수 있고, GML이라는 자체 스크립트 언어를 지원하여 프로그래밍으로 게임을 제작할 수 도 있습니다.
이러한 장점 때문에 많은 아마추어 제작자들이 게임메이커를 사용하고 있고, 몇몇 유명 인디게임도 게임메이커로 제작되었습니다. 가장 유명한 예로는 제시 브룩스의 <카로시>라는 게임이 있겠습니다.

얼마나 다양한 게임을 만들 수 있는지를 보여주기 위해 동영상이 제작되기도 했는데요. 100개의 게임 메이커로 만들어진 게임을 보여주는 동영상입니다.

제가 게임 메이커에 대해 공부하고자 하는 이유는 혼자서 게임을 직접 만들어보자는 취지에서 입니다. 다른 사람의 도움없이 가장 쉽고 빠르게 게임을 만들 수 있는 제작환경을 제공하기 때문에 게임 메이커로 게임을 제작해보고자 합니다. 이에 따라 앞으로 게임메이커 관련 스터디 글을 올릴 생각입니다.

마지막으로 게임메이커를 공부하시는 분들이 가볼만한 사이트를 링크 걸어 둡니다.

•YoYo Games> http://www.yoyogames.com

YoYo Games 홈페이지 입니다. 게임 메이커를 다운로드 받으실 수 있고, 기본 튜토리얼 문서도 제공합니다.

게임 메이커로 만들어진 게임들도 다운받아 해보실 수 있습니다.

•게임 메이커 위키> http://gamemaker.wikicomplete.info/

게임 메이커의 자체 스크립트 언어인 GML에 대한 정보를 찾아볼 수 있습니다.

VisualStudio로 치면 MSDN정도로 볼 수 있겠습니다.

•네이버 카페 playgm>http://cafe.naver.com/playgm/

국내 유명 게임메이커 관련 커뮤니티 입니다.

한글로 된 강좌들이 모여있다는 게 가장 큰 장점입니다.

•네이버 카페 crazygm>http://cafe.naver.com/crazygm

국내 유명 게임메이커 관련 커뮤니티 입니다.

한글로 된 강좌들이 모여있다는 게 가장 큰 장점입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

마비노기 영웅전 포스트 모템

WinterMute — Sat, 29 May 2010 00:04:01 +0900

디스이즈게임즈에서 올라왔던 마비노기 영웅전 포스트 모템입니다.
꽤 예전에 올라왔던 건데, 글을 늦게 올리게 되네요..

보러가기>

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

온라인게임과 넥스트 젠 애니매이션

WinterMute — Thu, 08 Apr 2010 20:28:37 +0900

3D 애니매이션 프로그래밍에 관한 프레젠테이션입니다.
무엇보다도 프레젠테이션을 깔끔하게 잘만들었네요.

(http://ogblog.tistory.com/ 에서 보구 퍼왔습니다.)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

올 것이 왔습니다.

planar210 — Wed, 03 Mar 2010 00:42:45 +0900

가을 발매라고 하네요.

올 가을 가족, 친구, 연인들 잘 챙기고 인생 망가지지 않게 조심합시다.

http://www.civilization5.com

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Symphony of Heores 포스트 모르템 - 5부

WinterMute — Mon, 01 Mar 2010 17:47:06 +0900

11. 다가오는 마감 일

3차 프레젠테이션이 끝나고서는 개발할 수 있는 기간이 넉넉하지 못했다. 원래 목표대로라면 게임을 거진 완성하고 버그테스트를 하고 있어야 할 시기였다. 하지만 그 시기에 게임을 제대로 완성한 팀은 한 팀 밖에 없었다. 시간만 모자른게 아니었다. 슬슬 졸업준비를 해야될 시기였다. 이력서, 자기소개서등 제출해야할 문서들이 많았다. 한 업체에서 우리가 만들고 있는 게임이나 툴을 보기위해서 오기도 하였다. 좋은 사람이 있으면 신입으로 뽑아가겠다는 것이었다. 여러모로 어수선한 분위기였다.

이 시기가 되면, 으례 만사가 지치고 힘들어지고 짜증나기 쉽상이다. 나도 하는 일도 별로 없으면서 스트레스가 상당했다. 게임은 생각처럼 안 나오고, 나 혼자서 학원은 나오는 데(조교의 업무인 학원 지키는 일을 하기 위해 꼬박꼬박 밤까지 남아야 했다.) 팀원들은 남아서 작업도 안하고, 시간은 없는데 해야 될 일은 산 더미 처럼 쌓여있었다. 모든게 비관적으로 보였다.

또 하나 힘들었던 건, 옆 팀인 "Nine O'Clock"팀은 벌써 게임을 완성하고 제 할 일을 하고 있었다는 점이었다. 거기에 위메이드 장학금 수상설(실제로도 수상했지만.)이 나돌기 시작하면서, 학원 분위기가 급격히 산만하게 바뀌었다. 할 일은 많이 남아있었지만, 시험이 끝나고 방학을 앞둔 학교의 분위기에서 프로젝트에 매진하기란 쉽지 않은 일이었다.

프로젝트 막바지에는 나와 프로그래밍 팀장 형, 이렇게 둘이서 거의 모든 작업을 이어갔다. 차가 끊길 때까지 작업을 했었고, 한 번은 도중에 차가 끊겨서 신도림에서 집까지 걸어가기도 했다. 하지만 같이 프로젝트를 완성해나가는 사람이 있다는 사실만으로도 즐거운 시간이었다.(물론 힘들었지만...)

12. 패키지 제작

"Symphony of Heroes"는 다른 팀의 졸업 프로젝트와는 달리 온라인 게임이 아니었다. 그렇게 기획한 의도 중 하나가 패키지를 제작하기 위함이었다. 우리가 만든 게임을 패키지로 완성해서 소장한다면 좋은 추억이 될 수 있을 것 같았다.
나는 원화가가 그려준 그림을 응용하여, 포스터, DVD표지, 메뉴얼을 직접 제작하였다. 이 작업에 많은 시간이 소요되긴 했지만, 나름 흥미로운 작업이었다. 게임이 완성되어가고 있음을 느낄 수 있는 작업이었기 때문이다.
마감일 직전에야 CD를 굽고, 패키지를 완성할 수 있었다. 총 30장 정도가 완성되었다. 이 중 몇 장은 최종발표때 경품으로 쓰였고, 나머지는 이 게임을 만들기위해 수고해준 팀원들과 나누어 가졌다. 이렇게 완성된 패키지는 두고두고 오랜 추억으로 남을 것이다.

완성된 패키지의 모습

13. 제작 발표회

졸업 프로젝트 팀에서 우수한 결과를 보여준 팀에는 장학금을 수여한다. 네 팀 모두 이 장학금을 목표로 개발하였다. 장학금에는 두 가지 종류가 있었다. "위메이드 장학금"과 "학원 장학금", 이 두 가지 다. "위메이드 장학금"의 경우 위메이드에서 직접 사람이 와서, 네 팀의 개발 중인 게임을 보고 평가를 했다. "학원 장학금"은 발표회가 끝나고 학원 강사님들이 정하는 장학금이었다. 금액으로 따지면 "위메이드 장학금"이 더 컸다. 그렇기 때문에 단순히 등수로 매긴다면 "위메이드 장학금"이 1등. "학원 장학금"이 2등으로 볼 수 있었다.

7월 말에 이미 "위메이드 장학금"수상자가 이미 결정되어, 우리들 중 1등은 정해진 상태였다.(아까 말했던 옆팀이다.) 그렇다고 하더라도 "학원 장학금"이 남아있었지만, "학원 장학금"은 액수가 적다는 소문이 있어서(그 소문은 거짓으로 밝혀졌으며, 상당히 많은 액수였다.) 받으나 마나 한 상이라는 인식이 있었다. 아직 마지막 발표까지 시간이 남아있었지만, 이미 패배했다는 생각에 열심히 하는 사람은 많지않았다. 이런 패배감이 만연한 분위기 속에서도 마지막 발표만은 잘하고 싶었다. 그냥 게임의 등수를 떠나서 모두에게 인상깊은 발표를 보여주고 싶은 오기가 생겼다.

마지막 프레젠테이션은 저번과 다르게 많은 준비를 했다. 대본도 미리 작성하고, 어디서 어떤 연출을 할지 미리 짰다. 이른 아침, 빈 강의실에서 리허설도 빼먹지 않았다.
자체적으로 평가하자면 내가 한 것중에는 최고의 프레젠테이션이고, 남들이 보기에도 나름 괜찮았을 것이라고 생각이든다. 하지만 안타깝게도 "학원 장학금"에도 수상 실패했다. 그래도 이렇게 추억을 남길 수 있다는 사실만으로도 공을 들인 가치가 있었다.

졸업식날 발표 모습

모션 컨트롤러로 플레이 하는 모습

무려 63슬라이드의 졸업 발표 프레젠테이션
한 슬라이드당 짧고 빠르게 넘어가는 컨셉으로 제작되었다.

14. 프로젝트 평가

한마디로 평하자면 "대체로 미숙했던 프로젝트"라 할 것이다. 특히 나 자신이 팀장으로써 많이 미숙한 모습을 보였다. 기획은 중심을 잡지 못했다. 팀원들에게 기획의 당위성을 제대로 설명하지도 못했다. 흔들렸던 시간들이 불필요하게 많았고, 어설프게 많은 것을 시도하려고 하였다.

기획 초기에 우려했던바는 게임이 완성되어서 결과로 나타났다. "음악 지휘랑 전투랑 따로 놀지 않을까?"에 대한 걱정 말이다. 이 문제는 결국 인디게임 공모전 수상 실패로 이어졌다.

기획자들의 업무 분담 문제도 있었다. 나는 내가 모든 걸 만들고 싶다는 욕심. 그리고 다른 팀원에게 맡기면 내가 원하는데로 기획이 안나올지도 모른다는 걱정으로 많은 업무를 분담하지 않았다. 대부분 나 스스로 해결하려고 했다. 그만큼 나의 피로는 더 누적 되었고, 많은양의 업무는 나를 지치게 만들었다. 그렇다고 게임의 모든 것이 내가 원하는대로 나온 것도 아닌데 말이다.

하지만 게임을 만드는 그 과정 전체는 재미있고 흥미로운 일이었다. 좋은 추억이 되었고, 지금 졸업프로젝트를 다시 하라면, 더 잘 해보고 싶다는 생각도 든다.
그리고 나의 소중한 포트폴리오로 남게 되었으니 더 할 나위없지 않은가? 어쨌거나 이 게임 덕분에 취업걱정은 덜었다. 그게 가장 큰 성과다.

15. 마치며...

이번 포스트모르템을 작성한 계기는 우리가 겪었던 프로젝트 과정을 기록으로 남기기 위해서였다. 어젯 밤 먹은 식사도 기억 못하는 내가, 오랜시간 미루다 이제 와서 쓰려니 쉽지 않았다. 그동안 좀 더 많은 기록을 남겼을 걸 하는 후회도 든다.
내 기억이 틀린 부분도 있을 것이고, 내 주관적인 입장에서 썼기 때문에, 다른 팀원들이 보면 틀린 이야기가 있을지도 모르겠다. 그런 부분이 있으면 지적해주시면 감사하겠다.
이 글로 후배 기수들 혹은 아마추어 개발자들이 게임을 만드는데 있어 작은 보템이 되었으면 좋겠다.

마지막으로 이 프로젝트에서 나 때문에 고생하셨던 모든 분들게 감사을 말을 남긴다.

Symphony of Heroes 포스트 모르템 4부 보러가기
Symphony of Heroes 동영상 보러가기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.