잔물결 ~스프링노트 지부~

고고마트

Thu, 20 Aug 2009 00:24:35 +0900

고고 마트 -오필순 여사 가족 생존 일지-

> 고고마트 다운받기

현재 2008/05/28~2008/06/02 동안 다운가능합니다. (기간이 지나면 계속 갱신합니다.) 7zip으로 압축했습니다.

사정상 다운은 막아뒀습니다. 필요하신 분은 연락바랍니다.

> 고고마트 작업 중 스프링노트

여과 없이 그대로 보여드립니다.

> 고고마트에 대한 변

고고마트 만들 당시에 이야기입니다.

> 4gamer에 실린 고고마트

엉겹결에 일본 웹진에서 취재를 해버렸네요. 학교 졸작 발표회 때 일입니다. 굴욕적으로 팀장이 "조영훈"으로 되었군요.

> 고고마트 영상

고고마트 플레이 영상입니다.

개발 기반

Direct X 9.0b

Lua 5.1 License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, dist ribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

요구 사항

펜티엄4 2기가 급 이상, Ati x1400이상, Nvidia 7300이상, 1기가 이상이면 무조건 가능합니다.

Core 2 Duo 급 정도면 쾌적하게 진행됩니다.

network 플레이나, 스코어보드는 고고마트 2.0에서 찾아뵙도록 하겠습니다.

(언제가 될지 모르지만, 팀원 전체가 언젠가 만들고 싶은 소망을 가지고 있습니다.)

개발 인원

Team GGRG in CK

컨셉 및 전체 기획 : 유승환 inthefate@hotmail.com

오브젝트 및 배치 기획 : 박현행

클라이언트 프로그래밍 : 최형석

웹스코어보드 프로그래밍(시도) : 김대희

루아 스크립트 : 이재근 (메인), 김종민 (보조)

원화 및 캐릭터 모델링 : 고수지

오브젝트 모델링 및 아이템 디자인 : 조영훈

캐릭터 애니메이션 : 김현아

그래픽 보조 : 유승환 (UI & MAP & 동영상)

사운드 기획 및 사운드 제작 : 유준영

기획 조언 : 주민석

스크린샷

맥스 스크립트

Fri, 18 Jul 2008 23:20:10 +0900

다음 글은 학과 까페에 올린 맥스 스크립트 활용에 대한 이야기입니다.

사실 완벽하게 사용했다 까지는 말하기 어렵습니다. 100% 알고 했다기 보다는

몰랐기 때문에 처음부터 시작해 본거지요. 그나마 루아스크립트라도 배워 놓은게 다행이었습니다.; (감사합니다. 심현보 교수님 ㅠㅠ)

Book1.csv

Object_Collect.ms

안녕하세요. 이번에 졸업한 유승환입니다. 사실 오래전에 졸작에 대한 이야기로 여러분께 이야기 하려고 했는데 이런저런 핑계만 스스로에게 늘어 놓았군요.

대단한 작품을 만든 것도 아니고, 그렇다고 후배분들에게 아주 으스댈 만한 제작 기법이나, 노하우를 가지고 있는 것은 아닙니다. 단지 여러분께 당당하게 말할 수 있다는 것은 아무것도 모르는 사람들이 모여서 하나의 완성품을 만들었다는 것이겠죠.

모르겠습니다. 올해 지스타에서도 무슨 말들이 오갈지는. 그저 여러분께 바라는 것이 있다라면 지금 현재 여러분들이 만들어가는 여러분만의 "자식"을 만들어 가는데에 보람을 느꼈으면 하는 바램입니다.

사설이 매우 길었군요. 자 그럼 설명 하도록 하죠.

사실 설명할 것도 없습니다. 순전히 "제로"부터 만들어 나간 것은 아니라서요. 레퍼런스를 참조 한 것이 다소 많기 때문이죠. 하지만 이런 방법도 있구나 하는 것만 이해 하신다면, 제가 말하는 게 무엇이었나만 이해 하신다면 좋겠습니다.

저희 GGRG 팀에서는 이러저러해서 외부에서 맵의 좌표를 가진 파일을 파싱하여서 쓰는 방식을 채용했습니다. (프로그래밍 인 루아 "파일 입출력 참조") 쉽게 설명해서, 좌표를 입력한 텍스트 파일을 루아에서 읽어들여서 클라이언트로 보내주어 해당 좌표에 오브젝트를 뿌려 주는 것이지요.

그런데 여기서 문제가 발생 했습니다. 오브젝트가 굉장히 늘어남에 따라 이를 일일이 수기로 입력하는 기획파트에서도 혼선이 발생하는 것입니다. 물론 해당 좌표에 대한 문서는 보관이 되어 있지만 어디서 에러가 발생하는지 그런 것은 파악하기가 힘들었습니다. 즉 완전무결성에서는 참 힘든 일이 발생했던 것이죠.

게다가 일일이 수기로하니 몇번의 작업을 더 해야 했었고, 이에따라 다른 파트도 일이 늦어지게 되었습니다.

안되겠다 싶었죠.

자 여러분은 여기서 어떻게 하시겠습니까? 그냥 수기로 계속 하시겠습니까? 혹은 다른 서드파티 툴을 이용하던가. 촉박한 시간에 한정된 인원에서 프로그래밍 파트를 조여서라도 맵툴을 만드시겠습니까?

물론 모두 가능한 이야기입니다. 심지어 규모를 줄이는 것도 가능한 이야기입니다. 어떤 선택을 하시는지 간에, 훌륭한 선택을 하시는 겁니다. 포기 하시는 거라고요?

포기 하지 마십시요. 포기는 적절한 선택이 될 수 없습니다.

전 조금 다른 생각을 해보았습니다. 적절한 선택은 아니였고, 조금은 위험한 방법이었죠. 프로그래밍에 "프"도 모르고, 이론이라고 조금알며, 루아 스크립트 조금 다루어 본 기억밖에 없는 제가 선택한 방법은

맥스 스크립트를 이용하는 것이었습니다.

맥스 스크립트가 뭐지? 라고 하시는 분은 모르셔도 상관이 없습니다. 그냥 넘어가셔도 됩니다. 기획 파트에게 꼬옥 필요한 부분은 아닌 거죠.

혹시 지금 어떤 3D 포맷을 이용하지? 하면서 연구 하시는 분들은 "MAX2XML"이라는 것을 아실지도 모릅니다. GPG 스터디에서는 초반에 이 것을 많이 추천하시더군요. 저희는 1학기 동안 형석형님이 끙끙거리다가 버그때문에 급하게 "X"파일로 바꾸었습니다.

(사설이지만...혹시 공부로서 꼭 파고 싶지 않은 분은 그냥 X 파일로 진행하시길 바랍니다. 물론 X파일이 좋다거나 버그가 없는 완전 무결이라는 것은 아닙니다. 메모리 누수도 많고, 버그도 있습니다. 단지 다이렉트 X에서 바로 쓰기 좋고, 또한 익스포터도 구하기 쉽습니다. 추천하는 익스포터는 판다 x 익스포터를 추천합니다. 사용하는 방법은 물어보시면 답해드리겠습니다.)

