치킨 날다

오늘은 Json으로 만든 임시 데이터 파일을 게임 시작 할 때 읽어오고, 게임 종료할 때 저장하는 기능을 구현하였습니다.

저번 개발 일지에서 두가지를 적었습니다.

하나는 아바타 정보를 index로 가지고 있는 것. 다른 하나는 DataManager가 함수만 제공하도록 한다는 것.

이 중 한가지만 적용이 되었습니다.

아바타 정보를 index로 가지고 있는 것은 여러모로 편리했습니다.

코드상으로도 좀 더 직관적이라 적절한 조치였다고 생각합니다.

하지만 이 방식대로 하면 DataManager가 데이터를 가지고 있지 않으면 값이 바뀔 때마다 UI를 들락날락 해야 했습니다.

그리고 처음 게임이 켜졌을 때 초기화 순서를 확실히 몰라 NullReferenceException이 자주 발생했습니다.

그래서 DataManager가 모든 데이터를 가지고 있도록 하였습니다.

다만 UI에서 값이 바뀔 때의 Index는 각 컴포넌트에 부착된 스크립트들이 가지고 있다가, 게임을 종료 할 때 MainMenuController가 모아서 DataManager의 SaveData 함수를 호출하면서 값을 저장합니다.

이 외에 한가지 작업이 이루어졌습니다.

바로 일괄적으로 적용되던 UpdateList를 하위 클래스로 분할하여 적용하였습니다.

그 이유는 Json 파일을 읽어오는 과정에서 필요한 타입만 다르지 작업 자체는 반복적이라 generic으로 함수를 지정했기 때문입니다.

그 결과 UpdateList에서 자신이 붙어있는 컴포넌트에 해당하는 Data를 DataManager에서 가져오는 방법을 찾을 수 없었습니다.

그래서 컴포넌트 별로 별도의 UpdateList의 하위 클래스를 붙이고, 이벤트 함수를 override 하여 그 내부에서 데이터를 따로 받아오도록 하였습니다.

마지막으로 테스트를 위한 멀티플레이 개발은 무료 에셋인 Photon Unity Networking 2(PUN2)를 사용하기로 결정하였습니다.

이를 이용해 최대한 함수를 wrapping하여 인터넷 상으로 P2P 방식을 통해 멀티플레이를 하도록 할 예정입니다.

이후에는 UI 개선과 이미지와 슬라이더 기능 추가, 견본 이미지를 통한 아바타 생성을 할 예정입니다.

여기까지 마무리가 된다면 그 이후에는 한숨 돌리며 게임 개발을 할 수 있을 것 같습니다.

개인적으로 게임 장르 별 공용 함수를 최대한 제작하고, 이를 이용할 계획입니다.

오늘은 Json 파일로의 저장 및 불러오기 기능을 개발하였습니다.

바닥 짚고 헤엄 치는 것 마냥 조금씩 개발을 하다가 디버그 하는 도중에 피곤하여 마무리 하였습니다.

몇가지 수정사항이 있다면, 유저가 이전에 아바타를 어떤 모양으로 지정 했었는지 저장 하는데, 이 파일이 각 컴포넌트의 이름을 가지고 있습니다.

이를 각 컴포넌트의 index를 가지고 있도록 하고자 합니다.

또한 기능 자체를 집중하다 보니까 UpdateList가 가지고 있어야 할 것을 DataManager가 가지고 있는 등 몇 가지 충돌이 일어났습니다.

DataManager는 순수하게 함수만 제공을 하고, 각 UI 스크립트가 데이터를 소지 하도록 수정하고자 합니다.

한 일주일 전까지만 해도 "이거 계속 해야 되나 너무 힘든데" 싶었는데

역시 사람이 간사한게 언리얼 막히고 유니티 조금 풀리니까 금세 재미가 붙어버렸습니다.

오늘은 MainMenu에 필요한 스크립트들을 모두 선언하고, 작동이 되는 것을 확인했습니다.

남은 것은 텍스트 파일을 읽어서 리스트를 받아오고, 이미지를 붙여 아바타 이미지를 완성하는 것입니다.

텍스트 파일을 읽는 것은 나중에는 DB로 대체가 되겠지만 우선은 텍스트 파일에 XML이나 JSON으로 포맷을 잡으려 합니다.

필요한 데이터는 간단하게 파일 명, 파일 경로이기에 큰 문제는 없을 것 같습니다.

이미지는 대략 형태만 잡아 놓고 나중에 완성이 다 되어갈때 쯤 적용을 해볼 예정입니다.

캐릭터 형태는 얼굴 모양으로 비어 있는 이미지를 두고, 배경색을 바꾸면서 피부색을 변경 할 예정입니다.

그리고 배경이 투명한 머리, 눈, 코, 입 이미지를 overlay 하면서 아바타를 생성하고자 합니다.

금요일에는 테스트 파일을 읽고 가져오는 기능을 적용하고자 합니다.

그리고 시간이 남으면 Unity에서 P2P 방식으로 통신하는 방식을 찾아보고자 합니다.

오늘도 상태가 안좋아서 좀 졸았는데 다행히 뭔가 진행이 되면서 조금 풀린다는 느낌을 받았습니다.

오늘은 간단하게 버튼에 Panel 변경 이벤트를 붙이고, 플랫폼상에서 필요로 하는 UI 대부분을 생성하였습니다.

이전에 Panel 변경이 잘 되지 않았는데, 이는 변경 방식의 문제가 아니라 Panel을 찾는 탐색 방식이 잘못되어서였습니다.

계층 구조를 가지고 있으면 부모 개체에서 탐색을 해야 되더군요.

