2017년 12월 31일 일요일

[20171231] ...시간

2017년 12월 31일 제 페북에 올린 글 입니다.
기록용으로 옮겨 둡니다.

--------------------------------------------------

이제야 게임 개발이 뭔지 알 것 같은데.
안타깝게도 주어진 시간이 얼마 없는 것 같다.
( '_')y-~

남은 시간... 알차게 불사를꺼야.



> 고생해서 찍은 타일을 페북에서 본 지인은 제가 찍은 타일인줄 몰랐다고 하더군요.
> "니가 이런 타일을????" ...같은 거겠죠. @_@
> 스튜디오 게시물에는 제 작업만 올라옵니드아~!~! +_+

[20171230] NPC

Skeletal Animation System 을 도입하려고 마음먹은 이래
어쩐지 손이 가지 않아 여러날을 이런 저런 변두리 작업을 쳐내면서 지내왔습니다.

정확히는 노가다 많은 작업들이죠.
덕분에 쓸만한 타일도 2종류를 완성했고

< New tile "Cave" >


방금은 NPC 캐릭터도 하나찍었습니다.

< unnamed npc : Idle x1 >

< unnamed npc : Idle x8 >

< unnamed npc : Move x1 >

< unnamed npc : Move x8 >

NPC 작업을 시작하면서 유명 스트리머 P 님의 "슈퍼마리오 메이커" 방송을 켜놨습니다.
한 번씩 슬쩍 슬쩍 보다보니 클래식 슈퍼마리오의 도트 스타일이 눈에 들어오더군요.

성능의 한계 때문이기도 합니다만.
극한의 쥐어짜기가 적용된 도트였습니다.

문득 "절제되고 쥐어짜진 도트를 찍어야 된다." 라는 결론에 도달했고...
위의 도트들은 그 결과물입니다.



통장잔고가 바닥을 보이기 시작하고부터...
인디에 도전할 새로운 누군가에게 글을 남긴다면 무엇이 좋을까 라는 생각을 자주 했었습니다.

대충 정해진것은 머릿말 뿐이었는데 그 문구는...
"제 인디 생활은 분수를 알아가는 과정이었습니다."
...입니다.

종일 머릿속을 맴돌고 있던 이 문구가 타이밍 좋게도 클래식 마리오의 도트를 만나면서 적절한 발상에 도착하게 된 것 같습니다.


Animation 을 최소화 할 수 있다면.
굳이 Skeletal Animation System 을 도입하고, 해상도를 올려야 할 필요는 없을 겁니다.

안쓴다고 확정 지을 수는 없습니다만
오늘의 도트를 찍던 기조를 유지할 수 있다면 가능성은 있겠습니다.


어후 쓸데없이 글이 길어졌네요.
다들 행복한 새해 맞이하세요.
( '_')y-~

2017년 12월 29일 금요일

[20171229] New tile concept - Cave

사실상 28일의 작업입니다만.
29일 새벽까지 작업을 한 관계로 새 게시물로 작성해 봅니다.


이런 저런 Tile 들에 대한 자료를 한껏 수집한 뒤에
이전 Tile을 만들었던 노하우를 최대한 발휘해서
새 Tile을 찍어보았습니다.

동굴 형태의 맵에 사용할 Tile 입니다.

< Cave tile concept >

자료를 찾다보니 카피하기 힘들게...
1. 회전시키고
2. 노이즈를 넣고
3. 3D 효과를 추가
...하더군요.

두가지만 해보았습니다. @_@

2017년 12월 28일 목요일

[20171228] Confusing

집중력이 날아가버린 덕에 주 작업을 놔두고 곁가지들만 쳐내고 있습니다.
덩어리 큰 작업을 하고나면 역시 한번씩 쉬어줘야 하나 봅니다.


맵에 새 타일을 적용하고. Light 버그를 하나 잡고, 크기를 조정했습니다.

< Apply new tile >

그리고...
다양하게 얼굴 파츠의 컨셉을 잡아봤습니다.

< Concept of face parts >

마지막으로 Title 화면의 컨셉을 잡았습니다.

< Concept of title scene >

제 드로잉 실력으로 자세한 묘사는 크게 무리가 있습니다.
분위기를 내는척 하는 정도가 한계이기 때문에 제 손에서 작업이 끝난다면 이런 느낌이 될 것 같네요.
( 이걸로 그대로 쓸지도 모릅니다. @_@ )