제가 말한 저 익스포터를 메모장으로 열어보시면 텍스트 형식의 스크립트로 되어 있습니다. 바로 맥스 스크립트를 이용해서 현재 작업하고 있는 작업물에 대한 좌표값이나, 이벤트값등을 XML 형식의 텍스트로 저장해주게됩니다.

이해 하셨나요? 맥스 스크립트는 간단히 말해 맥스안에 끼어있는 확장된 기능이라고 생각하시면 됩니다. 레퍼런스에서 명령어만 알면 루아를 배운 기획 분들도 쉽게 이해 하시리라 생각되며, 프로그래밍을 공부하시는 분들에게도 자신만의 구조로 된 파일을 만들어서 파싱 하실 수 있으리라 생각됩니다.

(최근에는 맥스 안에 들어있는 SDK를 이용해서 프로그래밍해서 만들더군요. iGameExport부분에

나와 있습니다. 사설로 제가 초반에 익스포터 구한답시고 저걸 컴파일해서 강제로 박아 넣을려고 그랬죠. -_-; 그러지 마세요 XML의 장점은 여러분이 맘대로 규정을 만들 수 있지만 반대로 정해진 최소한의 규정을 빼고는 서로 다르답니다;)

제가 생각 했던 것은 다음과 같습니다.

MAX -> 좌표를 가진 데이터 -> 좌표를 출력 -> 편집이 용이한 텍스트 형식 파일.

이런 방식은 한시간 안에 후딱 만들 수 있었습니다. 조금 익숙해 지는 군요.

MAX -> Position -> Write -> CSV

그래서 조금 바꿨습니다. 루아를 담당하던 이재근 군과 대화를 하고 ,로 각 구문을 구분하는 파일로 전달 하면 서로 편하도록 말이죠.

그래서 각 부분을 ","로 구분하는 즉, CSV의 형식의 파일로 출력 하도록 했습니다.

해당 파일에 대해서는 자식까지 찾아 넘기는 네이버 지식인에서 찾아 보시고, 간단하게 데이터베이스를 저장하는 파일 형식이라고 생각하시면 됩니다.

이것의 장점이 엑셀에서 편집할 수 있다는 것이죠. 에디트플러스 같은 문서편집기에서 데이터를 편집한다는 것과, 엑셀에서 편집이 가능하다는 것은 천지차이입니다. 5시간동안 해야 할 일을 1시간 아니 10분에 끝낼 수 있다는 것이죠.

맥스를 켜서, 오브젝트를 막 깔아 둔 상태에서, 해당 스크립트를 돌리면 아무 일도 안일어 난거 같습니다만, 버젓히 파일이 생성되어 있습니다. 실력이 부족해서 툴처럼은 못많들었네요. 시간도 여유로웠으면 비쥬얼한 맥스 플러그인을 만들 었을 텐데요. 그럼 여러분께 도움도 되었을 텐데 아쉽습니다.

자 부족한 부분은 엑셀로 편집하고 이걸 저희 프로젝트에 집어 넣으면 해당 좌표에 오브젝트가 출력됩니다. 생각 보다 쉽죠. (사실 오브젝트의 회전 값까지 해볼려다가 시간 부족 및 연구 부족으로 하다하다 안되서 그것은 수기로 했습니다. -_- 불편함이 많은 플러그인인건 확실 합니다.)

스크립트 구문에 대해서는 설명하지는 않습니다. 이런 방법이 있구나 하고 보시라고 올리는 거고요. 저도 사실 2시간 동안 하면서 만든거라, 가르치기 적절하지도 않네요.

혹자는 이럴지도 모르지요.

"기획에서 이 정도까지 해야해?"

아닙니다.

"기획에서 이것밖에 못해?"

가 맞습니다. 이번 프로젝트에서 그래픽 보조도 해보고, 맵도 만들고, 인터페이스도 만들고, 구성도하고 했지만, "와 나 정말 많이 했어" 생각 들면서도 막상 떠올려보면 "더 할 수 있지 않을까" 라고 생각도 듭니다.

문서만 쓴다고, 아이디어만 낸다고 기획이 아닙니다. 문제점이 뭔지. 어떻게 해결해 나갈건지에 대해서 고민도 하고 서로 의견을 내어 결과로 이끌어 가는 것이 기획이라고 생각합니다.

기껏 아마추어 게임 한번 만들어 보고 별 말을 많이 하네요. 저도. ㅎㅎ

당부 드릴것은, 지금 바로 앞에 있는 것 만이 방법은 아닙니다. 찾아보면 여러분이 생각지도 못한 방법이 많고, 그 방법은 교수님들께서 도시락 싸들고 다니면서 숟가락으로 퍼 먹여 주신다고 생각 하지 말았으면 하는 바램입니다. 방법은 자신이 찾는 것이 정말 현명한 사람입니다.

그럼 졸작 잘 하시고요. 정말 좋은 결과 기대하고 기다립니다. 화이팅

//파일 포함했습니다.

//밑에는 해당 파일에 대한 설명입니다.

----------------------------------------------
-----2007.10.22, 유승환
-----GGRG 팀 전용 MAX 2 CSV
-----김용준 님 맥스 스크립트 메뉴얼과 맥스 스크립트 레퍼런스를 참조해서 만든 조약한 스크립트입니다.
-----저희 팀 전용으로 사용됩니다.
-----앞으로 이후 졸작 팀에서도 맥스 스크립트를 유용해서 좋은 결과가 있었으면 하는 바램으로 시도해 봅니다.
-----스크립트 학습 2시간만에 만든 0.5 버젼입니다.
-----inthefate@hotmail.com
-----본 스크립트를 실행하면 루트 폴더에 CSV 파일이 생성됩니다.
-----엑셀로 편집하셔서 사용하시면 됩니다.

       ff = "c:\object pos.CSV"

-- 파일 명

f = createFile ff

-- ff의 이름으로 파일을 생성하라고 지시합니다. ff는 앞에 나온 파일명이라는 변수로 지정되어 있습니다.

format "Max 2 CSV,\n" to:f

-- "$"이라는 스트링을 받아서 출력합니다. 이때 to:f 를 이용 f로 보내라고 지시합니다.
-- 위의 구문은 print 문으로 할 경우에는 맥스 스크립트 리스너로 출력되더군요. (기록쪽은 모르겠습니다.)
-- to:f 를 지시하지 않을 경우에는 맥스 스크립트 리스너로 출력됩니다. 확인하세요.

format "NAME,%,\n" maxFileName to:f

-- maxFileName에서 파일 이름을 얻어 온 후에 %에서 받습니다. 이후 과정은 위와 같습니다.
--% 경우 뒤에 순서대로 받게 되니 갯수가 뒤에 변수와 같지 않을 경우 에러를 뱉게 되더군요.

format "OBJECTCOUNT,%,\n" objects.count to:f

-- objects라는 속성을 가진 것들의 count 수를 구해서 보내줍니다.

select $

