치킨 날다

저번에는 간단히 UI 스케치랑 규칙 정리만 했다면 오늘은 Unity 맛보기를 해보았습니다.

엄... 예전에 해보긴 했는데 다시 하려니까 막막하고 답답하고 미쳐버릴뻔했습니다.

Unreal로 개발하는 것도 막히는 경우는 있지만 찾아서 보면 이해가 되는데

Unity는 익숙치가 않아서 이게 맞는건지, 내가 생각하는게 옳은건지 모르겠더군요.

우선 간단히 UI를 만들어보았습니다.

언리얼에서는 Widget을 상속받는 클래스를 만들어 필요한 함수를 선언해주고,

블루프린트로 그 클래스를 다시 상속 받아 이미지를 생성한 뒤, 선언한 함수를 적용하면 되었습니다.

이 과정에서 한번 만들어 놓은 Widget을 변수로 가지고 있으면 모듈화를 할 수 있었습니다.

하지만 유니티에서는 아직까지 그런 방식은 찾지 못하였습니다.

씬에서 UI를 직접 넣고 각 컴포넌트에 스크립트코드를 추가하는 방식인데 여간 불편한게 아닙니다.

사실은 앞으로 5시간은 더 개발해야 하루에 정한 개발량을 채우는데 도저히 아니다 싶어 개발을 중단하였습니다.

그 대신 몇가지 필요한 것들을 검색해보았습니다.

우선, 블루투스를 이용한 통신은 불가능한것 같지는 않습니다.

에셋에 존재를 했고, 그 중 한 에셋에서의 설명으로 보아 최악의 경우 직접 안드로이드 API를 건드려서라도 해결이 되지 않을까 싶습니다.

두번째. 프로젝트 생성 시 3D 프로젝트와 2D 프로젝트의 리소스 타입 별 성능 차이가 있다는 설명이 있었는데 이 부분도 크게 문제가 될것 같지는 않습니다.

이를 마지막으로 오늘 개발 및 검색은 종료하였습니다.

다음 개발은 화요일이 되겠지요.

그 전에 친구에게 유니티 입문서를 빌리든, 서점에서 하나 사든 하여 책을 보면서 좀 해야 되겠습니다.

그리고 오늘 안에 이슈 보드와 라벨들을 정리하고, 남은 시간에는 언리얼 프로젝트에서 막힌 문제를 해결하기 위해 시간을 투자하려 합니다.

가능하면 2 월 내로 UI와 씬 이동은 구현하고, 컴퓨터로 테스트 할 수 있는 방법을 고안해보겠습니다.

어제 올렸던 질문에 답변이 없어서 우선 손 끝에 새 컴포넌트를 부착하고, 이를 히트박스와 콜리전 판단을 해보았습니다.

그런데 제대로 작동하지 않았습니다.

오히려 상시 자기 자신과 콜리전이 발생하는 문제가 발생했습니다.

오늘 안에는 해결을 하지 못할 것 같아 다른 작업을 병행했습니다.

범위 안에 캐릭터가 있는지 판단하는 트리거를 제작 하였는데 작동이 정상적으로 되지 않고 있습니다.

토요일에 마저 개발을 하게 될텐데 우선 범위 트리거를 구현 하려 합니다.

이것이 구현이 되면 그 이후로는 매우매우 쉬운 작업이기에 문제가 없을 것입니다.

때문에 이 쉬운 작업들은 뒤로 미루고, 범위 트리거 개발 직후에는 타격 판정을 완성 할 것입니다.

윤곽이 잡히는데 마일스톤 기간 안에 될것 같기도 안 될것 같기도 하고 아슬아슬하네요.

마일스톤을 칼같이 잡은건가 싶습니다.

오늘 할 일은 트리거를 구현하는 일이었습니다.

그 중, 가장 먼저 피격 판정/타격 판정 개발을 시도하였습니다.

제가 알고 있던 피격/타격 판정 구현 방식은 하나였습니다.

Capsule Component를 생성하여 Collision을 적용한 뒤, 이를 Root Component에 붙이는 것.

가장 간단하지만 경험 상 공격을 하지 않더라도 Capsule Component만 닿으면 공격 판정이 들어가는 방식이었습니다.

