dev log : 로그( Rogue )

2018년 7월 23일 월요일

[20180723] 잡설 - 익숙해짐

facebook 에서 옮겨옴

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

이 생활에 나름 익숙해졌음을 낯선 것에서 느낀다.

부가가치세 납부하려고 내역 정리중인데...
전에는 종일 걸려서 하던것을 3시간만에 모두 정리했다.

해야 하는 것과 말아야 하는 것을 구분하게 된 것이 가장 큰 이유 같구나.

( '_')y-~

> 할인 열심히 하면 용돈 정도는 들어온다.
> 하지만 난 반년동안 방치했잖아.
> 안될거야 아마. @_@

2018년 7월 18일 수요일

[20180718] A.I 기반 룰 완료!!

덥습니다. 정말 덥습니다.
하루에 샤워를 3번 정도 해야 할 정도로 더운 날씨가 계속되고 있는데...
이 날씨가 한동안 계속 된다니...
건강 잘 챙겨야겠습니다.
( '_')y-~

진행하던 "A.I 기반 업그레이드 작업" 이 마무리 되었습니다.

1. 연속 행동 룰
2. 행동중 피격시 리액션 룰
3. 여기에 덤으로... 행동 선택과정에 우선순위 부여

3번 작업은 모든 액터가 이동관련 행동을 선택한 이후, AP 가 남아 있는 액터들에 한하여 추가 행동을 선택하게 하는 것입니다.

처리 순서에 따라서 엄한 곳을 공격하는 일이 발생할수도 있는데요. 이것을 방지하기 위한 것입니다.

어쨌든 끝났습니다.
기반룰에 대한 큰 작업은 아마 앞으로는 없을 겁니다. ( 부디... )
전체 A.I 를 몇번씩이나 갈아 엎었고 덕분에 Revision 이 2800에 도달하였습니다. @_@

몇가지 자잘한 작업이 발굴되어서 처리해야 하지만... 그 이외에는 어떤 일을 해야할지가 머리에 전혀 없습니다.
제법되는 기간에 이 작업에만 머리를 몰빵한 덕분이겠죠. o_o

한동안 리소스 생산 관련 작업을 하면서 머리의 논리적인 기능에 부담을 줄여줘야겠습니다.

의미 있는 작업을 괜찮게 처리했지만.
축하해줄 사람이 없다는것은 제법 쓸쓸한 일입니다.
1인 개발의 한계이면서, 가장 안좋은 측면입니다.
다음 개발이 있다면( ! ) 꼭 동료를 구해야겠습니다.

그럼 컨셉 자료를 수집하러 갑니다.

( '_')y-~

2018년 7월 13일 금요일

[20180713] 연속 행동

비가 내리다 말다 하는통에 날씨가 더워지고 있어서 불쾌지수가 치솟고 있다고 합니다.
하지만 집구석에 처박혀 있는 저로서는 잘 와닿지 않는군요. @_@

방구석 개발자의 유일한 장점인듯 싶습니다.
( '_')y-~

지난 글에서 언급했던 한 턴에 여러 행동을 수행하는 작업이 마무리 되었습니다.

크게 2가지 작업을 진행했는데요.

플레이어 AP 관리 시스템과 그외 액터의 AP 관리 시스템 분리.
1턴에 여러 행동을 수행할 경우 공용 액션에 한하여 각 액션에 허용되는 시간의 한계치 설정

...입니다.

AP 는 action point 의 약자입니다.

AP가 일정수치가 되면 턴에서 행동을 할 수 있습니다.

각 액터의 AP 는 다를 수 있습니다.

1번의 AP 관리는...

"턴은 플레이어가 준비되어야만 진행된다."

...라는 룰을 추가한 것입니다.

이 룰의 추가로 인해 필연적으로

AP 가 준비되었음에도 행동을 못하고 턴을 넘기는 액터들이 생겨나고
플레이어의 AP 가 준비된 턴에 다른 액터들은 쌓여있는 AP 를 모두 소모하기 위해 여러 행동을 수행

...하게 되는 것입니다.

2번의 공용액션에 한하여 액션당 허용시간의 한계치 설정은...

1턴에 여러 행동을 수행할 수 있는 만큼 턴당 소모되는 시간이 길어질 수 있고
길어진 시간을 플레이어가 손놓고 기다리는 상황이 매번 반복될 수 있습니다.
공용액션에는 1턴당 0.3sec 가 허용되는데
이 시간을 액션 숫자만큼 나눠서 사용합니다.