-- 여기서 조금했갈렸는데...간단합니다. $는 선택한 것이라는 것이니 선택한 것을 선택한다고 이해 하면 됩니다.
-- 전부다 변환하고 싶으시면 $*으로 해주세요. 전 처음에 그렇게 했다가 필요한 메쉬만을 선택하기 위해서 풀어 놓은 상태입니다.
-- 이 외에도 폴리 상태나 혹은 여타 이름만을 선택 하는 방법도 가능하고요. 자세한 것은 맥스 스크립트 레퍼런스에 더 잘나와 있습니다.

objs = $

-- $위에 구문과 같이 설명 해야 하는 건데..objs를 $로 지정해 주는 것입니다.

         for o in objs do

             (
    --pos.n //n좌표로 출력
    format "type,%,%,%,%,1,0\n" o.name" o.pos.x o.pos.z o.pos.y to:f

  )

-- 하나하나 오브젝트에 대한 내용을 모두 돌려야 겠죠?
-- 그래서 for 문을 사용합니다. 저도 정확하게 구문을 이해 하고 있는 것이 아니라서 뭐라고 말씀을 못드리지만
-- objs를 o로 지정한 후에 돌리는 듯 합니다.
-- (대상).pos 는 해당 대상의 좌표를 뽑아 오는 것으로서 응용방법으로는 버텍스 좌표나, 엣지, 페이스 좌표도 뽑아 올수 있습니다.
-- 저는 필요 했던 것이 오브젝트의 x,y,z 좌표였기 때문에 o.pos.x 등으로 지정했습니다.(어디에도 안나왔길래 그냥 해보니 되더군요...)

close f

-- f의 행동을닫아줍니다. 그럼 종료 되는 것입니다.

=======================================================================================

ps. 계속 공모전 결과가 뒤로 미루어지네요. 뭐가 되었든 간에 빨리 연락이 왔으면 좋겠는데 ㅎㅎ

-폐기 2. 기본 룰 디자인

Wed, 14 May 2008 01:15:45 +0900

2. 기본 룰 디자인

(1) 목적

- 플레이 시작시에 부과되는 물건 구입 목표를 임의로 결정. 해당 목적의 아이템을 획득하여야 하며. 아이템에 포함된 속성인 만족도를 가족에 맞추어충족시켜야 함

마트를 배경으로 하여 플레이어가 필요한 물건을 구입하는 것을 게임으로 묘사하는 것을 목표로 한다.
이때 목적이 되는 물건을 찾고 돌아오기 까지가 목적이 된다.
3인칭 후면부 시점에 카메라 위치하여, 캐릭터의 뒷부분과 마트 전경 전체를 볼수 있도록 한다.
개인 플레이 / 네트워크 플레이 기본적인 룰과 시스템은 동일하다.
가족에 성향에 따라 욕구가 달라진다. 각 성향은 만족도에 영향을 주며, 모든 품목은 각각의 기호에 따른 만족도 속성을 지니고 있다.

그림 B2 - 1

정해진 시간내에 가족들이 원하는 물품을 구입하고 계산대까지 돌아오는 것 까지 최대한 가족을 만족시키는 것에 중점을 둔다.
물품에 대한 호감도를 수치로 두어 습득시에 가족 호감도에 적용.
상황에 대한 Event를 두어 상황처리
마감시간이라는 시간적 제한 설정을 넣어, 최초 시작 시간 부터 감산되는 시간 범주안에서 플레이어의 행동이 제약된다.
시간내에 돌아오는 플레이어에게 자신의 최상의 포인트를, 시간내에 돌아오지 못하는 플레이어에게는 감산된 포인트가 주어진다.

필요 피라미터 : 3인의 만족도 (a, b, c) , 시간

부가 피라미터 : 돈 (가산형) , 할인율 (가산되는 돈에 대한 퍼센티지 환산 포인트) --> 추가될지에 대한 부분은 미지수.

(2) 출 발

맵의 구조는 단층형 정돈된 구조의 미로 형태. 자체적인 구조는 창고형과 백화점형의 중간 형태로 번거롭게 물건이 많이 쌓여있지 않지만, 품목이 다양하므로 설치형 구조물이 배치되어 있다.
플레이어의 출발 위치는 동일 선상이며, 최대 4인 플레이를 고려 출발 위치는 4개의 카트가 들어갈 정도로 배치한다.
캐릭터의 출발 위치에는 개설된 게임룸에서의 "플레이어 아이디 넘버"를 따오며 자동으로 상속받아 배치한다.

그림 B2 - 2

= 이때, "Ready" 신호를 먼저 누른 순서부터 "1~4"중에 임의의 수 N¹(1≤N≤4)을, 그 다음 번은 N을 제외한 숫자를 "1~4"사이의 임의의 수 N²을, 나머지 두 플레이어에게 남은 숫자 N³, N⁴ 를 분배하여 가장 작은 수 부터 플레이어를 배치한다.

= 출발 위치 넓이는 70 X 4 보다 살짝 넓은 정도이며, 의도적으로 4대가 겨우 들어갈 정도로 배치한다.

= 플레이어의 배치와 맵에 대한 계산, 로딩이 완료된 후에 카운트 다운이 시작된다.

= 카운트 다운은 초단위, 3초 --> 2초 --> 1초 --> START! 순으로 화면에 출력된다. (실질적으로 출발하기까지 4초가 걸린다.)

= 3~0까지 카운트 다운이 마무리 될 때 까지 플레이어의 이동값은 잠금 상태로 고정이 된다. (주 : 이에 해당하는 이동 잠금/해금에 대한 이벤트 명령이 필요.)

= 카운트 다운이 완료되면 플레이어에 대한 이동값이 풀리게 되고 이동에 대한 키입력이 입출력되게 된다.

(3) 순서도

그림 B2 - 3

시작과 함께 자신이 가지고 있는 만족도 a, b, c와 구입 물품이 설정되게 된다.
만족도 값은 기본값이 "a" 동일하게 지정된다. 아이템은 관련 연산에 의해 배치된다. --> 아이템 참조.
플레이어에게 행동의 제약을 주는 규칙으로는 1) 시간과 공간의 이동 2) 룰에 따른 규칙성 을 제외하면 자유스럽게 돌아다닐수 있다. (충돌에 의해 맵 밖으로는 돌아다닐 수 없다. 맵을 벗어난 부분은 리소스적으로 만들어 두지 않는다.)
일반적인 물품 습득의 경우에는 습득하였나 하지 않았나에 따라 변동된다. 습득하지 않았을 경우에는 아무런 행동변화가 일어나지 않는다. (게임 플레이 부분에 루프)
물품을 습득하였을 경우, 각 물품에 대한 만족도 데이터값을 각각의 데이터에 맞게 반영한다. a 만족도에 대한 속성이 감소일 경우 정해진 만큼의 피라미터를 빼며, 상승일 경우 정해진 만큼의 피러미터를 더하고, 변동없을 경우 그대로 반환한다. (감소의 경우 좋아하지 않는다, 상승의 경우 좋아한다, 변동없을 경우 관심없다로 표현된다.)
만족도에 대한 처리가 완료되면 UI에 실제적으로 표시되고 습득품에 대한 정보값을 가지고 있게 한다. --> 인터페이스 상 키로 인한 표시를 한다.
상황에 대한 처리는 물품습득에 대한 퀘스트 형식으로 부여된다. (기본적인 속성으로서 물품 습득에 대한 내용은 변하지 않는다. 다만 무엇을 구하느냐에 대한 규칙이 정해지게 된다.)
상황은 크게 급격 세일 품목에 대한 규칙과 가족 호출 상황 규칙이 주어진다. --> 각부분에 대한 설명은 각 항에서 설명한다.
상황은 시간으로 그 제약을 두게 한다. 시간내에 상황을 만족하면 물품 습득에 대한 규칙에 따라 값을 받으며, 습득하지 못한 경우에는 그 상태로 상황을 종료한다.
상황에 따라 다르나 일반적인 물품에 대한 만족도는 그에따라 만족도에 대한 값이 부과되며, 상황 만족 종료 보상으로 보상값을 더 받는다.
특수 상황에 대한 값은 그에 따른 만족도를 부가받는다.
게임 전체를 총괄하는 시간이 종료 될때 까지 위와 같은 순서를 반복한다. 정해진 시간내에 종료시점까지 지정된 종착지점까지 돌아오게되면, 전체적인 데이터를 포인트로 환산하여 결과를 산출한다. 시간내에 돌아오는 조건을 만족하지 못할 시에는 정해진 포인트에서 감소된 일부의 포인트만 부여받게 된다.