이를 좀 더 그럴듯하게 구현하고 싶었습니다.

정말로 손이 닿아야지만 타격 판정이 일어나도록.

그러면서 몇가지 방법을 생각했습니다.

하나는 양 손에 타격용 Capsule Component를 붙인 뒤, 두 Component간의 collision을 체크하는 방법.

다른 하나는 손에 해당하는 socket을 직접 collision 체크 하는 방법.

우선은 후자가 가능한지 찾아 보다가 OnComponentBeginOverlap가 받는 변수 중 OtherBodyIndex를 발견하였습니다.

이를 이용하면 혹시 특정 소켓의 collision을 탐지할수 있지 않을까 싶어 AnswerHub에 질문을 올려놓았습니다.

만약 내일 답이 온다면 구현을 할 것이고, 불가능하는 답이 나오거나 답이 없다면 전자의 방식으로 구현을 할 것 같습니다.

앞으로 2주가 채 안남았는데 그 안에 모든 트리거가 구현이 될지 슬슬 걱정이되기 시작했습니다.

마지막으로, 테스트 중 한가지 버그를 발견했습니다.

달리던 도중 점프를 하면, 착지 후 이동속도가 매우 매우 느려지는 버그를 발견했습니다.

우선은 이슈로만 등록을 하였고, 고치는건 언제가 될지 모르겠습니다.

가능하면 마일스톤 먼저 해결을 하고 일정이 남으면 고쳐보려 합니다.

글 쓰기 앞서, 카테고리를 바꾸었습니다.

MBGC는 Mobile Board Game Cafe의 약자로, 기존에 개발하려 하던 Mighty 뿐만 아니라 기타 보드 게임들도 선택해서 플레이 할 수 있도록 하려 합니다.

이렇게 바꾼데에는 몇가지 이유가 있습니다.

첫번째로, 이런 형식으로 만드는 것이나 그냥 Mighty만 하나 만드는 것이나 큰 차이가 없었습니다.

게임 선택 기능을 넣을지 말지만 차이가 있었기에 조금 다르게 수정하였습니다.

두번째. 이 프로젝트는 어디까지나 제 포트폴리오를 위해 작성되는 프로젝트입니다.

그런 면에서 조금은 더 확장성이 있는 편이 빠른 시일 내에 취직을 못 했을 때에도, 내용적으로도 그럴듯 할 것이라 생각하여 변경하였습니다.

세번째. 저는 대학생 떄 게임 동아리에 소속되어 있었습니다.

동아리 활동을 하는 동안 후배들에게 게임 개발을 알려주고 싶었고, 졸업 직전에는 졸업 후에 강의를 열고 싶었습니다.

하지만 실력이 모자르고 아직 제 앞길도 제대로 닦지 못하여 그러지 못하고 있었습니다.

이 프로젝트를 완성을 하게 된다면 이후에는 작은 형태의 게임을 추가 할 수 있는 플랫폼으로 만들어 매년 새로 들어오는 후배들에게 게임 개발을 알려주며 새로운 게임을 도입하는 것이 더 좋다고 생각하여 변경하였습니다.

제대로 시작 전에 욕심을 부리는 것 같지만 일단은 그리 하였습니다.

오늘 해결해야 할 이슈는 프로젝트 시작 전 단계. 기획 입니다.

규칙 정리, UI 이미지 스케치, 마일스톤 정리, 구현 방식 탐색, gitignore 생성 및 프로젝트 올리기. 총 5가지의 항목이 있는데, 이 중 3가지를 처리하였습니다.

첫번째로, 규칙 정리가 이루어졌습니다.

규칙 정리는 이전에 작성한 기획서를 토대로 나무위키에 작성된 내용을 참고삼아 문서화 하였습니다.

작성하면서 제가 알던 규칙이 정석적인 규칙이 아니라는 것을 알 수 있었습니다.

또한 점수와 관련된 부분을 정리하면서 수익적인 면에 대해 고민할 수 있었습니다.

