마운트 앤 블레이드 장르의 게임을 만드는 중.
매일매일 6시간 개발 + 2시간 기획 + 1시간 산책.
일단 결과물부터
3d 공간에서 픽셀 아트로 연출.
옥토패스 트래블러라는 게임의 비주얼을 보고 따라 했는데, 생각보다 인터넷에 따라하는 법도 제법 있음(정작 나는 스퀘어 에닉스 게임 해본 적 없음). 결과도 만족스러워서 스타일은 이대로 굳힐 거임.
지금 화면에는 다 안 나왔지만 씬에 6000명이 있는데, 당연하지만 최적화를 위해 DOTS로 만들었음. 내 4년 되어 가는 노트북으로도 60fps가 안정적임.
그리고 각 엔티티는 FSM이랑 Utility로 AI를 구현했는데, 지금은 이동이랑 공중, 휴식 상태만 만들어 놓아서 별로 역동적인 게 없음.
사실 DOTS는 손에 꽤 익어서 별로 시간을 많이 잡아먹진 않았는데, 이번에는 주로 3개의 기술적인 난관이 있었음...
1. 지형: terrain을 baking해야 함--다행히도 터보 유튜브에서 봤던 게 있어서 손쉽게 해결했음. 그게 없었으면 지형 하나하나 다 손으로 깔아야 할거야.
2. 물리: 최적화를 위해 Gravity를 꺼둔 상태임. terrain을 baking해둔 덕분에 Gravity로 유닛들을 땅 위에 박아두기 쉬웠지만, cpu가 너무 낭비되고 있었음. raycasting으로 지면과의 거리를 재서 Gravitiy비슷한 느낌을 내는 건 그다지 어렵진 않았음. 어려운 건 유니티 공식 문서를 뒤지는 것 뿐. 현재는 플레이어만 좀 정교하게 만들어 두고 ai유닛들은 상대적으로 기계적인 움직임을 보임.
이렇게 바꾸고 난 뒤에는 제일 골치 아픈 게 내리막길이었는데, raycast가 캐릭터 정중앙에서 나오기 때문에 캐릭터의 콜라이더 밑에 고도차가 존재하면 멈칫멈칫거림(무슨 얘기인지 몰라도 됨). 진짜 혼신의 똥꼬쇼를 다 한 결과로 순수 Physics Velocity로 이동하면서, 오르막 내리막, 넉백 등을 구현하는 것에 성공함.
성능면에서 결과적으로 6000명 기준으로 cpu사용량은 18~22퍼에 그쳤음. Gravity를 쓸 때는 24~26퍼 였음. 내 목표는 모든 구현을 하고 나서 cpu사용량 35퍼 미만임.
3. 길찾기(작업중): 이건 지금까지 한 75% 진행했는데, Flow Field(유동장) 알고리즘이랑 WaveFront Propagation(파도 전파) 알고리즘을 합친 방법임. 이렇게 해도 성능이 부족할 거 같아서 spatial partitioning(공간 분할)도 넣는 중임.
어쨌든 길찾기 알고리즘이 미완이라서 현재는 그냥 20초 간격으로 전진 후진을 하는 상태임.
그리고 가장 시간을 많이 할애한 부분:
1. 셰이더
뒤에 보이는 구름은 skybox에 메티리얼을 넣어서 구현한 건데, 구름을 3층 구조로 해서 이동속도, 햇빛 반사 등을 다르게 했음.
그리고 눈에 띄지는 않지만 바닥에 구름의 그림자를 넣었음. 이건 높은 곳에 가거나 멀리서 보면 눈에 잘 띔.
고백할 게 있다면 skybox 셰이더는 AI랑 만든 거임. 근데 문제가 뭐냐면 저런 것조차 12시간 넘게 프롬프트랑 씨름해서 겨우 얻어낸 것임. 물론 원래는 좀 더 복잡한 효과를 주문했었음. 근데 얘가 고장이 나버려서 계속 오류 나는 코드를 토해 냄.
어쨌든 그래서 바닥에 있는 구름 그림자는 걍 내가 hlsl로 만들었음. 1시간 걸림.
2. 일출 일몰
사실 굳이 넣어야 하나 싶었어.
근데 만일 하나 전투가 오래 지속되니 해의 위치가 달라진다거나, 밤에 싸우다가 새벽빛이 들어온다거나, 이런 연출을 원했음.
이것도 사실 간단하게 directional light 각도만 틀면서 하면 됨. 다만 게임적 허용이라고 해서, 밤의 시간은 짧게 하고 낮의 시간은 길게 함.
3. 포스트 프로세싱
이건 사실 시간을 많이 쓰면 안되는데 가지고 노는 게 재밌어서 오래 걸림. 아마 다른 개발자들도 비슷한 경험을 겪었을 거야.
좀 고민 했던 건 depth of field. 멀리 있는 건 흐리고 가까이 있으면 뚜렷이 보이게 하는 건데, 추가한 이유는 그냥 보기 좋아서(...). 약간의 트릭이라면 내 캐릭터의 앞이랑 뒤 방향에서 흐리게 만드는 표준 거리를 다르게 해야 해. 카메라랑 가까운 유닛들을 기준으로 흐리기 기준을 잡으면 멀리 있는 애들은 너무 빠르게 흐려지는 느낌이고, 반대면 카메라 코앞을 막고 있어도 흐려지지 않을 거야.
다음으로 해야 할 것들:
1. 기획 마무리. 지금은 전투 파트를 제작 중이지만, 마운트 앤 블레이드 장르를 지향하는 만큼 rpg 시스템도 중요해. 난 개인적으로 마앤블 시리즈에 유감스러웠던 부분인 스탯간 벨런스, 빈약한 서사를 다룰 거 같아. 대신 내가 만들 게임에도 부족한 부분이 있겠지. 예를 들면 공성전 같은 건 아직 어떻게 만들어야 할 지 상상도 안되고, 말 타고 내리고 하는 것도 진짜 귀찮을 거 같아.
2. 길 찾기 알고리즘 완성
3. 아트 리소스 제작. 내가 시간이 없어서 걷기 동작을 일단 6프레임짜리로 만들어서 테스트 중인데, 고쳐야 할 부분이 눈에 밟힘.
4. 아틀라스 패킹: 지금은 shader graph로 스프라이트 시트의 한컷 한컷씩 보여주고 있음. gpu 최적화를 위해서는 하나의 이미지에 최대한 많은 유닛들의 스프라이트 시트를 욱여넣는 것이 중요해. 일단 유니티 Tool로 패킹하고 json에 uv데이터를 남기는 코드를 짰는데, 이제 shader graph랑 씨름 할 시간임...
이건 gif에 나온 씬을 담은 데모 빌드임! 관심 있으면 다운해서 돌려봐도 됨. fps은 60프레임으로 고정했음.
drive.google.com/file/d/1BG8Wi4tzKVwFy4_UmWmK44K_A7c9dePg/view?usp=sharing
testBuild.zip
drive.google.com
개재밌겠는데
무슨 말인지 모르겠지만 추천ㅋ
그냥 비주얼적으로 피드백 줘도 대환영임
마앤블 길찾기는 그냥 타겟설정은 부대 단위로 하다가 근접한 애들이 있으면 걔 공격하고 그런느낌이던데.. 각 유닛이 썡으로 길찾기 돌리는 느낌은 아니었음. 걔들은 2D도 아니고 쌩으로 3D상에서 네비메시 굴리는 것 같던데 게다가
dots에 네비메시가 없어서..그걸 baking하거나 만들어야 함. 그리고 난 일종의 방식으로 만드는 셈이고. 그리고 사실 flow field 알고리즘도 유닛마다 썡으로 길 찾는 게 아님. 물론 나도 일정 거리에 들어오면 그냥 무지성 공격 시키게 하고 있음.
생각해보니까 님이 말한 접근방식이 구현하기 쉬울듯
고수...
와 맛있다
길찾기 궁금하네 어떻게 했다는거임?