'Developer/GAME'에 해당되는 글 34건

  1. 2013/01/06 글뻥 초간단 NGUI - 3
  2. 2013/01/06 글뻥 초간단 NGUI - 2
  3. 2013/01/04 글뻥 초간단 NGUI - 1 (3)
  4. 2012/12/04 글뻥 Photon Cloud 강좌 4 (11)
  5. 2012/11/29 글뻥 Photon Cloud 강좌 3 (8)
  6. 2012/11/28 글뻥 Photon Cloud 강좌 2 (1)
  7. 2012/11/26 글뻥 Photon Cloud 강좌 1 (6)
  8. 2012/10/23 글뻥 GOH (갓오브하이스쿨) Gstar 2012 버전 선공개입니다. (2)
  9. 2012/10/23 글뻥 음... 민망하지만, 우리 디자이너가 아이디어 낸 게임입니다.
  10. 2006/08/16 글뻥 Microsoft XNA 2006.8.30 공개
지난 4편까지의 썰을 정리하면 
1~3편까지는 기본적인 게임의 구조에 대해...
4편은 데이터와 함께 절차를 살짝 짚는 정도로 이야기 하였고...
이번 5편에서는 그 절차중 가장 중요하고 기획자나 개발자가 절대 프로젝트 마지막 출시까지 지켜야하는 보이지 않는 룰인 장르에 대해 이야기해보고자 한다.
(경험상 많은 개발팀이 장르의 문법을 지키지 않고 개선작업에 매달리다가 망했다.)

장르라는건, 마치 상품의 종류와 같다.
예를 들어, 스포츠카나 SUV, 세단 등의 차가 있다면 다 같은 차임에도 차종이 다른것과 같은 이치가 통한다.
개인별로 호불호가 갈리겠지만, 만들고자 하는 차는 F1레이싱카인데, 4륜구동이 좋아보인다고 4륜구동을 장착하는 순간 그 차는 F1일까? SUV일까?

모든 기계는 트레이드오프가 발생한다는 전제를 잊어서는 안된다.
이게 좋으면 이걸 달고 저게 좋으면 저걸 다는 순간 시스템의 핵심은 날라가버리고 마는 것이다.

그래서 5편에서는 장르에 관한 이야기를 하고자 한다.

인터넷에서 구한 한장의 이미지를 보는 순간, "이거다!"하는 했는데...
바로 위의 이미지이다. 이 이미지 해상도가 그리 높질 않아서 대충이나마 해석과 챠트로만도 파고들 수 있지 않을까 싶다.

먼저 게임을 구성하는 5가지 메커니즘(시스템)부터 알아보고가자.

첫째는 물리다. 
아주 간단한 슈팅게임조차 총알을 발사하고 비행기를 움직여서 적의 공격을 피한다. 다시말해, 물리를 통해 플레이어는 게임을 배운다.
레이싱 게임이나, 비행시뮬레이션 게임은 물리가 전부다. 나아가 앵그리버드는 물리로 이루어진 퍼즐게임이다. 컷더로프는 말할 것도 없다.

두번째는 경제다.
나무, 돌, 가상화폐, 비행기숫자, 총알 등의 수집, 소비, 교환 등 게임내의 요소 또는 자원의 거래시스템이다.
게임에 따라 거래 시스템을 포함하고 있지 않아 보이기도 하지만, 기회요소조차 거래로 본다면 모든 게임이 약하든 강하든 이 시스템을 가지고 있다.

셋째는 진행이다.
대부분의 게임들이 특정한 방법(마법키나, 파워업,레벨업 등)으로 플레이어가 게임을 진행하도록 강제하거나 지시하는 시스템이다.

넷째는 전술계획이다.
게임에 따라 무엇인가 전술지도나 보드판 등에 놓음으로 공격과 방어의 잇점을 누릴수 있는 시스템을 포함하기도 한다. 특히 RTS나 TCG는 이 시스템이 매우 중요하게 작동된다.
물론 어떤 게임은 개별 유닛의 위치에따라 공격과 방어의 이익과 불이익이 있기도 하다.

다섯째는 소셜관계이다.
친구와 이야기를 나누거나 협력하는 등을 초월하여 이제는 선물을 주고 받거나 친구의 게임내 행동에 참여하거나 기여할 수 있는 시스템이다. 

이러한 5가지 매커니즘이 조합되어 장르로 구성된다.

다시 위의 이미지 파일로 돌아가서 정리하자면...

사용자 삽입 이미지
결국 장르라는 건 물리/경제/진행/전술/소셜 5가지 요소들의 편집이다.
(가장 두꺼운 라인은 핵심, 그냥 라인은 필수, 라인이 없는건 옵션)
예를 들어 소셜 퍼즐게임이란 퍼즐요소와 소셜게임요소를 섞어 놓은것으로...
물리는 간단하게나마 들어있고, 리소스수집과 컨텐츠소모가 있으면서 퀘스트와 목표를 제시하고 플레이어간 게임 리소스를 교환하게하고 협력/분쟁을 조성하는 메커니즘이 들어가 있는 게임이다.


즉, 게임기획서는 궁극적으로 이러한 메커니즘을 정의하고 코어루프의 Pay gate를 정의하는것으로 제 역할을 다 할 수 있다 하겠다.
이말을 다시 정리하면,

