2018년 7월 31일 화요일

[20180731] Buff - Belly and Haste

근 2주만에 숙면을 취했습니다.
찜통 더위와중에 잠깐 비가 왔는데 그게 효과가 있었나 봅니다.

이마에 발진이 생겨서 피부과에 다녀왔습니다.
없어질듯 안없어져서 7 - 8 개월 가량을 방치했는데 주사맞고 약먹으니 금방 좋아지네요.
@_@



작업 이야기로 들어가면 게임이 작동 가능하게 만들기 위한 작업에 돌입했습니다.

그 첫번째 로서 Buff 기능을 작업했습니다.
게임에는 종종 Update 가 수반되고 그로인해 능력치가 조절되는 기능이 필요한데요.
그 것들을 일괄 처리하기 위한 방편입니다.

사실 기반 기능은 지난번에 몬스터 "Stalker" 를 만들때 작업했지만, 당시에는  Update 가 필요하지 않았기 때문에 자리만 잡는 수준으로 작업되었습니다.


Buff 기능을 작업하면서 동시에 처리된 기능들이 있습니다.

1번은 Belly 입니다.

"Project Rogue" 에는 허기짐이라는 능력치가 존재합니다.

  • 턴을 일정량 소비하면 줄어들고
  • 음식물을 섭취해서 늘릴수 있으며
  • 줄어들때 HP 가 가득차있지 않다면 HP가 회복
  • 모두 소비되었다면 일정 턴마다 HP 가 감소

...라는 특징을 가지고 있습니다.



소위 "만복도" 라고 부르는 수치인데요.
Buff 로 처리하기에 딱 맞는 녀석이어서 겸사 겸사 처리되었습니다.


2번은 Haste 입니다.

가장 대중적인 "가속" 주문을 추가하기 위해 작업되었습니다.

  • 아이템을 사용하거나 착용해서 획득하고
  • 턴당 요구되는 Action Point 능력치가 감소

...라는 특징을 가지고 있습니다.



이번에 처리한 것은 턴 제한이 있는 "가속" 이었기 때문에 Buff 로 처리되었습니다.

아마도 "감속" 기능도 손쉽게 마무리 될 겁니다. ^_^



오늘 작업은 슬슬 마무리 합니다.
다들 더운 날씨 잘 넘기시길 바랍니다.
( '_')y-~

2018년 7월 26일 목요일

[20180726] Monster : Bawler

대단한 더위입니다.
인디 시작하고 한 번도 더위가 작업에 지장을 준적이 없었는데 이번은 다르네요
에어컨 없이도 참 잘 지내왔는데 이번에는 잘 지내지 못하고 있습니다. @_@



7월 18일 이후 처음 올리는 작업일지입니다.

19일은 "현타" 가 와서 그냥 하루를 날렸고
20일은 게임 플레이에 대한 이런 저런 구상을 하면서 그냥 보냈습니다.
주말 이틀을 놀고
23일은 "부가가치세 신고"
24일은 몬스터 Dot 작업
25일은 몬스터 Table, A.I 작업
26일은 몬스터 A.I 작업을 마무리 하고 이런저런 정리 작업을 진행했습니다.

덥기도 하고 지치기도 해서 영~~ 효율없이 일했지만, 작업 결과물은 그럭저럭 나왔습니다.

< Idle list x 1 >

< Idle list x 4 >

< Idle list x 8 >

세부적인 묘사가 아쉽다고 생각하고 있지만, 언제나 그렇듯이 여기서 일단 멈춰 둡니다.

< Attack x 1 >

< Attack x 4 >

< Attack x 8 >

이 녀석을 게임에 넣고보니 미리 만들어둔 컨셉들이 거진 소모되어서 언제 날잡아서 크게 자료 수집과 컨셉 디자인을 해야 합니다.

< Damaged x 1 >

< Damaged x 4 >

< Damaged x 8 >

머리에 약간의 쉬는 시간을 줬으니 다음 작업은 뇌를 혹사하는 작업이 될 것 같습니다.
대부분 실질적으로 게임을 플레이 하기 위한 작업이 될 겁니다.

그럼 다시 작업하기 전에 잠깐 쉬러 갑니다.
( '_')y-~

2018년 7월 25일 수요일

[20180725] 고민

A.I 관련 기능과 데이터의 추상화 레벨을 높일 것인가 말것인가?
...에 대해서 고민하고 있다.

이 작업은 제법 오래전에 A.I에 유전자 알고리즘을 적용하려던 계획과도 맞닿아 있는 일이다.

무언가가 가변적으로 돌아가려면 그 형태에 유연성을 부여할 수 밖에 없고, 유연성을 포기할 부분에서는 규격화가 필요한데, 이 작업은 유연성 확보를 위한 것이다.

장기적으로 A.I 구성에 대한 고도의 편의성을 제공하겠지만, 이 기능을 구성하고 관리하기 위해서 막대한 시간도 투입 될 것이다.

내가 툴을 최소한으로 만드는 이유... 그것도 관리 하기 싫기 때문이다. ㅇ_ㅇ

현재의 시스템으로는 약간의 변화만 있어도 A.I 를 별도의 코드로 작성해야 하고, 이것은 이후 시스템의 개선에 큰 걸림돌이 될 것이다.
하지만 시스템을 구성한다고 해서 1인 개발을 하는 내가 그 잠재력을 충분히 활용할 수 있을 것인가.
현재 시스템을 유지하면서 코드 작성과 노가다에 보내는 것이 차라리 이득일 수도 있다.

궁극적으로 "조립식 A.I"  를 위한 시스템을 구성할거냐 말거냐의 문제인데...

얼마만큼의 시간이 남아 있는가?
...라는 질문에  현재의 나는 답이 없다.

얼마만큼의 시간을 더 투입 할 것인가?
...라는 질문에도 답이 없다.

미래를 낙관해서 포트폴리오 만드는 기분으로 지를 것인가?
...말것인가?

아니면 이 모든 문제의 근원인 통장 잔고를 해결하기 위해서 어디 가서 외주, 알바라도 뛸것인가.

때려치고 어디 입사를 할 것인가.

모르겠다 모르겠어.

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가지 작업을 진행했는데요.

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

AP 는 action point 의 약자입니다.
AP가 일정수치가 되면 턴에서 행동을 할 수 있습니다.
각 액터의 AP 는 다를 수 있습니다.

1번의 AP 관리는...
  • "턴은 플레이어가 준비되어야만 진행된다."
...라는 룰을 추가한 것입니다.

이 룰의 추가로 인해 필연적으로
  1. AP 가 준비되었음에도 행동을 못하고 턴을 넘기는 액터들이 생겨나고
  2. 플레이어의 AP 가 준비된 턴에 다른 액터들은 쌓여있는 AP 를 모두 소모하기 위해 여러 행동을 수행
...하게 되는 것입니다.


2번의 공용액션에 한하여 액션당 허용시간의 한계치 설정은...
  1. 1턴에 여러 행동을 수행할 수 있는 만큼 턴당 소모되는 시간이 길어질 수 있고
  2. 길어진 시간을 플레이어가 손놓고 기다리는 상황이 매번 반복될 수 있습니다.
  3. 공용액션에는 1턴당 0.3sec 가 허용되는데
  4. 이 시간을 액션 숫자만큼 나눠서 사용합니다.
...시간을 나눠쓰기 때문에 여러 액션을 수행해도 기다리는 시간을 최소화 할 수 있습니다.

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


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


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

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

2018년 7월 9일 월요일

[20180709] 굴림

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



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

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

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


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


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-~

> 너무나 다행인 거시다.