요약
Rust 게임 엔진 Bevy 0.20이 셰이더 언어 교체와 BSN 문법 개편, 렌더링 개선을 담아 나왔습니다.
Bevy는 Rust로 만든 데이터 중심 게임 엔진입니다. 이번 판에는 기여자 227명이 보낸 풀 리퀘스트 817개가 들어갔고, 0.19에서 옮겨 오는 이전 안내서도 함께 나왔습니다.
왜 중요한가
- 자체 WGSL 방언을 버리고 WESL 셰이더 언어를 채택해, 기존 셰이더는 모두 옮겨 써야 합니다.
- 실시간 경로 추적(빛의 경로를 계산해 그리는 방식) 렌더러 Solari가 macOS의 Metal에서도 돌아가게 됐습니다.
- 바뀌지 않은 데이터를 건너뛰는 기능이 들어가 GPU 메시 추출이 132배 빨라졌다고 밝혔습니다.
핵심 내용
- 장면을 코드로 적는 BSN 문법에서 장면 참조에 @ 기호를 붙이고, 목록 속 엔티티는 -- 기호로 나누도록 바꿨습니다.
- UI 위젯 모음 Feathers에 색 입력, 드롭다운, 스크롤 목록이 추가됐고 글꼴 크기 기준 단위 em·rem도 생겼습니다.
- 메시 셰이더 초기 지원, 스프라이트용 사용자 정의 머티리얼, CAD식 궤도 카메라도 들어갔습니다.
- 시스템 안에서 난 패닉(프로그램 강제 중단)을 오류로 바꿔 처리할 수 있게 됐습니다.
- 다음 판에서는 .bsn 애셋 형식, 원격 인스펙터, HDR 디스플레이 지원 등을 준비하고 있습니다.
HN 반응
- 렌더러를 기여한 한 개발자가 BSN 문법은 기호가 너무 많고 갈수록 나빠진다고 비판했고, 다른 이용자들도 대체로 공감했습니다.
- 호환성을 깨는 변경이 잦아 상업 제품에는 아직 이르다는 의견과 함께, AI 에이전트로 Bevy 게임을 만든다는 경험담이 여럿 올라왔습니다.
이번 릴리스에는 좋은 것이 많습니다. 저도 렌더링 코드를 일부 기여했는데, 그중 CPU 쪽 렌더러의 작업량을 변경된 엔터티 수에 비례하는 O(n)으로 줄인 작업이 가장 큰데도 릴리스 노트에는 언급되지 않았습니다.
다만 BSN 문법은 좋지 않고 점점 더 나빠지고 있다고 말씀드려야겠습니다. 기호(sigil)가 너무 많고, 목록 요소를 구분하는 데
--를 쓰는 것(!)은 설계가 막다른 길에 몰렸다는 신호입니다. LR(1)이 아니라는 점부터가 설계를 잘못했다는 신호였어야 합니다. 씬 포맷은 에디터를 최우선으로 두고, VCS에서 병합하기 쉬운지를 가장 중요한 기준으로 삼아 다시 설계해야 합니다.설계가 어떻게 지금 모양이 됐는지 궁금해서 찾아봤더니, 이 이슈0에서 여러 절충안을 논의했더라고요. 저는 엔터티와 컴포넌트를 세미콜론과 쉼표를 섞어 구분하는 안이 마음에 들었는데, 뭐 어쩔 수 없죠. 이중 대시에도 곧 익숙해지겠죠.
Bevy에서 하시는 작업을 정말 좋아합니다. 어떤 대형 그래픽·성능 작업을 준비하고 계신지 보려고 PR 목록을 작성자 핸들로 걸러서 자주 보곤 합니다.
안타깝게도 BSN 문법에 대해서는 저도 같은 생각입니다. 결국 절충의 문제이겠지만, 앞으로도 하위 호환을 깨는 변경이 불가능하지는 않을 것 같아서, 다음 몇 번의 릴리스에서 문법을 어떻게 개선할 수 있을지 궁금합니다.
그래도 제가 정말 기대하는 건 이 문법의 자동 포매팅입니다. 문법의 모양과 느낌도 신경 쓰이지만, 코드베이스 전체의 일관성은 그보다 더 중요하거든요.
Dioxus가 rsx!로 이런 걸 하는 방식과 크게 다르지 않습니다. 다만 0.19에서 처음 나왔고 이번 릴리스에서 크게 개선됐죠. 얼마나 쓰이고 자리 잡을지 지켜보는 재미가 있을 겁니다.
그래도 Dioxus는 훨씬 이해하기 쉽고, Leptos와 Yew는 그냥 HTML입니다. 핵심 문제 중 하나는 (a) 에디터용 씬 포맷, (b) SwiftUI 같은 UI용 DSL, (c) 게임 오브젝트를 스폰하는 DSL이 서로 다른 문제라는 점입니다. 이 셋을 한 문법으로 다 덮으려 하면 결국 누구도 제대로 만족시키지 못하는 타협안이 됩니다.
https://taintedcoders.com/ 도 0.20으로 업데이트됐습니다.
제 장난감 프로젝트 https://crates.rugaex.com/ 도 업데이트했어요.
저도 제일 먼저 찾아보는 자료예요.
정말 우연이네요! 저는 몇 년째 심시티나 시티즈: 스카이라인 같은 도시 건설 게임을 직접 만들어 보고 싶다고 생각만 하다가 지난주에 드디어 시작했거든요. 시뮬레이터는 Rust와 Bevy로 만들고 있어요.
최대한 현실적인 도시 시뮬레이터를 만들려고, 경제 모델, 복지, 이민, 사회 정책에 관한 발표된 논문들을 근거로 시뮬레이션의 각 부분을 구동하고, 그걸로 다시 게임을 굴리려고 합니다.
지금까지는 에이전트 팀을 써서 시뮬레이터의 첫 단계들을 만들었는데, 꽤 유망해 보여요!
이렇게 복잡한 게임은 처음 만들어 보는 거라 어디까지 갈지 정말 기대됩니다 :)
이번 소식을 보고 Bevy로 게임을 시작한다는 사람들이 계속 나오는데...다들 "에이전트 팀"이 게임을 만든다고 하네요. :P
하하, 저도 직접 손으로 만들고 싶지만 시간이 없어서요. 이렇게 하면 게임플레이와 시뮬레이터 메커니즘에 집중할 수 있거든요!
"첫 번째 에이전트가 눈살을 찌푸리며 인간이 이기는 방법을 정확히 일러 주는 걸 듣는다. 이 정보를 다음 봇에게 넘겨서 나한테서 승리를 낚아채게 할 셈인가? 이 판을 이기려고 나는 충분히 웃으며 고개를 끄덕여 줬다고."
게임이 아니라 시뮬레이션을 만들고 계신 것 같은데요 :) 게임은 보통 학술 모델을 잔뜩 끌어다 쓸 만큼 현실적이지 않고, 너무 현실적으로 만들려 하면 오히려 재미가 없어지거든요. 이 게임은 다를 수도 있고, 재미있을 수도 있겠죠! 다만 "극사실적으로 만들면 극도로 재미있겠지"라는 흔한 함정은 조심할 만해요. 저도 다른 사람들도 여러 번 빠졌고, 직접 도시 시뮬레이션을 만들 때도 그랬어요 :) 다시 말하지만 기를 꺾으려는 건 아니고, 꼭 해 보세요! 최악의 경우라도 새로운 걸 배우게 되잖아요!
물론이죠!
저는 엔터티와 기본 요소를 제공하는 시뮬레이터 코어를 만들고, 거기에 시뮬레이션 레이어를 제공하는 플러그인을 붙이는 방식으로 접근하고 있어요. 레이어는 전부 선택 사항이고 바꿔 끼울 수도 있어요.
그래서 어느 부분이든 조정하거나, 간단한 버전과 복잡한 버전을 제공하는 건 어렵지 않을 거예요!
그리고 피드백 고맙습니다! 만드신 시뮬레이터는 어딘가에 공개하셨나요?
저도 언젠가 같은 걸 해 보려고 했는데, 시간과 에너지가 도저히 나질 않았어요.
에이전트를 붙여 볼까요? 그러면 이제 그만 생각할 수 있을지도 모르잖아요?
제가 딱 그렇게 하고 있는데, 지금까지는 아주 좋아요!
요즘 재미 삼아 Bevy를 배우고 있는데 정말 즐겁습니다. 호환성을 깨는 변경이 사방에서 계속 들어오지만, 다 중요한 문제를 해결하려는 취지라고 봅니다. 지금 시점에 실제 상용 제품을 걸기에는 아마 아직 덜 성숙했을 겁니다. 저 역시 제품을 출시하는 현실적인 문제보다 멋진 아키텍처에 끌리는 사람이라 이런 말을 하는 겁니다.
버전이 0.2라면 보통 호환성을 깨는 변경이 있을 거라고 예상해야 하고, 상용 프로젝트에 쓸 준비는 안 됐다는 뜻이죠.
Rust 생태계에서는 semver의 "0.x"에 들어 있는 "0"이 별 의미가 없어요 :) 널리 쓰이고 안정적인 프로젝트 중에도 계속 이런 식으로 버전을 매기는 곳이 많거든요.
WESL 개발자입니다. 저희는 Bevy와 함께 훌륭한 셰이딩 언어를 만들고 있고, 정말 즐겁게 작업하고 있습니다. 대규모로 무언가를 만들다 보면 흥미로운 과제가 정말 많아서 저한테는 큰 재미입니다.
언어 서버 wgsl-analyzer와 저희 wesl 컴파일러에 대해 무엇이든 물어보세요. 셰이딩 언어를 더 낫게 만들 아이디어가 있다면 꼭 알려 주세요. 저는 그 생각을 정말 많이 하거든요.
Solari 패스 트레이싱 작업은 정말 인상적이라는 말로도 모자랍니다.
더 알고 싶으시다면, 지난주 Bevy 밋업에서 Jasmine이 이에 대해 훌륭한 입문 발표를 했고 유튜브에 올라와 있습니다.
https://youtube.com/watch?v=V1XJtUOsY2s
저는 주로 Godot을 쓰고 그 선택에 만족하지만, Bevy가 살짝 부러운 점이 하나 있어요. 멀리서 보기에 엔진을 만드는 사람들 상당수가 자신이 기여하는 분야에 대해 주관이 뚜렷하면서 지식도 깊어 보인다는 거예요(이건 Rust 쪽에서 전반적으로 더 흔한 현상일 수도 있다는 인상을 받았어요).
Godot에서는 일단 기능부터 구현하는 데 집중하고, 그다음 여러 릴리스를 거치고 UX를 신경 쓰는 사람들의 손을 몇 번 거친 뒤에야 "다듬어졌다"는 느낌이 드는 경우가 꽤 자주 있거든요.
Bevy 팀은 대단한 일을 하고 있고, 항상 개발이 이어지고 있다는 점이 훌륭합니다. 저는 게임 개발자가 아니지만, 시뮬레이션을 만드는 회사들의 채용 공고에 Bevy가 올라와 있는 걸 보면 흥미롭습니다.
저는 스타크래프트 3가 FPS가 된다는 걸 알고 나서, 스타크래프트 2 같은 실시간 전략 게임을 Bevy로 만들었습니다. 블렌더로 에셋을 만드는 일, 아트를 위한 생성 모델, 그리고 코딩 대부분은 claude fable/opus/sonnet 에이전트 팀에 맡겼습니다. 그래도 Bevy의 설계가 게임의 모양을 잡고 새 기능을 쉽게 추가하는 데 한몫했다고 느낍니다. 에이전트를 백그라운드와 밤새 돌려서 전체를 일주일 만에 만들었고, 결과물은 플레이하기 아주 재미있으며 LAN 모드도 있습니다. 스타크래프트 2만큼 다듬어지고 균형이 잡히진 않았지만 실제로는 견줄 만한 수준이라서, 저로서는 놀라울 따름입니다.
공개돼 있다면 꼭 해 보고 싶어요!
마침 요즘 Bevy와 다른 엔진들을 살펴보고 있었어요. Bevy는 라이브러리를 더 모듈식으로 만들려고 고민한 흔적이 보입니다. 그런데 지금까지는 시작하기조차 정말 어려워요. (빌드조차 못 해 봤습니다)
저는 리눅스, macOS, 윈도 어디서도 그런 적이 없었는데, 어떤 오류가 나오나요?
Bevy는 어느 정도 모듈식이긴 하지만 서로 엮여 있는 부분도 있어요. bevy_ecs만 따로 쓸 수도 있고 다른 것들도 각각 따로 쓸 수 있지만, 상당수는 나머지도 같이 쓴다고 가정하거든요. 그래도 렌더러만 빼고 전부 쓰는 게임이 있는 걸 보면, 어떤 면에서는 모듈식이 맞는 것 같아요.
네, 어떤 부분이 더 강하게 엮여 있는 건 아닌지 궁금했어요. 제가 겪는 문제는 Wayland가 설치되지 않은 시스템에서는 빌드가 아주 어렵다는 거예요(아니면 아예 불가능할 수도 있고요).
Wayland와 X11 둘 다 없는 건가요? 저는 둘 다 겨냥해서(빌드는 하나로 공유하고요) Wayland가 있으면 쓰고 없으면 X11로 기본 설정되게 하는데, 대부분의 경우 잘 되는 것 같거든요.
아니면 둘 다 없는 환경인가요?
아뇨, Wayland만 없어요. 제 시스템은 오래돼서 Wayland가 기본으로 들어 있지 않았고, 그래픽 카드도 지원하지 않아요. 그런데 얼마 전에 libwayland를 설치해서 빌드에 성공했어요. (설치하면 시스템이 망가질까 걱정했는데 지금까지는 괜찮은 것 같아요.)