효과적인 게임 기획이란 장르를 정의하고 필수 메커니즘을 정의한 기획서라는 의미이다. 
그리하여 게임기획서의 목차를 따지자면 다음과 같이 정의할 수 있다.
1. 게임의 개요(공통) : 게임의 목적과 대상고객층, 장르, 테마 등을 요약한다.
2. 게임의 테마(공통) : 시대적배경 같은 것을 정의한다. 예를 들어, 판타지, 2차세계대전, 현대전 등이다.
3. 콘트롤/UI (게임콘트롤, 공통) : 요즘 클릭질 게임이나 방치형 게임이라도 어느때 유저가 입력이 일어나는지 정의해두자.
4. 코어루프 (공통) : 게임메커니즘과 과금모델 요약한다.
5. 게임메커니즘 (게임의 규칙에 해당된다.) 
   5.1. 물리모델 (장르별 옵션)
   5.2. 경제모델 (장르별 옵션)
   5.3. 진행모델 (장르별 옵션)
   5.4. 전술모델 (장르별 옵션)
   5.5. 소셜모델 (장르별 옵션)
6. 과금모델 (옵션) : 상업게임이라면 필수겠죠?
7. 서비스로드맵 (옵션) : Baseline과 향후 업데이트 계획을 옵션으로 한다.

* 참고 : 모바일 사용자층 분석자료 - http://www.mobizen.pe.kr/1157

2015/04/28 09:38 2015/04/28 09:38

* 원래 좋은 게임 기획이라는 타이틀을 달고 있었지만, 생각해보니,내가 기획자도 아니고, 이 글을 쓰는 취지는 결국 개발자에게 맞는 기획서를 만들어서 전달하기 정도이니... "좋은 게임 기획"보다 협의의 의미로 "효과적인 게임 기획"으로 변경하였습니다.

앞에서 Core loop의 정체를 살펴보았다.
회사 생활이나 군대 생활도 결국 Core loop란게 존재한다.
(Core loop가 존재하지 않는다면 콘텐츠가 바닥나 버리고 금새 지겨워질것이다.)

예를 들어 일에서는 다음의 코어루프가 인정된다.
- Boss에게서 Quest를 받는다. (Extend)
- Quest를 수행 한다. (Action) 
- 보상으로 피드백을 받는다. (Reward 혹은 Penalty)

물론 이상적인 부하직원이라면
- Quest를 제안한다. (Action)
- Boss의 피드백을 받는다. (Reward 혹은 Penalty) 
- Boss가 재정의한 Quest를 받는다. (Extend)
- Quest를 수행한다. (Action)
- Boss의 피드백을 받는다. (Reward 혹은 Penalty)

이러한 Route를 밟겠지만...  뭐 암튼 여기서 가장 중요하게 기억하고 넘어가야 할 포인트는 코어루프란거가 있다!
그정도로만 알고 넘어가자.

이제부터 알고가야할 개념은 다음의 무지막지한 통계 이미지 들이다.

-가볍게 가보자.
1975년 부터 2015년까지의 시간별 플랫폼 점유율의 변화이다.

사용자 삽입 이미지

다음은 같은 시간대의 게임의 테마의 변화이다.
사용자 삽입 이미지
다음은 시대별 장르 변화이다.
사용자 삽입 이미지
이러한 데이터를 왜 꺼내놓고 이야기하냐면...
바로 다음의 이미지 때문이다.
사용자 삽입 이미지
인간이 가진 욕구를 게임의 메커니즘이 충족시키는 Points를 비교해놓은 차트이다.
해상도가 낮으니 보다 선명한 자료로 본다면...
사용자 삽입 이미지
위와 같다.

위와 표현은 다르지만, 여러가지 요소들을 어떻게 표현하고 어느쪽을 강화하느냐에 따라 게임은 장르 분화가 발생된다.

사용자 삽입 이미지
따라서, 게임을 효과적으로 만드는 방법중 하나는 바로 장르를 선택하는 것이다.
장르가 선택되고나면, 어떤 부분을 어떻게 만들어야 할지가 결정된다.

물론 여기에 과금포인트라는 부분도 있다.
정확하게는 어떻게 돈을 써야 불편하지 않아 하는가에 대한 일부 대답이다.
개인적인 연구에 의하면 사람들이 게임에 돈을 쓰는 경우는 약 7가지 정도로 압축되었는데, (이건 논문 쓰라면 써야 할 판이다.)

사용자 삽입 이미지
기본적으로 생계형 게임이라면, 위의 조건에 맞는 과금 모델을 만들어 놓고 당연하게도 과감하게 "돈을 질러 주세요"라고 요구해야 한다.
이 부분은 좀더 강조하자면, 상점 만들어 놓고 여기와서 사주겠지? 하면 망한다.
- 캐릭터 만들어 놨다면, 캐릭터 체험해보게하고 시간제 한정 30% 할인 이벤트 열어주거나,
- 게임을 계속 하려면 결재하라고 해야하는 것이다.

* 아래처럼 상점 만들어 놓으면 사는 시대는 몇년전에 갔다.
사용자 삽입 이미지

* 이제는 더욱 적극적으로 돈내고 고객이 되라고 해야한다.
사용자 삽입 이미지
즉, 정리하자면 효과적으로 게임을 기획한다는 것은

