HN 공개: 내 게임 엔진 오픈 소스화

Moddio 게임 엔진 2

• Moddio는 멀티플레이어를 우선으로 하는 게임 엔진임.
• 서버 권한을 가진 네트워크 코드, 스냅샷 보간, 클라이언트 측 조정 기능을 내장하고 있음.
• 월 5달러짜리 VM에서 50명 이상의 동시 플레이어 또는 300개 이상의 움직이는 객체를 지원함.

데모

• 박스에 포함된 내용: Box2D 물리 엔진, 서버 권한을 가진 네트워크 코드, 인벤토리 및 아이템 시스템, 내장 속성(HP, 에너지 등)과 재생률, 대화 시스템, 상점, 유닛 컨트롤, 클라이언트 측 예측된 발사체 및 유닛 이동, 유닛 AI 및 A* 경로 찾기, 모바일 컨트롤 등.

게임 실행 방법

• Node 18 이상이 필요함.
• 저장소 설정 후, /src 디렉토리로 이동하여 game-sample.json을 game.json으로 이름을 바꾸고, 루트 디렉토리로 돌아와 서버를 실행함.
• 이제 http://localhost:80에서 게임을 플레이할 수 있음.

새 게임을 처음부터 만드는 방법

• Moddio 게임은 https://www.modd.io에서 제공하는 Moddio 게임 에디터를 사용하여 생성 및 편집됨.
• 게임을 만든 후, 로컬 설치에서 사용할 수 있는 game.json을 내보낼 수 있음.
• 내보낸 게임 JSON을 game.json으로 이름을 바꾸고 ./src 디렉토리로 이동함.

기여하는 방법

• Moddio는 MIT 라이선스 하에 완전히 무료이며 오픈 소스임.
• 기여자가 되는 방법에 대해 알아보려면 기여 방법 페이지를 방문함.

크레딧

• Isogenic 게임 엔진, Phaser, PlanckJS, uWebsocket, Box2D, Kenney 자산, Hero Icons 등이 사용됨.

GN⁺의 의견

• Moddio 게임 엔진은 멀티플레이어 게임 개발에 특화되어 있으며, 저렴한 비용으로 많은 플레이어를 지원하는 강력한 기능을 제공함.
• 오픈 소스이며 커뮤니티의 기여를 통해 지속적으로 발전하고 있어, 초급 소프트웨어 엔지니어들에게도 접근성이 좋음.
• 게임 개발에 필요한 다양한 기능들이 내장되어 있어, 개발자들이 빠르게 프로토타입을 만들고 테스트할 수 있는 환경을 제공함.

[GN⁺]

Hacker News 의견들

• Android 앱 가입 화면에서 Google 사용자명과 비밀번호를 앱 안의 웹 폼처럼 보이는 곳에 입력하라고 하는데, 사용자는 앱이 비밀번호를 엿보는지 알 방법이 없음
  보통 앱은 로그인 화면으로 이동했다가 다시 돌아오는 흐름을 쓰는 것 같은데, 그 패턴 구현이 어려운지 궁금함. 크로스 플랫폼 지원 때문에 생기는 문제인지도 궁금함

  • 원칙적으로 아주 어려운 일은 아님. 자동차 제조사들과 일하면서 사용자가 OEM 계정으로 로그인하게 해야 하는데, 이론상으로는 모두 규정 준수라고 하지만 실제로는 많은 부분이 안 되고 수정도 오래 걸림
    다만 위에서 말한 방식은 정말 일어나면 안 되는 일이고, Google이 이미 금지한 줄 알았음
  • 이건 OAuth 2.0이라고 부르며, Okta 같은 걸 쓰면 구현이 간단함

• 사용자가 게임 엔진을 채택하게 만드는 건 결코 쉬운 일이 아니고, 특히 비공개 소스라면 더 어려움
  사이트에 있는 게임 갤러리를 보면 지금까지 꽤 잘 해낸 것 같은데, 몇몇 친구들이 만든 건지 아니면 꽤 활발한 커뮤니티가 있는지 궁금함

  • 좋은 기능, 배우기 쉬움, 낮은 진입 부담의 조합은 꽤 멀리 갈 수 있음
    캐주얼하게 며칠 또는 몇 시간만 들여도 의미 있는 결과가 나오는 구조를 떠올리면 됨. Flash를 기억해보면 됨
  • 활발한 커뮤니티가 있고 매일 150~300개의 새 게임을 만들고 있음
    게임 개발자와 플레이어 모두에게 진입 장벽이 낮은 점이 확실히 도움이 됨. 다운로드나 가입이 필요 없음