아아...
벌써 새해가 다가옵니다.
( '_')y-~

2017년 12월 26일 화요일

[20171226] Working for new tile pattern

새로운 타일 패턴을 추가하는 작업을 진행중입니다.

좀 더 단순하게.
좀 더 아기자기하게.
...가 목표입니다.
( '_')y-~


타일 패턴을 조립하는 기능을 추가하고.
결과물을 저장한뒤에...

< working... >

뿌려보았습니다.

< 1st version >

실력에 비해 너무 아름답게 나온것이 아닌가.
...라고 생각중입니다. @_@

색상 조정의 여지가 상당량 있습니다만, 이 분위기는 유지하려고 합니다.
( '_')y-~

2017년 12월 25일 월요일

[20171225] New tile concept - Green

여전히 의식의 흐름안에 있습니다.

가벼운 느낌으로 가고싶습니다.

< New Tile Concept >

그렇습니다.
( '_')y-~

[20171225] 의식의 흐름에 따른 Tool 작업

...본분을 무시하고.
Tool을 작업중입니다.

< Tile Pattern Generator >

...그렇습니다.
( '_')y-~

.
.
.
작업 완료~!
< Operation >

< Result >


2017년 12월 24일 일요일

[20171224] Re research~!

"Dicer" project를 진행하던 시절에 절감했습니다.
"1인 개발에 옷갈아입히는 시스템은 '과욕' 이다." ...라고.
...하지만 최소한이라도 하려면 어떻게 해야할까요?


역시 문제는 "그려야 할 것이 너무 많다" 는 것입니다.
"Project Rogue" 는 저해상도( 304  x 208 ) 게임이기 때문에 이미지를 회전시키면 뭉개집니다.
그래서 회전된 모습이 필요하다면 따로 그려줘야 합니다.

거기에 신체 부위별로 파츠가 분리되어 있기 때문에 "파츠 종류 x 모션 종류" 만큼을 그려야 합니다.

이건 "루비이야기" 작업을 뛰어넘는 수준의 막대한 작업량을 불러옵니다.
도저히 혼자서 감당할 수가 없습니다.

< ......o_o;;;;; >

현재...
"머리칼", "머리", "왼쪽눈", "오른쪽눈", "왼팔", "오른팔", "몸통", "왼다리", "오른다리"
...9개의 파츠를 더미 작업만 해본 결과.
각 파츠당 6개의 animation frame 이 필요합니다.
하나의 컨셉에 최소 54 개의 이미지가 필요하며 향후 늘어날 예정입니다.

결론은... "이 방식으로는 안된다." ...입니다.

< "삽질 of 루비이야기".... 이걸 몇십배 스케일로???? >

현재 나와 있는 해결책은...
1. 옷 갈아 입지마.
2. 2D skeletal animation system 을 도입
...과 같습니다.

1번은 넘어가고.

2번 해결책을 위해서는...
1. System 을 도입하고.
2. 회전해도 멀쩡할 정도의 원본 이미지 해상도
3. 게임 해상도 상승
...정도가 필요합니다.

2D skeletal animation system 은 "Dragon Bones" 에 대해서 대략적인 조사와 테스트를 끝내놓았기 때문에 시행착오는 적을겁니다.
파츠 교환 시스템을 만들고 테스트를 하면 되겠죠.

남은 것은 이미지와 게임의 "한계 해상도가 어디인가" 에 대한 삽질이 필요합니다.

그리하여...

삽질하러 갑니다.
( '_')y-~

2017년 12월 21일 목요일

[20171221] Improve Move Process

Actor 가 연속으로 움직이는 과정에서 게임의 턴관리 Process 미비로 "턴사이에 1 프레임씩 대기시간이 주어지던 문제" 를 해결하였습니다.

문제가 있는 것인지 없는 것인지 감이 확실히 잡히지 않았는데
Actor의 이동속도를 올려놓고 보니 분간이 가더군요.

아래의 이미지는 작업전의 모습입니다.
여전히 확연하게 눈에 들어오지는 않습니다만 신중하게, 집중해서, 자세히 들여다 보면 타일 1개의 이동을 마칠때마다 "뚝" 끊기는 것을 볼 수 있습니다.

동영상으로 치면 버퍼링이 걸린달까요.