1. 장르 정할것
2. 테마 정할것
3. 과금모델 정할 것.
4. 과금모델에 맞는 게임 설계를 할것.
5. 게임설계는 Free2Play Core loop 참고!
사용자 삽입 이미지
다음편에는 위에 기록된 장르의 특징 관련 이야기!

2015/04/16 09:23 2015/04/16 09:23
TAG ,
멀리도 왔다.
1편에서는 게임이란 불균형을 균형으로 바꾸는 행위라고 정의하였고,
2편에서는 결국 불균형을 균형으로 바꾸는 행위에는 Trade off 라는 행위가 있다는 것을 괴변을 중심으로 논증하였다.
(여기서 괴변이라 함은 개인적인 주장이기때문입니다.)

앞편에서도 썰을 푼것처럼 게임이란 철저히 Trade off System에 지배받는다.
예를 들어, 가위바위보 게임을 예로 들어보자.

규칙은 간단하다.
- 가위바위보를 할때 동시에 내야한다.
- 가위, 바위, 보를 손으로 표현한다.
- 가위-가위, 바위-바위, 보-보는 비긴다.
- 가위-보, 보-바위, 바위-가위는 왼쪽이 이긴다.

먼저 여기에 Trade off라는 개념을 빼보자.

- 이긴쪽의 보상이 없고 진쪽의 페널티가 없는 상태이다.

플레이어 2명을 모집해서 2명에게 위의 규칙을 주고 가위바위보 게임을 하게하면 아마도 이러한 감정이 있을 것이다.
(아래는 가족을 통해 실험한 결과이다.)
- 뭐지? 뜬금없이...
- 가위바위보... 보... 보... 보... 보...
- 여보! 뭐 없어?
- 나 : 없는데..
- 이게 뭐야? 왜 해야하는데...?

위와 같은 조건에서는 게임이 아니라 행위가 되어 버린다. 그것도 지금 누리고 있는 행복(TV시청, 모바일게임)을 방해하는 행위에 "불과"하게 된다.
규칙을 다음과 같이 바꿨다.
- 가위바위보를 할때 동시에 내야한다.
- 가위, 바위, 보를 손으로 표현한다.
- 가위-가위, 바위-바위, 보-보는 비긴다.
- 가위-보, 보-바위, 바위-가위는 왼쪽이 이긴다.
- 꼴등이 커피쏘기
강력한 패널티를 건채로 프로젝트 팀원을 대상으로 진행한 결과 몇 만원에 달하는 패널티를 받지 않기 위해 필사적이 되었다.
(2009년 우리팀을 대상으로 했을때, 판수가 올라갈수록 목소리와 긴장감이 커져갔다.)

즉, Trade off 조건(패널티 또는 보상)이 Rule로 작동하자, 가위바위보 행위는 커피안사기 게임이 되어버린다. 

위의 "커피안사기 게임"을 시스템 다이어그램으로 표현하면 다음과 같이 정리할 수 있다.
사용자 삽입 이미지
위의 행위에 Rule을 다음과 같이 더하면 게임을 조금더 재미있게(여기서 재미란 다 같이 참여하는 분위기였다) 할 수 있었다.
(맨날 지는 플레이어를 위한 상호 합의과정이었다.)

- 가위바위보를 할때 동시에 내야한다.
- 가위, 바위, 보를 손으로 표현한다.
- 가위-가위, 바위-바위, 보-보는 비긴다.
- 가위-보, 보-바위, 바위-가위는 왼쪽이 이긴다.
- 꼴등이 커피쏘기
- 오늘의 꼴등은 내일 면제
사용자 삽입 이미지
이를 1편의 내용인 Core loop에 대입하면 다음과 같이 Trade off System이 결정될 수 있다.
사용자 삽입 이미지
* 1편에서 Reward로 표현한 부분을 Penalty로 표현하였는데, 이는 Winner에 Focus한 게임 Rule이 아니라, Looser에 Focus한 게임 Rule이 때문이다. 

여기서 적용된 Rule을 한번 더 따져보자.
- 가위바위보를 할때 동시에 내야한다.
- 가위, 바위, 보를 손으로 표현한다.
- 가위-가위, 바위-바위, 보-보는 비긴다.
- 가위-보, 보-바위, 바위-가위는 왼쪽이 이긴다.
- 꼴등이 커피쏘기
- 오늘의 꼴등은 내일 면제
첫 문장은 우리가 Common sense로 알고 있는 동시성을 나타낸다.
예를 들어, 가위바위보를 할때 같이 바위를 냈다가 한쪽이 보로 바꾸면 우리는 반칙이라는 표현을 하고 공정하지 않다라고 이야기한다.
다시말해 가위바위보라는 행위에 대한 Pre Condition이 되는 조건이 바로 첫번째 문장이다.
이 규칙이 바로 2편에서 이야기한 Trade off가 성립될 수 있는 가장 중요한 조건으로 "거래"란 공정성을 기반으로 한다라는 의미로 해석되어야 한다.

두번째 문장은 Action에 대한 정의이다.
다시말해 행위는 어떤 형태로 일어나는가에 대한 정의이다.

세번째, 네번째 문장은 게임의 결과판정에 관한 정의이다.

다섯번째 문장은 최종 1인(Winner 혹은 Looser)에 대한 보상 (혹은 패널티)에 대한 정의이다.