완성이 된다면 인앱 결제를 통해 게임을 구매하고, 게임 플레이를 한 이후에는 점수에 일정 비율을 반영하여 아바타 꾸미기를 추가하면 좋을 것 같다고 느꼈습니다.

두번째로, UI 이미지 스케치가 이루어졌습니다.

중간중간 필요한 경고 창 등이 빠졌을 수도 있지만 일반적인 플레이에 필요한 기본적인 UI는 모두 디자인 되었습니다.

미적인 감각이 없더라도 무난하게 표현 될 것입니다.

마지막으로 마일스톤을 지정했습니다.

마일스톤은 지정하기 시작한지 얼마 되지 않고, 아직 개발 경험이 적어 상세하게 적지는 못했습니다.

우선은 4월 전까지 멀티플레이를 포함한 플랫폼 기능을 구현 할 예정입니다.

Mighty라는 게임은 5월 중순이 되기 전에 기본적인 기능은 구현 할 예정입니다.

여기까지 구현이 된다면 당장은 출시를 할 수 있는 상황일 것입니다. 

이후로는 시간을 재분배 하여 애니메이션 추가나 새로운 게임 개발 등으로 일정이 나뉠 것 같습니다.

다음 개발 일자인 31일에는 블루투스를 이용한 P2P 서버 생성, Unity에서의 UI 개발, 씬 이동 등과 같이 게임 개발에 필요한 기능들에 대해 기술적으로 먼저 알아 볼 것입니다.

또한 gitignore도 검색하여 이를 적용하고, 프로젝트 관리를 할 예정입니다.

오늘 개발 해야 했던 부분은 점프 반복이었습니다.

하지만 이에 앞서 한가지 소름 돋는 일을 적어볼까 합니다.

저는 이전까지 프로젝트를 4.23 버전으로 개발 하다가, 이번에 4.24 버전으로 올렸습니다.

그런데 버전을 올리자 멀티플레이 기능이 마비가 되는 일이 발생 했습니다.

정확히는 다른 플레이어가 생성한 세션을 검색 할 때 남은 인원이 0으로 처리 되는 문제였습니다.

AActor의 Role 호출을 새로운 getter 함수로 바꿨을 뿐인데 이게 무슨 일인가 싶어 이것 저것 건드려 보다가 문뜩 이런 생각이 들었습니다.

"이거 생성은 잘 되는데 탐색 한 결과 출력이 이상한거 아니야?"

이를 확인하기 위해 해당 함수로 이동하자, 아뿔싸.

세션 탐색 후 이를 표기 할 때 최대 수용 인원 정보가 비어 있었습니다.

이를 제대로 고칠 수도 있었으나 언젠가는 P2P 방식에서 Dedicated Server로 변경할 예정이기에 당장 테스트가 가능하도록만 수정을 하였습니다.

그 후에 드는 생각.

"도대체 이전에는 어떻게 됐던 거지?"

버전을 내려서 테스트 하기에는 번거롭고 조금 기괴하고 소름 돋는 경험이었습니다.

다시 원래 작업으로 돌아와, 점프 반복입니다.

점프 키를 누르고 있으면 계속해서 점프가 되어야 하는데 애니메이션은 반복되는 반면, 점프 함수 자체는 1번만 출력이 되었습니다.

이전서부터 몽타주를 사용하는 방법을 알고 있었는데 다른 방법이 혹여 있나 하여 시간을 끌다 면접을 보면서 개발을 멈췄었습니다.

오늘은 몽타주를 적용해 보았습니다.

방식은 2가지가 있었습니다.

하나는 착지 몽타주가 끝날 때 점프 함수를 호출하는 것.

다른 하나는 점프 몽타주가 재생 되면 점프 함수를 호출하는 것.

이 두가지 방법을 Notify 없이 구현을 해보았습니다.

하지만 조건이 안 맞았는지 둘 다 제대로 적용이 되지 않았습니다.

개발을 멈추기 전에도 이 문제로 오랜 시간 고민을 했던터라 안되니까 갑자기 힘이 쭉 빠지더군요.

그래서 이 기능 자체를 차후 구현하는 것으로 변경하였습니다.

단순히 취미 같은것이 아니라 어느정도 기간 안에 성과가 뚜렷이 보여야 하는 상황이라 불가피하게 정한 결정입니다.