Panel 변경을 하고, 필요한 UI를 생성 한 뒤에는 스크립트 구조에 대해 조금 고민을 했습니다.

FindSession을 제외하고, MainMenu와 Session 부분에서 공통적으로 요구되는 기능이 있었습니다.

하나는 파일을 읽는 것. 다른 하나는 버튼에 따라 이벤트가 여러 개 발생하는 것입니다.

공통적으로 이 둘은 Script가 다른 Script의 함수를 가져다 쓰거나, 다른 Script의 변수 값을 변경 할 수 있어야 합니다.

때문에 이 부분을 다음 주 화요일에 찾아볼 계획입니다.

또한 현재의 화면 전환 방식도 고민이 되는 점입니다.

현재는 Panel을 미리 생성해두고, 필요로 하는 Panel만 Active 하는 방식을 채택하고 있습니다.

때문에 멀티플레이가 될 시, 이 또한 최소 다른 Script의 함수를 호출할 수 있어야 합니다.

그렇지 않다면 Editor상에서 만든 UI를 Inactive 해놓은 뒤, 버튼 이벤트 발생 때 한번 생성을 하는 방식을 채택해야 합니다.

최악의 경우, Script에서 UI 생성을 모두 완수해야 할 것입니다.

때문에 이러한 Editor에서 생성한 UI를 Script에서 runtime 상에 생성하는 방법도 찾아보려 합니다.

이 두 문제가 해결이 되고 구현이 완료가 되면, 그 뒤는 블루투스를 이용한 멀티플레이 기능으로 넘어갑니다.

우선 라이브러리를 결정하고, 그에 따라 테스트 방식에 차이가 있을 것 같습니다.

오늘도 오버워치 리그 여파로 비실비실 거리다가 시간을 날렸습니다.

확실히 제가 유니티에 많이 미흡하긴 한가봅니다.

3년?  4년 전에 언리얼 엔진을 처음 사용 했을 때 겪었던 느낌을 그대로 느끼고 있습니다.

언리얼 엔진은 막히더라도 금방 해결법을 찾는데 유니티는 한번 막히면 그날 내리 막히니 비교되서 더 힘듭니다.

누군가 유니티 문서 잘 되어 있다고 그랬는데... 문서도 왠지 언리얼이 더 잘 나오는 것 같고 으음...

원래는 오늘 UI를 모두 만든 뒤 연결을 해보려 했는데 연결 부분을 먼저 만지다 보니까 하나 정도만 만들었습니다.

유니티 UI는 canvas 밑에 panel을 두고 그 밑에 botton이나 text를 두는 방식입니다.

간단하게는 UI별로 Scene을 따로 두는 것이지만 성능 저하가 심하다고 알고 있습니다.

그래서 하나의 Scene에서 여러 UI를 열었다 닫았다 하는 방법을 찾았습니다.

여러 시도가 있었고, 지금 정한 방식은 panel을 여러개 생성한 뒤 하나만 active 해놓고, 나머지는 버튼 이벤트에 따라 active, inactive를 해주는 방식입니다.

이 방식으로 정하니 다음 단계가 보였습니다.

첫째. 버튼 별 이벤트들을 어떤 방식으로 나눌 것인가. 하나의 파일에 둘 것인가 각자의 파일을 만들 것인가.

둘째. panel을 게임 시작 할 때 다 같이 생성해서 바로 inactive 하는 방법을 찾아야 한다.

이 두가지를 금요일에 좀 찾아봐서 해결하면 될 것 같습니다.

아마 두번째 문제를 해결 먼저 하고 첫번째를 해결할 것 같습니다. 아무래도 이벤트는 정리가 안되어서...

상당히 더뎌서 집중이 떨어지지만 여기까지 해 놓으면 그 뒤로는 좀 더 속도가 날 것이라 믿습니다.

오늘은 메인 UI에서 버튼 이벤트를 붙여보았습니다.

다행히도 어제 주문한 책이 모두 배달 와서 이것 저것 보면서 시도해볼 수 있었습니다.

또한 책과 검색을 통해 대략적인 Unity의 개발 방식을 이해할 수 있었습니다.

그래도 아직은 언리얼 개발 때만큼 집중이 되지는 않습니다.

좀 더 집중있게 하여 하루에 더 많은 일을 진행 할 수 있으면 합니다.

다음 주에 할 일은 두가지 정도로 생각하고 있습니다.

하나는 메인 UI에서 Next, Preview 버튼을 누를 시 텍스트 뿐만 아니라 실제 아바타에 이미지를 추가하는 기능을.

다른 하나는 멀티플레이 기능을 제외하고 세션 생성 또는 탐색 시 새로운 UI를 띄우는 기능을 구현하고자 합니다.

이와 동시에 시간이 남으면 블루투스로 구현 하고자 하는 멀티플레이 방식의 구현 방식과 테스트 방식을 고민해보려 합니다.

오늘은 UI 이벤트에 필요한 기능들을 정리하였습니다.

한 3시? 쯤에 개발을 멈춘것 같습니다.

개발 일지 적은지 열흘 정도 된것 같은데 여러모로 집중이 떨어지네요.

일단 익숙치 않으니까 손에 잘 잡히지가 않습니다.

그러다보니 모르는 부분이 생기더라도 흥미가 계속 떨어지는 느낌입니다.

주말에 입문서 몇 개를 구매 하였는데 품절되어 배달이 꽤 늦을 것 같습니다.

금요일 전에 온다면 책을 읽으면서 조금이라도 개발을 해보고, 그보다 늦는다면 금요일도 개발을 잘 못할 것 같습니다.

유니티... 익숙치 않아서 그런 것일수도 있지만 처음 스크립트 언어 썼을 때와 같은 느낌입니다.

막막하네요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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