마지막 문장은 보상 혹은 패널티의 2차 결과로 나타나는 확장 또는 특권에 관한 정의이다.

이렇게 세분화해서 설명한 이유는 이 Post를 보는 분들이 주목해야 할 부분이 게임의 기획에 있어서 Action-Reward-Extend loop에 대한 고민중 가장 많이 실패하는 Rule에 대한 이야기를 하려함이다.

우리는 흔히 게임을 만들때 있어 Action, Reward, Extend를 쉽게 상상한다.
하지만, 게임을 만들어야 하는 개발자 입장에서 이러한 정보로는 게임을 만들 수 없다.

이는 프로그램의 본질이란것이 결국에는 if-else 수 십개~수천개, 수만개로 돌아가는 거라는걸 이해해야한다라는 뜻이다.
기획자와 개발자간의 알력도 바로 이러한 시스템의 본질에 대한 이해 차이에서 비롯된다.

* 인공지능 쯤이야... if문 100개 정도면... 이라고 덤비다가 나중에 수정사항 하나 생기면 연쇄 작용 촉발... 그걸 코드 폭발이라고 하지... 
사용자 삽입 이미지



수 많은 망한 프로젝트를 외주해보면서 느낀점도 Rule을 간과하면서 발생한 문제이다.

4편에서는 Trade off 룰을 만드는 과정에 대해 간단한 예로 설명해보고자 한다.

* 1편과 본편에서 논한 Reward와 Extent를 TEST할 방법은 플레이어가 그것을 원하는가?과 같은 질문 목록을 만들어서 평가할 수 있을 것 같다.
- 예를 들어 RPG게임에서 총이 없는데 총알을 주면 어떤 의미가 있을까? 완전히 효용가치가 없다고 볼 수는 없겠지만, NPC에게 팔아서 환금외에는 가치가 높지 않을것이다.
- RPG게임인데 총이 있고 총알을 주면 더 높은 파괴력을 원하는 유저에게는 도움이 될 것이다.
- RPG게임인데 총이 있고 개조파츠를 주면 영구적인 파괴력 상승을 원하는유저에게 도움이 될 것이다.
- Trade off 대상은 이처럼 가치가 다르다.
2015/03/19 15:49 2015/03/19 15:49
앞편에 이어...

1편의 결론은 게임이란 불균형을 균형으로 바꾸려는 행위이다.
다시말해, 유저가 불균형을 탈출하려는 노력이 바로 게임의 좋은 출발점이 될 수 있다고 생각한다.
인간은 신기하게도 불균형을 탈출하려는 본능이 있는것 같다.

예를 들어, 우리가 재미를 이야기하지만, 
- 마우스 클릭질이 그닥 잼있는건 아니다.
- 마찬가지로 키보드 노가다가 잼있는 것도 아니다.

그렇다면 왜 FPS 게임을 하며 혹은 MMO 또는 기타 게임을 하며 우리는 마우스 클릭질 한번에 울고 웃는 걸까?

답이 안온다면 이렇가정을 해보자.
게임을 시작하자마자 치트를 써서 더이상 부족한 자원이 없도록 해본적이 있는가?
혹은 레벨을 극강으로 올려 본적은?

이러한 치트행위의 결과는 게임의 재미가 반감되면 좋으련만, 더이상 게임이 아니게 된다.

다시 말해, 게임이 게임으로써 존재하려면,

1. 불균형으로부터 시작되어야 하고
2. 코어 루프로 그 불균형을 균형으로 바꾸려는 시도를 하게 해야만 한다.
3. 균형 또는 유저로 불균형이 나타나면 게임은 종료되는 것이다.

- Free to Play BM은 "2"의 불균형을 영속적으로 깰 수 없도록 하거나 아주 비싼 댓가를 치루도록 한다.
- 일반 콘솔게임은 전투후 더 높은 레벨로 감으로써 불균형이 어느정도 지속되도록 한다.
- 전략게임에서는 그러한 불균형이 플레이어들의 실력으로 나타나게 한다.(끊임없이 경쟁시키기 위해 끝없는 패치가 앞에 있을뿐)

즉, 게임기획은 예초에 불균형으로 시작해서 불균형을 얼마나 반복시킬지를 의사결정하는 과정이다.

더 쉽게 이야기하면 게임에 통용되는 자원의 부족함에서 기획이 시작되어야 한다.
예를 들면, 스타크래프트는 "미네랄"과 "베스핀가스"라는 "화폐"를 유닛으로 바꿔서 다시 적 유닛과 건물로 교환하는 게임이다.
최근 방송에서 자주나오는 COC 역시 "Gold"와 "Elixir"라는 화폐를 유닛과 방어건물로 바꿔서 다시 적 건물과 유닛으로 교환하는 게임이다.

유독 전략게임만이 아니라, RPG게임장르 역시 파밍이라는 행위로 얻은 무언가(무기, 방어구, 골드 등)를 다른 몹 또는 플레이어와의 전투를 통해 경험치로 교환하는 게임이다.

