머슬가이

멀티플레이 슈팅게임 만들기 (9)

슈팅게임 서버, C++로 처음부터 만들어보기 — 줄 곳이 없다보스를 잡으면 보상을 줘야 한다. 그런데 줄 곳이 없었다.지금 서버가 플레이어에 대해 아는 건 이게 전부다.class Session {private: uint64_t player_id_; std::string username_; bool logged_in_ = false;};전부 Session 안에 있다. 연결이 끊기면 Session이 죽고 같이 사라진다. 재화가 그러면 안 된다.Step 5에서 이렇게 적어뒀었다.영속성 없음 — 서버 재시작하면 전부 사라진다. player_id_도 "계정 번호"가 아니라 사실상 "접속 순번"에 가깝다.그때는 "나중에 보완"이라고 미뤘는데, 보상이 생기면서 청구서가 돌아왔다.연결보다 오래 사는 것..

멀티플레이 슈팅게임 만들기 (8)

슈팅게임 서버, C++로 처음부터 만들어보기 — 남을 방에 집어넣기매칭을 붙일 차례다. 두 명이 대기열에 모이면 방을 만들어서 같이 넣어주고, 보스를 띄운다.기능만 보면 단순하다. 대기열은 vector 하나면 되고, 두 명이 차면 방을 만들면 끝이다.그런데 코드를 쓰다 막혔다. Server가 alice와 bob을 방에 넣으려면 두 사람의 방 소속을 바꿔야 하는데, 그 값이 Session 안에 있다.class Session {private: uint32_t room_id_ = 0; // private. Server가 이걸 어떻게 건드리나};지금까지는 왜 문제가 없었나room_id_가 Session 안에 있는 건 이유가 있었다. Step 6에서 방을 만들 때, 소켓이나 유저네임과 마찬가지로 "그 연..

슈팅게임 서버, C++로 처음부터 만들어보기 — 번호는 아는데 보낼 수가 없다방에 여러 명이 모였다. 이제 채팅을 붙일 차례다.서버는 방에 누가 있는지 알고 있다. members: [1, 2]. 그런데 1번에게 메시지를 보내려고 하니 할 수 있는 게 없었다. 번호는 번호일 뿐이고, 그 번호가 어느 연결인지 이어주는 게 아무것도 없다.Step 6에서 방 멤버를 player_id만 저장하기로 한 결정이 여기서 청구서로 돌아왔다.번호와 연결을 잇는 표그래서 Server에 표를 하나 더 뒀다.std::unordered_map> sessions_;이게 있으면 브로드캐스트는 그냥 반복문이다.void broadcast_to_room(uint32_t room_id, const nlohmann::json& message..

슈팅게임 서버, C++로 처음부터 만들어보기 — 상태를 어디에 둘 것인가지금까지 모든 상태는 Session 안에 있었다. 소켓, 유저네임, 로그인 여부. 전부 "그 연결만의 것"이라 문제가 없었다.방은 다르다. 방 목록은 모두가 공유하는 상태다. alice가 만든 방을 bob이 볼 수 있어야 한다. alice의 Session에 방 목록을 넣으면 bob은 그걸 볼 방법이 없다.드디어 중앙 관리자그래서 모든 Session 바깥에서 공유 상태를 들고 있을 Server 클래스를 만들었다.여태 안 만들었던 이유는 필요가 없었기 때문이다. 필요해지기 전에 구조부터 잡지 않는다는 원칙을 지키다 보니 딱 지금이 그 시점이 됐다.기능보다 리팩터링 먼저방 기능을 바로 붙이지 않고, 먼저 main()에 있던 accept 루..

슈팅게임 서버, C++로 처음부터 만들어보기 — 서버는 아직 "누구"인지 모른다지난 편에서 메시지를 구조화해서 주고받을 수 있게 됐다. 그런데 서버는 여전히 중요한 걸 모르고 있었다 — 누가 보낸 메시지인지.채팅이든 방 생성이든 경매든, 전부 "누가"가 전제되는 기능이다. 그래서 이번엔 로그인을 붙였다.Session에 상태가 생겼다지금까지 Session은 순수하게 네트워크만 다뤘다. 소켓, 버퍼, 송신 큐. 여기에 게임 상태가 들어간다.uint64_t player_id_;std::string username_;bool logged_in_ = false;왜 하필 Session인가Session은 연결마다 하나씩 만들어지는 객체다. A가 접속하면 A의 Session, B가 접속하면 B의 Session이 따로 ..

슈팅게임 서버, C++로 처음부터 만들어보기 — TCP는 메시지 단위로 오지 않는다지금까지 만든 echo 서버엔 사실 치명적인 함정이 숨어있었다. TCP는 "바이트 스트림"이지 "메시지 스트림"이 아니다.직접 확인해봤다클라이언트에서 3000자짜리 문자열을 WriteLine 한 번으로 보냈는데, 서버 로그는 이랬다:Received 1024 bytesReceived 1024 bytesReceived 954 bytes한 번에 보낸 게 세 조각으로 쪼개져서 도착했다. 1024씩 잘린 건 내 수신 버퍼가 char buffer_[1024]였기 때문이다.반대로 여러 번 보낸 게 한 덩어리로 합쳐져 오기도 한다. 보낸 쪽이 "한 번에 썼다"는 사실은 받는 쪽에 전혀 전달되지 않는다.지금은 echo라 상관없지만, {"t..

슈팅게임 서버, C++로 처음부터 만들어보기 — 한 명 처리하다 막혀있던 문제지난 편까지는 한 명씩 순서대로 접속 받고 echo 해주는 서버였다. 근데 이거, 사실 치명적인 문제가 있다 — 한 명이 접속해서 아무것도 안 보내고 가만히 있으면, 다른 사람은 접속 자체가 안 되는 것처럼 멈춰버린다.직접 재현해봤다PowerShell 창 두 개 열어서:창 1: 접속만 하고 아무것도 안 보냄창 2: 접속하고 메시지 보냄 → 응답 대기결과: 창 2가 응답을 영원히 못 받고 멈춰있었다. 서버가 창 1을 처리하는 루프에 갇혀서, 창 2를 위해 다시 "새 접속 받아라"를 호출할 기회 자체가 없었던 거다.비동기로 전환accept(), read_some()처럼 "끝날 때까지 기다리는" 함수들을, async_accept, a..

슈팅게임 서버, C++로 처음부터 만들어보기 — 보낸 거 그대로 돌아오게 하기지난 편에서 접속만 받아서 로그 찍는 서버를 만들었다. 이번엔 한 단계 더 — 클라이언트가 보낸 텍스트를 그대로 돌려주는 echo 서버를 만들어봤다.뭘 바꿨나접속을 받고 바로 끊던 걸, read_some()으로 데이터를 읽고 write()로 그대로 돌려주는 루프로 바꿨다. 클라이언트가 연결을 끊으면(EOF) 루프를 빠져나와서 다시 다음 접속을 기다린다.char buffer[1024];while (true) { boost::system::error_code error; size_t length = socket.read_some(boost::asio::buffer(buffer), error); if (error ==..

슈팅게임 서버, C++로 처음부터 만들어보기 - 서버 올리기뭘 만들고 있나2D 멀티플레이 슈팅게임을 만들어보고 있다. 채팅, 경매, 방 생성, 보스 클리어 리워드, 매칭, 친구추가까지가 목표다.왜 클라이언트/서버를 나눴나멀티플레이 게임에서 제일 먼저 정해야 하는 건 "누가 진실을 결정하는가"다.보스 체력이 얼마 남았는지, 경매에서 누가 이겼는지 같은 걸 플레이어 각자의 게임 화면이 판단하게 두면, 클라이언트 값을 조작해서 우기는 걸 막을 수가 없다.그래서 서버 권위형(server-authoritative) 구조로 가기로 했다. 클라이언트는 요청만 보내고, 판정은 항상 서버가 한다.기술 스택클라이언트: Unity + C# — Unity는 스크립트가 C#만 지원해서 자연스럽게 결정됐다서버: C++ + Boo..

저번엔 작업한 내용을 완전히 삭제하는 방법에 대해 글을 썼지만, 이번엔 오타나 사소한 수정같은 경우 history를 남기면서 작업하는건 상당히 깔끔해보이지 않기 때문에, 이번엔 커밋 덮어 쓰는 방법에 대해 글을 적습니다.1. 가장 최근 커밋 덮어쓰기: git commit --amend가장 흔하게 쓰이는 방법으로, 방금 만든 직전 커밋을 통째로 갈아 끼우거나 수정할 때 사용합니다.상황 A: 깜빡하고 빼먹은 파일이 있을 때Bash git add 빼먹은파일.javagit commit --amend --no-edit # 메시지는 그대로 두고, 방금 커밋에 파일만 쏙 집어넣어 덮어씀상황 B: 커밋 메시지를 오타 없이 고치고 싶을 때Bash git commit --amend -m "수정된 올바른 커밋 메시지"2...