Swing! Archflow!

최근에 ai 때문에 핸드폰으로 장기 게임을 하나 받아다가 하고 있다가 재밌는걸 발견했다.
의도를 했는지는 잘 모르겠지만 이 ai가 자주 쓰는 전략의 근간은 경제 원리라는것이다.


첫번째로 같은 가격대로 서로 제로썸 하는 형태.

게임은 현실의 반대를 표출한다.
욕망의 대리만족. 불만의 표출. 본능의 해소등등을 포함한다.

일방향 미디어의 관음증적 대리만족에서 한발 더 나아가 양방향 미디어로서 직접적인 관계를 맺는다. 그렇기 때문에 게임에서의 비현실적인 요소들을 더욱 적극적으로 받아 들인다.

간단한 예로 현질등의 행위를 통한 비정상적인 행동은 현실에서의 돈을 통한 욕구 불만족을 풀지 못하는데에서 오는 대리만족이다.

본래 태생부터가 비정상인 게임이란 미디어에 비정상적으로 가지고 논다는것 자체게 비정상이다. 애시당초 게임이란 놀이 자체가 정상이란 범주가 존재하지 않는다.

다만 자기안위적이고 변화를 두려워 하는 사람들의 마음속에 정상적인 형태라는 테두리가 남아 있을뿐.

보다 직접적인 예를 들어 보자.
땅을 파서 옆에 옮기고 다시 메꾸는걸 반복하는 사람이 있다. 본인은 재미있다고 하는데 옆에서 보는 사람이 재미없는 행위를 왜 반복하냐고 화를 낼 필요는 없다.

재미란 주관적인 요소로 본인이 재밌다고 여기면 그 사람에겐 재밌는것이다.
자신만의 생각의 안주에서 벗어나지 못한채 편협하게 사물을 바라보는것.
그 자체가 오히려 비정상적인게 아닐까?

무언가를 비정상이라 말하기 전에 과연 정상은 무엇인지 먼저 생각해봐야 한다.

고정간격 계획과 소거 (fixed-interval schedules and extinction) 라고 붙인 실험을 보면 보상에 따라 행동을 하고 보상이 돌연 중단되면 이들의 반응이 소멸된다.

(이는 일반적인 형태의 게임을 지속하다 더 이상 보상을 얻지 못하는 경우 더 이상 게임을 중단하는것과 흡사하다. )



변동강화계획 (variable schedules of reinforcement)이라는 실험에 의하면 비정기적인 경우시에 오히려 더 많은 해당 행위를 반복한다고 한다. 간헐적 강화라는 것으로 중독이라 일컫는 강박 증상은 게임 자체의 보상이나 재미를 뛰어넘는다.

(도박적인 재미와 중독에 대한 강한 보상등이 아마도 이 부류일것이다. 그리고 현재 온라인 게임이 가지고 있는 변동강화계획 실험에 딱 맞아 떨어진다고 본다.)

아이디어가 핵심이 되는건 아니지만 매우 중요한 요소이다.

이는 씨앗과 같아 그 자체의 의미보다는 키워서 발전해가는데 더 큰 의미가 있다.

또한 해당 아이디어라는 씨앗이 초기의 이미지완 다르게 같이 작업하면서 여러가지 재배방식에 따라 또는 환경에 따라 변화하기도 한다.

하지만 이곳에 자신의 씨앗이라고 고집을 피워선 곤란하다.

밭을 갈아 버리는건 당신의 몫이 아니다.

아이디어는 끊임없이 다양하게 내놓고 그 중에서 성장 가능한것만 골라 재배하는데 촛점을 맞춘다.

물론 때때로 잡초처럼 질기게 살아남는 아이디어들도 존재한다. 이를 굳이 버릴 필요까지는 없다. 잡초도 때론 도움이 되는경우가 종종 있다.

중요한건 어느 토양에 잘맞는 아이디어를 심는가이다.

게임은 위의 세가지중 한가지 혹은 3가지를 적절히 믹스해서 이뤄진다.
시간을 투자하면 강해지고 게임을 끝낼수 있거나, 조작 하나로 게임을 엔딩까지 가거나, 머리를 써서 플레이 하는 형태의 게임은 고전적으로부터 이어져 왔다.