(4) 만족도

- 새로운 부분입니다. 잘 봐주세요. -_-

= 사람마다 좋아하는 것이 부분부분 혹은, 극명하게 다르게된다. 기호도적인 측면에서 자연스러운 것이며 데이터화 시키기 어려운 부분이다. 기호도를 수치적으로 분활 하여 해당 물품에 대한 호불호를 나누도록한다.

그림 B2 - 4

예를 들어 초컬릿이라는 물품을 구입하였을때 가족들의 반응이 다음과 같을때, 전체에 대한 호감적인 반응이 아닌 상대적인 반응으로 다가온다. 딸은 달콤하고 트렌드에 따라간다. 남편은 단것을 싫어하고 술이나 생선류를 좋아한다. 복학하는 큰아들은 뭐든지 잘먹지만 간식거리엔 큰 흥미가 없으며, 당근에 취약하다. 이렇게 되었을때, 간식류이며 단것에 속하는 초컬릿에 대한 상대적 호감도가 나뉘어 지게 된다. 즉

딸은 초컬릿을 좋아한다. 그래서 수치가 상승한다.
남편은 초컬릿을 싫어한다. 그래서 수치가 하락한다.
큰아들은 초컬릿을 뭘 먹든 상관안한다. 그래서 수치 변동이 없다.

이에 따른 수치 변화량이 데이터에 반영이 되고, 화면 좌측하단에 표시될 그래픽 인터페이스에 표시가 되게 된다.

그림 B2 - 5

*본 피라미터는 예시로 보여지는 것입니다. 실질적인 디자인은 UI 부분에서 결정된 안에 따라 진행합니다.*

호불호는 캐릭터의 성격에 따라 조합이 가능해지며, 초기 설정을 그대로 따르도록 한다. 대상 오브젝트에 대한 호감도를 캐릭터 데이터에서 가지고 있는 것이 아니라, 오브젝트 속성안에 캐릭터에 대한 호감도 값을 가지고 있는 것으로 한다.

그림 B2 - 6

좋아하는 것에 대한 정보는 호불호가 극명하게 갈리기도 하지만 공통적으로 좋아하거나 겹치는 부분이 존재하게 된다. 이는 교집합 혹은 합집합으로 표현하고 데이터화 가능하다.

그림 B2 - 7

좋아하는 것에 대한 기준은 각자에 따라 달라진다. 즉 극명하게 좋고 나쁨을 나누는 기준은 캐릭터에 기본적으로 설정된 기호에 맞추어 수치화한다.

그림 B2 - 8

기본적인 수치는 수치에 아무런 영향을 주지 않는 "0" -null-을 보통으로 잡는다. (이는 관심이 없다는 것을 뜻한다.)
보통을 기준으로 만족의 수치는 점진적으로 증가하며, 이는 물품을 습득하는 것에 대한 만족을 뜻한다.
보통을 기준으로 만족의 수치가 -화 되어버리면, 이는 물품을 습득하는 것에 대한 불만족을 뜻한다.
"만족"의 반대는 "불만족"이 아니다. 만족하지 못한다가 된다. 설정상에 좋아하는 것 미리 준비 되지 않았다고 해서, 좋아하지 않는 다라는 것으로 내리지 않는다.
따라서, 좋아하는 것에 대한 설정과 함께, 관심정도를 데이터화 한다.

만족도는 모든 습득형 오브젝트에 정보를 가지고 있으며 플레이어가 습득함에 따라 별다른 제한이 없으면 그대로의 데이터를 받고 반환하게된다.

좋아하는 호감도가 완전히 갈리는 것만은 아니다. 동시에 좋아 할수도 있으며, 모두가 싫어 할 수도 있다. 교집합, 차집합의 속성 부분에서도 특징적으로 규칙이 달라지지 않는다.

(4) 상황

- 플레이어에게 주어진 목적은 좀더 가족을 만족시켜줌과 동시에 퀘스트 형태의 부여된 상황을 처리해야 한다. 일정 조건을 만족시켜 퀘스트를 발동시키면 그에 따른 해결과정을 거쳐 완료한다. 상기에 명시된 거와 같이 다른 게임에서 나타나는 "퀘스트"라고 하면 되겠다.

상황은 크게 두가지로 속성이 나뉜다.

1) 가족 호출 조건 상황

2) 한정 세일 조건 상황

1) 가족 호출 조건 상황

가족들의 요청에 따라 필요한 물건을 구입하는 조건. 최초 발생과 동시에 게임이 종료 될 때 까지 시간 제한 없이 진행하는 초기 상황, 그리고 일정치의 만족도에 도달 했을때 발생하는 중간 상황으로 이어진다.
필요 상황을 코믹하게 도입한다. 상황에 따라 원하는 품목, 보상치가 다르다. 또한 현재 플레이어가 위치하는 코너에 따라 상황도 달라진다. 위치 별로 지정된 이벤트 값을 충족하면 해당 이벤트를 호출하게 된다.
가족 호출 조건 상황을 만족하게 되었을때, 해당 물품을 원하는 가족원은 본래의 만족도 보다 더 많은 만족도를 충족하게 된다.
만약 완료하지 못했을 경우, 해당 구성원의 만족도가 하락하게 된다.

2) 한정 세일 조건 상황

가족 호출과 부여되는 목표나 조건은 비슷하다. 단, 표면적으로 사람이 원해서 얻는 물품이라는 이미지가 아닌, 물품에 이끌려 가는 이미지라는 점이 다르다.
시스템은 동일하다. 특정 위치에 들어서면 세일에 관련된 상황을 부여 받게 된다.
음성으로 세일 상황을 알리고, 동일하게 인터페이스 상에서 제한 시간과, 상황이 표시된다.
시간내에 마무리 되면, 가족 전원의 만족도가 상승하게된다.