< Old Process >


다음 이미지는 작업후의 모습입니다.
이 이미지와 번갈아서 보면 이쪽이 움직임이 부드럽다는 것을 느끼실 수 있을겁니다.
( 못 느낄 수도 있습니다. ( @_@)y-~ )

< New Process >


원본 영상에서는 나름 분간이 가는데... gif 는 프레임 한계로 분간이 어렵네요.
원본영상의 절반이 안되는 프레임이라 그런가봅니다.

아무튼... 그런 작업을 진행했습니다.

찝찝했던 무언가를 날려버린듯 기분이 좋네요.
( '_')y-~

[20171221] Puzzle

1. Boss 전을 Puzzle Game 의 형태로 구성하면 좋을 것 같다.

바닥에 광역 공격의 남은 턴을 표시 하는 시스템을 만들고
이것을 엮어서 구성하면 타일밟기 형태의 퍼즐이 구성 가능하다.



2. 복잡도가 올라가는 만큼 유저에게도 많은 능력이 요구된다.

힘들게 파밍해서 도착한 곳에 생전 듣도 보도 못한 퍼즐풀이를 요구하는 Boss.
어느면에서도 공정하지 못하다.

"Crypt of The necrodancer" 에서는...
만날 수 있는 모든 몬스터에 대해서 패턴 습득이 가능한 시스템을 제공한다.
참고해봐도 좋겠다.

장르 취지에는 맞지 않지만 적절한 저장 시스템이나 재시도 시스템이 들어가도 좋을 것 같다.

[20171221] 한계

설계의 한계를 극복하러 떠납니다.

갈아 엎으러 갑니다.

( '_')y-~


> 끊김없는 이동을 원했습니다.
> 설계상 1프레임씩 끊길 수 밖에 없음을 확인했습니다.

2017년 12월 20일 수요일

[20171220] 관찰

국내에서 나온 모 Classic Roguelike 게임을 살펴보던중에 발견한 것이 있어서 기록으로 남깁니다.

이 증상은 현재 "ProjectRogue" 서도 동일하게 발생하는 문제입니다.
고칠지 말지 고민중이었는데, 플레이 가능한 게임에서 이 증상을 접하고 났더니 꼭 고쳐야겠다는 생각이 들었네요. @_@

+ 기본정보
해당 증상은 "이상한 던전" 시리즈 등에서 사용된, "턴제 게임이지만 전 캐릭터가 이동만은 동시에 수행하는 시스템" 을 채택한 게임들중 일부에서 볼 수 있는 증상입니다.
+ 이미지 기본 정보
검은색 : 이동할 수 없는 지형
회색 : 이동 가능한 지형
빨간색 : 몬스터
노란색 : 플레이어
숫자 : 턴 순서

아래와 같은 상황이 조성될 수 있습니다.

< 시작 >

이 상태에서 플레이어가 움직여서 아래와 같은 모양이 되면


먼저 턴이 돌아온 "1" 몬스터는 플레이어 방향으로 이동할 수 없어 대기 상태에 들어가고


후에 턴이 돌아온 "4" 몬스터는 플레이어 방향으로 이동하게 됩니다.

절차와 시스템 상으로 아무런 문제가 없는 무결한 상태입니다만
유저의 눈에 어떻게 보이는가가 문제입니다.

유저의 눈에는 1번 몬스터가 이유 없이 가만히 있는 것으로 보입니다.
"버그" 처럼 보인다는 이야기지요.

이 증상은 턴제 게임을 약간의 연출로 턴이 없는것처럼 처리한 기법에서 기인하는 문제입니다.

시스템상 존재하는 턴이 유저에게 가시적으로 전달되지 않기 때문에 "1" 몬스터가 움직이니 않는 것이 뭔가 잘못되어 보이는 겁니다.

해결법은...
1. 이동에 한해서 턴순서를 무시하거나
2. 이동 처리에 실패한 몬스터에 대해서 다시 이동의 기회를 주거나
3. 플레이어와의 거리를 기준으로 턴 순서를 조정하거나
...여러가지 해결책을 시험해 볼 수 있을것 같습니다.

( '_')y-~

[20171220] 잡설 - 세금납부준비 2017

연말을 맞이하여 즐거운 연례행사~!

세금납부 준비중.
( o_o)y-~