조작의 요소는 고전 슈팅및 액션등에서 자주 사용된다. 게임의 중심이 조작(순발력, 컨트롤)을 어떻게 하는가이며, 이는 FPS에도 그대로 이어져 내려온다. 순간적인 상황 판단하에서 어떻게 움직이고 어떻게 진행하는가?

시간의 요소는 고전 RPG부터 이어져 온 흐름으로 레벨업 해지면 강해진다는 개념이다. 이 흐름은 현재 MMORPG에도 그대로 적용된다. 시간을 투자한만큼 엔딩에 가까워지며 그에 따른 자동적인 난이도가 조절되는 형태.

머리의 요소는 전략게임에서 흔히 나오는 요소로 머리를 써서 상대의 약점을 공격하는 개념이다. 고전적인 장기, 바둑에서 부터 전략게임까지 다양하게 이어져 왔다.

그리고 시대가 바뀌면서 이런 3가지 요소가 서로 한데 뭉치면서 조작과 머리와 시간을 동시에 사용하는 액션RPG나 RTS등으로 진화되었지만 이 모두 3대 법칙에서 벗어나진 않는다.

일전에 썼던 포스트중에서 말한바 있는 전략게임 매니아에게 미소녀 어드벤처를 만들라거나, FPS게임 개발을 원하는 사람에게 턴제 SRPG를 요구하거나 등의 이야기를 한 적이 있다.

원하는것과 원하지 않는것. 아직까지 세분화 되지 않은 분야들이 존재하는데 있어 100% 원하는것을 할 순 없겠지만 그래도 기본 전문 지식분야라는게 존재한다.

2차세계대전사와 총기의 밸런스 연혁, 전 세계 무기분야를 꾀고 있는 사람에게 SD 횡스크롤 액션 게임을 개발하라는것은 거친 터치의 극화풍을 가진 이에게 SD그림을 그려달라는것과 진배없다.

물론 못하지는 않는다. 이른바 게임 기획이라는 분야 자체에서 외형만 변할뿐 기획을 한다. 혹은 그림을 그린다라는것에서는 달라지지 않는다. 하지만 그것은 그가 가진 능력의 절반도 못미치는 결과를 낼수밖에 없다는걸 인지하고 하는게 아니라 전략게임 기획서를 훌륭히 잘 쓰니 횡스크롤 액션게임 기획서도 잘쓸것이다라고 기대를 하는건 잘못 된 것이다.

양식을 잘하면서 한식도 잘 요리하는 사람이 있을순 있다. 하지만 기본적으로 보통의 경우엔 한식을 잘하는 사람에게 푸와그라를 만들어 달라고 하진 않는다. 요리책 뒤져서야 만들수야 있겠지만 그것에 과연 제 맛이 날것인가?

사람의 능력을 100% 발휘할수 있는 환경. 처음부터 그런게 만들어지진 않겠지만 최소한 서로서로 부족한 점을 보완하여 적어도 70~80% 정도의 능력을 발휘할수 있는 공간은 만들어야 하지 않을까?
그리고 그런 환경이 되면 물만난 고기처럼 제대로 된 기획을 할수 있지 않을까 싶다.

온라인 게임 개발 자체의 역사가 매우 미천한 관계로 개발 구조가 완벽하게 정립되지 않았다. 다만 기존의 스탠드 얼론 개발방식으로 이미 닦여진 해외의 개발방법과 국내에서 개발하며 삽질과 맨땅헤딩 무공으로 어느정도 개발하는데에는 무리가 없는 형태까지 발전했다. 하지만 이 방법이 온라인 게임 개발에도 적절한가는 문제점이 존재한다.

스탠드 얼론 게임은 패키지로 시장에 내놓으며, 게임의 성공여부는 '팔리는가? 팔리지 않는가?' 로 나뉜다. 게임의 재미를 통해 구매를 통한 유저층의 확산이 기본 패턴이다.