...시간을 나눠쓰기 때문에 여러 액션을 수행해도 기다리는 시간을 최소화 할 수 있습니다.

어후... 글로 쓰려니 어렵네요. 이쯤에서 글은 접어두고 영상으로 확인하시면 되겠습니다.

이 작업에 대략 50시간쯤 투자되었습니다.
겸사 겸사 A.I 들도 많이 손봤고.
버그도 여럿 잡았습니다.
알찬 작업이었네요. ( +_+)_b

다음 작업은 여러 액션을 수행하는 도중에 공격을 받은 액터의 행동방식을 정의하는 작업입니다.

잠깐 쉬고 마저 달려야 겠습니다.
( '_')y-~

2018년 7월 9일 월요일

[20180709] 굴림

비가 옵니다.
이런 날은 흔히 일이 잘되는 날인데요.
역시나 일이 잘되는군요.
( ^_^)y-~

오늘은 오전 11시 부터 지금( 오후 08:40 )까지 주구장창 일했습니다.
실질적인 작업량은 얼마 되지 않는데요.
꼴랑 Revision 7개를 올렸는데 그나마도 중요한 작업은 아니었습니다.

잠깐 밥먹는 시간부터 일어나서 가볍게 운동하는 시간까지 쉴새 없이 머리를 굴렸고 덕분에 적절한 수확이 있었습니다.

Turn Management System 의 아마도 마지막 주요 작업이 될 작업에 대한 기본 구조를 확정지었고
동시성이 보장되는 몬스터의 공방시스템에 대해서는 약간의 "혼돈" 을 받아 들여서 흐름을 확정지었습니다.

본 작업은 아마 내일 진행될 것 같네요.

1번 작업은 세부적으로는 한 개의 턴안에서 여러 행동을 하게 만드는 작업입니다.
상당한 코드 갈아 엎기가 예상됩니다.

2번 작업은 몬스터들의 집단 공방 상황에서 피격시 행동의 연속성 유지에 대한 룰 구축 작업입니다.

공격을 하는 도중에 맞거나
공격대기 상황에 맞거나.

...등의 상황에 대한 처리죠.

아마 명확함을 포기하는 대신에 미묘한 상황을 만들어줄 것이라 기대합니다. ( @_@)a

이제 좀 쉬어야 겠네요.
( '_')y-~

> 허전하니까 컨셉 잡아놓은 몬스터 몇 마리를 꺼내놔 봅니다.

[20180709] 잡설 - Simultaneity

facebook 에서 옮겨옴...

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

classic rogue-like 장르에 어줍잖게 동시성을 우겨 넣으려니 뭐가 잘 안된다.
@_@

좋은 점은 이 과정에서 x-com 의 턴관리 시스템에 대한 어느정도의 이해를 하게 되었다는 것이다.

절차적인 기반아래에서의 동시성을 위한 스케쥴링과 시분할.
...에 대해 x-com 은 좋은 표본이 된다.

( '_')y-~

> 여기에서 의 x-com이라 함은 "x-com2 : war of the chosen" 이다.
> 다른 시리즈는 몰러
> 동시성 구현을 위해 일정 상황에서 피격 액션을 무시하는 것은 적절한 해결책이다.
> 피격 액션을 무시하지 않으려다 보니 지금의 나처럼...
> 공격자임과 동시에 피격자인 액터에 대해서 별도의 처리를 할거냐 말거냐 같은 고민을 하게 되는 거시다.
> 아오 골이야.

> 가져갈 것과 포기할 것을 명확히 하는 것이 가장 어려워.
> 이건 아무리 공부하고 고민해도 해결이 안돼.

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

가치가 경합하는 상황에서 약간의 "혼돈" 을 받아들이면 그럴싸한 컨텐츠가 될 수도 있다.

현실이라면 주먹다짐이 될 수도 있지만...

게임 안에서라면 문제 없잖아.

( '_')y-~

> 이 것을 주 컨텐츠로 게임을 만들면...
> 가장 흔하고 쉽게 접하는 그 장르의 게임이 된다던가 만다던가.

2018년 7월 5일 목요일

[20180705] Thickness Complete