애플 이놈들은 왜 재무보고서에 한국에서 얻은 수익만 따로 뽑는 기능을 제공안해서

1. "판매 및 추세" 에 가서 일일이 필터 걸고 한국 판매 자료만 따로 뽑은 다음에

2. 파일 하나 하나 인코딩을 utf8 에서 ansi 로 바꾸고

3. "와 이 리포트에는 판매량만 나오고 수익, 매출은 안나오는구나~!" ...라는 탄식과 함께 웹페이지에만 표시되는 예상 매출 과 수익을 일일이 csv 파일에 집어 넣게 만드는가.

( ...와 같은 뻘짓을 했는데

1. 오른쪽 상단의 보고서 생성을 누르고 다운로드

2. 모든 국가를 선택해서 보고서를 뽑으셨다면 안에 txt 파일이 여러개 들어있을겁니다.

3. 파일 이름이 "WW" 로 끝나는 파일만 확인해서

4. "Contury of Sale" 항목이 "KR" 인 것만 따로 뽑으면 됩니다.

5. 앱의가격이 10 일때 마켓은 "10 + 부가세" 해서 11을 받고 내 통장에 "7 + 부가세" 해서 8이 들어오게 됩니다.)

6. 1 / 8 이 세금이므로 통장에 들어온 "한국 수익의 12.5%" 를 부가가치세로 내면 됩니다. )

...이제 이걸 집계하면 끝나겠지.
집계는 신고할때 하자.

태국도 따로 국가 카테고리가 제공되는데... 한국은 없다.
수익면에서 딱히 중요하지 않은 시장이라는 의미겠지.
( '_')y-~

2017년 12월 17일 일요일

[20171217] Improve

하루 기절해 있다가 다시 작업을 시작합니다.

지난번 작업했던 날은 생각없이 붙들고 늘어졌더니, 시계를 봤을때 새벽 1시가 되어있더군요.
자고 일어났더니 눈 상태가 엉망이어서 부득이 하루 쉬고 왔습니다.
( @_@)y-~


오늘도 길 뚫기 작업중입니다.

우선 기존에 만들어 뒀던 2종류의 연결 추가 로직을 비활성화 했습니다.
그리고 공간간의 연결점을 가급적 모서리가 아닌 곳으로 선택하도록 약간의 조정을 했습니다.

< Connection process off >

심심한듯 보이지만 괴랄한 형태의 길은 확실히 사라졌습니다.


다음은 큰 공간을 우선적으로 방으로 선택하는 로직을 제한적으로 추가했습니다.
그리하여 큰 공간이 길이 되어 버리는 확률을 줄였습니다.


이어서... 미묘하게 마음에 들지 않는 공간 분할 로직을 손 보았습니다.
조건을 ">" 로 주느냐 ">=" 로 주느냐에 따라서 성능이 두배 가까이 차이나는 놀라운 현상과 함께 적당히 마무리 되어 아래와 같은 모양이 되었습니다.
( 사실 다 네모 네모한 이미지라서 변경사항들이 전달되고 있기는 한 것인지 의문이긴 합니다. @_@ )

< Final version...?? >

이 버전의 특징은 방의 규격화에 있습니다.
방의 최소 크기를 가급적 보장할 수 있도록 알고리즘을 조정했습니다.


그리고 마지막으로 약간의 테스트를 수행했습니다.

알고리즘의 아주 기초적인 안전성 확인을 위해...
그냥 무식하게 돌려보는겁니다. @_@

< Test >

< Test End >


드디어 내일은 게임에 새로운 알고리즘을 적용해볼 수 있을것 같습니다.
( '_')y-~

2017년 12월 16일 토요일

[20171215] Working

....!!!!

길을 내는 작업을 진행 중입니다.

적절한 형태를 갖추기위해 추가한 알고리즘중에 안좋은 방향으로 작동할 가능성이 있는 녀석을 발견했습니다.

2개 이상의 연결이 있는 공간에 한해서 추가적인 연결이 가능할경우 연결을 추가하는 로직이 있는데 이 녀석이 조건부로 문제가 되고 있네요.

공간의 종류를 확정하기 전에 연결을 수행하기 때문에.
이후에 해당 공간이 "길" 로 분류되는 경우 무의미하게 복잡하기만한 길을 생성하게 됩니다.
관련 로직을 들어내거나.
분류 이후에 방들에 한해서만 작동시키거나
...둘중에 하나는 해야 할 것 같습니다.

