반건조수달의 마른안주

1. 서문1) 어느덧 학교를 졸업하고 회사에 이력서를 넣고 있다. 결과가 나오기까지 3주에서 4주가 걸린다고 한다. 게임에서 건너뛰기하듯 시간을 건너뛰어 결과를 확인하고 싶다. 기다림은 힘들다. 2) 시간을 보내려 스위치2를 샀다. 2주가량 게임에 빠져 젤다 왕눈과 포코피아 엔딩을 봤다. 포코피아를 더 플레이할까 했지만 이제는 게임에서 집을 짓는 게 일처럼 느껴져 그만뒀다. 한숨을 푹 쉬며 야외취침하는 이상해씨를 바라보며 게임을 껐다. 그래서! 이제는 게임세계를 넘어 현실세계를 탐험하러 간다. 제주도로사실 그냥 심심해서 간다. 3) 해외로 나가기엔 불편하고 번거롭고, 너무 가까운 곳으로 가자니 기분이 안 산다. 적당히 멀고 불편하지 않은 제주도가 이럴 때 딱이다.(게다가 남들 학교 가고 일하는 3..

블랜더의 가장 큰 장점은 뛰어난 실시간 렌더링인 것 같다. 맥스와 같은 기존 모델링 툴에서는 렌더링 하는데 시간이 꽤 걸린다. 간단하게 렌더링하면 퀄리티가 좋지 못하다. 반면 블랜더는 실시간 렌더링 결과가 정말 뛰어나다. 최종 결과물과 거의 비슷한 퀄리티를 실시간으로 볼 수 있다. 이게 블랜더의 가장 큰 장점이다. 내 일이 전부 모델링뿐이라면 모를까 대부분 모델링에서 텍스처링까지 하고 엔진에 넣어보는 작업을 하게 된다. 그럴 때면 내가 맞는 방향으로 가고 있는지 확인하기 위해 한번씩 렌더링을 걸어보는 작업이 중요하다. 그럴 때 맥스는 좀 불편하다. fbx를 따로 가져가서 따로 렌더링을 해봐야 한다. 렌더링 세팅을 해줄 수 있지만 그러면 파일이 필요 이상으로 무거워진다. 블랜더는 파일도 가벼우면서 실시간 ..

블랜더로 컨셉아트를 그리고 있다. 렌더패스가 생각보다 더 유용하게 쓰인다. mist가 기본적으로 근경과 원경을 확실히 나눠줘서 너무 좋고, 처음부터 3D 메쉬에 매핑하면 될 것을 귀찮아서 안 하고 포토샵으로 텍스처를 입히고 있는데 이게 그냥 했다면 미친짓이었겠지만 렌더패스로 노말을 뽑아서 하니까 할만하다. 그리고 뽑은 노말 z 축을 마스크로 걸어서 색을 칠해주니 위에서 내리 쬐는 빛의 영향을 표현하기 정말 편하다. 그냥 무작정 오버레이로 뽑으면 좀 어색하게 나오는데 이건 정말 괜찮게 나온다. 블랜더 짱

처음에 플레이어 캐릭터를 더미로 세워두고 테스트를 하다가 AI로 따로 진화한지 얼마 되지 않았다. 그래서 아직 버그가 계속 나온다. 체력부분에도 버그가 있다. 일반 공격을 할 때는 멀쩡한데 특수 공격을 하면 플레이어와 AI의 체력이 동시에 깎인다. 하...그래도 지금 발견하고 고치고 있ㄴㄴ게 참 다행이다.

블루프린트 최적화를 하면서 대부분 다 고쳤는데 버그가 하나 남았다. 비헤이버 트리에서 wait 노드가 문제다. 1.7초 이상 기다리면 버그가 일어난다. 정확히 1.7초다. 만약 wait 노드를 꼭 써야 한다면 1.7초는 무조건 넘길 것이다. 그래서 wait 노드를 쓰지 않는 방법을 생각해봤다. 아마도 Decorator를 쓰면 될 것 같다. 기존의 태그로 캐릭터 액션과 스테이트를 정의하는 시스템과 업데이트 비헤이버 함수를 통합하려고 했었는데 wait를 안쓰고 뭔가 잘 할 수 있는 방법이 뭐가 있을까 고민을 해보니 Decorator를 쓰면 될 것 같았다. 함수 내에서 태그를 검사하는 것보다 비헤이버 트리에서 데코레이터로 태그를 검사하는 기능을 만드는게 더 범용성 있고 AI별로 적용할 수 있고 좋을 것 같았다..

요즘은 컨셉아트를 블랜더로 한다길래 나도 블랜더로 만들어보는 중이다. 써보니 왜 다들 쓰는지 알 것 같다. 우선 프로그램이 가볍다. 기존의 3D 툴이나 렌더링을 할 수 있는 게임 엔진, 마모셋 같은 프로그램은 무거운 편이다. 기본 용량도 크고 그 안에서 할 수 있는 작업도 많은만큼 부하가 크다. 반면 블랜더는 용량 자체가 굉장히 작다. 반면 성능은 필요에 따라 기존의 프로그램들과 동일한 모습을 보여준다.렌더링 퀄리티가 괜찮다. 프로그램이 가볍고 무겁고 간에 렌더링 퀄리티가 좋지 않았다면 안 썼을 거다. 렌더링 퀄리티가 괜찮다. 렌더링 속도도 좋은 편이다. 가볍게 좋은 렌더링 퀄리티를 뽑을 수 있다보니 간단하게 작업을 하고 바로 포토샵으로 넘겨서 작업을 하거나 아니면 블랜더에서 더 퀄리티를 높이기도 한다...

블루프린트를 계속 최적화하고 있다. 지금 최적화를 한번 한 게 다행이다. 꼬인 게 그리 많지 않아 쉽게 풀 수 있었다. (나중에 ㅇ이걸 하려고 했다면 와우...) 덕분에 casting을 사용하지 않는 다양한 방법을 시도해보고 있다. Game State Manager 시스템을 도입했다. 원래 두 캐릭터가 서로 casting 하면서 정보를 공유했는데 메모리를 많이 잡아먹고 오류가 많이 나서 프로젝트가 꺼지기도 했다. 그래서 둘의 정보를 Game State 클래스 블루프린트에서 관리하고 두 캐릭터는 각각 begin play에서 state manager를 변수화해서 사용한다. 메모리 문제도 없어졌고 코드도 더 읽기 쉬워졌고 무엇보다 나중에 AI가 플레이어의 공격을 피하는 동작을 만들 때도 도움이 될 것 같다. ..

다른 시스템을 마저 만들기 전, 이미 만들어 놓은 시스템을 점검하면서 최적화하고 고칠 부분은 고치고 있다. 최적화는 생각보다 문제는 없었다. 몇가지 틱 이벤트만 지워주고 casting 몇개만 없애주면 지금 할 수 있는 일은 다 했다고 볼 수 있다. 검사 해 봤을 때도 레퍼런스 의존도가 심하지 않았고 메모리 대부분은 텍스처와 애니메이션이었다. 래그돌에는 문제가 조금 있었다. impulse가 두번 적용되는 문제가 있었다. 디버그 목적으로 print string을 중간중간 잘 넣어 놓은 덕분에 빠르게 고칠 수 있었다. 컴포넌트의 일부에서 변수를 공유하는 바람에 오류가 난 것 같았다. 변수를 분리해주니 문제가 사라졌다.  래그돌 상태일 때 카메라가 플레이어를 따라오지 않았다. 래그돌 상태에 진입하면 멈추고 다시..

사실 프로젝트가 크지 않기때문에 그렇게까지 많은 노력을 기울이지 않아도 큰 문제는 없다. 그래서 괜히 귀찮아지고 고쳐야하나 싶은 부분이 많기도 하다. 그러나 두가지는 꼭 짚고 넘어가야 좋을 것 같다. Casting과 Tick이다. Casting은 의존성을 지나치게 높이고 똑같은 애를 여러번 캐스팅하면 문제가될 수있다. Tick은 매 프레임 계산이 들어가기 때문에 문제가 된다. 특히 블루프린트에서는 C++과 다르게 Tick 이벤트의 부하가 심하다. 이 두개는 무조건 개선하고 나머지는 깔끔하게 정리만 하려고 한다. 지금도 충분히 잘했다. 아마도..?

고치려면 상태를 알아야 한다. 어디가 삐긋치려면 상태를 알아야 한다. 어디가 어긋난 지 알아야 그 부분을 고칠 수 있다. 게임엔진에서는 디버깅툴, 프로파일링 툴과 같이 상태를 진단하는 도구를 이용해 상태를 확인하고 고친다. CPU와 GPU 사용량부터 메모리 사용량, 레퍼런스 의존도와 같이 다양한 상태를 보여준다.  상태를 띄우는 위젯을 만든 것처럼 기본적으로 제공하는 정보도 있다. 몇가지 디버깅 툴을 알아보도록 하겠다. https://dev.epicgames.com/documentation/en-us/unreal-engine/using-the-gameplay-debugger-in-unreal-engine?application_version=5.4게임플레이 디버거플레이 중 `를 누르고 EnableGDT를 ..