또다른 하나의 예는 과거 오락실이라 불리던 아케이드 게임이다. 여기서 통용되던 화폐는 단연하게도 "기회"이다.
초기 주어진 기회 (보통 3회)로 격투 또는 슈팅 또는 퍼즐(퍼즐의 경우는 1회가 많았다.)이라는 거래 행위의 결과 Score라는 것으로 교환되었다.
(물론 혹자는 엔딩은 무엇인가요? 라고 물어볼 수 있는데, 이건 잘라 말하면 없어도 되는 요소이다. 현대의 수 많은 모바일 게임들이 그걸 증명한다. 엔딩은 단지 더이상 개발자가 보여줄게 없을 때 "와~ 이제 다 보여줬어요!"하는 개념으로 접근하여도 된다는 이야기이다.)

다시말해, 게임 기획의 본질은 이러한 경제시스템을 구축하는데 있다고 할 수 있다.

소위 쩌는 게임은 본질적인 쩌는 경제시스템을 구축하는데 성공하였고, 그러한 경제시스템에 있어 가장 기본은 Rule이다.

이 시점에서 정리하자면 다음과 같다.


1. 당신이 만들려고 하는 게임의 화폐는 무엇인가요?
   . 제한되어야 하고 얻어야 하는 목적 그 자체!
2. 당신이 만들려고 하는 게임의 거래방식은 무엇인가요?
   . 거래방식이 다양할 수록 다양한 전략적 선택이 생긴다. 
3. 당신이 만들려고 하는 게임은 무엇을 거래하나요?
   . 거래후 결과물로 무엇을 할 수 있는지에 대한 질문이다.
   . 당연하겠지만, 스코어로 얻을 수 있는건 실제 사회에서의 쩌는 명성이다.
   . 경험치로 얻는 것은 더 높은 레벨이다.
   . 승리로 얻는 것은 스코어로 환산하여 명성으로 전환할 수 있다.

이 3가지 물음에서 초기기획은 잡혀져야 한다.
2015/03/01 21:59 2015/03/01 21:59
좋은 게임이란 무엇인가?

1. 놀라움이 있을 것.
- 예 : 설탕물을 입에 계속 물고 있게 할것인가? 아니면, 랜덤하게 설탕물을 입에다 뿌려 줄것인가?
- 놀라움의 대상 : 아트, 기술, 규칙

2. 호기심이 생기도록 할 것.
- 예 : 이 문을 열면 뭐가 있지?, 이 팀으로 이길수 있을까?, 이걸로 뭘 만들 수 있지?, 몇개를 부수면 무슨일이 생기지?
- 내 기록을 깰 수 있을까?라는 호기심에 대한 답으로 플레이어는 조작한다.

게임의 정의란?
제한된 규칙안에서 권력의 비평형 상태를 만들기 위한 투쟁하는 자발적 지배 체제의 훈련이다.
자발적 지배 체제의 훈련 : 고의적인 행위
권력투쟁 : 우위를 점하는 상태. 즉, 목표와 충돌이 존재
제한된 규칙 : 장난감과 다른 "규칙"이 존재
비평형 상태 : 공평하게 시작하지만 승패가 존재

즉, 게임이란 "주어진 문제를 해결하는 실험"이다.

다시 말해, 게임의 기획이란
문제를 만들어 놓고 플레이어에게 다음과 같은 질문을 하는 것과 비슷하다.
- 다른 플레이어보다 높은 점수를 받을 방법을 찾아라.
- 다른 플레이어보다 먼저 골 포인트에 도착할 방법을 찾아라.
- 현재 레벨을 깰 방법을 찾아라.
- 다른 플레이어를 먼저 죽일 방법을 찾아라.

보다 정규화하면 다음과 같다.

(가시적) 미적요소 - 메커니즘, 스토리 - 기술 (비가시적)

좋은 기획은 이중에서 뼈대가 되는 메커니즘 설계에서 부터 시작한다.

흔히 모델링이라고도 하며, 코어루프, 성장루프, 캐쉬플로우, 바이럴루프(소셜루프)라고 하기도 한다.

이중에서 가장 중요한 코어루프만 예를 들면, 
Action -> Rewards -> Extentions -> Action -> ...
이처럼 액션과 보상, 확장이 반복되는 구조이다.
즉, 플레이어가 "뭘 했더니", "뭘 받았고", "뭘 받은 걸로 뭘 업그레이드 또는 진화, 확장"했는지에 대한 모델링이다.
흔히 우리는 이를 게임의 문법이라 이야기하기도 하는데 코어 루프는 이미 몇몇 장르를 통해서 입증된 문법은 다음과 같다.

1. Action 
- 플레이어가 칼을 휘둘러 적을 죽였다.
- 플레이어가 총을 쏴서 적을 죽였다.
- 플레이어가 깃발을 점령했다.
- 플레이어가 덱을 짜서 공격했다.
- 플레이어가 퍼즐 3개를 맞췄다.
- 플레이어가 식료품 상점을 지었다.
- 플레이어가 XX원을 이긴다에 베팅했다.
등등등

2. Rewards 
- 점수를 XX점 획득했다.
- 코인을 XXX개 벌었다.
- 광석을 캤다.
- 친구를 추천받았다.
- 아이템을 얻었다.
- 경험치를 XX얻었다.
- 승리/패배 횟수를 얻었다.
- 콜렉션을 얻었다.
등등등

3. Extensions
- 장비를 업그레이드 했다.
- 스테이지를 추가로 열었다.
- 친구를 얻었다.
- 동료를 얻었다.
- 새로운 유닛을 얻었다.
- 순위가 올라 갔다.
- 보너스 판을 얻었다.
- 콜렉션을 채웠다.
등등등