< Now Working >

컨텐츠 자동생성의 길은 멀고도 험하군요.
( '_')y-~

2017년 12월 15일 금요일

[20171214] Classification

아낌없는 가스비 지출로 뜨끈뜨끈한 방에서 숙면을 취한 덕인지, 몸살 기운이  어느정도 사그러들었습니다.

운이 좋네요.
다음엔 이렇게 넘어가지 못하겠죠.
( @_@)y-~


지난 작업에서 예고되었던 것처럼 오늘의 작업은 길을 추려내는 것입니다.
그러기 위해서는 방으로 쓰일 공간과 길로 쓰일 공간을 명확히 분류하는 것이 필요합니다.

흰색이 길로 쓰일 공간 입니다.

< Classify space to room and road >

이 작업을 진행하는 와중에도 버그를 찾아 버리고 말았네요.
Bulk up 과정에서 추가된 공간들이 연결 정보를 가지지 않고 있었습니다.

문제를 해결하고 이런 저런 튜닝을 하고나니 시간이 훌쩍 가버렸네요.
@_@



> 확실하게 실패하는 알고리즘을 만드는 것은 정말 피곤한 일이네요.
> 코드가 난잡해지는 것은 기본이고
> 유효성이 경합하는 과정들을 일일이 손봐줘야 한다는 것이 아주 번거롭습니다.
> 그래도 재미는 있네요.
> ( ^_^)y-~

2017년 12월 13일 수요일

[20171213] Build Grid

날씨가 너무 춥네요.
집안에서 패딩을 입고 작업을 해야하는 지경입니다.
( o_o)y-~


지난 작업에서 공간분할과 관계설정, 그리고 경로구성을 마무리 했으므로, 이제 실질적인 맵 구성을 시작합니다.

우선 Map 생성을 위한 Test Scene 으로 옮겨와서...
벽과 일반타일을 설정합니다.

< Normal and Wall Tile >


이어서 각 공간을 연결합니다.
각 공간은 약간씩 겹쳐 있기 때문에 중복되는 공간중에서 연결할 공간을 선택하게 됩니다.

< Connect space to space >


출구( 주황색 )가 뭔가 이상해 보입니다.

그리하여 자신과 자신이 연결되어있는 버그를 해결하고,
입구( 빨강 )에 연결된 공간이 0 개인 버그도 겸사 겸사 해결한뒤에

다음과 같은 모습이 됩니다.

< Bug free....? >


알고리즘 1 cycle의 속도가 느려서 이런 저런 튜닝을 하다보니 어처구니 없는 실수를 한 것을 발견했습니다.
관련 버그를 정리해서 멀쩡한 속도로 복구한뒤, 가변성을 위한 이런 저런 로직을 추가해서 일단 마무리 했습니다.

< Final Version....? >

현재는 모든 영역이 "방" 으로 설정되어 있는 상태입니다.
다음 작업은 길로 사용될 공간을 추려내는 작업이 되겠네요.


으... 힘들군요.
몸살 기운이 가득합니다.

내일 작업은 몸 상태 봐서 하루 쉴지도 모르겠네요.
다들 감기 조심하세요.
( '_')y-~

2017년 12월 12일 화요일

[20171212] Do not make like this~!

근래의 작업은 이걸 피하기 위함이죠.

어휴.... 이런 맵에서 게임을 진행할 수도 있다니.
죄를 지은 기분이네요.

< ( o_o)y-~ >

작업중입니다.
( '_')y-~

2017년 12월 11일 월요일

[20171211] Path

하루를 건너 다시 작업을 시작했습니다.
기껏 하루를 쉬었는데 멋지게도 감기가 걸려 버렸군요.
하하...

늘어져 있어봐야 고통스럽기만 한데다가
게임을 할정도의 신체 상태는 아니라서.... 게임보다 쉬운 코딩( ? ) 을 하기로 합니다.
( '_')y-~


지난번의 작업은 경로 구성을 위한 준비 작업이었죠.
그래서 다음 단계로 경로를 구성했습니다.

< Path for red to orange >


그리고 한 개 더 구성했습니다.

두 개의 경로는 던전안에 반드시 포함될 영역입니다.
던전의 부피적 측면( ? ) 에서 뼈대를 잡아주는 겁니다.

