회고 - 11.06

한달 감상평 : 어떻게 지나갔는 지 모르겠는 한달이었다. 부산 지스타를 위해서 '아케이드 파티' 0.9.0 패치를 준비하고 있는데, 생각보다 작업량이 많아서 바쁘게 한달을 보냈다. 골머리 아픈 문제들을 해결하면서 경험과 실력이 느는게 느껴지고 있다. 하지만, 얼른 이 작업을 마무리하고, 다른 일을 하고 싶은 마음이 들기도 한다. 항상 회고마다 언급하지만, 다른 개발자분들이 짠 코드를 보면서 감탄도 하고, 기억해 뒀다가 나중에 써먹어야지 하는 생각도 든다. 그래서 프로그래밍이 재밌는 것 같다. 하나의 작품을 써내려 가며 본인 자신의 기예를 선보이는 장소라는 생각도 어렴풋이 든다.

---

Programming

Work

• 이모티콘 기능
  • 요약 : 플레이어들끼리 이모티콘으로 의사소통을 할 수 있는 소통 시스템을 도입한다. 새롭게 업데이트 되는 로비는 플레이어들이 자유롭게 돌아다닐 수 있는 오락실인데, 여기서 이모티콘(말풍선)과 애니메이션으로 본인의사를 표현한다. 실제 게임에서는 플레이어 카드 상단에 뜨는 말풍선과 캐릭터 이미지에서 애니메이션을 출력해주므로, 게임 플레이중에서도 소통할 수 있다.
  • 이모트 동기화를 하면서 새로운 네트워크 동기화 방식을 알수 있었는 데, network object를 하나 따로 두고 그 object를 매개로 다른 monobehaviour에서 자유롭게 통신을 하는 식이다. 이전까지는 동기화를 해주기 위해서 networkbehaviour를 사용하고 거기 안에서 networkvariable과 rpc를 사용하는 방식만 고집해왔는데, 따로 매개가 있으니 동기화 메소드 관리가 용이 해보였고, 더 가벼워 보였다. 이 방식을 사용하면서 느낀 점은 동기화 메소드가 많아짐에 따라 이 매개체가 가지고 있는 메소드가 더 많아지거나, 클래스가 더 많아져서 개발 와중에 혼동이 올수도 있다. 따로 정리를 하거나, 스크립터블 오브젝트 이벤트 시스템 매니저를 만들게 되면, 도움이 되지 않을까 싶다. (Thanks, one..)
  • 이모트 기능은 플레이어의 상태라기 보단 이벤트에 가까우므로 rpc와 delegate callback으로 처리하는 게 맞다고 생각하여 state로 동작했던 방식을 리팩토링 했다. 네트워크 프로그래밍을 하면서 매번 느끼지만, 내 머릿속에서 그려지는 동기화가 되어지는 그림이 잘 안되는 경우가 있다. 아직 퍼즐 수가 모잘라서 그런지 짜맞추는 머리가 부족해서 그런지 모르겠지만, 아직 숙달되기엔 멀었다.
  • 이모티콘에 따라, 애니메이션도 같이 넣어주게 되었는 데, 50개의 이모티콘중 몇개 만 애니메이션을 가지게 될 줄 알았던 애니메이션이 50개 전체가 애니메이션이 들어갔다. 이 50개를 하나하나 animation state로 관리 했더니, 그림이 누에고치처럼 되어버렸다. 이를 해결하기 위해 blend tree를 써봤는데, 깔끔은 해졌으나, 블렌딩에 문제가 있었다. 여러개의 복잡한 애니메이션들이 연결되어 있을 땐, 훌륭한 솔루션이 되지만, 이모티콘 처럼 1대1 즉 하나의 인풋에 하나의 아웃풋이 나오고 애니메이션이 빠져나오는 구조에서는 좋은 해결책이 되진 못했다. 10의 값을 주고 0으로 바로 초기화 해줄 때, 바로 트리 안에 있는 최솟값이 한번 재생하고 넘어간다...그래서 초기화 애니메이션을 하나더 넣어줬더니 이모티콘끼리의 블렌딩이 안되었다.. 그래서 최종 해결책으로 최고참 개발께서 animation override controller로 해결해주셨다... (현재 재생되고 있는 클립을 하나의 state에서 바꿔주는 controller이다.) 이것만으론 블렌딩 이슈가 해결이 되지 않아, 더블 버퍼라는 방식으로 블렌딩 처리를 해주셨다. 두개의 state를 두고 최소 2개의 이모티콘끼리는 상호작용하면서 블렌딩 처리해주는 방식이다.