한가지 주의할 점은 많은 게임디자이너들이 사용자의 직접적인 행위를 콘트롤이라 규정하고 시작한다는 점이다.
거기까지는 좋은 시도지만, 정말 조심해야할 함정은 "빠르게 많은 행위"와 "빠르게 많은 입력"은 다르다는 점이다.

결론은 좋은 게임의 디자인시작은 코어루프에 대해 답을 하는 것이다.
2015/02/23 12:44 2015/02/23 12:44
유니티3D는 사전 정의된 폴더(Special Folder)를 가지고 있다.

Assets : 기본적으로 소스를 포함하고 있는 폴더
Editor : 유니티에서 사용되는 사용자 정의 에디터 폴더
Gizmos : 기즈모 리소스
Plugins : 플러그인 파일들 하위 폴더로는 "iOS"와 "Android"가 Native Path로 설정됨
Resources : Resources.load로 런타임에서 호출가능한 리소스 폴더
Standard Assets / Pro Standard assets : 일반적인 유니티 패키지를 import했을때 사용하는 폴더
StreamingAssets : 비디오 파일이나 원화 같이 프로젝트 소스가 참조하는 리소스를 넣는다고 되어 있으나, 데스크탑 계열에서는 읽고 쓰기가 가능하지만, 모바일은 읽기만, 웹플레이어는 아에 설정이 불가.
(왜 필요한지...?)
WebPlayerTemplates : 이건 그림으로 설명하자면, 웹플레이어의 경우 템플릿을 설정할 수 있는데...
사용자 삽입 이미지
이때 사용하는 폴더로 구조는 다음과 같음.
사용자 삽입 이미지

중요한건 빌드 순서일터,
(왜냐하면 플러그인을 import하고 많은 분들이 그냥 내버려 둠으로써 Compile 순서가 꼬이는 등의 문제가 있을 수 있기 때문)

총 4단계를 거치는데, 

Phase 1: Standard Assets,Pro Standard Assets,Plugins.
Phase 2: Standard Assets/Editor,Pro Standard Assets/Editor,Plugins/Editor.
Phase 3: Editor 폴더 밖에 있는 스크립트
Phase 4: 나머지 스크립트

끝.
2015/02/21 03:47 2015/02/21 03:47
프로 SW개발자로 들어선것이 1999년이니 햇수로만 개발현장을 떠나지 않고 지킨것이 16년정도 되는 군요.
수 많은 사업들에 참여하였고, 현재는 게임개발자로 남은 연료를 태우고 있습니다만,
사람 마음이란게 참 재미있는것 같습니다.

SI현장에서 만난 고객도 그러했고,
게임개발현장에서 만난 고객도 그러했고,
심지어 내부 고객도 그러했으며, 월급주는 상황에서도 똑같은 경험을 하게 되는데...

대부분의 경우, 더 자세히는 "새로운 것을 만들자"라고 시작하는 일의 경우,
정작 새로운 것을 만들어 놓으면 듣는 이야기가...
"뭐야 이거 무서워"
사용자 삽입 이미지
그렇다고, 이미 익숙한 걸 건네주면...
"지금 나랑 싸우자는 것임?"
사용자 삽입 이미지

매커니즘으로 분석해보면 대부분의 사용자(USER)들은 다음의 심리를 가지고 있다는 사실을 알 수 있습니다.
- 새로운걸 내게 보여줘! 새로운 경험을 하게 해달라고... 하지만, 너무 새로우면 내가 무서우니까 니까 잘 알아서 무섭지 않으면서도 새로운 걸 내놔. 

즉, "새로움 추구" -> 막상 새로운 걸 만나면 "시발 무서워" 또는 막상 익숙한 걸 만나면 "지금 나랑 싸우자는 것임?"

다시 말해, 개발자는 사용자(USER)가 익숙한 시스템과 UX는 추구하되 시각적으로 다름을 추구해야 합니다.
이를 게임에서는 "장르"라고 하죠. 네넵.

다시말해 "장르"라는 것에 충실히 따른다는 것은 "사용자가 익숙한 시스템을 추구하되 시각적으로는 다름을 추구한다는 뜻과 같습니다."
여기에 하나에서 두개 정도의 독창성을 추구하되 절대 포기하지 말아야 할 것은...

"즉각적인 System Feedback"입니다.
예를 들어, 사용자가 "A"를 입력하고 화면에 입력된 결과가 1초 뒤에 뜬다면 사용자는 짜증이 나겠죠?
혹은, "A", "B", "C" 가 반복해서 보여지는데 마우스 클릭으로 "A"를 입력해야 한다면?

여기서 중요한 개념이 예측가능성 (predictability) 입니다.
- 사용자가 원하는 입력을 자신이 원하는 때에 즉시 하고, 그 반응은 항상 빨라야 합니다. 

어느 미친넘이 이런 시스템을 사용할까요?

각설하고, 중요한건 장르를 알아야 합니다. 
장르를 공부하고 나서 "직관"이란 것도 생깁니다.

공부하는 이유는 이러한 "직관"을 얻기 위한 과정인 것입니다.

"직관"은 수 많은 시행착오와 공부를 통해 얻어지는 것이지 상상한다고 얻어지는 것이 아닙디다.