< Once again path for red to orange >


이제 두개를 하나의 목록으로 정리 합니다.

왼쪽 그림은 이랬으면 좋겠다 라는 느낌으로 분할 작업이 마무리 되었을때 만든 겁니다.
영 결과물이 흡족하지 못하지만...

마지막엔 저기 까지 가겠죠.



다음으로 분량을 확보합니다.
만들어진 공간들의 50% ~ 70% 가 유효 영역으로 활용될 수 있도록 연결되지 않은 공간들을 임의로 선택하여 연결합니다.
흐음... 모양이 영 흡족하지가 않네요.

< Bulk up >


Bulk up 과정에서 약간의 규칙을 추가하여 그럴싸한 모양이 나올 확률을 올렸습니다.

< End >

이 작업은 일단 여기서 끝입니다.
이제 각 공간별로 특성을 주는 작업을 해야겠습니다.
( '_')y-~

2017년 12월 9일 토요일

[20171209] Relation

작업의 형태에 따라서 코딩은 줄이고 머리만 집중적으로 혹사하는 경우가 있습니다.

지금이 바로 그런 경우인데요.

이 경우 머리속으로 쓸만한 결론이 날때까지 이런 저런 케이스를 검토해봅니다.
에너지는 크게 소비하고 코딩결과물은 매우 적어서 제대로 노는 것처럼 보입니다.

요 몇일 그렇게 시간을 보냈더니 뭔가 진척되긴 했는데 결과물이 딱히 없군요.
그래서 오늘은 고민의 결과물을 코딩으로 뽑아내는 날이 될겁니다.


슬슬 해상도의 압박으로 인해 Test Scene 선택을 위한 U.I 가 필요한 지경이 되었습니다.
Scroll 기능과 Button 을 추가할 날이 조만간 올 것 같습니다.

< Scene for Select Test Scene >


그리고... 분할된 공간들간에 약간의 관계 정보를 추가했습니다.
인접한 공간들의 정보를 수집한거죠.
다음 작업을 위한 기반이 되어줄겁니다.

< Collect Neighbor >


이어서... 맵의 유효 영역 설정을 위해 두개의 기준점을 을 선택했습니다.
두 지점을 연결하는 길을 몇 개 구성해서 게임에 사용될 영역으로 사용할 겁니다.

던전의 기본구조가 가급적 원형에 가깝길 바라기 때문에 한지점을 기준으로 사용할 수는 없습니다.( 갔던 길 또 가는게 싫습니다. ( o_o)y-~ )

좀 더 역동적인 구성을 원한다면 기준점의 숫자를 늘리면 될겁니다.

< Select Pivot >


경로 구성을 위해 기준점과 각 공간사이의 거리를 계산합니다.
위에 인접 공간들의 정보를 수집한 것이 여기서 사용됩니다.

거리를 계산하고 나면 어느 위치에서건 거리가 감소하는 방향으로 역추적해가면 기준점에 도착할 수 있습니다.
네. 경로 구성이 가능하다는 이야기 입니다.

< Set alpha based on distance >


기준점과 공간 사이의 거리를 계산하는 기능을 기준점 선택에 적용했습니다.
선택된 두개의 기준점이 반드시 일정한 거리를 유지하도록 제약을 주는 겁니다.

이것으로 이른바 "분량" 이라는 것이 약간은 보장될겁니다. ( o_o)y-~

< Select pivot based on distance >


이 글은 작업을 진행하면서 작성했습니다.
일단 글을 시작해두고 작업을 진행하니까 흡사 글을 작성하려고 작업하는 듯한 상황이 조성되면서 나름의 동기부여가 되는 느낌적인 느낌이 있었습니다. ( @_@)a

한 파트 마무리 할 때마다 정리를 하니까 나름 의미가 있는 결과물이 나오는 것도 같네요.
일단 오늘은 이쯤에서 마무리 합니다.
( '_')y-~

2017년 12월 7일 목요일

[20171207] Divide

공간을 반복 2분할 하는 방식으로 잘라서 각 공간들이 관계짓기 쉽게 해보았습니다.

이미 모든 공간이 분할 완료 되었기 때문에 따로 길을 구성할 필요도 없습니다.
각 공간별로 주변 정보를 수집해서 Graph 탐색이 가능하게만 하면 되지 않을까 싶습니다.