• 서버(방) 관리 기능
  • 요약 : 현재 생성되어 있는 로비 및 로비 안에 있는 플레이어들의 정보를 설정 창에서 확인 할 수 있게 한다. 플레이어의 ping과 로비의 ping을 각각 확인 할 수가 있고, 플레이어 퇴장, 로비의 공개상태 여부, 로비 비밀번호 등의 기능이 들어간다. 스팀 플랫폼일 때와 LAN일 때 둘다 구현해야한다.
  • ipadress로 유니티에서 소켓 통신을 할 수 있는 오픈소스가 있다. 여기에 나온 discoveryinfo 클래스에서 udpclient 에서 데이터 보낼 때,내가 보내고자 하는 데이터를 serialize해서 보내줬다. 이런 통신을 하게 될 줄 몰랐는데, 내가 아는 것만 하기를 바라는 건 욕심이고, 하다보니 재밌었다.
  • 오픈소스 : https://github.com/in0finite/NetworkDiscoveryUnity
    
    
  • steam에서는 방식이 달라서 위의 클래스는 사용하지 않고, steam api를 사용해서 lobby 정보를 구현했다. 
• 플레이어 - object 상호작용 
  • 요약 : 오락실 안에 물건들과 상호 작용을 한다. 이미 기능은 다 구현이 되어있고, 상호작용하는 컨텐츠를 기능에 붙이고, object에 따라 커스터마이징 한다. 다른 게임에서의 플레이어와 npc의 상호작용과 똑같다고 보면 된다.
  • 실제로 npc와 플레이어의 상호작용과 똑같고 이러한 상호작용이 요한 상황에서 요긴하게 쓸수 있는 구조를 배울 수 있었다. 이벤트와 이벤트 리스너와의 관계와 비슷하다고 느껴졌는 데, 특정 조건을 만족하는 이벤트 리스너를 불러오는 것과 비슷한 느낌이다.(지금 상황에서는 거리)
  • ui를 input action으로 컨트롤 할때, selectable이라는 클래스를 상속 받고 있는 클래스들끼리 유니티 안에서 자동으로 움직일 수가 있다. 버튼을 보면 navigation이라는 설정이 있는 데, 이걸로 어디로 움직일지 설정 할수가 있다. Eventsystem을 베이스로 동작을 하는 데, 안에 구조를 확인 해보면 유니티는 확실히 똑똑한 사람들이 모여서 만든 게 확 느껴진다. 다만, Eventsystem에서는 현재 선택된 오브젝트를 static으로 관리 하기 때문에, 하나의 프로그램 안에서는 단 하나의 selected object만 존재 할수 있다는 단점이 있다. 그래서 로컬 멀티 플레이를 지원하는 게임이기 때문에, 기존에 만들어져 있는 플레이어 마다의 input controller로 버튼과 비슷한 element 클래스를 만들어서 컨트롤 해줬다.
  • 이 menuinput action의 멀티 컨트롤과, 레이어 별로 input의 상호작용을 막아주도록 새로운 input 구조를 최고참 개발자 분이 구조를 짠다고 하셨다. 윈도우의 input 시스템 처럼 stack형식으로 쌓아 준다고 했는데, 워ㅜㄴ리는 이해가 가지만, 어떻게 구현할지는 감이 잘 안와서, 만드신 구조를 천천히 탐닉해 볼 예정이다.

Personal

•  블로그 정리
  • NetworkVariable vs RPC
  • AOS vs SOA

 

 

 Life

캠핑

• 가리왕산 캠핑에 갔다. 생긴지 얼마 안된 곳이라 하던데, 그 넓은 부지에 우리 한팀 밖에 없었다. 가는 길, 머물던 장소, 돌아가는 길 까지 모두 완벽했다. 장연경관은 사람의 손길이 많이 들어가지 않아, 인위적인 느낌이 적었고, 무엇보다 경치가 비교적 가까이 있어서 등산에서 느낄수 있는 자연의 웅장함은 다른 궤를 가지고 있었다. 한가지, 아쉬웠던 점은 텐트가 2인용 텐트에서, 4인용 원통형 텐트로 바뀌어서, 처음 보는 형태의 텐트를 치느라 고생을 했던 점이다. 그래도 한번 쳐봤으니 다음엔 손쉽게 칠 수 있으니, 좋은 경험 했다. 이런 내 개인의 실수로 인한 감점 요소를 제외하곤 모든게 완벽했다.