2015/02/15 04:49 2015/02/15 04:49
Sonar cube란 소스의 정량적 상태를 가시화하는 툴이다.
이러한 소스 가시화는 예전부터 꾸준히 테스트 또는 CI 등으로 나타났는데 이제서야 제대로 된 소스의 상태를 추적관리 할 수 있도록 해주는 툴이 나타났다고 생각한다.

먼저 JAVA가 설치되어 있어야 한다.
http://www.oracle.com/technetwork/java ··· 260.html에서 다운로드 받아서 설치하자. Unity3D 안드로이드 개발할때 정신적으로 피곤하지 않으려면, 최신버전보다 2~3단계 하위버전으로 x86버전으로 다운로드 받자.
설치가 완료되면, 제어판에서 시스템, 고급시스템설정, 고급탭에서 환경변수를 클릭한다.

시스템변수 부분에 새로 만들기를 클릭하여 다음과 같이 입력한다.

변수명(변수이름) : JAVA_HOME
변수값 : C:\Program Files (x86)\Java\jdk1.7.0_45
* 변수값은 설치경로에 맞게 수정.

자바설치의 마지막으로 Path라고 변수명이 되어 있는곳에 다음과 같이 추가한다.

;%JAVA_HOME%bin;

모든 이제 cmd로 Command창을 열어 java라고 명령을 내려보면 작동하는걸 확인할 수 있다.

자바가 설치되었으면 MySQL을 설치한다. 물론 다른 DB도 지원한다. (지원 DB : MySQL, Oracle, PostgreSQL, MSSQL) 
일부 MSSQL이 설치되어 있는 분들도 있겠지만, 여기서는 범용성을 따져서 MySQL을 설치하겠다.

http://dev.mysql.com/downloads/
에서 Community server를 다운로드 받아서 설치하자. 
root암호를 입력하고 나면 모든 설치과정이 완료될 것이다.

MySQL이 설치된 경로로 이동하여 다음과 같이 MySQL로 접근하자.

MySQL -u root -p패스워드

다음과 같이 SONAR DB를 생성한다.
CREATE DATABASE SONAR;


생성된 DB를 확인하려면 다음과 같이 명령을 내린다.
SHOW databases;


이제 다음의 명령을 차례대로 내려서 sonar가 사용할 계정을 생성한다.
CREATE USER 'sonar'@'localhost' IDENTIFIED BY 'sonar';
GRANT ALL PRIVILEGES ON SONAR . * TO 'sonar'@'localhost';
FLUSH PRIVILEGES;


아직 한참 남았다. Sonar cube와 Sonar runner를 다운로드 받아서 압축파일을 해제하자.
http://www.sonarqube.org/downloads/