온라인 게임은 지속적인 서비스가 중요하다. 곧 고객의 의견을 받아 들여 최대한 유연하게 그러면서도 빨리 수정하고 고쳐가야 한다.


조각은 거대한 하나의 덩어리를 미리 잡고, 그것을 깎아서 만들어간다. 그리고 그 결과물이 마음에 들지 않거나, 생각보다 너무 크거나, 생각보다 너무 작은 경우엔 버리고 새로운 덩어리를 찾아야 한다.

소조의 경우엔 기본 뼈대를 잡는다. 그리고 해당 뼈대만 잘 잡는다면 큰 문제없이 변화가능하며, 기본 뼈대가 크게 잘못되지 않는한 지속적으로 붙이고 깎고, 변화해가면서 작업해갈수 있다.


예를 들어보자면 스탠드 얼론 게임의 경우엔 20여가지 미션(혹은 챕터 또는, 스토리)을 깨는 방식이라면 이 모든걸 한꺼번에 만들어서 출시해야 하지만 온라인의 경우엔 기본 플레이 패턴(또는 구조)만 확실하게 잡고, 스크립트 노가다 작업할 분량을 계획세워 초기에는 3~4개를 제공하고 매달(또는 매주) 2~3개씩 업데이트 하는 형태라 말하겠다.

물론 그렇다고 개발 자체가 10분의 1로 줄어들진 않지만 보다 유연한 개발(xp등에서 말하는 클라이언트의요구에 따른 개발)을 할 수 있으며, 작업의 딜레이 자체가 적고(소수로 쪼개서 나눠서 하는 모듈화 작업이므로 스케줄이 방대해질수 없다.)매번 테스트를 기반으로 한 작업(안정화)과 동시에 지속적인 서비스(패치를 요구하는 유저들의 요구와 기대심리)를 만족시킬수 있다.

스탠드 얼론 게임의 경우엔 작가주의적 개발이고,
온라인 게임의 기본은 서비스이다. 그리고 서비스는 유저들이 즐기고, 좋아하고, 편해야 한다.


조소형으로 개발한다면 개발 자체의 큰틀을 확고하고 유연하게 짜고, 그것을 검증 및 테스트를 하며 개발에 들어갈수 있다.

일단 개발이 시작한 다음부터는 어떤상황(천재지변을 제외한)에도 대처 가능한 유연성을 지닌다. 또한 게임 개발의 최고 정점등을 예측 가능하여 기존 게임 개발과 달리 쉬지 않고 일하다 유저가 바닥나면 업데이트를 종료하는것과 차이가 있다.

개발 자체의 순간적인 검증이 언제나 이뤄지며, 중간중간 테스트를 통해서 내부 테스트 자체가 일종의 서비스 상황과 비슷하게 이뤄지므로 서비스 자체에 대한 대응 능력도 같이 클수 있다.

이렇게 바뀌기 위해선 역시 기획 자체도 보다 유연하고 다양하게 꾸며져야 한다. 개발 방법과 기획 그리고 프로그램 설계가 모두 유연하게 가능방법으로 가야 보다 온라인 게임 개발 자체가 효율적으로 돌아갈것이다.

온라인 게임개발 페이스.

신규 프로젝트
* 100미터 달리기 -> 조낸 달리는거다.

프로토 타입 개발
* 100미터 허들 -> 문제점이 조낸 많지만 차던 넘든 조낸 달려 가야한다.

알파 버전 개발
* 400미터 계주 -> 전력으로 달려주지 않은 다음넘이 조낸 고생한다.

베타 버전 개발
* 1600미터 계주 -> 페이스를 조절하며 달려야 한다. 실패하면 조낸연쇄반응이다. 라이브 단계

라이브 단계
* 마라톤-> 죽어버리고 싶더라도 계속 달려야 한다. 그렇게 빠를 필요는 없지만 끊임없이 달려야 한다. 한번이라도 쉬어 버리면 그냥 그 상태로 끝이다. 페이스를 잃어 버리고 다시 달리기 힘들듯이 한번 패치를 실패하면 유저들은 다시 돌아오지 않는다.

ps. 더 빗대어볼만한 상황은? ;;;

