오늘은 AttachPuzzle에서 비정상적으로 작동하는 TwoBlockTrap 문제를 해결하고,
Trap에서 아직 구현하지 않았던 기능들을 구현 한 뒤, 코드를 정리하였습니다.

 

우습게도, AttachPuzzle이 비정상적으로 작동하는 이유는
생성자 노드에서 노드 연결이 중간에 끊겨 있었기 때문이었습니다.

이를 연결하자 거짓말처럼 정상 작동하였습니다.

 

이를 해결하고 Push한 뒤, Trap의 Wall들을 다시 내리는 기능을 THWallBase에 맞게 구현하였습니다.

비록 아직 동작을 확인하지는 못했으나, Trap을 개선하면서 동시에 테스트를 해볼 수 있기에 일단 마무리 했습니다.

 

구현 방법은 게임 시작 시 Wall의 World Location을 저장하고,
벽이 멈출 때마다 이 World Location과 거리가 일정 이상 멀어지면
Control Point를 음수로 reverse 하여 원래 거쳐왔던 경로를 되돌아가도록 하였습니다.

 

마지막으로 안쓰는 코드를 지우고, 최종적으로 Push를 함으로서
MovementComponent 적용 부분을 최종적으로 마무리하였습니다.

 

당장 내일부터 다시 개발을 시작하는데, 우선 Code Arrange부터 하려 합니다.

이후 Ledge부터 시작하여 Climb 기능을 구현해나갈 계획입니다.

 

이 부분이 마무리가 되면 구현 방식을 수정하거나 새로 구현해야 하는 Trap들을 구현하고,
Trap의 동작을 Multiplay에 맞게 변경 할 계획입니다.

 

뒤이어 Character의 피격 애니매이션 적용이나 얼굴 부분 회전 등의 기능을 구현 할 예정입니다.

'개발일지 > Treasure Hunter' 카테고리의 다른 글

20.50.04 개발일지  (0) 2020.05.04
20.04.30 개발일지  (0) 2020.04.30
20.04.27 개발일지  (0) 2020.04.27
20.04.23 개발일지  (0) 2020.04.23
20.04.22 개발일지  (0) 2020.04.22

개발일지를 하나 적고 코드를 다시 보다가 간과한 사실이 하나 있습니다.

 

read 할 때는 중간에 다른 변수를 거쳐 가도 된다는 점입니다. 

 

그냥 모든 Host와 Client가 Write는 자유롭게 하되,
Read에서 한번 걸러주면 될 것 같습니다.

 

예를 들어 {bool, List<PlayerInfo>} 구조체를 만들어서
true면 Player 추가로 기존의 PlayerInfoList보다 새로 받아온 PlayerInfoList의 길이가 더 길 경우에만 read를,
fasle면 Player가 제거로 기존의 PlayerInfoList보다 새로 받아온 PlayerInfoList의 길이가 더 짧을 경우에만 read를.

 

아니면 이 둘을 별도의 변수로 두어도 될 것 같습니다.

 

계획을 바꿔, 금요일에는 이 방식을 구현해보고자 합니다.

'폐기된 게시판 > MBGC' 카테고리의 다른 글

20.05.01 개발일지 - 일시정지  (0) 2020.05.01
20.04.28 개발일지  (0) 2020.04.28
20.04.24 개발일지  (0) 2020.04.24
20.04.21 개발일지  (0) 2020.04.21
20.04.17 개발일지  (0) 2020.04.17

요 몇일 컨디션이 안좋은거 버티면서 운동 하던게 한달만에 한꺼번에 반동이 와버렸습니다.

 

내리 2시간을 유니티 업데이트 후에 2시간 정도 뻗어버렸습니다..

 

그래서 충분히 개발까지 할 수 있을법한 시간에 대략적인 계획만 잡게 되었습니다.

 

문서를 읽어보면서 나온 내용을 종합해보자면

1. OnPhotonSerializeView에서 Stream이 Writing 중이면 통신을 보내고, Reading 중이면 통신을 받는다.

2. OnPhotonSerializeView는 Update와 같이 수시로 호출이 된다.

3. OnPhotonSerializeView는 PUN2 내부 스크립트에서 호출되는 함수다. 의도적으로 호출할 수 없다.

이 세가지입니다.

 

제가 구현해야 하는 기능은 "Player들의 PlayerInfoList의 동기화" 입니다.

여기서 주의해야 할 점은

1. 새로운 Player가 접속했을 경우, 기존에 Data를 가지고 있는 Player의 PlayerInfoList를 read 해야지
본인이 가지고 있는 것을 write 해서 기존의 Player들의 PlayerInfoList가 날라가면 안된다.

2. 반대로 Player가 방을 나갈 때는 해당 Player의 PlayerInfoList가 write 되어야 한다.

이 정도 될 것 같습니다.

 

지금 생각하는 구현 방식은 대략 두가지 정도입니다.

1. Player가 각자 관리하는 트리거를 둔다.
Host-Client 구분은 쉽게 될 것 같으니, 이를 통해 Client는 평소에는 write 하지 않고 read만 하도록 한다.
Host는 항상 write와 read를 열어 둔다.

Client의 주도로 List가 바뀌는 경우(ex. ready, logout)에는 해당 이벤트가 발생 시 호출하는 함수에서 트리거를 열어둔다.

열린 트리거는 write 하는 부분 마지막에 자동으로 잠궈두도록 한다.

 

2. RPC로 PlayerList를 관리한다.

OnJoinRoom 이벤트에서 RPC 함수를 통해 자신의 PlayerInfo를 전달한다.

Update 함수에서 전달 받은 PlayerInfo가 존재하는 경우, 이를 초기화하고 PlayerInfoList에 PlayerInfo를 적용한다.

이 중 Host는 다시 RPC를 함수를 통해 최신 버전의 PlayerInfo를 전달한다.

 

가능하면 금요일에 이 방법들을 구현해보고 싶으나, 아직 확신이 없습니다.

때문에 몇일 더 구현 방법을 고려해보고 그럴듯하다는 확신이 생기면 개발을 하고자 합니다.

'폐기된 게시판 > MBGC' 카테고리의 다른 글

20.05.01 개발일지 - 일시정지  (0) 2020.05.01
20.04.28 개발일지 2  (0) 2020.04.28
20.04.24 개발일지  (0) 2020.04.24
20.04.21 개발일지  (0) 2020.04.21
20.04.17 개발일지  (0) 2020.04.17

+ Recent posts