WHY'S BlOG

프로젝트 작업을하면서 기존 맵에 이동제한구역을 설정해야했습니다..

하지만 이전에 Navigation Bake가 있는상태에서 새로할려면 Clear을 하고나서 해야하는데..

그전에 Bake할때 쓰인 오브젝트들을 어떻게 위치를 지정했고 또 어떤 방법으로 Bake를 했는지 

오래되었기에 아는사람도 없는 상태였습니다.

이미 이전에 다 Navigation으로 캐릭터가 다니는 길, 적이 다니는길을 다 작업해놓은 상태였기에..

기획분과 아트분이 말씀하신 빨간색 네무부분을 이동제한구역으로 새롭게 할려면 다시 Bake해야하는 상황이었습니다..

여러번 bake - clear - bake - clear을 해본 결과!

적이 껴서 움직이지 못하는 사태가 발생했고..

계속계속 다시해보다가 정말 간단하게 해결했습니다! Bake없이!

Compomnent 로 'NavMeshObstacle'을 추가하면 되는일이었습니다! :0!!!

너무 간단하네요!

그리고 Carve 는 해당오브젝트의 모양만큼 네브메쉬에 구멍이 뚫리게되어 캐릭터들이 해당 구멍을 피해서 다니게 됩니다!

그래서 저는 따로 3D오브젝트로 박스를 만들어주고 이동제한구역이 있는 곳에 맞게 박스를 배치한뒤 위처럼 컴포넌트를 추가해줬습니다.

Carve Only Stationary는 정지된 상태에서만 네브매쉬에 구멍을 뚫는것으로 

이를 비활성화하면 실시간으로 오브젝트의 움직임에 따라 구멍을 파낸다고 합니다

저같은 경우에는 기존의 네브매쉬를 건드리면 안되기에 이렇게 Nav Mesh Obstacle을 사용했는데

보통은 움직이는 장애물을 표현할때 많이 사용한다고합니다

하루종일 Bake한게 아깝긴하지만 그래도 해결이 돼서 너무 다행이네요! :D!!

다들 화이팅!

혼자서 게임을 만들어볼 생각이 있어서 나름 생각만 하던 기획안이 있었습니다.

두개의 캐릭터를 동시에 조작키로 움직이는것이었는데요..

유튜브에서 게임영상들을 보면서 어려운 게임들을 보니 저도 모르게 영향을 많이받았던것같습니다.

여기서 구체화해서 두개의 캐릭터 중 하나는 사람.. 다른 하나는 영혼으로 구상하였습니다 ㅋㅋ

그리고 키보드에서 한명이 WASD와 방향키 조작을 하는것은 그때도 좀 힘들거라고 생각했는지

나름 모바일로해서 양쪽의 2분할 화면을 통해 각각터치로 진행하면되겠구나 라고 생각했죠.

보이시나요? 왼쪽에선 미션을 수행하고 오른쪽 화면에선 총쏘고 앉아있는거! 환장하겠네!

그러다가 두 캐릭터를 동시에 움직이는게 굳이 조작키 두개일 필요는 없지않나? 반대로 움직이면 한번에 두 캐릭터가 다 움직일 수있잖아! 라는 생각을 떠올리게됩니다! :0! 

여기서 또 개연성을 부여해서 귀신은 사람과 반대로 행동한다는 설이 있으니 어떻게 또 말이 맞아보이구요??

그래서 한가지 조작키로 두 캐릭터를 동시에 움직이는 게임을 생각해냅니다!

이 당시에는 2D로 생각을 했고 미로형식을 생각했습니다. 

반대로 움직이다가.. 같은 지점에서 만나게되면 온전한 몸(본체+영혼)이 되어 출구로 나갈 수 있는!

나름 스토리도 구축했고 개연성도 부여하였고 참신성도 있다고 생각했지만..

게임에 넣을 미로에는 이런것들이 있겠지 싶어서 나름 찾아보고 구성해보면서 느꼈습니다.

어 ㅋㅋㅋ 뭐지??

쫌 망했네 ㅋㅋㅋ..?

 미로맵 2개로  2D로 미로를 만들려고하니 서로 겹쳐지는 부분이 있어야하는데..설계해보니

엄청나게 복잡해졌습니다. 그냥 단순히 일자여도 복잡해질까말까? 인데 난이도가 올라갈껄 고려해서

조금이라도 모양이 복잡해지면 정말 복잡해지는것입니다!

심지어 맵이2개가 아니라 1개여도 나름골치가 아파집니다!

서로 반대로 움직이는 캐릭터가 만날려면

양 끝에서 서로 출발을 해야하는데 그러면 무조건적으로 둘은 대충 예상되는

중간부분에서만 계속 만나게됩니다.

난이도가 쉽고 어렵고를 떠나서 게임자체가 갑자기 엄청 재미가 없어지는거죠! 