아마추어용이라 생각했던 기획서의 코드화 분류화에 대한것이 의외로 좀 더 실무적이란것을 최근에 깨달았다.

단순히 기획서를 보기 좋게 찾기 좋게 분류한데서 시작하여, 일 하다가 때려치고 나가더라도 다음사람이 어이 받아서 하기에 전혀 무리가 없는 형태로 구상한것이였는데, 이 부분이 차후 패치부분과 연동되어 훗날 라이브단계에서의 이후 패치까지도 연계됨에 있어... 나름 자부심을 가지고 이 기획서의 정리라는 부분에 대해서 강의를 해볼까 한다.


0. 브레인스토밍 단계
1. 제안단계 - A. 1P 제안 / B. 워드 제안 / C. PPT제안
2. 기획서 단계. -> 각 시스템별 모듈화
3. 작업문서 단계.  -> 도표및 엑셀등으로 한장만으로 해당 작업자가 작업할수 있게 구성.

위의 형태로 진행되며, 각각 수정에 대한 기록을 남겨 추적하여 한데 모은것이 용이하고, 바이블 형태로 꾸미는데 필요한 별도의 정리또한 간편하다.


게임기획의 기본 요건인 제안단계 또한 사람들이 자주 간과하는 부분인데, 기획자가 여러번 생각해서 문서로 정리해준다면 실무자들의 뇌뚜껑을 따버릴수도 있다.

보통의 게임기획자들은 1가지 시스템 제안을 하고 그것이 진행하는가? 안하는가? 의 yes or no 또는 0 또는 1의 의사결정으로만 제안한다.

하지만 제안단계에서 A. 최대 B. 중간 C. 최소 라던가... A.SF 테마 B. 현대 테마 C.환타지 테마등으로도 바꾼다면 선택분기가 넓어지고 좀 더 적극적인 참여를 끌어낼수 있다. 이런 패턴으로 A. 정액제방식 B. 부분유료 C.완전꽁짜등도 고려해볼수 있을것이고, 게임의 볼륨은 현재 자신이 처한 현실에서 가장 적절하게 선택가능한걸 찾을수 있다.

또한 훗날 업데이트를 할때 미리 한번쯤 연구한것이기에 적절하게 수정해서 추가할 수도 있고, 다양한 생각을 팀원보다 미리, 빨리, 먼저 한다는것이 관점이다.  

다양하게 생각하고 미리미리 준비하는 작업. 완벽하고 완전한걸 노리기 보다는 다양하고 많은걸 노리는쪽이 좀 더 살상력이 높다는건 캐틀링에서도 보여주듯이 최대한 많이 생각하고 최대한 깊게 생각하고 최대한 간결하게 준비하는것.



ps. srpg 기획서나 만들어 공개해볼까 생각중..

기획 문서를 작업할때 간단하게 작업하는게 좋다.
게임 기획서는 묘비에 새기는 이름이 아니다.
 돌판에 어거지로 새겨넣듯이 작업하면 그것은 말 그대로 묘비에나 어울리는 문서가 된다.

게임 기획서는 생존해야 한다.
게임 기획서는 진화해야 한다.
게임 기획서는 움직여야 한다.

그렇기 위해선 기민한 문서 방식이 필요하다.
가장 좋은건 해당 폴더 루트에서 관리해주는것이 좋다.
폴더별로 들어간 경우 각 문서의 전반을 알아보기도 힘들뿐더러, 죽은 문서와 살아 있는 문서를 구분조차 할 수가 없다.

적어도 작업자 자신은 항시 최신 문서가 어떤것인지 알아야 하고, 그것을 자신만 보기 좋게 하는게 아니라 누구나 쉽게 볼수 있게 구성해야 한다.

그렇기 위해서 가장 간편하면서 손쉬운 방법이 바로 코드화이다.
코드화로 정렬한 문서는 이름순으로 정렬시에 가장 보기 좋은 구성을 가진다.


이 경우 3가지 방법으로 소트가 가능하다.
이름순. 확장자순. 수정일순 등으로 변경해서 빠르게 찾을수 있는 장점이 있다.

