앙박의 기술서

Fusion2를 사용한 프로젝트에 상점에 진입하는 기능이 필요하다. 흠... 오! 상점에서 물건 구매했을 때만 네트워크로 뿌려주면 되겠구나! 그래서 상점 진입하고 나가는 것 자체는 Local에서 작동하게끔 설계가 되었다. 때문에 OnTriggerEnter와 OnTriggerExit 함수를 사용했고, 여기서 문제가 발생한다. OnTriggerEnter 메소드가 계~속해서 호출되는 것 아니겠는가? 분명히, 100%, 퍼펙틀리 OnTriggerEnter다. OnTriggerStay가 아니라... 많은 경우의 수를 하나하나 테스트하기 시작. 콜라이더가 잘못 되었나? 어... 콜라이더가 아예 없네? 그럼 왜...OnTriggerEnter가 작동하지? 아하!... 캐릭터 컨트롤러에 내장 콜라이더가 있다고?..

Fusion2에서 네트워크 객체란 각 틱마다 시뮬레이션 되며 피어들에게 동기화 될 수 있는 GameObjct를 가리킨다.  멀티 플레이는 동일한 실제 세계 시간에 정확히 동일한 연산이 이뤄질 수 없다. RTT가 0이 될 수 없기 때문이다. 대신 시뮬레이션 속 동일한 틱에서 동일한 연산이 이뤄지도록 하는 것이 최선이다. 물론 이것도 RTT 때문에 완벽히 수행될 수는 없다. 하지만 로컬 시뮬레이션을 돌려 서버의 다음 시뮬레이션을 예측하는 방법으로 눈속임 할 수는 있다. 원래는 시뮬레이션을 서버에서만 돌리고 클라이언트들에게 통보하는 방식이라 클라이언트의 시뮬레이션에는 딜레이가 있을 수 밖에 없다. 하지만, 클라이언트가 독자적인 시뮬레이션을 돌린 후에 서버로부터 받은 정보를 덮어 씌우는 방식이라면? 이 방법이 ..

오늘은 로비를 구현해봤다.  아 쉽지 않다. 아직 고쳐야 할 부분이 많은데 엄두가 안 난다. 잘 이해가 안 가는 개념도 여럿 있어서 지속적인 리팩토링이 필요하다.   게임이 실행되면 우선 NetworkRunner를 생성한 다음 Lobby에 접속한다.   호스트 모드로 세션을 생성하는 메소드를 만든 후 버튼에 연결해준다.   생성된 세션들을 업데이트 해준다. 이 과정을 거치면 모든 플레이어의 화면에 세션 리스트 UI와 정보가 뜨게 된다.  생성된 세션들에 클라이언트 모드로 참여할 수 있다.    세션에 참여한 플레이어들의 정보를 담을 객체를 생성해준다. 여기에는 플레이어 닉네임과 직업에 대한 정보가 담겨 있다.  호스트가 개임 시작 버튼을 누르면 세션에 참여한 모든 플레이어가 동시에 게임 플레이 씬으로 넘..

네트워크에는 ping이라고 불리는 개념이 있는데, 특정 장치(예: 서버나 다른 컴퓨터)에 데이터 패킷을 보내고, 응답이 돌아올 때까지의 왕복 시간(RTT, Round Trip Time)을 측정하는 녀석이다. 보통 ms(밀리초) 단위로 표시되고 한국에서는 10 ~ 30ms 정도의 RTT를 가진다. 이 때문에 FPS 게임에서 마우스를 클릭해 총이 발사되기까지 10~30ms 정도의 지연 시간이 발생한다(동작의 처리는 서버에서 하기 때문에, 클라이언트는 동작 요청을 보내고 서버로부터 응답을 받아야 한다.). 근데 멀티에는 다양한 플레이어가 있고 각자 RTT가 다르다. 총을 발사했다는 정보가 각 플레이어게 도달하는 시간이 각자 다르다는 건데, 그러면 누군가에겐 총알이 맞은 것처럼 보이지만 누군가는 피한 것처럼 보..

게임을 잘 만들려면 어떡해야 할까? 내 생각에는 세상의 최대한 많은 것들을 아는 것이 정답인 것 같다. 게임을 게임답게 만드는 온갖 낭만을 첨가하기 위해 인문학적 소양을 기르거나, 시스템을 빠른 속도로 기깔나게 개발하기 위한 개발론을 습득하거나.   이미 널리 알려진 기능들을 모방하는 단계를 넘어, 본인만의 복잡한 기능을 구현할 필요가 생기기 시작하면 코딩 외에 지식들이 절실해진다. 그 예로 독자적인 시뮬레이터를 구현하기 위해 물리 법칙을 구현하며 애를 먹었던 일이 있는데, '버렛 적분'이라는 기가 막힌 수식으로 대부분의 문제를(완벽하진 않지만) 해결해 버린 기적을 경험한 적 있다.  개발자는 많을 것을 알아야 한다. 그게 내 생각이고, 이를 위해 기초부터 다져보려고 한다. 그런 의미로 본 포스팅에서는 ..

디펜스 게임을 만들던 중 길찾기 알고리즘을 만들 필요가 생겼다.   먼저 필요한 것과 주어진 것을 되짚어 보았고, 나는 맵을 Grid단위로 쪼개서 관리하고 있었다.  그러곤 Gird 길찾기 알고리즘을 구글링 해보니까 A* 알고리즘이 가장 무난하다는 걸 알게되었고, 이건 대학교 때 이미 몇 번 다뤄본 알고리즘이다. (솔직히 기억은 안 난다)  그래서 A* 알고리즘을 선택했다.   정말 별 거 없는 이유로 선택했다는 생각이 잠깐 든다. 이론 내 맵은 Grid이고 A* 알고리즘이 적합하지만, A* 알고리즘 자체는 grid를 넘어 다양한 맵에 적용할 수 있다. 맵은 path, graph의 형태를 띄면 되고, Path/Graph Search Algorithm 키워드로 검색을 하면 A*는 단골로 등장한다.   그럼..