생각할것도 없고 뭐 똥개훈련시키는것도 아니고.. 

만드는 저도 힘들고 플레이할 사람도 재미없는게 뭔가 눈에 훤히 보였습니다.

이 시점에서 게임을 2D로 할지 3D로할지 많이 고민했습니다. 2.5D는.. 나름 쟤도 2D3D 사이에 차원이라고 생각을 하였으나 현재 고민하고있는 부분에 대해서는 실질적으로 해결책이 될것같진않았습니다.

하지만 선택지가 2가지 밖에 없으니 생각보다는 쉽게 결정했던것같습니다.

지금 제 게임의 정체성(동시에 두 캐릭터를 하나의 조작키로 움직이는것)을 포기하지않는다면 2D는 절대 안된다.

라는 결론이 나왔고 생각보다 3D로 생각하고 난 다음부터는 맵설계가 그나마 쉬워진것같았습니다.

대신 처음2D로 할려고했던 이유는 최적화문제도 있지만..제가 직접 도트를 찍어 기획아트개발 모두를 전담할려고했기에 고민할 필요가 없어 보이던 3D도.. 나름 고민했습니다.. 

그래도 다행인건 2D에서 같은 지점에서 만나야 했던것을

3D에서는 같은y축(세로 선상)에서 만나면 되기에 다행이었습니다.

큰 틀이 바뀌진 않았죠 ㅠㅠ 휴 ㅠㅠ

그 다음부턴 게임 구체화를 했던것같습니다. 구체적으로 어떻게 나타낼것이며 스테이지들을 보여줄때 어떻게 보여줄것이며 게임 메인화면은 어떻게 구상하고 게임오버시, 클리어시 어떻게 나타낼지를 구체화했죠.

직접 손으로 쓴 것들도 되게 많은데.. 지금 개발일지를 적자고 수첩을 찾아서 사진을 찍을려고 하니 이미 태블릿에 있는것들 찾아서 캡쳐만 해도 양이 상당해서 직접 손으로 쓴것들을 따로 안올리겠습니다.

그렇게 틈틈이 게임을 구체화 하고있었는데.. 

위의 컨셉들을 모두 엎기로했습니다.

이유는 다음 개발일지에서....

유니티 3D 게임 프로젝트를 진행하게되면서 최적화의 중요성을 많이 알게되었습니다.

빌드자체에서 걸리는 시간이라던가 게임플레이 도중에 발생하는 지연이라던가 그런것들을 보며 구현도 중요하지만 구현한것을 원활하게 돌아갈 수 있도록 최적화하는것이 정말 중요하구나를 깨달으며 프로젝트에 적용한 최적화 방법을 소개할까 합니다.

부모-자식 간의 관계를 최소화로 하자

유니티에서 Hierarchy의 depth가 깊어지면 깊어질 수록 부모의 결과를 전파하기 위한 계산이 추가됩니다.

부모에 대한 position이나 rotation 등 정보가 변경되면 자식들에게도 메세지를 보내게 되므로 성능에는 악영향을 끼치게됩니다.

그래서 저는 프로젝트내에서 건설과 관련된 오브젝트를 맡았었는데..

왼쪽이 이전에 있던 오브젝트 하나이고, 오른쪽이 하나의 오브젝트를 다 떼어내어 따로 분류를 해놓은 부모-자식간의 관계를 최소화로 만든 Prefeb들입니다. 저는 원래 Building하나로 오브젝트 풀에 넣어 재사용했던것을 모두 다 떼어놓아 오브젝트들 모두 각자의 prefeb으로 해결했습니다.

확실히 왼쪽에 있었을때의 코드들도 항상 부모-자식을 참조하고 있었기에 좋은코드라고 볼 수 없었고 저도 만들면서 일단 완성하는거에 초점을 두자라고 생각을 하며 만들긴했어서 많이 더러웠습니다.

하지만 최적화에 신경을 쓰게 되면서 제가 만든 오브젝트가 정말 이상한모양이라는것을 깨닫고 오른쪽처럼 기존의 오브젝트들을 하나씩 다 떼어놓고 코드들도 정리하고나니 정말 보기에도 좋고 이해하기에도 좋은 결과물이 나왔습니다.

좀 더 확실한 결과를 보여드리기위해 profiler 을 이용해 비포&애프터 사진을 찍어 성능비교를 하고싶었으나, 프로젝트를 하는도중에 이전 결과물이 날아가버려 (ㅠㅜ..) 구체적인 성능을 비교할 순 없었습니다.

하지만 계층구조가 깊으면 깊을수록 자식들의 수가 많아져 그만큼 연산(Transform...)이 늘어나기때문에 속도를 위해서라도 부모-자식 간의 관계를 최소화하는것이 좋습니다.