다행히도, 이 기능 구현을 뒤로 미루니 많은 부분이 해결이 되었습니다.

첫번째는 Git으로만 관리하던 프로젝트를 Github로 올릴 수 있었습니다. 

이전에도 가능은 했으나 현재 branch에서 작업이 남아 있어 이를 하지 않고 있었는데 작업을 미룬 후 드디어 Github에 올렸습니다.

덕분에 포트폴리오에는 링크로 대체를 할 수 있게 되었습니다.

두 번째는 작업 정리가 가능했습니다.

다음 일에 대해 생각을 하게 되니 자연스럽게 앞으로 해야 할 일들을 정리 하는 시간을 가지게 되었습니다.

현재는 이와 같은 형태로 이슈를 정리하고, 마일스톤을 짜 놓은 상태입니다.

이에 따라 수요일(화요일은 Mighty 개발 함)부터는 트리거 위주로 개발을 하면 될 것 같습니다.

트리거까지 구현이 완료되면 간단한 기능 영상을 촬영해서 공유해보겠습니다.

나무위키에 Mighty라 검색하면 나오는 트럼프 카드를 기반으로 한 게임입니다.

5년 전에 MT에서 선배에게 배웠던 게임인데 당시에는 너무 재밌어서 JAVA로 게임을 만들다가 실패했었습니다.

다시 꺼내게 된 이유는 이번에 면접을 여러 곳 봤는데 Unity를 요구하는 회사가 너무 많았습니다.

물론 훌륭한 프로그래머라면 크게 구애받지 않을 것이나

전 아직 미숙한지라 늘 사용하던 C++, Unreal이 아니면 자신있지가 못하네요.

그래서 욕심을 조금 내서 Unreal로 개발 중인 Treasure Hunter를 주 5일 개발에서 4일 개발로 줄이고, 

대신 Unity로 Mighty를 주 2일 개발 할 예정입니다.

여러모로 Treasure Hunter와 대비되는 프로젝트입니다.

2D 기반에 Bluetooth로 통신하는 간단한 형식에 마켓 업로드까지 목표로 하고 있습니다.

개인적으로는 4월 전까지 개발을 했으면 합니다.

이 카테고리는 물론 Mighty의 개발 노트입니다.

취준생 2년차에 들어섰습니다.

한 6개월 동안 개발했던 프로젝트인데 서류 쓰고 면접까지 보면 왠지 될것만 같아 중간중간 놓게 되었습니다.

하지만 몇번을 희망고문 당하다가 오늘 심하게 데이고 다시 개발을 시작할 준비를 하고 있습니다.

몇일 전에 학교 선배를 만났는데 꾸준히 개발 일지를 쓰라고 말씀해 주셨던게 기억났습니다.

예전에는 개발일지에 불규칙적으로 이슈가 끝나는대로 올렸습니다만

이제는 이슈 해결 여부와 관계 없이 좀 상세히 적어서 올려보려 합니다.

현재 Treasure Hunter는 기본적인 움직임에 대한 애니메이션이 구현되어 있습니다.

당장 해야 할 일은 점프 키를 눌렀을 때 연속 점프가 가능하도록 하는 것.

그리고 공격과 피격, 몇가지 트리거를 통한 상호작용 기능 구현입니다.

이 부분이 완료가 되면 이 프로젝트에서 가장 구현하고 싶었던 맵 자동 생성을 해볼 생각입니다.

그 이후에는 직업별 스킬 구현과 데디케이트 서버 쪽으로 생각 중입니다.

늘 목표를 크게 잡고 일정을 제대로 소화 못했는데 이번에는 꼭 좀 했으면 좋겠습니다.

서류 몇개 더 떨어지고 정말 간만에 개발을 하다가 막혔던 부분 중 공유하면 좋을 것 같아서 적어봅니다.

Animation에는 Layered blend per bone이라는 노드가 있습니다.

기존의 포즈에 지정한 포즈를 특정 bone을 기준으로 일부만 적용 할 수 있는 노드입니다.

움직이면서 상호작용, 점프 공격 등을 이로 구현을 하였는데 구현하면서 문제가 있었습니다.