남은건 길 답게 잘 꾸미는 것 정도겠네요.

< 새로운 공간 구성 >

만들어진 공간들에 규칙성이 크게 보인다는 문제가 있지만
위치를 약간씩 비틀어서 해결할 수도 있을 것 같습니다.


아래는 이전 버전의 공간 생성 로직입니다.
이전에 생성된 공간과 겹치지 않는 임의의 위치값을 생성한후  새로운 공간을 추가합니다.
여기에 미로 생성 로직을 적용하고 있었지요.

< 이전 버전의 공간 구성 >

새로 추가한 공간분할 로직을 작업하면서 생각해보니 기존 로직을 잘 정리한 이후에
이미 만들어 놓은 충돌영역 압축 기능을 적용하면 쓸만한 공간 분할 로직을 만들 수도 있을 것 같습니다.

그리고 압축된 영역에 길을 추가하면 가장 이상적이겠네요.

공간을 반복 2분할 하는 방식에서 보이는 규칙성을 제거할 수 있을 겁니다.


하루에 글을 2개나 작성하고 있네요.
삽질은 계속됩니다.
( '_')y-~


> 가끔은 답을 손에 쥐고도 그게 답인지 모르는 경우가 있는것 같습니다.
> 인간 답네요.

[20171207] 개선

이런 저런 Classic Rogue Like 게임들을 찾아서 맵의 생성 스타일에 대한 약간의 조사를 했습니다.

제가 만든 로직과 비교해본 결과...
1. 던전 생성 로직이 못 써먹을 수준은 아니다.
2. 던전의 품질( ? )에 일관성이 없다. ( 컨텐츠의 양적 측면이 보장되지 않는다. )
3. 던전 각 지역간의 관계성이 없기 때문에 동선이 중구난방이다.
4. 랜덤값에 의존하여 동선이 만들어 지고 있기 때문에 정규화가 불가능하다.
...정도의 결론이 났습니다.

나름 준수하게 만들어졌다고 생각되는 Rogue Like 게임들은 초기데이터 즉...
각 구역을 정의하는 과정부터 서로간의 관계를 규정하기 위한 어느정도의 배려를 하고 있고, 그 배려가 게임의 양적 측면과 동선에 대한 품질을 어느정도는 보장할 수 있도록 만들어 주고 있었습니다.

품질을 무시한다면 현재 로직에,,,
Graph 탐색이 가능하도록 약간의 기능을 추가해서
...써먹을 수도 있긴 하겠습니다만

딱히 만족스럽지가 못하네요.
( x_x)y-~

일단 작업의 방향성에 대한 결론을 내기 전에 좀더 고 품질의 초기데이터 를 생성하기 위해
작업을 시작했습니다.

< Working... >

"정의된 공간들을 어떤 방법으로 관계지을 것이냐?" ...라는 질문에 답하는 것이 주 작업이 될 것 같습니다.

삽질은 계속 됩니다.
( '_')y-~

2017년 12월 6일 수요일

[20171206] 관찰

pixel dungeon 을 켜서 관찰하던중에 흥미로운 모습을 발견했다.
1. 한 지점에서 다른 지점으로 장거리 이동하는 상황
2. 해당 지점으로 가기 위해서는 대략적으로 두가지의 경로가 예측되는 상황
3. 두 경로중 한 경로는 "전장의 안개" 가 모두 밝혀져있는 긴 경로
4. 다른 경로는 예상되는 이동경로 중에 한 부분의 "전장의 안개" 가 남아있는 짧은 경로
캐릭터는 전장의 안개가 포함된 경로를 사용하지 않고 빙 둘러서 목표지점에 도착했고.
"전장의 안개"에 가려진 부분을 밝히자 해당 위치를 이동 경로로 사용하기 시작했다.

여기서 얻을 수 있는 결론은.

pixel dungeon의 path finder 는
1. 적어도 캐릭터의 이동에 한해서
2. 캐릭터가 방문했거나 방문했던 것으로 간주할만한 지점의 데이터를 수집하고.
3. 수집한 정보를 이용해서 캐릭터의 길찾기를 수행한다.
맵 전체의 데이터를 기반으로 길찾기를 수행하는 것보다 확실히 효율적일 것이다.

