2P by GN⁺ | ★ favorite | 댓글 1개
  • 과거 Macromedia/Adobe Flash의 경험을 되살리는 것을 목표로 하는 경량 게임 엔진
  • 모든 플랫폼에서 동작하도록 설계되었으며, 유일한 출력 대상은 순수 WASM
  • 출력물에 실행 파일이나 글루 코드 등이 포함되지 않으며, Emscripten 미사용
  • import와 export 목록이 PlatformCommunication.hpp에 명확히 정의됨
  • 브라우저를 포함한 어떤 플랫폼에서도 쉽게 구현 가능한 구조

개요

  • 경량(light-weight) 게임 엔진으로, 과거 Macromedia/Adobe Flash의 경험을 재현하는 것을 목표로 함

아키텍처

  • 어떤 플랫폼에서도 실행되도록 만들어졌으며, 유일한 출력 대상으로 순수 WASM을 목표로 함
  • 출력물에 실행 파일, 글루 코드 등이 포함되지 않으며, Emscripten을 사용하지 않음
  • import와 export 목록이 PlatformCommunication.hpp에 깔끔하게 정의되어, 브라우저를 포함한 어떤 플랫폼에서도 손쉽게 구현 가능

댓글과 토론

Hacker News 의견들
  • 와, Zero Engine을 만드신 분들이군요? 오래전에 DigiPen 여름 캠프에서 써봤고, Zilch로 프로그래밍하는 게 정말 즐거웠음
    Galaga 클론을 플레이하는 AI도 만들었음. 이번 Unity 사태 때문에 Zero는 어떻게 됐나 궁금했는데, 다시 부활할 것 같아서 정말 기대됨

    • 멋지네요! Zilch는 제가 애지중지 만들던 거라, 그렇게 말해주니 정말 기쁩니다 :D
  • 참고로 하나 보태자면, 내장 그래픽이 달린 확실한 저사양 노트북에서는 또 하나의 멋진 슬라이드쇼처럼 동작함
    오래된 Mate 20 Pro에서도 해봤는데 “Downloading runtime”에서 멈춘 것처럼 보였음. 불안정한 4G 탓이 아닌 것 같아 USB로 노트북에서 chrome://inspect를 열어 탭을 확인했더니 Uncaught (in promise) Error: Needs OES_texture_float_linear to function 오류가 나왔음. 어차피 못 가지고 논다는 메시지를 보여주기 위해 오류 화면을 만들 가치가 있느냐는 철학적 질문이 되긴 함

  • 개념은 마음에 듦. 다만 내 GPU와 브라우저가 지연 때문에 울고 있고, 인상적인 슬라이드쇼처럼 보임
    몇 번 시도한 끝에 겨우 시작 구체를 선택할 수 있었음. 처음엔 로딩이 끝난 건지도 확신이 안 들었음. 물론 Firefox에서 1.8GHz Celeron, 내장 GPU, 8GB RAM을 쓰는 중이라 고사양과는 거리가 멂

    • Chrome에서는 좀 더 잘 도는지 궁금함. 꽤 많은 사람이 Firefox 문제를 겪는 것 같음. 앞으로 Firefox도 정기적으로 테스트해보겠음
    • 다시 시도해볼 수 있다면, 일부 머신에서 성능을 크게 개선하는 수정이 방금 배포됐음
      네이티브 게임 엔진을 WASM으로 포팅한 것이다 보니, 문제는 브라우저 타이밍 API와 잘 맞지 않던 프레임률 제한 코드에 있었음: https://raverie-us.github.io/raverie-engine/
    • M2 Pro에서도 정확히 같은 경험을 했고, 저도 Firefox였음
    • 아직도 Celeron을 만드는군요?
  • “우리 엔진에는 Spaces라는 독특한 기능이 있었고, 별도의 월드/레벨을 인스턴스화할 수 있었다”는 부분은, 제가 보기엔 Godot 엔진이 하는 것과 정확히 같아 보임[1]
    그 엔진도 브라우저(WASM) 타깃이 있음. [1]: https://godotengine.org/

    • WASM 타깃이 있을 뿐 아니라 웹 버전도 있음: https://editor.godotengine.org/
      프로젝트에서 우선순위가 높지는 않은 것 같음. 조금 테스트해보니 동작은 하는 듯하지만 :), 네이티브 실행보다 느림
    • Unity의 과 어떻게 다른지도 잘 모르겠음
  • 브라우저의 Web API와 순수 WASM이 JS 계층 없이, 또는 낮은 비용으로 상호작용할 수 있게 해줄 WASM 개발 흐름이 있는지 궁금함
    가끔 https://github.com/WebAssembly/proposals를 보는데 매우 혼란스러움. 타입 임포트 제안은 몇 년은 멀어 보이고, 거의 완료된 GC 제안은 GC 언어용이지 브라우저↔WASM용은 아닌 듯함. 컴포넌트 모델은 브라우저 사용 사례와는 거리가 있어 보이고, JS String Builtins는 JS 문자열을 더 빠르게 해주지만 DOM은 아님. ECMAScript 모듈 통합은 WASM 모듈을 ES 모듈로 바꾸지만 Web API는 ES 모듈이 아니라 도움이 안 됨. 기여자들 대화를 보면 이런 기능 제공이 우선순위도 아니고 계획에도 없는 것처럼 보일 때가 있으며, 대다수에게는 클라우드·암호화 같은 용도의 WASI와 컴포넌트 모델이 더 중요한 듯함

    • 저도 이걸 정말 원함. 페이지는 그냥 WASM이고, “브라우저”는 WASI처럼 플랫폼 임포트를 제공하는 순수 wasm 브라우저를 보고 싶음
      다만 말한 것처럼 그들에게 우선순위는 아닌 것 같음. 언젠가는 가능하길 바람
    • 참조 타입(reference types) 덕분에 기술적으로는 이미 브라우저 API를 직접 호출할 수 있음. WASM이 JavaScript 객체를 주고받을 수 있기 때문임
      관련 Web API를 모두 임포트한다면, 개별 API 호출 사이에서 JS 객체를 그대로 전달할 수 있어서 중간 JS가 거의 필요 없을 수 있음. 실제로 JS가 필요한 건 처음 WASM 모듈을 초기화할 때 정도임
    • 순수 WASM의 문제는 차단할 수 없는 광고가 있는 폐쇄형 웹으로 이어질 수 있다는 것임
    • 적어도 일부는 GC 제안이 지향하는 방향이라고 봄
  • 멋진 프로젝트임. 고해상도 디스플레이에서 UI를 확대하는 방법이 있나요?
    2:1 디스플레이에서는 글꼴에 계단 현상이 보임. 브라우저 확대/축소를 50%로 설정하면 UI는 선명해지지만, 모든 것이 너무 작아져서 쓰기 어려움

    • OP에게: 수정 방법은 캔버스 너비를 window.innerWidth * window.devicePixelRatio, 높이를 window.innerHeight * window.devicePixelRatio로 설정하는 것임
      그다음 CSS로 캔버스를 화면에 최대화하면 됨
    • 왜 UI에 브라우저 네이티브 렌더링 엔진을 쓰지 않는지, 적어도 SVG라도 쓰지 않는지 이해가 안 됨
      리소스(메모리, 네트워크, CPU) 면에서 더 저렴하고, 접근성 대응도 쉽고, 렌더링도 더 쉬울 텐데
  • Trevor! DigiPen에서 문법으로 프로그래밍 언어 설계를 다루던 CS 선택 과목을 정말 좋아했음
    가르쳤던 학생들 중 상당수가 지금 Minecraft에서 일하고 있음. 지금 Minecraft 스크립팅 API를 설계하면서, 그때 배운 기초와 DigiPen 시절의 많은 내용을 활용하고 있음. 아직도 멋지게 활동하는 모습을 보니 반가움

    • 도움이 됐다니 정말 기쁘네요! 언젠가는 다시 강의를 하게 될 겁니다 ;)
      작업 중인 스크립팅 인터페이스도 꼭 보고 싶어요. 예전에 Minecraft 모드를 정말 많이 만들었고, 늘 어떤 형태의 동적 스크립팅을 원했거든요
  • 정말 멋짐. 이 분야에서 순수 WASM 기반 제품을 보니 반가움. 다만 제 M1 Mac Pro에서는 꽤 버벅임

  • 질문이 하나 있는데, 이거 NES에서도 돌아가나요? 리퍼비시한 전면 로딩 모델이고 부품은 대부분 원본이지만, RAM을 좀 더 붙였음
    위에 글루건으로 붙였고, 케이스도 빨간색으로 칠한 뒤 군인 장난감 몇 개를 달아놨음

    • WASM > NES 변환기를 만드는 일이 왜 실제로 재밌어 보이는 걸까요…
  • 기본 공 장면만 띄웠는데도 Radeon Pro 560X와 거의 4K 환경에서 GPU를 엄청 세게 때림
    카메라를 회전하는 것만으로도 프레임률이 매우 낮아짐. WebGL 최적화 문제가 있을 수 있는지 아는 분 있나요?

    • Intel HD Graphics 620에서는 아주 부드럽게 동작함. 7세대 Intel 내장 그래픽이라 오래되고 느린 편인데도, 기본 공 장면만 봤을 때 시스템에서 굉장히 매끄러워서 놀랐음. Chrome을 쓰고 있음
    • 다시 시도해볼 수 있다면, 일부 머신에서 성능을 크게 개선하는 수정이 방금 배포됐음
      네이티브 게임 엔진을 WASM으로 포팅한 것이다 보니, 문제는 브라우저 타이밍 API와 잘 맞지 않던 프레임률 제한 코드에 있었음: https://raverie-us.github.io/raverie-engine/
    • 전용 그래픽 카드를 안 쓰는 것처럼 들리기도 함. 다른 WebGL 데모들은 정상적으로 돌아가나요?