= 상황의 순서

조건 : 게임 맵을 화면에 뿌리면서 동시에 이벤트 위치 값 생성. 각 이벤트에 따른 속성이 위치에 부여된다.
각 이벤트에 따라서는 플레이어의 보유 피러미터에 따른 값에 따라 발생하는 이벤트도 있다. 예를 들어 가족 구성원 중 과자를 좋아하는 사람의 만족도가 하락하였을때 만족도를 올려주기 위한 이벤트성으로 과자 가져오기 상황이 발생할 수도 있다.

기본적인 발생 조건은 지정된 위치에 플레이어가 도달하게 되면 플레이어는 동시에 발생 하게 된다.

화면 내에 2D 컷신으로 상황에 대한 이벤트 발생을 알린다.

한계 시간이 인터페이스 상에 출력이 되며, 목표 물품이 무엇인지 표시 되게 된다.
시간은 점차 감소하며 플레이어는 목적이 있는 곳까지 도달하여야 한다.
시간내에 물품을 습득하였을 때 플레이어의 가족 구성원 만족도는 이벤트에 따른 보상으로 보상 받게 된다.
시간내에 물품을 습득하지 못하였을 때 플레이어의 가족구성원의 만족도는 이벤트에 따른 감산을 받게 된다.
이벤트 종료 후에 시간계와 이벤트에 집중되었던 모드는 모두 해제되게 된다.

고고마트에 대한 변

Mon, 05 May 2008 09:39:33 +0900

고고마트에 대한 변

유승환

시작

06년 졸작 도중에 방향성을 핑계로 쉬어버리고, 07년 겁없이 팀을 만들겠다고 생각 중에 떠오른 아이디어를 구상 중이었습니다. 다른 게임들을 참고하거나 혹은 본래의 성격대로 했더라면 좀더 쉽게 풀어갈 수 있지 않았나 싶었지만, 최소한 몇개의 전재 하에 게임을 만들자 라는게 주안점이었습니다.

첫째, 폭력적이지 않을 것.

둘째, 조작이 복잡하지 않을 것.

셋째, 만드는 우리가 즐기면서 만들 수 있을 것.

그래서 나왔던 아이디어가 "소달구지 경주" 등 몇가지가 있었습니다. "소달구지 경주"는 지금 생각해도 아쉽기도 했지만, 당시 아이디어 대로 만들었다면 결코 완성시키지 못했을 것 같습니다. 파종 시스템 등 고고마트 보다 기술적으로 걸리는 것이 좀 많았을 거라고 생각되는 군요. (하지만 역시 재미있을 것 같았습니다. 전통 문화와 연결되는 게임은 언젠가 만들어 보고 싶은 심정입니다.)

고고마트에 대한 구상의 시작은 사실 별 것 아닌 일로 시작 했습니다. 평소에도 장보기를 좋아했던 터라, 간만에 마트에 갔을 때, 문뜩 이런 생각이 떠오르 더군요.

"카트를 미는 거, 재미있지 않을까?"

원흉은 모두 이놈이다.

바로 다른 거 없이 당시 팀원이었던, 고수지 양과 김종민 군, 그리고 일본에서 합류 할 조영훈 군에게 이야기를 해주었죠. 바로 OK 승인이 떨어졌습니다. 그때가 1월. 다른 팀들은 이미 시작하고 있을 때, 저희는 저 혼자서 기획 초안을 끙끙거리면서 작성하고 있었습니다. 다른 팀원들은 각자의 사정하에 일이 있었죠.

지금 생각이지만, 많이 외롭기도 했고, 모르는 것도 많았습니다. 제작 방식이라던가, 기획서 작성 요령이라던가 아무 것도 몰랐죠. 지금도 아는 것은 없지만, 적어도 그때 만큼은 그게 가장 힘들었기도 했고, 혹은 아무것도 모르니 별별 생각을 다 넣을 수도 있었습니다.

대충 이런 짓을 하면서 혼자 흡족해 했습니다. (학과의 박찬일 교수님은 이런 것을 원하시더군요.)

100% 본인 작입니다.

자. 대충 밑그림이 그려졌습니다. 저의 밑그림은 이랬죠.

폭력적이지 않으며 누구나 할 수 있다. 마트를 소재로한 코믹한 게임. 쉽게 할 수 있어야 한다. 속도감과 조작감을 동시에 느낄 수 있어야 한다.

이때 게임 기획이 어땠는지는 설명하지 않겠습니다. (가슴만 아파집니다. 이때 포기한 것이 많기 때문에..)

그런데 개학하면서 정작 저희팀에 다른 문제가 생겼습니다. 바로 인원수가 문제였죠.

팀

팀원 문제는 처음부터 끝까지 저희를 따라다녔습니다. 이미 작년 2학기 말에 왠만한 팀들이 조직이 되었었고, 저희팀이 있는지 조차 방학 중간 발표까지 교수님들도 모르셨습니다. 인원 구성이 기획 둘, 그래픽 둘 뿐이었습니다. 뼈대가 되는 프로그래밍이 없다는게 말이 됩니까. 그래서 개강을 하자마자 프로그래밍 구하기가 급급했습니다. 결국 구하긴 했지만, 당장에 뭔가 결과를 얻어내기란 힘든 두 사람이었습니다. 그래픽 팀원 한명은 어렵지 않게 모을 수 있었습니다. 그러나 역시 숨겨진 복병이 되어 버릴 줄이야. 회사를 다닌다면서 결국 이름만 오른 팀원이 되어 버렸습니다. 업친데 덥친격, 프로그래밍 친구 한명은 이겨내질 못하고 휴학을 해버렸죠. (난 아무것도 하질 않았는데. -_-;)

그러나 불행중 다행으로 실력자를 모실 수 있었죠. 00학번의 형석형님인데, 참 이분 없었으면 어떻게 할 수 있었겠는가 싶었습니다. (도중에 트러블이 있었지만, 다들 잘해보자 있었던 일이니.) 그리고 사운드 팀원으로 유준영이라는 친구를 얻을 수 있었습니다. 그것이 4월 말. 다른 팀들이 모두 프로토 타입을 뽑아 내고 있을 때, 첫 걸음이 시작 되었습니다.

밑바탕 조사

조영훈 군이 일본에서 조사해온 일본 마트 사진도 있었고, 주변에서 끌어 모은 자료가 있었지만, 어딘가 모르게 석연치 못했습니다. 수회의 마트 방문을 하면서 이걸 사진으로 담아가고 싶다고 생각했죠. 그래서 결심했습니다.

"이마트에 이메일을 보내자."

...다음날 이마트에서 전화가 오더군요. 학교의 협조 공문이 있더라면 가능하다라고. 그래서 다음날 학과장님께 가서 당당하게 요청했습니다.

"협조공문 부탁드립니다. 교수님"

학과에서는 처음이라는 군요. 이런 협조공문까지 받아가면서 조사한다는 것이.

덕분에 많은 사실에 대해 알 수 있었습니다. 마구 잡이로 배치되는 것이 아니라는 점, 마트의 폭과 너비, 그리고 배치등이 철저한 조사에 의해 결정 된다는 점이 매우 흥미로웠습니다. 어떤 의미로 이것이 "레벨디자인"이구나 싶었습니다.