덥습니다. ( @_@)y-~
소나기도 오고 후덥지근한 날씨가 이어지고 있네요.
조만간 근처 커피숍으로 피난을 갈지도 모르겠습니다.

어제에 이어 진행하던 벽의 두께 조절 기능이 마무리 되었습니다.

오늘은 작업 내역을 우선 간략하게 image 로 설명하겠습니다.

< 1 : increase wall thickness >

< 2 : setup gate >

< 3 : make road for gate >

< 4 : make road >

< 5 : test... old setting >

< 6 : test... new setting >

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

벽이 두꺼워지는 만큼 각 공간의 최소 크기가 5 x 5 가 되었습니다.
( 벽 2 + 방내부 1 + 벽 2 )

만들어 놓고 보니 이 것이 생각보다 여러가지 문제를 동반하는 것을 발견하였습니다.

기준으로 잡아놓은 34 x 34 크기의 맵으로는 충분한 양의 공간 분할이 불가능해졌습니다.

위의 5, 6번 이미지를 보면 맵이 매우 허전한데요.
맵 크기는 그대로 두고 공간 분할의 기준 크기를 늘렸기 때문입니다.

4번 이미지는 44 * 44 크기의 맵으로 만들어진 겁니다.
맵에 허전함은 느낄수 없지만 맵의 크기가 많이 증가했습니다.

"맵이 비대해져서 유저가 피곤함을 느끼지 않을까"
...라는 것이 지금의 가장 큰 걱정입니다. @_@

또 다른 문제는 벽 두께를 일률적으로 적용하다 보니 벽 두께가 곧 방과 방간의 기본 거리가 되는 것입니다.

벽 두께가 1일때는 나름 속도감있는 공간 간의 이동이 가능했는데 벽의 크기가 2가 되면 3개의 타일을 건너야 다음 공간에 도착합니다.

그리고 길은 시야가 1로 줄어들지요.

"지루함과 답답합을 느끼지 않을까"
...라는 것이 두번째 걱정입니다.

그리고 일률적인 벽두께가 아니라 가변적인 벽 두께를 적용해야 할까?
...라는 것도 추가적으로 발굴된 과제입니다.

어찌되었건...
벽의 크기를 줄여도 늘여도 잘 돌아가게 코드가 구성되었기 때문에 이제 시간을 두고 이런 저런 느낌을 확인한 다음에 어떻게 마무리 할지 결정해야겠습니다.

그럼 오늘 작업은 여기까지~!!
( '_')y-~

< All in one >

2018년 7월 4일 수요일

[20180704] Wall Thickness

날씨가 많이 더워졌습니다.
축축 쳐지는 것이 휴식이 간절하네요.
힘내서 이 달은 버텨볼 생각입니다.
( '_')y-~

Tile 과 Theme 기능이 대충 정리되어서 이 부분에서는 Theme 별 Tile 을 잘 찍는 것만 남았습니다.
나름 흡족 스럽습니다.
( ^_^)y-~

이어서 약간의 코드 정리 작업을 진행했습니다.

경험이 적은 분야의 코드를 작업하게 되면...

이런 저런 기호가 남발되고
코드가 잘 정리되지 않으며
중복 코드가 여기 저기 남는

...그런 일이 쉽사리 벌어집니다.

완전히 정리되지는 않았지만 적어도 Tile Tool 관련해서는 이름과 기능이 잘 맞아들어가도록 마무리 했습니다.

그리고 오늘.

오늘은 Theme 기능을 추가하면서 발굴한 작업을 진행중입니다.
"벽의 두께를 조절하는 기능" ...입니다.

Map 을 구성하는 각 공간( 방 ) 들은 벽을 공유 하고 있습니다.
현실로 끌고 와보면 "내 집의 벽은 옆집의 벽이기도 하다" 는 것과 마찬가지 입니다.

그리하여 각 공간이 Theme 별로 다른 Tile 을 사용하게 만드는 기능이 이 현실과 만나면...
처리되는 순서에 따라서 Theme 와 맞지 않는 벽 Tile 이 출력되는 경우가 있게 됩니다.

아래의 그림 처럼 말이죠.

< Your wall is my wall~! >

우선 순위 조절로 어느정도 극복이 가능하지만...

부족한 느낌이 강하게 들어서 벽의 두께를 조절하는 기능을 넣어보기로 했습니다.

지금은 우선 Test 환경만 작업되어 있는 상태입니다.

