본문 바로가기

분류 전체보기241

[Portfolio Log] WebRTC 기반 포폴 기록 2 타일맵 충돌체, z-index 수정, 카메라 추가, 장면 전환 작업을 추가했다. 워낙 Phaser 자체가 쉽게 잘 되어 있어서 개발하는데 크게 막히는 부분은 없는 듯 하다. 어떤 기능이 필요한데 싶으면 이미 함수로 지원을 해주고 있어서 가져다가 쓰면 된다. 1~3번까지 1일이면 된다고 생각했는데, 실제로는 matter plugin에서 오브젝트를 생성하여 충돌 처리를 하는 부분이나 장면 전환 부분에서 생각보다 시간을 많이 썼다. 맵 찍는 것도 꽤 걸렸고... 1. 타일맵 충돌체 개선 2. 타일맵 z-index 값 조정 3. 집 내부에 들어갔을 때 사용할 Scene 구현(문 오브젝트랑 상호작용) 다음은 멀티플레이 관련 기능들을 작업할 예정이다. 채팅 UI, 캐릭터 선택 UI, 소켓 처리 등을 작업하지 않을까.. 2023. 10. 3.
[Phaser] Pixel bleeding 이슈 타일맵 기반으로 개발을 하다보면 타일에 없는 격자가 생기는 이슈가 발생한다. Pixel bleeding 현상이라고 하는데 타일맵의 크기를 늘려서 돌출 시키는 형태로 변경하면 사라진다. https://github.com/sporadic-labs/tile-extruder 이쪽에서 tile-extruder를 설치하고 기존에 처리하던 타일맵을 돌려준다. 그러면 각 타일의 크기가 2px씩 증가되어 타일맵 이미지가 형성이 되는데, 기존에 처리하던 Tiled 프로젝트가 있다면 이미지를 수정해주어야 한다. 나의 경우 32 x 32 타일맵을 사용하고 있었고, 돌출한 이후에는 34 x 34 형태가 되었다. 상단의 tileset 탭에서 속성을 누르고 image를 다시 잡아준다. (34 x 34로 추가한다.) => 타일셋에서.. 2023. 10. 2.
[Phaser] Animation, TileMap Phaser Make your first game(https://phaser.io/tutorials/making-your-first-phaser-3-game/part1) Tutorials, Samples - Official Sample과 참고자료들 처음 게임 만드는 예제는 정말 강추한다. Phaser 애니메이션 처리 방식 Phaser의 애니메이션은 이미지를 넣고 소스상에서 애니메이션을 만드는 방식도 가능하고, json으로 아틀라스 이미지의 offset 정보와 animation 정보(FPS, 참조 image 등)를 처리하는 형태도 가능하다. Atlas 애니메이션 편집 툴(Frame 정보 json으로 뽑기, 애니메이션 정보 json으로 뽑기) https://gammafp.com/tool/atlas-packe.. 2023. 9. 28.
[Portfolio Log] WebRTC 기반 포폴 기록 1 최근에 미디어수프를 이용하여 1:N 화상통화까지 구현했고 디테일한 부분(장치 설정, 하단 컨트롤러)은 나중에 작업하려고 한다. 테스트가 필요한 부분까지는 충분히 작업했다고 본다. 다음으로 Phaser를 이용하여 Tilemap 기반의 게임을 개발하는 부분을 작업하고 있다. 순수 javascript 기반으로 게임을 개발하지 않는 이유는 다음과 같다. 1. 게임 프레임워크를 개발하는 시간이 들지 않는다. 게임 하나를 만드는 과정에서 사용자의 입력, 애니메이션 처리, 충돌, 렌더링 같은 다양하게 신경써야 할 요소들이 한 두 가지가 아니다. 근데 이미 만들어둔 게임 프레임워크가 있다면, 빠른 개발을 위해서 충분히 쓸만 하다고 판단했다. 2. 내 기준에서 게임 프레임워크 구현이 포트폴리오의 가치가 있는가? 게임 프.. 2023. 9. 28.
[Node.js] 간단한 멀티 슈팅게임 소스 분석 크리스코스 유튜브의 멀티플레이어 게임 소스를 분석했다. https://github.com/chriscourses/multiplayer-game 게임 상의 로직은 각도로 총알 쏘는 슈팅게임인데, Node.js 기반에서 동작하는 멀티플레이 게임이다. 서버단에서 총알 리스트와 플레이어 리스트를 가지고 있고 일정 tick마다 update를 클라에게 내려준다. 클라는 해당 데이터를 받아 플레이어와 총알을 그린다. 서버쪽 데이터를 보고 없는 데이터는 생성, 있었으면 업데이트, 클라에서 있던 것이 없어졌으면 삭제 총알은 이렇게 처리하고 플레이어는 점수판에 대한 갱신도 추가적으로 해주고 있다. 또한 서버는 플레이어와 총알의 충돌 처리도 동시에 진행하는데 충돌이 일어난 경우, 서버의 플레이어 리스트에서 제거하고 총알도 .. 2023. 9. 26.
[Mediasoup] 1:N 연결 구현 테스트를 해보고 놀랐던 점은, 내부적으로 동작하는 코드가 효율적인 것 같다는 생각이다. 노트북 CPU 가속을 키지 않은 상태인데도 생각보다 CPU를 많이 사용하지 않는다. 직접 만든 SFU의 경우 서버에서 사용하는 양만 꽤 나갔던 걸로 기억하는데... ㅎㅎ 소스를 내가 작성한 것은 아니고, 유튜브 Amir Eshaq라는 분이 작성하신 소스가 있어서 보면서 학습했다. 기존에 작성했던 SFU 서버의 동작 방식과 크게 다르지는 않다. 다만 Mediasoup의 처리 순서를 따라가다보니 소스코드가 더 많은 것이 사실이다. 코드 내용을 뜯어서 분석했으나 그대로 정리하고 올려도 직접 뜯어보지 않으면 이해하기 어려울 것이다. 그래서 약간의 설명만 남겨두고 마무리하려고 한다. 클라쪽에서는 consumerTransport.. 2023. 9. 24.
[Android / iOS] Push Notification 기능 추가 안드로이드의 경우 1. Firebase Console에 앱을 등록 2. google service파일을 앱에 추가 등록하면 끝난다. 3. 내부 코드 작성 Android 코드 작성 Gradle 디펜던시 추가, 서비스 클래스 추가 코드는 복붙, 매니페스트에도 추가, 권한 처리하고 키 받을 수 있는지 테스트 https://firebase.google.com/docs/cloud-messaging/android/client?hl=ko&authuser=0 iOS의 경우 1. Firebase Console에 앱을 등록 2. google service파일 등록 3. Apple 개발자 계정 처리 - 앱 등록하고 알림 활성화 - APN키 생성하고 해당 키를 Firebase에 등록 4. Xcode 프로젝트 파일에 Notif.. 2023. 9. 22.
[Mediasoup] 미디어수프 아키텍처 미디어 수프의 아키텍처를 이해하기 위해서는 사용하는 개념에 대한 내용부터 알고 있어야 한다. Worker는 하나의 서버 같은 개념인데, Core의 수로 한정이 되어 있다. Router는 Room 단위로 분리가 된다. Transport는 Peer를 의미한다. Producer과 Consumer는 이름 그대로 스트림을 보내는 Peer와 스트림을 받는 Peer를 의미한다. 왼쪽 그래프에서 Peer의 수는 9개다. (Transport 9개), 서버로 보내는 피어의 경우 3개이다. (Producer 3개) 스트림을 받는 피어의 경우 6개이다. (Consumer 6개) 왼쪽 그래프에서 Peer의 수는 7개다. (Transport 7개), 서버로 보내는 피어의 경우 3개이다. (Producer 3개) 스트림을 받는 피.. 2023. 9. 22.
[Mediasoup] communication-between-client-and-server - 1 https://mediasoup.org/documentation/v3/communication-between-client-and-server/ Communication Between Client and Server 미디어 수프튼 클라와 서버간 통신하기 위해 어떤 시그널링 프로토콜도 제공하지 않는다. 웹소켓, HTTP 혹은 기타 수단을 가지고 통신하고, 미디어수프 관련 파라미터를 교환하며, 요청과 응답을 받는 것은 어플리케이션에 달려 있습니다. 대부분의 상황에서 양방향 통신이 이루져야 하므로 전이중(Full-duflex) 채널이 되어야 합니다. 그러나 어플리케이션은 같은 채널을 재활용할 수 있습니다. (미디어수프와 관련되지 않은 메시지의 교환용으로, 인증 프로듀스, 챗 메시지, 파일 전송 등등) Guide.. 2023. 9. 20.
[WebRTC] SFU 서버 구현 SFU 서버 구현은 쉽지 않았다... 라고 하지만 밀로님께서 이미 구현해놓으신 코드가 있어서 많은 참고가 되었다. 로직 자체가 크게 어렵지 않으니까 보다보면 충분히 이해된다. 참고로 Signaling 같은 고급 기술은 포함되어 있지 않다. 단순히 Peer간의 컨셉만 구현했다. SFU 서버 구축에 대한 이해도가 부족해서, 다른 소스는 어떤 식으로 작성이 되었는지 찾아보았다. 서버와 클라간 Peer를 연결하고 서버에서 유저의 스트림을 관리한다는 컨셉은 동일하더라. 핵심 로직에 대한 언급을 하기 이전에 컨셉을 이해 해야 한다. SFU 방식은 브라우저간 직접적인 P2P 통신을 하지 않는다. 각 브라우저는 서버와 P2P 연결을 하는데 서버에 자신의 스트림을 주는 SendPeer와 다른 브라우저의 스트림을 받는 R.. 2023. 9. 19.