아쉽게도 이러한 점이 게임에 제대로 반영되지 못했다는 것이 아쉬웠습니다. 그래도 냉장고와 오브젝트를 만들어 내는데 중요한 재산으로 쓰였다는 것은 분명하네요.

가능했다면 모두 표현하고 싶었습니다. 기술적으로 어려움이 많아서 포기. 오르는 길은 멀고도 험하더군요.

어려움

인원 문제를 해결하고 나니, 갈아 엎게 되는 게 많아지더군요. 전년의 경험과 조언에 따라 공개 엔진을 사용하려고 했건만, 프로그래밍 파트의 욕심으로 결국 자체적으로 만들기로 결정되면서 행보가 늦어졌습니다. 더군다나 처음에 결정했던 파일 포맷에서 다시금 xml로 전환 해서 진행 했어야 했죠. (후에 와서 나온 말이지만, 그때의 결정이 후회된다 라고 형석형님이 그러시더군요. 문제가 많았던 포맷이었습니다.) 그리고 타 팀에 비해서 그래픽 팀원이 해야 할일도 많았고, 그래픽 작업에 어려움을 많이 느끼는 조영훈 군의 재교육 문제도 있었습니다. 그리고, 예상치 못한 복병, 회사원 그래픽 팀원이 아예 아무것도 할 수 없는 상태로 되어버렸죠. (이에 대해 비난도 무엇도 하지 못했습니다. 자신의 길을 남이 강요 할 수는 없는 노릇이었죠.)

그리고 또 하나의 문제는 기획 파트가 두명인데, 일에 대한 집중은 저에게 몰아졌다는 것도 큰 문제였습니다. (김종민 군에 대한 평가를 절하 하려는 것은 아닙니다. 단지 그로인해 이래저래 발목잡힌 일이 좀 있었습니다.) 그 문제는 2학기에 박현행 군이 기획으로 들어 오면서 짐을 그나마 덜어낼 수 있었고, 일정 부분은 "프로토 타입" 목표를 정해두고 큰 틀은 팀장인 제가 잡고, 작은 틀은 각자가 자율에 의해 짜 맞추어 가는 것으로 짐을 덜어 내었습니다. 막판에 그래픽 파트 욕심(?)으로 엉겹결에 맵 그래픽까지 떠 맡는 팀장이 되어 버렸는데, 그 때문인지 저를 그래픽으로 오인하는 사람들이 좀 있더군요. (팀 내 직함은 "팀장 및 메인 기획 및 UI 그래픽 및 맵 그래픽 및 그래픽 보조"가 되어 버렸군요.)

모든 팀원들에게 업무가 과중되었습니다. 기술적으로, 기능적으로 각자의 욕심을 조금씩 버려야만 했습니다. 그래서 기획안도 그때마다 수정되고 버려지고, 고쳐졌죠. 하지만 기본적인 소재와 방식은 버리지 말자고 다짐했습니다. 점점 늘어지면서 문서화 과정에 연연하는 것 보다, 지속적으로 대화하고 직접 말하고, 간단한 것은 노트나 메모장으로 넘겨주는 것으로 진행해 나갔습니다.

마지막까지 중심이 되었던 사람들은 형석형, 수지, 영훈, 준영, 현아, 현행, 재근 그리고 저 정도 였습니다. 마지막까지 다른 팀원들을 버리지는 않았죠. 그러면서 덩치만 큰 팀으로 오인되는 것이 가슴이 아팠습니다. 저 사람들은 아무것도 안했어! 라는 것이 아니라, 노력이 배분되어 보였던게 싫었던 거죠.

"할수 있겠어요?"

마지막까지 교수님들께 들었던 말이었습니다.

"네 할수 있습니다."

저는 항상 웃으며 대답했습니다. (사실 속으로는 얼마나 부글부글 거리겠어요. 원래는 다 할 수 있는 것인데, 자존심 상하고..) 팀원 전체를 믿을 수 있었기에 가능했었죠. 부분적으로 미심쩍은 부분이 있긴 했지만. "가능했습니다."

해결과정

이가 없으면 잇몸으로라도!

진행하면서 별별 일이 다있었습니다. 잘 먹히던 애니메이션이 안먹히거나, 스키닝에 문제가 생기던 문제, 메모리가 오버플로우되고, 오브젝트 변신 문제등 참 많은 일들이 벌어지더군요. 전날까지 이상없던 프로그램이 PT 당일 아침에는 이상 증세를 보이면서 "뻔한" 변명이 되어 버리는 일도 일상 다반사.

오브젝트 위치 값을 스크립트로 때려 박을려니 이건 앞이 깜깜해지더군요. 현행 군이 하루종일해도 답이 안나오고. 그래서 파일 입출력을 재근에게 부탁해서 만들었습니다. 그래서 한 6시간 작업으로 압축 되었습니다. 그래도 쭉쭉 벌어지는 에러.

자 어떤 과정으로 그 전까지 진행 했느냐. 간단하게 맥스를 맵툴이라고 가정하고 맥스에서 나온 오브젝트 x,y,z 위치값을 모두 수기로 적거나, 혹은 엑셀로 옮겼습니다. 여기까지 진행하는데 약 3시간 정도. (그것도 두사람이서 진행 했을때 이야기입니다.) 약 천여개 이상의 오브젝트가 깔리는데 환장 하겠더군요. 다음에 그것을 스크립트에 적합하게 전환하는데 약 2~3시간. 역시 환장하는데다가, 중간에 오타로 인해서 에러 발생.

그래서 화가나서 만들어 버렸습니다. 맥스 스크립트를. 단 두시간만 붙들고 오브젝트 컬렉터를 만들어 버렸죠. 사실 레퍼런스와 인터넷에 떠도는 것을 참고해서 만든건데, 이것으로 한시간 내지 30분으로 시간 단축을 해버렸습니다. 저도 놀랬죠. 간단한 구문으로 가능하구나 하고.

http://ruanzero.springnote.com/pages/896668

그 외에 그래픽 에러를 잡기 위해 XML 포맷 분석도 끙끙거리면서 해보고, 안되는 프로그래밍 코드도 살펴보면서, 없는 UI 기능 추가해 보겠다고 건방지게 코드 건들고 스크립트 건들여서 기능 추가 해보고, 건방진 짓도 해보곤 했습니다.

화면 좌측에 키보드 버튼 껌뻑 거리는 걸 넣어 보려고 추석 연후에 집에 내려간 형석형 몰래 작전(?)을 진행했습니다.

즐거움이란

사실, 우리가 만든 이 게임이 뭐가 재미있냐 라고 묻는다면, 저는 자질이 부족한지 명확한 답을 내리기가 힘듭니다. 별 재미도 없네라는 반응도 있을 테고, 정확히 이런 재미를 추구하고자 시작 했던 프로젝트도 아니였었죠.

기획적으로 부족한 것이 많았던 프로젝트였었고, 주변 우려도 상당히 많았습니다. 일부 팀원의 정서적 안정도 필요로 했죠. (대부분은 그럴 필요없이 알아서 불타 주었지만)