구현해야 할 Layered pose는 2개인데 노드에 포즈를 추가하면 제대로 작동을 하지 않았습니다.

한참을 뒤적이다가 다음 페이지를 찾고 시도한 결과 문제를 해결할 수 있었습니다.

https://answers.unrealengine.com/questions/233385/view.html

이와 같이 Montage를 두 Layered blend per bone 노드 사이에 배치를 하면 무사히 두 Layered Pose가 적용이 됩니다.

한국어로 적어놓으면 누구라도 찾아서 도움이 되겠죠...

테스트용 맵을 만들면서 건물을 만드려는데 벽에 달린 창문을 만드는 방법이 고민이 되더군요.

처음에는 창문 기준으로 상하좌우 벽 나눠서 작은 벽을 쌓을까 싶었습니다.

하지만 문뜩 "큰 벽에 구멍 뚫는게 엔진에서 지원이 안될까?"라는 생각이 들더군요.

그래서 커뮤니티에 질문을 올렸는데 답이 바로 달리더군요.

"지오메트리 쓰면 구멍 뚫을 수 있습니다."

찾아보니까 지오메트리에서 addictive와 subtractive가 있는데, 전자는 범위 안을 채워주고, 후자는 비워주더군요.

그래서 큰 벽을 addictive로 만들고, 창문 크기 만큼 subtractive 지오메트리를 겹쳐놓으면 창문이 완성이 됩니다.

그리고 그 부분은 투명한게 아니라 아예 통과도 됩니다.

뭐라도 만드시는 분들 레벨 디자인 한번쯤 거치실텐데 도움이 되셨으면 좋겠습니다.

한 2주 동안 아무것도 못했는데 그 이유가 샷건 탄환을 구현하는데 투자했기 때문이다.

7월 중순에 시작했던 탄환 구현을 오늘에서야 완성을 하며, 방식을 공유하고자 한다.

샷건 탄환 구현에 있어서 가장 중요한 부분은 3가지이다.

1. 탄환이 규칙적인 모양으로 발사되지 않도록 한다.

2. 탄환이 방사형으로 퍼지면서 발사되도록 한다.

3. 엉뚱한 방향으로 탄환이 튀지 않도록 한다.

3번부터 설명을 하자면, 우선 탄환의 Collision을 수정하여 탄환들끼릭은 서로 부딛치지 않고 무시하고 통과되도록 하였다.

게임 내 탄환을 도탄하는 기능도 없고, 샷건은 탄환 수가 많아 크게 이질감을 느끼지 않는다.

그리고 탄환이 출발하는 Location을 수정해주었다. 

구체적으로, 내가 구현한 샷건은 20발의 탄환이 발사가 된다.

이 20발의 탄환을 5 * 4 형태로 발사가 되도록 하였다. 

탄환들끼리의 거리가 가까우면 이상한 방향으로 발사되기 때문에, 각 탄환의 index 별 위치를 조절해가며 퍼지지 않는 위치를 지정하였다.

여기까지 한다면 직사각형 모양으로 균등하게 발사 되는 샷건이 된다. 

그렇다면 어떻게 1번 조건을 만족 시키는가?

탄환의 위치에 랜덤 변수를 추가하였다.

각 탄환은 해당 index를 5로 나누어 그 몫을 column index로, 나머지를 row index로 가진다.

그리고 이 column index와 row index의 각각의 중심값으로부터의 차이를 구한 뒤 일정 값과 플레이어 화면 중심에서의 우측 벡터, 혹은 위 벡터를 곱하여 탄환의 위치를 지정한다.

이때, 이 일정 값을 특정 범위 안에서의 랜덤한 값을 주어 좀 더 혼잡한 위치에서부터 탄환이 출발하도록 하였다.

마지막으로, 각 탄환이 퍼져야 할 벡터들을 더한 뒤 Find Look at Rotation으로 해당 벡터로 변환해주는 Rotation을 구해서 Transform에 적용하면 샷건 탄환의 발사가 완성이 된다.

글로만 보면 이해가 잘 안가니 블루프린트 스크린샷을 첨부하겠다.