Bevy 0.12 - Rust로 만든 데이터 주도 게임 엔진

 (bevyengine.org)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 렌더러가 선택적 Deferred Rendering을 지원하며, 재질별로 forward 또는 deferred 경로를 선택하고 DefaultOpaqueRendererMethod로 전역 기본값을 설정할 수 있음
  • 기존 Bevy 앱이나 플러그인은 0.11 to 0.12 Migration Guide를 통해 마이그레이션 절차 확인 필요
  • Bevy Asset V2가 자산 전처리, .meta 파일 기반 설정, 여러 AssetSource, 재귀 의존성 로드 이벤트, 비동기 자산 I/O, 개선된 핸들을 지원함
  • 자산 전처리는 AssetPlugin { mode: AssetMode::Processed }와 bevy/asset_processor Cargo 기능으로 활성화하며, 현재는 대부분의 사용 사례에 아직 권장되지 않음
  • Android에서 앱 일시 중단 시 더 이상 크래시하지 않고, 재개 전까지 시스템 실행을 멈추며 ApplicationLifetime::Suspended와 ApplicationLifetime::Resumed 이벤트를 제공함
  • StandardMaterial에 specular_transmission, diffuse_transmission, thickness, ior, attenuation_color, attenuation_distance가 추가되어 유리·물·플라스틱·잎·종이 같은 투과 재질 표현을 지원함
  • glTF 로더가 KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume, KHR_materials_emissive_strength 확장을 지원하고, TEXCOORD1 또는 UV1 두 번째 UV 맵을 가져올 수 있음
  • Draw command 자동 batching/instancing이 가능해졌으며, 동일한 재질과 메시를 가진 엔티티를 현재 배치할 수 있고 NoAutomaticBatching 컴포넌트로 제외 가능함
  • 그림자는 PCF Shadow Filtering을 도입해 DirectionalLight와 SpotLight에서 더 부드러운 그림자를 지원하며, 기본 방식은 ShadowMapFilter::Castano13임
  • ECS에 one-shot systems가 추가되어 시스템을 등록한 뒤 SystemId로 필요할 때 실행할 수 있으며, exclusive system, system piping용 system, 자기 자신 호출, 병렬 평가는 지원하지 않음
  • FixedTime이 제거되고 Time이 FixedUpdate에서도 문맥에 맞는 값을 반환하며, FixedUpdate가 과도하게 누적되어 앱이 멈추는 “death spiral”을 방지함
  • AnimationPlayer에서 set_elapsed는 seek_to로, stop_repeating은 set_repeat(RepeatAnimation::Never)로 대체되며, elapsed는 애니메이션 속도의 영향을 받지 않는 실제 경과 시간을 반환함
  • Bevy shader import가 Rust 스타일 구문으로 바뀌어 #import bevy_pbr::forward_io::VertexOutput, 중괄호 다중 import, 부분 경로 import, 완전 수식 경로 사용을 지원함
  • UI는 UiMaterial로 커스텀 material shader를 UI 노드에 사용할 수 있고, Outline 컴포넌트로 레이아웃 공간을 차지하지 않는 노드 외곽선을 지원함
  • 접근성 통합에 ManageAccessibilityUpdates 리소스가 추가되어 값이 false일 때 엔진의 접근성 트리 자동 업데이트를 중지할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Bevy는 Unity나 Godot 같은 전통적 엔진과 비교하면 게임을 만드는 방식이 완전히 다름
    UI나 스크립팅 없이 모든 걸 Rust 코드로 처리해서 libGDX나 Cocos2D-x에 더 가까움. 다만 ECS와 Rust를 쓰기 때문에 코딩 방식이 또 크게 달라져서, 사실상 자기만의 섬에 있는 느낌임
    Bevy로 성공한 인디 게임을 보고 싶지만, 대부분의 게임 개발자는 이미 배웠고 주변에서도 쓰는 전통적 도구를 더 선호할 가능성이 큼. 게임을 만들고 싶어 하면서 Rust도 선호하는 사람의 교집합이 크지 않고, 그 안에서도 실험적 새 엔진을 배우는 데 상당한 시간과 노력을 들이기보다 신뢰와 자료가 쌓인 도구를 고를 사람이 많아 보임
    개인적으로는 Bevy에 Bevy와 Rust 기반의 IDE와 스크립팅 언어가 필요하다고 봄. 새 프로젝트에 큰 노력을 들여야 하는 장벽이 사라지진 않겠지만, Rust 경험이 없고 코드 벽에서 시작하는 걸 부담스러워하는 신규 사용자에게 훨씬 친숙해질 수 있음. Unity나 Godot처럼 캔버스에서 몇 시간 안에 아주 기본 프로토타입을 만들 수 있는 방식과 대비됨
    개발자가 스크립팅 언어에 반대하는 걸로 알지만, 핫 리로드와 더 깊은 디버깅은 필요하고 Rust만으로는 효과적으로 하기 어렵다고 생각함. 많은 게임 개발자가 Rust와 빌림 검사기에서 압도될 수도 있음. 다만 지금은 직접 구현할 시간과 자원, 의지가 없음

    • Bevy는 구조상 빌림 검사기와 직접 부딪힐 일이 많지 않음. 컴포넌트와 리소스는 대체로 소유 타입을 쓰고, Query와 Ref를 통해 큰 걱정 없이 다룰 수 있음
      Bevy를 조금 만져봤고 저장소를 확인해보니 수명 표기가 0개였음
    • 게임 개발에서 가장 시간을 많이 먹는 건 자산 관리이고, 그다음이 프로그래밍인 경우가 많았음. Bevy 같은 엔진은 버그 수정 시간을 줄이려 하지만, 자산 파이프라인이 부족하면 그 절감분을 자산 쪽에서 잃게 됨
      스크립팅 언어가 조금은 도움이 되겠지만, 현재 Bevy를 쓰는 사람들은 매우 기술적인 성향이 강하고 전업 디자이너가 아닐 때도 많아서 절실한 수요가 크진 않아 보임
      Rust 커뮤니티가 게임 개발에 미칠 영향은 기대하고 언젠가 기여하고 싶지만, 지금은 제시한 이유들 때문에 C++/C# 파이프라인을 유지할 생각임. Rust는 옆에서 제대로 배우고, 도구가 성숙하면 이후 프로젝트에서 고려할 수 있음
      핫 리로드는 컴파일 시간이 감당하기 어려워질 때 쓰는 임시 처방인 경우가 많음. 평균 4초, 전체 재컴파일 20초 정도라면 전체 컴파일을 피하는 방법에 자원을 많이 쓸 필요가 줄어듦
      다만 Rust는 전반적으로 컴파일 시간이 더 길다고 들었기 때문에, 스크립팅이나 핫 리로드 필요가 생각보다 빨리 올 수 있음. 그래도 현재 진행 중인 인디 프로젝트들은 아직 그 장벽에 닿지 않을 가능성이 큼
    • IDE는 꽤 오래전부터 계획돼 있었고, 이번 릴리스 이후 최우선 과제라고 알고 있음
      Bevy 창시자인 Cart는 Bevy가 Rust 우선이어야 한다고 보며, 개인적으로도 동의함. 그렇다고 여러 스크립팅 언어용 플러그인을 만들 수 없다는 뜻은 아니고, 실제로 이미 몇 가지가 있음

  • Bevy 창시자이자 프로젝트 리드임. 무엇이든 질문해도 됨

    • 회사 규모 대비 꽤 큰 WASM 앱을 Bevy로 만들고 있는데, 엔진을 쓰는 경험이 매우 좋았음
      Bevy와 커뮤니티가 훌륭함. 몇 가지 티켓 작업이 필요했는데, 핵심 기여자 중 한 명을 찾아 후원하고 요청을 끝까지 밀어붙이는 일이 아주 쉬웠음. 예를 들면 모프 타깃이 그랬음
      Carter가 정말 중요한 것을 만들고 있고, 그 뒤에 훌륭한 추진력이 있음. Bevy는 웹 배포가 매우 쉽고, 더 많은 사람이 살펴볼 만함. 커뮤니티도 좋고 도움을 구하기도 쉬움
    • 문서가 제한적이라 진입이 꺼려짐. Bevy 책은 몇 분이면 다 읽고, 막혔을 때 참고할 자료가 금방 떨어짐
      문서는 언제 개선될까? 릴리스 노트를 보면 이상적으로는 각 기능마다 여러 페이지의 문서가 있으면 좋겠음. 일이 많다는 건 이해하고, 전체 문서는 안정화 이후에야 가능할 수도 있겠음
    • 취미 게임 개발자로서 새 프로젝트를 시작한다면 Bevy로 할 것 같음. Love와 Godot의 중간쯤을 잘 나눈 느낌이고, Love보다 견고하지만 Godot만큼 초보자 지향은 아닌 듯함
      Bevy는 얼마나 의견이 강한 엔진인가? 기능과 개발자 접근성 사이에서 절충해야 했던 적이 있는지 궁금함
      지금 Bevy에 가장 이상적인 프로젝트는 어떤 종류일까?
    • Rust와 Bevy로 게임을 작성하면 다른 언어 대비 어떤 장단점이 있는지 궁금함. 특히 성능, 안전성, 개발 속도 측면을 듣고 싶음
    • 동적 시스템과 일급 Bevy 스크립팅을 가능하게 하는 기능들은 언제 볼 수 있을까?
      스크립팅 플러그인은 몇 가지 있고 지금은 주로 rhai에 집중하는 듯하지만, 적절한 Bevy 지원이 부족해서 막혀 있는 느낌임
      현재 Bevy의 초점이 Rust 전용 게임이든 아니든 스크립팅 수요는 있고, 이미 서드파티 해법을 찾느라 바쁜 사람들이 있음. 당장 공식 Bevy 스크립팅을 기대하진 않지만, 서드파티 크레이트가 동작할 수 있는 기반은 Bevy가 받아들여야 한다고 봄

  • 글에서는 지연 렌더링이 MSAA를 지원하지 않는다고 하지만, 이는 순진한 구현에서만 맞는 얘기임
    예를 들어 사전 패스에서 복잡한 픽셀의 스텐실 마스크를 만들고, 계층적 조기 스텐실 거부를 사용해 복잡한 픽셀에는 샘플별 패스를, 그렇지 않은 픽셀에는 픽셀별 패스를 실행할 수 있음. SIMD 레인 활용은 완벽하지 않음
    또 복잡한 픽셀 마스크를 처리하는 패스를 두고 (x, y, sample) 좌표 버퍼를 모으면, 이후 단일 하이브리드 픽셀별/샘플별 컴퓨트 셰이더 패스에서 완벽한 SIMD 레인 활용도 가능함

    • 흥미롭다. 예전에 이걸 생각해봤지만 너무 느릴 거라 가정했음. 그 기법으로 출시된 타이틀을 알고 있는지 궁금함

  • 한동안 Bevy로 게임을 만들고 있음. 코드도 볼 수 있고 질문해도 됨
    https://ant.care/
    https://github.com/MeoMix/symbiants
    지금까지의 고충은 UI 시스템이 위젯을 편하게 만들기엔 너무 장황해서 egui로 바꿨지만, 1년 안에는 네이티브 Bevy로 돌아갈 것 같다는 점임. egui에도 큰 제약이 있음
    부모/자식 관계 지원이 많지 않고 ECS가 어느 정도 이를 꺼리는 구조임. 스프라이트에 라벨을 붙이고, 스프라이트를 이동/회전시키면서 라벨은 위치만 따라가고 회전은 따라가지 않게 만드는 일이 예상보다 어려웠음
    세션 간 엔티티 영속화가 기본 지원되지 않음. Entity는 클라이언트 측 고유성을 위한 것이고, 저장된 부모/자식 관계를 쉽게 재생성하는 것도 자동으로 되지 않음
    아직 WASM 병렬성 지원이 없지만, Bevy 아키텍처는 작업 병렬화를 통해 성능 이득을 얻도록 시스템 순서를 유연하게 두려는 설계가 많음
    공간 질의는 ECS 목표와 충돌하는 느낌임. 타입 기준, 즉 엔티티가 Position을 갖는지로 찾기보다 Position 값으로 찾고 싶어지면 질의 엔진과 동기화해야 하는 보조 캐시가 많이 생김
    commands로 월드를 변경하면 성능을 위해 배치 처리되도록 지연되는데, 지연 동작이 많으면 월드를 적극적으로 바꾸는 시스템을 만들기 어렵음. 그래서 apply_deferred를 자주 호출하고, 경쟁 상태를 해결하려고 커스텀 명령을 사용하게 됨
    Android의 WASM, 특히 Pixel 6와 Chrome 조합은 현재 동작하지 않지만 하위 의존성 문제라 Bevy 13에서 고쳐질 예정임
    장점은 Rust 엔진과 Rust 게임 조합이 작업하기 매우 좋고, Rust+WASM도 기술이 발목을 잡는 느낌이 거의 없다는 것임. 머리가 ECS식으로 생각하기 시작하면 되돌아가기 어렵고 매우 유연함. 어쩌면 너무 유연할 정도임
    커뮤니티가 활발해서 문제를 이야기할 사람을 찾기 쉽고, 문서는 많지 않지만 예제는 많음. 미래에 대한 낙관도 크며 개발 속도가 빠르고 릴리스마다 주요 우려를 상당히 진전시킴

    • 참고로 ant.care는 iPhone에서 동작하지 않음. Safari와 Firefox에서 모두 테스트했는데, 웹사이트가 잠시 뒤 무한 루프로 다시 로드됨

  • 릴리스 노트가 훌륭함
    숙련된 게임/엔진 개발자에게는 일부가 너무 입문적일 수 있지만, 그 세계에 늘 있는 사람이 아닌 입장에서는 변경 사항 설명과 주제 해설 사이의 균형이 매우 좋았음

  • Rust로 작성된 게임은 5개인데 게임 엔진은 50개라는 농담을 봤음
    실제로 Bevy로 작성된 게임 목록이 있을까?

  • 모든 프레임워크는 더 기존적인 무언가를 단순하고 깔끔하고 빠르게 구현하겠다고 시작하지만, 화려한 기능들은 부족함
    그러다 기능을 따라잡으면서 똑같이 복잡한 괴물이 되고, 그 순환이 반복됨

    • 소프트웨어 프로젝트 생애주기를 크게 보면 타당하지만, 소프트웨어의 단순성이나 사용 편의성에 대한 어떤 주장에도 그대로 적용될 수 있어서 특별히 유용한 비판으로는 보이지 않음
      결론이 “기능을 추가하는 모든 쉬운 소프트웨어는 망할 운명”처럼 들리는데, 조금 극적임
      Bevy의 아키텍처나 기능 추가 방식에 대해 구체적인 생각이나 우려가 있는지 궁금함. 그런 운명을 피하려고 최선을 다하고 있음
    • 동의하지 않는 건 아니지만, Bevy에는 대부분의 프레임워크에 없는 강점인 모듈성이 있음. 개념만이 아니라 실제로 잘 동작한다고 입증된 모듈성임
      Tiny Glade는 bevy_ecs를 쓰지만 Bevy의 렌더링 크레이트는 전혀 쓰지 않음. 개인적으로도 대체 렌더링 경로, 예를 들면 레이 트레이싱이나 GPU 주도 메시렛+가시성 버퍼 렌더링을 구현하는 작업 중 PR이 몇 개 있는데, Bevy 내부는 거의 바뀌지 않음
      사용자 입장에서도 별로 달라지지 않음. 앱에 FeatureFooPlugin을 추가하고 FooComponent 같은 걸 쓰면 동작함
      개별 크레이트나 플러그인은 비대해질 수 있지만, Bevy 전체는 괜찮을 것임. 사용자는 그런 플러그인을 무시하고 자신에게 더 잘 맞는 다른 것을 쓰면 됨
      또한 이건 게임 엔진임. 정의상 비대하고 복잡한 괴물이며, 어떤 게임에는 쓸모가 있을 수 있으니 온갖 기능을 흡수하게 됨. 핵심은 기능 비대가 사용성에 어떤 영향을 주느냐임. 기능이 1000개 있어도 대부분과 상호작용할 필요가 없다면 전혀 괜찮음
    • 관건은 프로젝트가 API를 단순하고 깔끔하고 빠르게 유지하기 위해 과거와 결별할 의지가 있느냐라고 봄
      하위 호환성을 신경 쓸 필요가 없는 새 프로젝트일수록 쉽다는 말은 맞음. 내가 본 Bevy는 사용자에게 좋은 사용감을 요구하고 API 표면을 줄이려는 문화가 강함. Rust 패키징 덕분일 수도 있지만, 이를 위해 과거와 단절하는 데 꽤 적극적이라 좋게 봄
      cargo가 좋은 점은 Bevy에 의존하기로 해도, 미래 버전이 깨지더라도 움직이는 목표를 쫓을 필요가 없다는 것임. 그냥 자신의 버전에 머물면 됨. 그래도 최신으로 옮기기 쉽게 가이드도 제공함. 적어도 Bevy를 조금 만져본 내 경험은 그랬음

  • 0.10에서 0.11로 올릴 때는 앱에 꽤 많은 변경이 필요했는데, 이번에는 바로 컴파일됐음

  • Bevy는 특히 큰 프로젝트에서 좋아하는 게임 엔진 중 하나임. Asset V2 전처리와 .meta 파일이 매우 유용해 보임
    향후 릴리스의 라이트맵 지원도 기대됨

  • 웹 예제를 보다가 UI 섹션을 봤는데 전부 캔버스 안에서 처리되는 것 같음
    UI를 대신 DOM으로 만들고 WASM에 연결할 수 있을까?

    • 가능하고, 실제로 그렇게 한 경우를 본 적 있음. UI와 Bevy 사이에 정보를 주고받는 방식을 만들어야 함
      Rust, 즉 WASM 쪽에서는 web_sys 같은 방법이 있고, JavaScript 쪽에서는 WASM 함수를 호출하는 방법도 있어서 선택지가 많음
답변달기