하지만 이 프로젝트가 우리에게 가져다 준 것을 찾는 것이 어렵지는 않았습니다.

지스타에서 계속 플레이 하던 개발자들 보다 훨씬 넘게 점수를 채워주던 어린 꼬마들, 웃으면서 즐겨주던 고등학생들, 그리고 최고 기록 세웠다면서 자랑하던 후배들. 명확하게 우리가 왜 게임을 만드는 가에 대한 답을 내려 주었습니다.

"사람들을 즐겁게 하는 것. 그것을 보고 싶어."

이런 꿈, 단지 꿈으로 끝날까요? 아니면 앞으로도 계속 이어질까요?

개구락지 든, 꾸러기든, 우린 조금씩 성장해 갑니다.

일정

Tue, 01 Apr 2008 20:26:11 +0900

2007년 4월 2일 월요일

1. 개요

현재 팀에 대한 최종적인 목표와 일정이 잡혀있는 상태에서 중간 중간의 상태를 알기에 어려움이 있습니다. 때문에 각파트별 / 팀 전체에 대한 목표를 설정하고, 일정에 대한 명확한 시행을 위한 중간단계를 확인하여, 좀더 완성작에 가까워 질수 있도록 체크 포인트와 프로토 타입 일정을 잡습니다.

2. 체크 포인트

(1) 의미

각 파트별 구현 / 작업 목표를 정하고 중간 단계에서 협의 하는 목적을 위해 규정합니다.

(2) 기간

매월 15일 / 30일에 개인 작업 목표에 도달하였는가와 앞으로의 전체적인 일정을 수정합니다. 단, 1회 체크 포인트는 4월 6일입니다.

-4월 체크 포인트: 6일 / 30일 (1회 /2회)

-5월 체크 포인트: 15일 / 30일 (3회 /4회)

-6월 체크 포인트: 15일 / 30일 (5회 /6회)

-7월 체크 포인트: 15일 / 30일 (7회 /8회)

-8월 체크 포인트: 15일 (9회)

-8월 알파 테스트 타입: 30일

-9월 베타 테스트 타입: 15일

-9월 골드 버전 타입: 9월 말 à 10월 수정 기간

정리해고

Wed, 05 Mar 2008 04:08:04 +0900

이전 기획서 잔존

진행하면서 폐기 처리된 부분입니다.

개개인 일정

Wed, 05 Mar 2008 03:52:27 +0900

드디어 나왔다!!

일정표!!

_ES001P_일정-R.xls

5월 22일

Page.htm --> 10주차 일정표

- 24일까지 할일 말씀드립니다.

기획

김종민 : 루아 사용 계획 꼭 해주세요. 거창한 문서보다 어떻게 실용화 시킬 것인가. 자신의 실력 대비 할수 있는 한계까지 부탁드립니다.

이지웅 : 캐릭터 변동 있을거 같습니다. 캐릭터 벨런싱 문서는 후에 시뮬레이션으로 하며, 일단은 진열 오브젝트는 종료 해 주고, 작업물 관리, 수정에 들어가 주길 바랍니다.

유준영 : 제작한 음악 카페에 올려주길 바람.

==>

그래픽

고수지 : 아줌마 캐릭터 맵핑 초안까지 완성, 모델링은 영훈군에게 넘기길 바랍니다. (맵핑이 아직 완성되지 않아도 일단은 피직 혹은 스킨을 설정이 가능하므로.) 모델링 / 맵핑까지 완성이 되면,

조영훈 :

==>

프로그래밍

최형석 :

김대희 :

==> 개인에게 따로 할말은 없습니다. 클래스 나눈거 제가 잘 아는 건 아니지만 좀 볼수 있을까요? 루아 사용은 어떤 식으로 진행할 건지

상의 부탁드립니다. 현재 파트를 형석형이 클라이언트, 대희가 네크워크 를 하기로 했는데...

일단 대희는 당장에 작업 결과물이 나오지 않아도 괜찮으니까, 일단 하되. 그냥 지지부진 기다린다는 것 보다 목표를 정해서

매일 매일 단계적으로 하고 있는 사항 이야기 해줄 것. 매번 체크해 갈테니.

그리고 형석형님, 맵은 어떻게 띄울 건지 지금 하시는 거 마무리 지으면 다시 이야기 좀.

5월 21일

기획

김종민 : 루아 사용 계획, 진행 방향 보고해 줄 것. 현재 진행은 어느정도인지도 명확하게 바람.

현재로서는 AI 부분에만 사용하는 걸로 알고 있는데 확대 시킬 것인가, 혹은 더 덧붙일 것인가.

AI 페턴에 대한 기획은 어떻게 진행할 것인지 문서화 바람. /(이번주 수요일까지 사용 계획 보고서, 나머지는 주말 전까지.)

이지웅 : 컴퓨터 수리한거 어찌 되었는가? 연락이 전혀 안되서 몇주동안 일이 안되는지 이젠 뭐라 할말이 없네만.

3달동안 질질 끌어간 오브젝트 리스트 완성품을 이제 보고 싶네.

한번에 완성해서 올릴 생각인가? 조금씩 올려볼 생각은 안드는지 묻고 싶네.

이번주 수요일까지 수납형 오브젝트 엑셀리스트, 문서 완료하고, 캐릭터 밸런싱 문서 시작할 것.

수요일에 그래픽 파트에서 파일 넘길 것임. 리스트화 시켜서 목록 관리, 파일 관리도 할 것.

외부 도우미들 메신져 주소 가르쳐 줄테니까 연결해서 파일 받아라.

ps. 건강상의 문제라면 좀 연락 하라고 했지?

유준영 : 오브젝트 컨셉 사진 모아달라는거 1주일 초과. 진행 안됨. PM 업무 넘길려고 했는데 아무래도

무리. 보고서 달라는 것도 좀 해주길 바람.

==> 다들 메신져좀 들어올 것. 개인적인 사정으로 내가 학교에 잘 안비친 것도 문제 있지만, 적어도 메신져에 한달동안 안보이는 것은?

그래픽

고수지 : 현재 진행하는 아줌마 캐릭터 언제까지 마무리 될 수 있는지 말씀해 주시길. 외부 도우미 인원하고 연락도 긴밀하게 해주시길

바랍니다.

조영훈 : 애니메이션 작업하고 있으면 좀 올려!! bip/max/영상 셋트로 해서 올려 주실 것.

==> 그래픽 파트는 수요일까지 그래픽 소스. 이름 변경. 포멧 형식. 그래픽 설정에 맞게 맞추어 주시고, 해당 이름은 기획파트의 이지웅 군에게

리스트 넘겨 주시길 바람. 파일도 동봉.

프로그래밍

==> 개인에게 따로 할말은 없습니다. 클래스 나눈거 제가 잘 아는 건 아니지만 좀 볼수 있을까요? 루아 사용은 어떤 식으로 진행할 건지

상의 부탁드립니다. 현재 파트를 형석형이 클라이언트, 대희가 네크워크 를 하기로 했는데...