서로 다른 어플리케이션이므로 같은 폴더에 넣지는 말자. =(
먼저 Sonarcube가 압축이 해제된 폴더에서 "conf"에 있는 "sonar.properties"파일을 열고, 

다음의 부분을 찾아서 
#----- MySQL 5.x
#sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true&useConfigs=maxPerformance
다음과 같이 주석을 제거하자.
#----- MySQL 5.x
sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true&useConfigs=maxPerformance
sonar runner가 압축해제된 폴더에 "conf"폴더에 있는 "sonar-runner.properties" 파일을 열어서 다음의 항과 같이 수정하자.
#----- MySQL
sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
#----- Global database settings
sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
#----- Security (when 'sonar.forceAuthentication' is set to 'true')
sonar.login=admin
sonar.password=admin

이제 Sonarcube를 실행해보자.
압축해제한 경로의 bin\window-x86-32\StartSonar.bat 을 실행하면 된다.

접근은 http://localhost:9000/ 로 가능하다.

로그인은 admin / admin으로 접근할 수 있다.

로그인후에 좌측상단의 Setting 을 눌러 "System"아래에 있는 "Update Center"를 클릭한다.
그러면, "Installed Plugins", "Available Plugins", "Plugin Updates", "System Updates" 탭으로 보여질텐데, 그중 "Available Plugins"링크를 클릭하여 다음의 플러그인을 다운받도록 하자.

C# / ReSharper / StyleCop

링크를 누를때마다 install 버튼이 활성화 되는데 꼭 눌러주자.
이 과정이 완료되면 Sonarcube를 재시작해준다.

마지막으로 소스가 있는 폴더로 이동하여 "sonar-project.properties"파일을 생성한다. 
다음과 같이 생성한 파일을 채워넣자.

# Project Identification
sonar.projectKey = Unity 
sonar.projectVersion = 1.0 
sonar.projectName = ProjectPuppy

# Info required for Sonar 
sonar.sources = .

# Comma-separated paths to directories with sources (required) 
sonar.language = cs

# ----- Default source code encoding
sonar.sourceEncoding = UTF-8


이제 Sonar runner를 소스가 있는 폴더에서 실행하는 일만 남았다.
C:\{프로젝트경로}>c:\sonar-runner-2.4\bin\sonar-runner.bat
모든 작업이 완료되면 http://localhost:9000/ 로 접근하여 소스 분석결과를 확인해보자.


2015/02/04 11:06 2015/02/04 11:06
TAG
최근 박준표님과 유저스토리 관련 이야기를 나눴었는데..
그 때의 생각이 나서 간단하게나마 최초 요구사항을 어떻게 도출했는지 사진을 통해 회고하고자 한다.

최고 AKA Snapsh-OO-t이 출시된건 아마도 10월경이었던걸로 기억난다.
이때 우리팀은 현재의 문제점과 고객에게 받은 Keywrord를 나열하였다.

그때까지 나왔던 Key Word를 Postit에 기재하고 예상 일정을 세웠다.
사용자 삽입 이미지
항상그렇지만, 초도 버전까지 정신없이 달리고나면 남는건 향후 개선포인트들이다. 위의 개선 포인트 중 U에 동그라미는 고객의 요청사항이다.
사용자 삽입 이미지
하나씩 그룹핑하다보면 Keyword들이 보인다.

사용자 삽입 이미지
아마도 이까지가 시급히 개선해야할 1차 범위였던 것으로 기억난다.
사용자 삽입 이미지
마지막, 시간이 가능하다면 추가로 진행할 부분이었다.

다시 이를 그룹핑하여 가능한 항목별로 나열하고 실재 일정과 대입하였다.
사용자 삽입 이미지

막상 써놓고 보니, 별로 한일이 없어 보이지만, 치열한 토론 끝에 포스트잇 한장 한장 써붙였다.

잘된 점 
1. 누가 요구사항을 도출했는지를 명확히 구분하였다.
2. 기능별 요구사항을 그룹핑한 결과 일정 추정이 단순해 졌다.
3. 2의 이유로 업무 분장이 쉬워졌다.
4. 요구사항 항목은 결국 한장의 프린트지로 관리되었다.

잘안된 점
1. Why를 기록하지 못했다. 누가 왜 이런 요구를 했는지 중에 "왜"가 빠졌다.
2. 요구사항이 1장의 목록으로 관리되다보니 구현에 집중하면서 정확한 상황을 인식하고 구현하는데 경험요소에 많이 좌우되었다. (굳이 단점이라고 할 것 까지는 없었던 듯 하다.)

인상적이었던 점
1. 1년차에게 기획서 없이 개발한다는 이야기를 들었다. (기획서는 요구사항이 아니다.라는 생각과 배치되어 요구사항 있잖아 하고 넘어 갔는데.. 이건 좀 미스인듯)
2. 요구사항의 중요성을 그토록 토로했지만, 결과적으로 팀내 누구도 체화하지 않았다.(수련이 필요한 영역임에 분명한 것 같음)
3. 실컷 같이 만들어 놓고 "실장님꺼"란 이야기를 들었다. (방송국에서 편집권은 PD에게 있다. PM은 프로젝트 편집권을 쥐고 있는 PD다.)

마지막으로 게임 같은 콘텐츠 개발 방법에 대한 추가 보완이 필요하다.
- 기능적으로 접근하는 방법이 과연 맞을까? 하는 생각이 든다.
- 과거 웹에서는 데이터 Driven 으로 개발되는 사례가 많았다. 그와 같은 방식으로 회귀해야 하지 않을까?
- RichClient & X-Internet 개념은 모바일 게임에서도 여전히 유효한듯.

여러가지 교훈을 남겼던 프로젝트 였다.
비록 "신뢰를 얻는 스킬의 부족"일지라도 내 방식은 "진심은 통한다"이다.
굳이 못하는거 안하는게 답인듯...
2015/01/22 00:42 2015/01/22 00:42
출처는 이전의 AES 방식(링크 : http://www.wolfpack.pe.kr/828) 과 같이.. 까먹었슴돠..

using UnityEngine;
using System.Collections;
using System.Security.Cryptography;
using System.Text;

public class MainTester : MonoBehaviour {

 string _x = "";
 UTF8Encoding ByteConv = new UTF8Encoding();
 RSACryptoServiceProvider RSA = new RSACryptoServiceProvider();
 
 // Use this for initialization
 void Start () {
 _x = "Hello!!!";
 byte[] _encText = Encryption(ByteConv.GetBytes(_x), RSA.ExportParameters(false), false);
 Debug.Log( ByteConv.GetString(_encText) );
 Debug.Log(ByteConv.GetString(Decryption(_encText, RSA.ExportParameters(true), false)));
 }
 
 static public byte[] Encryption(byte[] Data, RSAParameters RSAKey, bool DoOAEPPadding)
 {
 try
 {
 byte[] encryptedData;
 using (RSACryptoServiceProvider RSA = new RSACryptoServiceProvider())
 {
 RSA.ImportParameters(RSAKey);
 encryptedData = RSA.Encrypt(Data, DoOAEPPadding);
 }
 return encryptedData;
 }
 catch (CryptographicException e)
 {
 Debug.Log(e.Message);
 return null;
 }
 }

 static public byte[] Decryption(byte[] Data, RSAParameters RSAKey, bool DoOAEPPadding)
 {
 try
 {
 byte[] decryptedData;
 using (RSACryptoServiceProvider RSA = new RSACryptoServiceProvider())
 {
 RSA.ImportParameters(RSAKey);
 decryptedData = RSA.Decrypt(Data, DoOAEPPadding);
 }
 return decryptedData;
 }
 catch (CryptographicException e)
 {
 Debug.Log(e.ToString());
 return null;
 }
 }
}


암호화 결과 : 0BB@�{8n��*�b"�FN?s�
복호화 결과 : Hello!!!
2015/01/20 15:40 2015/01/20 15:40