또한 코드화 되어 있기 때문에 실제 자신이 작업하는 문서만 찾아서 보는데에도 큰 도움이 되며, 제작완료(패치, 분기 업데이트등의 큰 단위 묶음이 완료)시엔 바이블 형태로 문서를 1가지로 통합하는것에도 매우 손쉽다.

이는 회의록은 회의록으로 시작시 같은 문서들이 존재하며, 날짜를 통한 작업우선순위및 시간을 보며, 간단한 주석등으로 문서의 개요정도를 볼수 있게 구성하는데 있다.

반드시 문서를 열어보지 않더라도 바로 보고 작업하는데 어려움이 없게 구성하며, 검색이나 구글 서치등을 통해서 뒤질때도 매우 편리하게 작용된다.

물론 이런 코드화를 하기 전에 먼저 시행해야 하는것이 작업별 묶음이다.


문서는 크게 기획문서와 개발문서로 구분하는게 좋다.
보통의 기획문서는 기획자들이 무슨 의도로 설계해서 만들었는가를 위주로 정의 한다면 개발 문서는 말 그대로 타 파트 개발자들이 순수하게 자신이 작업할 문서만을 보고 작업하면 되게끔 구성하는것이다.



한방에 모든걸 만들고 싶어하는 중급 기획자들이 종종 실수하는것중에 하나가 기획서 안에 모든걸 집어 넣으려 하는데 있다. 기획서 안에는 모든걸 들어가더라도 제작 단계에서는 끊어서 개발할 필요성이 존재한다.

만약 캐주얼풍의 게임으로 캐릭터가 20여명 정도가 나와야 된다고 느낀다면 이 작업을 개발문서에서는 쪼개주어야 할 필요가 있다.

5마리씩 조개거나 4마리씩 쪼개서 차후 패치단계로 천천히 돌리게끔 구성한다면 개발 자체에 쓸데없이 테스트도 못하는 상태로 주구장창 캐릭터만 만들고 있을순 없지 않은가? 더불어서 인력없다고 한탄할 필요도 없다.

사실 캐릭터 1개, 몬스터 1개, 배경 1개만 있으면 기본적인 구동테스트 준비는 끝이라고 봐도 무방하다. 그리고 나머지는 오로지 코드와의 싸움일것이다.

물론 여기에 기초되는것은 게임 개발 툴의 존재 유무이나, 현재 대다수의 게임 개발사에서는 툴 베이스로 개발하지 과거의 90년대 말 ~ 2000년대 초반처럼 "오로지 우리가 갈길은 삽질뿐!!" 을 외치며 하드코딩으로 진행하진 않을것이다. (만약 하드코딩으로 진행하다면 당장 도망치는게 살길이다. -_-;;)

공성전도 들어가고, 나라도 확장하고, 군주관계도 맺고, 사부와 제자도 맺고, 죽었다가 환생하기도 하고, 노래도 부르고, 춤도 추고, 요리도 하고, 집도 만들고, 무기도 만들고, 상점을 개설해서 사고 팔고, 수시로 변화하는 미궁에 들어가서 모험도 하고, 공대 조직해서 보스를 잡는것도 좋다.

하지만 우선시 해야 할것이 무엇인지를 파악해야 하며, 무엇부터 시작해서 무엇을 테스트 하고, 모두 완료 된 시점에서 다음에 미리 무엇을 준지할것인가? 이런것을 생각해 주는 작업이 게임 기획이다.

단순히 어떤 게임 보니깐 이딴게 들어가더라 라는건 의미없는 짓이다.
그럴 바엔 기획자 없이 개발하는쪽이 훨씬 편하고 빠르게 개발 가능하다.

기획서의 존재 자체는 미리 만들 작업의 예측.
이 작업을 왜 하는가에 대한 당위성.
제작 완료후 문제가 있었던 점.
그리고 어떤게 시작해서 어떻게 종결했는가를 알려주는것과 같다.

그러기 위해서는 간단한 파일 관리부터 조금씩 시작해두고, 가능한한 카테고리별로 쪼개서 관리가 편하고, 보기도 편하며, 찾기도 손쉽게 구성해야 한다.