일단 대희는 당장에 작업 결과물이 나오지 않아도 괜찮으니까, 일단 하되. 그냥 지지부진 기다린다는 것 보다 목표를 정해서

매일 매일 단계적으로 하고 있는 사항 이야기 해줄 것. 매번 체크해 갈테니.

그리고 형석형님, 맵은 어떻게 띄울 건지 지금 하시는 거 마무리 지으면 다시 이야기 좀.

b. 게임 룰

Fri, 01 Feb 2008 03:57:52 +0900

전환 게임 룰

주의사항

-플레이어가 보기에 간단해야 할 것

-상기 내용을 충족하면서 명료하고 데이터 상에 오류가 없어야 할 것

-게임 기획 의 최초 목적에서 크게 벗어 나지 않고 , 단순함에 빠지지 않을 수 있도록 배려할 것.

-현재 인원으로 해결할 수 있는 내용이어야 할 것

etc.스코어 보드

Sun, 30 Sep 2007 00:24:31 +0900

f. UI

Fri, 28 Sep 2007 14:29:17 +0900

UI 컨셉 : 만화적이면서 게임전체의 분위기에 어울 릴수 있게 표현. 사실적인 느낌의 UI 같은 표현의 UI 배제

> 각 페이즈 단위로 구성을 나누면서, 기획/구성하도록 한다.

> 각 페이즈는 다음과 같다.

[타이틀 부]

[게임시작화면 부]

[게임시나리오 부]

[본 게임 부]

[게임 완료 부]

> 게임이 진행되는 동안에는 다음과 같은 순서로 진행된다.

[타이틀]->[게임시작화면]->[게임 오프닝] ->[게임시나리오 <1>]->[본 게임 <1>]->[게임 완료/결과출력]->[게임시나리오 <2>]->[본 게임 <2>]->[게임 완료/결과출력]

->[게임시나리오 <3>]->[본 게임 <3>]->[게임 완료/결과출력]->[게임시나리오 <4>]->[본 게임 <4>]->[게임 완료/결과출력]->[타이틀]

> 각 게임이 완료 될 때 마다 플레이어의 이름과 스코어가 지정된 php 서버로 전송된다. (김대희 군 작업)

> 게임 완료 후, 클리어 했다는 정보 값이 저장이 되며, 프로그램을 실행 할때 마다 값을 읽어 들여, 새로운 맵을 보너스로 할수 있게 한다.

각 페이즈 설명

>>타이틀

타이틀은 다음 순서로 그림을 출력한다.

<학교 로고> -> <팀 로고> -><다음 페이즈 진행명령>

각 그림파일은 [512X512]로 만들어지며, 페이드인 1초. 화면이 뜬후 대기시간 1초, 페이드 아웃 1초로 진행한다.

(ATI와 NVIDIA가 텍스쳐 인식이 차이가 있는 듯. 그점 고려해서 진행한다.)

>> 게임 시작화면

그림 참조.

뒷 배경은 기존에 구성된 맵에서, 일정 부분을 카메라로 보여주고 캐릭터가 돌아가는 것을 보여준다.

그 위에 게임을 시작 할 수 있는 UI 부분을 얹는다.

포함 내용

장보러가기 <게임 시작 페이즈>

이달의 우수고객 <스코어 보드//인터넷 페이지 이동 혹은 php에서 읽어 오는 스코어 보드를 클라이언트에서 출력>

점원 명단 <GGRG 팀원 명단>

게임 종료 <윈도우로 나간다.>

배경은 3D 화면을 그대로 띄우고 그 위에 2D GUI를 출력. UI에 대한 선택은 키보드 <업> <다운> 두가지로만 가능하며, 실행은 키보드 <Z>키로 입력한다.

최초 선택 위치는 <장보러 가기> 부분에 위치하며, <기본> 텍스쳐가 아닌 밝게 빛나고 있는 <선택> 텍스쳐가 위치하게 된다.

선택된 항목의 텍스쳐는 <기본>텍스쳐에서 <선택> 텍스쳐로 변화하여 선택 되었다는 것을 표현한다.

선택 실행 후에 각각 해당 페이즈로 이동하며, 게임 시작화면은 소거시킨다.

>> 게임 오프닝

다이렉트 쇼이용, AVI 오프닝 출력

+ 코덱 +

화상 : XVID / 음성 : MP3 / AVI

15초 가량 진행되며 Esc로 캔슬 가능.

오프닝 컨셉 : 바이오 하자드 3의 오프닝을 코믹하게 변경.

종료후에 [게임 시나리오 모드 <1>] 로 진행한다.

제작 : 포토샵, 프리미어.

제작 기간 : 1주일

>> 게임 시나리오 모드

게임 화면에서 게임 UI가 제거 되고,

#일지#

Fri, 28 Sep 2007 11:43:04 +0900

GGRG_팀원_소개.doc 시스템_플로우_챠트.vsd

UI_출력에_대한_문서.doc

07. 9 . 26

해야 할일 산떠미.

변명은 말자. 진행해야 하니.

UI 문서

기획 문서

오브젝트 문서

맵 디자인

레벨 디자인

기타 등등.

Game_Over.doc

07. 8. 27

챙길 것들

2007-2_강의시간표(학과용).hwp

2007-2_강의시간표(학과용)유.hwp

회의_(070824).rtf

세일_아이템_습득.doc

07. 8. 16

죽겠다..이놈의 사랑니가 난것도 모자라 썩었나. 아파 죽겠다.

오늘의 주안점 시간 체크 대신에 체력 / 시식코너로 보충 / 시간이 지나면 체력감소

같은 맵을 사용/ 배치의 변화 (루아로 무한 ADD ON 가능) / 레벨 업에 따른 난이도 변화

자세한건 다른 기획과 토의를 하고...

07. 7. 27

언제나 잘되는 것은 아니니까..

하지만 언제나 잘 안되는 것도 문제 있다.

OBJ_AQUANI.max

뭔가 꼬였다. 다행히 오토백에 남아 있었구나..=ㅅ=

MaxBack.max

04.Picture_Perfect.mp3

07. 7.13

anilist(1).doc

옮길 것... ㄷㄷ

두통이야.. ㄱ-

07. 7. 7

후우 너무 덥네요. 멍해 있는 시간하고 책보는 시간만 늘고

결국 작업물은 적네요. -_-

anilist.doc

07. 7. 2

UI를 구성해 보았습니다. 실제 화면하고 보면 어떻게 다를지.

근데 문제가 있더군요. 윈도우 생성 코드가 윈도우 테두리까지 포함 800 x 600인 것입니다!!

털썩.... UI 좌표에서 문제 생길거 같습니다. 형석형이랑 이야기 해서 수정해야죠.

옆에 뛰노는 GGRG 맨입니다.

뭐 팀원들이 항의하면 걸로 바꿀 용의도 있습니다. -_-

근데...슴X 없....퍽..

뷰어에 올리니까 알파값이 아직 먹히지 않아서 흰 테두리는 남더군요. 그래도 느낌은 표현되었습니다. 상당히 재미있던데요. ㅠㅠ

뭐 UI 자료는 여기까지 이제는 실 구성입니다. ~_~