캐릭터의 이동으로 수집한 데이터만으로 길찾기를 수행한다는 것이 무척이나 Rogue Like 스럽다.

하지만 맵을 조망하는 시점에서 게임을 하는 경우 부자연스러워 보일 수 있다.

삽질중.
( '_')y-~

[20171206] 자료 수집 - RogueLike Games

발견한 순서대로 추가됩니다.

+ 국산 ( Classic )


+ 외산 ( Classic )
+ 외산 ( Like )

2017년 12월 5일 화요일

[20171205] 잡설 - Rogue 와 Like

이제 이걸 해야 할 듯 싶다.

http://r2roadstudio5th.blogspot.com/2017/10/20171018-1.html

이 작업은 간단하게 만들고 빠지려던 최초 계획의 범위 안에 들어가는 것일까? 벗어나는 것일까?

이런 판단이 가장 어렵다.
가장 뼈저리게 경험부족을 느끼는 부분이 이런 부분이다.

명백히 게임의 질과 관련된 부분이라 소홀히 넘어갈 수는 없지만 이 작업에 집중하면 개발 기간은 자연히 길어진다.

간단히 만들고 빠진다던 나의 계획은 "낮은 질의 게임을 만든다." 와 같은거였던가. 아니였던가.

그걸 판단한 기억은 없다.

작업 과정에서 얻은 노하우가 개발 기간을 늘린다.
회사에서 흔하게 마주하는 늘어지는 개발의 원인중에 아마 이것도 하나겠지.

살면서 누군가와 "어떻게 하면 좋은 로그 라이크 게임을 만들 수 있는가?" 따위를 논해본적은 없다.
"무엇이 좋은 로그 라이크 게임인가?" 따위는 더더욱 논해본적이 없다.

오프라인 커뮤니티에 가면 그런 논의가 가능할까?
만들거나 만들었던 사람 찾는것 부터가 일이겠다.

의식의 흐름에 따라 사고를 이어가니.
생각이 낮은 방향으로 흐르는 것 같다.

생각은 그만하고 긍정적인 마음가짐으로 일을 하자.
( '_')y-~

2017년 12월 4일 월요일

[20171204] Fog of war

이른바 "전장의 안개" 라고 불리우는 기능을 작업했습니다.

이 게임은 해상도 대비 캐릭터의 크기가 작습니다.

< character size >

그러다 보니 아직 가지 않은 지역이 지나치게 많이 노출이 됩니다.
테스트 플레이를 하다보니 map hack 을 켜놓고 게임을 하는 느낌이 들더군요.
명백히 게임을 덜 흥미롭게 만든다고 판단되어
아직 방문하지 않은 지역을 완전히 감추어줄 필요가 있다고 결론내렸습니다.

< map hack?? >

앞서 작업해놓은 shadow 기능은 map 상에 player 이외의 object가 시야안에서 노출되는 것을 막기 위한 기능이었기에 이런 문제를 해결해줄 수는 없습니다.

그리하여! 작업했습니다.

< Fog of war >

SpriteBatchNode 를 활용하여 Terrain Node 와 동일한 크기의 Tile map 을 만든후.
방문한 지역이...
1. 방인지 길인지를 확인하여
2. 적당히 일정 영역의 안개를 제거
...해주는 방식입니다.

모아 찍는다고는 하지만 Vertex를 낭비하는 느낌이 있습니다.
그러나... 귀찮으니 일단 넘어가기로 합니다. ( @_@)y-~

이제 이 기능을 게임에 적용해야겠습니다.
( '_')y-~

2017년 12월 1일 금요일

[20171201] 잡설 - One Shot

혼자서 하는 인디질이라는 것은 여러가지 애로사항이 있지만...

특히나 시간과의 싸움이 문제다.
시간은 돈이니까.
시간을 절약하기 위해 가급적 재작업 할 일을 줄여야 한다.

하지만 1인 개발이라는 것은 시행착오와의 싸움이다.
방대한 게임 개발의 각 분야를 누가 다 경험해볼 수 있단 말인가.

일단 돌아가게 만들었더라도 해당 컨텐츠를 양산하기 위해서는 작업 효율, 범용성 등의 문제를 해결하기 위해 재작업은 필연적으로 발생한다.

마음은 급하고 시간은 없다.
외로운 싸움이다.
( '_')y-~

< revision history... >