• 제목만 봤을 때 이게 modd.io일 줄은 몰랐음. IO 게임을 만드는 데 쓰이는 인기 있는 프레임워크/플랫폼임

  • 게임을 많이 하고 예전에 팔아본 적도 있지만, 그 용어는 들어본 적이 없음. IO 게임이 뭔가?

• Brains 서버 하나에 들어가서 플레이어 50명 정도의 경험이 어떤지 궁금했음. 웹소켓에서 예상되는 것처럼 움직임이 좀 덜컹거렸고, 비슷한 걸 만들고 있어서 네트워크 압축도 궁금했음
  LZ-string 압축만으로 충분한지는 잘 모르겠음. 플레이어 50명에 초당 약 20KB를 쓰는데, Warzone은 150명에서 초당 48KB 정도만 씀. 무제한 데이터가 아니라면 클라우드 대역폭 비용이 꽤 나갈 수 있음
  압축된 바이트 버퍼가 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼처럼 보이는 것도 신기했음. LZ-string 압축 결과가 원래 이렇게 되는 건지 모르겠지만 꽤 낯설게 보임
  어쨌든 잠재 비용을 줄이려면 네트워킹 쪽에 개선 여지가 많음. 전체 프로젝트는 매우 인상적이고 잘 만든 작업임

  • 우리 웹소켓에서는 움직임이 꽤 타이트함: https://gooberdash.winterpixel.io/
    핵심은 클라이언트 측 예측과 롤백 네트워킹 알고리즘임. 우리 게임 상태는 30Hz에서 약 1KB라 보통 단일 패킷에 들어가고, 그래서 웹소켓도 아주 나쁘지는 않음. 물론 비신뢰성 프로토콜이 더 낫기는 함
  • “웹소켓에서 예상되는 것처럼 움직임이 좀 덜컹거렸다”는 부분을 좀 더 설명해줄 수 있을까? 몇몇 “IO 게임”을 해봤는데 가끔 지연이 심한 플레이어를 제외하면 꽤 부드러워 보였음
    몇 달 전 WebSockets를 조금 테스트해봤는데, 이해한 바로는 게임처럼 지연 시간에 민감한 통신에서 TCP를 쓰는 데 상당한 단점이 있음. TCP 헤더가 UDP보다 2배 이상 크고, 추가 제어 패킷이 있으며, 오래된 데이터가 재전송되는 동안 새 데이터 전송이 지연됨. WebSockets도 TCP 위에서 동작하니 같은 단점을 가짐
    그런데도 TCP가 WebSocket 메시지 전달을 보장한다고들 하지만, 패킷 손실을 재현할 수 있었음. 결국 단점은 그대로 있고, 실제로 보장 전달이 필요하면 그 위에 직접 뭔가를 만들어야 하는데, 그럴 거면 처음부터 UDP 위에 필요한 메시지만 그렇게 만들 수도 있었을 것 같음
    네트워킹은 조금 만져본 것 외에는 지식과 경험이 거의 없으니 감안해서 보면 됨
  • CJK 문자는 출력 가능한 유니코드 문자 중 매우 큰 부분을 차지함. [1] 가장 큰 블록 두 개에는 U+3400~U+4DBF, U+4E00~U+9FFF가 포함됨
    해당 문자열은 \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c로 디코딩됨
    [1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs

• 게임을 절대 완성하지 못하는 확실한 방법은 엔진 작성부터 시작하는 것임
  자체 기술을 만드는 건 충분히 가능하지만, 매 단계에서 그 기술은 범용 게임 플랫폼이 아니라 자기 프로젝트에 맞춰져 있어야 함

  • 블로그를 시작해야겠다!
    여기서 “블로그를 시작한다”는 건 완전히 처음부터 새 블로그 엔진을 만든다는 뜻임
  • modd.io의 어떤 부분을 말하는 건지 더 설명해줄 수 있을까? 게임을 만들려다 실패한 결과물이라는 뜻인가?
  • 엔진을 쓰는 사람들 대부분은 애초에 게임을 만들고 싶은 게 아니라, 사실은 엔진을 만들고 싶은 사람들일 가능성이 큼

• Node.js 기반 멀티플레이어 백엔드는 연결 수가 늘어나면 결국 기어가는 수준으로 느려지는 걸 봐왔음. 이 문제를 어떻게 해결했는지 궁금함
  이런 경우 Go 같은 대안이 더 낫지 않을까?

  • 왜 그런지 잘 모르겠음. 연결 측면에서는 Node의 이벤트 루프 덕분에 HTTP 요청/응답 쪽 입출력 블로킹은 문제가 안 될 것 같음
    백엔드가 프런트엔드를 위해 물리 연산이 무거운 작업을 하고 있을 것 같지도 않음
  • uWebSockets(https://github.com/uNetworking/uWebSockets)를 씀. C로 작성됐지만 NodeJS에서 쓸 수 있는 인터페이스가 있음
    간단한 테스트에서는 빠르게 느려지는 다른 인기 웹소켓 라이브러리들보다 훨씬 성능이 좋았음
  • 대부분의 IO 게임에서 병목은 입출력일 것 같음. 장르 이름은 최상위 도메인에서 온 것이지만 말장난처럼 보이긴 함
    그래서 Node가 좋은 선택으로 느껴짐
  • 확장성은 특히 연결 수가 많을 때 실제 고려사항이 될 수 있음. 우리 경우에는 백엔드를 최적화해서 상당한 수의 동시 연결을 효율적으로 처리하게 했음
    각 게임은 최대 64명으로 제한되어 있지만, 100개 이상의 연결까지 테스트했을 때 성능 문제는 보이지 않았음. 각 게임은 격리된 컨테이너에서 실행됨

• 새 엔진을 만드는 동기가 궁금함
  README를 보면 무기 시스템(근접/투사체), 상점, 클라이언트 측 예측 투사체와 유닛 이동 같은 꽤 구체적인 것들이 내장돼 있음
  왜 이런 것들을 엔진에 구워 넣고, 복사 가능한 플러그인으로 만들지 않았는지 궁금함. 물론 많은 게임은 이런 기능이 필요 없는데, 이건 게임 엔진인가? 아니면 FPS/RPG/기타 특정 장르용 엔진인가?
  기술 자체를 싫어하는 건 아니지만 여전히 “왜?”라는 질문이 남음. 무엇을 위한 건가? 왜 Three.js와 자체 서버 대신 이걸 써야 할까?

  • 질문 고마움. 우리는 다른 모듈형 대안들보다 엔진을 더 의견이 강한 구조로 만들기로 의식적으로 결정했음. 2D 멀티플레이어 게임을 극도로 빠르게 개발하고 싶기 때문임
    예를 들어 간단한 MMORPG를 2시간 만에 만들었음: https://www.youtube.com/watch?v=GZVsxkALR5U
    사용 편의성과 커스터마이징 수준 사이에는 반비례 관계가 있다고 봄. 우리는 만들기 어렵다고 알려진 멀티플레이어 게임과 캐주얼 게임 개발자 사이의 간극을 줄이기 위해 전자를 선택했음
  • “무엇을 위한 건가?”
    당신을 위한 건 아닌 것 같고, 그런 특정한 게임을 만들고 싶은 사람들을 위한 것임. 모든 엔진이 범용일 필요는 없음

• 여기와 잘 맞을 것 같은 취미 프로젝트가 몇 개 있었음. 코딩은 할 수 있지만, 취미 프로젝트를 할 때는 그렇게 집중하고 싶지 않은 순간이 있어서 로우코드와 대화형 편집기가 취미 개발자에게 좋아 보임
  개인적으로 가장 기대되는 건 지도와 세계 생성임. 게임을 JSON으로 내보내고, 프로그램으로 수정한 뒤 다시 가져오는 게 가장 좋은 방법처럼 보이는데 맞는지 궁금함
  다만 조금 부담스럽긴 함. 수정하지 않은 튜토리얼 월드가 JSON 3500줄이라 이해해야 할 게 많음
  처음 떠올린 방법은 의도적으로 편집을 해보고 JSON이 어떻게 바뀌는지 보는 것임. 괜찮은 JSON diff 뷰어도 찾아봐야 함. 그러면 건드리고 싶은 부분을 찾는 데 도움이 될 듯함. 에셋과 지도 타일은 대화형 편집기에서 모을 것 같음
  이런 접근이 합리적인지, 도움이 되는 도구가 있는지 궁금함

  • JSON을 직접 수정하는 건 권하지 않음. 꽤 읽기 어렵고 부풀려져 있음. modd.io에는 지도를 직접 수정할 수 있는 액션들이 있음
    우리 커뮤니티의 한 제작자는 ChatGPT로 지도를 동적으로 생성하고 있음. 숨바꼭질 게임을 만들고 있는데, 2D 지도 JSON을 생성하라는 프롬프트를 보내고 새 라운드가 시작될 때마다 그 지도를 로드함. 아직 공개하지 않아서 게임을 공유하긴 어려움
    또 커뮤니티 멤버 중 한 명이 우리 게임 JSON용 인터프리터를 만들고 있음. 예: https://pypi.org/project/pymodd/

• 이런 오픈소스 프로젝트가 더 나오는 걸 보니 반가움. GitHub 스타가 100개도 안 된다는 게 놀라움

  • 오해하지 않았으면 하는데, 진짜 궁금해서 묻는 것임. GitHub 스타가 100개 미만이라는 게 왜 놀라운가?
  • 아마 방금 공개했기 때문일 수도 있음