< New test scene >

각 공간의 크기 조절부터 유효 영역 설정, 그리고 길의 생성까지.

한 단계씩 확실하게 손 볼 생각입니다.

작업하러 갑니다.

다들 태풍피해 없이 잘 지내셨으면 좋겠네요.

( '_')y-~

2018년 7월 2일 월요일

[20180702] cocos2d-x 3.15 Projection Matrix Problem

20180629 : 발견( facebook 에서 옮겨옴 )

일정 크기 까지는 멀쩡한 Tile Sheet 가 600 초중반 이상으로 커지면 상, 하, 좌, 우가 짤리고 중간 부분에서 Tile 이 늘어난다.
( 내가 이거 확인하려고 한땀 한땀 pixel 단위로 다 확인했다구~! )

가로나 세로 한쪽만 넘어가는 경우 해당 방향에서만 문제가 생긴다. 미묘하게 scale 비슷한 것이 일어나는 느낌인데... 자세한 것은 뜯어봐야 알 것 같다.

이런 종류의 문제를 미연에 방지하고자 패턴 조립단계에서부터 크기와 위치 값을 정수 로 한정 했고 Pattern 조각들도 정수값에 딱 맞는 사이즈를 가지며 반으로 잘라도 그냥 정수다.

덕분에 내 코드 부분은 빠르게 확인이 마무리 되었고, 다음작업으로 맘편하게 Texture Render 관련 cocos 코드를 디비게 되었다.

cocos야 나한테 왜이러냐~!~! 왜이러냐고~~!~!

( '_')y-~

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

20180702 : 진전( facebook 에서 옮겨옴 )

지금의 tile sheet 짤림 문제는...

cocos가 perspective view 를 깔아놓고 거기에 2D view 를 올리다 보니 발생한 문제같다.

지금 보니 Render to Texture 만의 문제가 아니다.
해상도가 늘어나면 1 픽셀이 짤려 나가는 것은 그냥 일어난다.

Projection Matrix 설정에 문제가 있는거지...

난 또 국지적인 문제인줄 알았잖아.

이전에 shader 작업하면서 이런 저런거 만들때 z 값이 들어가면 아무렇지도 않게 3D View 로 보이길레 이게 뭔가 했는데...

그~~~~으~~~런 거였구나~~~~아.

하아.
벽보고 욕이나 좀 해야겠다.

( '_')y-~

> 이제 이걸 어쩐다.

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

20180702 : 해결

3D 뷰 에서 크기와 시야각이 고정되어 있는데 2D View에 이격이 발생한다면 그것은 기준점의 문제일 것이다.

...라는 가정하에 eye 를 설정하는 코드를 살펴 보았다.

float Director::getZEye(void) const
{
return ( _winSizeInPoints.height / 1.1566f );
}

위치를 비율로 잡는 거야 알겠는데 왜 1.1566f 인가?
...라는 의문으로

cocos2d-x git CCDirector.h
...에서 최신 버전의 코드에 어떤 변경점이 있는지 확인해 보았다.

float Director::getZEye(void) const
{
return ( _winSizeInPoints.height / 1.154700538379252f );//(2 * tanf(M_PI/6))
}

...와 같이 코드가 바뀌어 있었다.

> PI 는 180` 도 기준
> / 6 이면 30`
> * 2 면 60'
> getZEye 를 사용하는 코드에 보면 기준 시야각이 60` 이다.
> 설정 파일에 쳐 넣어 좀. -_-+++

그래 이런 심각한 문제를 아무도 눈치채지 못하고 넘어갔을리가 없지.

적용했고 잘 돌아간다.

( '_')y-~

> cocos 인간들아 내 시간 물어내라.
> 물어내라고. T_T
> 이 시점에 가장 빡치는 부분은 내가 cocos 관련 주요 이슈 메일을 받고 있고
> 꾸준히 읽어왔다는 것이다.
> 아... 승질나.

< Changes >

< Complete Verification >

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

20180706 : 뒷 이야기

cocos projection matrix 버그 잡고 났더니
화면 scroll 될때마다 눈에 밟히던 화면 지글거림도 사라졌다.

툴 작업중에 버그를 발견하지 않았다면...
후반 작업에서 지글거림 해결하겠다고 갖은 삽질을 했을텐데.끔찍.

( '_')y-~

> 너무나 다행인 거시다.