박용현의 개발일지

1. 최종프로젝트 1에서 일부러 class와 session 관리를 어떻게 하고 있는지 보여주지 않았습니다.위의 이유에 대해서는 할말이 정말 많지만 이미 망가져버린 코드 구조의 흐름을 보여주고 싶지도 않았지만 일단, 누군가 진지하게 읽을 수 있으니 간단하게 설명하며 보여드리겠습니다.2. user.class유저 클래스에서는 로그인한 유저들을 관리하기 위해서 필요한 정보를 객체화 해서 관리하기 위해 만들었습니다.const { TOWN_SPAWN_TRANSFORMS } = configs;class User { #pingQueue = []; #intervalId = null; constructor(socket) { this.socket = socket; this.id = socket.id; ..

글을 쓰기에 앞서 4주동안 열심히 스파르타 코딩 클럽에서 최종프로젝트를 하던 나의 조가 해체가 되었다.그렇게 튜터님들과 팀원들의 노력으로 다른 조에 병합하게 되었고, 그곳의 서버에 무언가 데이터를 싸버린 것을 본 저는 핸들러가 제대로 동작할 수 있게 노력을 하였습니다.1. 프로토 메세지를 확인message SkillInfo { int32 skillId = 1; // 스킬 ID float damageRate = 2; // 스킬 계수 float coolTime = 3; // 스킬 쿨타임}message C_GetSkill { int32 skillId = 1; // 장착된 스킬 ID int32 itemInstanceId = 2; // 고유 아이템 ID int32 slotIndex = 3; ..

2탄을 만든 이유:1. 동기화 기준의 불명확성서버와 클라이언트 간 용광로 상태를 동기화하는 명확한 기준이 부재클라이언트간 독립적으로 계산할 수 있는 데이터를 제공하지 않고, 서버와 클라간에 시간을 주기적으로 서버에서 받아야만 정상 동작으로 설계 2. SRP 위반GameManager에 용광로 관련 연산 로직을 포함, 단일 책임 원칙을 지키지 못함.GameManager의 역할이 비대해지며 코드 가독성과 유지보수성에 부정적인 영향을 미침.개선 방법:1. 동기화 방식 개선멀티플레이 환경에서 모든 클라이언트가 동일한 상태를 유지할 수 있도록 설계 변경.서버 시간과 클라이언트 시간을 계산해 동기화하는 대신, 용광로 상태가 변경될 때마다 서버에서 시뮬레이션을 수행하여 연산 결과를 클라이언트에 전송.클라이언트는 수신된..