Bevy의 여섯 번째 생일을 맞아 지난 한 해의 주요 성과와 개선점, 그리고 앞으로의 우선순위를 돌아봅니다.
안녕하세요! Bevy의 제작자이자 프로젝트 리드인 @cart입니다. 믿기 어렵지만, Bevy가 이제 _여섯 살_이 되었습니다!
전통에 따라, 이 기회를 빌려 지난 한 해를 돌아보고 미래를 위한 우리의 희망과 꿈을 이야기하겠습니다. 궁금하시다면 Bevy의 첫 번째, 두 번째, 세 번째, 네 번째, 다섯 번째 생일 게시글도 확인해 보세요.
Bevy 개발자와 커뮤니티 구성원 여러분께서도 자신만의 Bevy의 여섯 번째 생일 회고 게시글을 작성하시기를 적극 권합니다. 게시글을 어디에든 게시하고(원한다면 소셜 미디어에도), 여기에 링크해 주세요. 한 달 후 이 글들을 한데 모은 “Bevy 여섯 번째 해 돌아보기” 요약 게시글을 올리겠습니다. 이는 커뮤니티로서 우리의 성과를 축하하고, 개선할 부분을 찾으며, 다음 해의 방향을 조율할 기회입니다.
모르시는 분들을 위해 설명하자면, Bevy는 Rust로 구축된 상쾌할 만큼 단순한 데이터 주도 게임 엔진이자 앱 프레임워크입니다. Bevy는 영원히 무료이며 오픈 소스입니다! GitHub에서 전체 소스 코드를 받을 수 있습니다. 빠른 시작 가이드도 마련되어 있습니다. 커뮤니티가 개발한 플러그인, 크레이트, 게임, 학습 자료 라이브러리는 Bevy Assets에서 확인할 수 있습니다.
이 모든 일은 Bevy Foundation의 관대한 후원자 덕분에 가능합니다. Bevy를 즐기신다면, 부디 우리의 작업을 후원해 주세요! 모든 기부금은 모두를 위한 Bevy 개선에 직접 사용되며, 우리의 야심에 비해 자금은 턱없이 부족합니다.
8월 25일: Bevy Merch
9월 30일: Bevy 0.17
12월 10일: Bevy Metrics
1월 13일: Bevy 0.18
2월 7일: Bevy Jam #7
4월 1일: Bavy Jam #1
6월: Bevy의 crates.io 다운로드가 6,000,000회를 달성했습니다!
6월 19일: Bevy 0.19
8월 10일: Bevy가 여섯 살이 되었습니다!
일관성과 명확성을 위해, 이 숫자들은 일반적인 보고 방식에 맞춰 모두 “절대 합계”로 제시했습니다. 예를 들어, 현재 GitHub 스타는 총 47,529개입니다. 즉 저장소에서 보게 될 숫자입니다. 또한 작년에 보고된 합계도 함께 포함했으므로, 작년 이후 수치 변화를 계산할 수 있습니다.
여기서 같은 말을 반복하지 않으려 항상 노력하지만, Bevy의 첫 번째, 두 번째, 세 번째, 네 번째, 다섯 번째) 생일 게시글에서 말한 것들은 지금도 무척 자랑스럽습니다.
올해 마침내 BSN: Bevy의 차세대 씬 시스템을 도입했습니다:

이는 Bevy 사용성의 거대한 도약이었습니다. 개발자는 템플릿화되고 의존성과 에셋을 인식하는 방식으로, 조합 가능하고 상속 가능하며 상호 연관된 ECS 엔티티 및 컴포넌트 계층을 빠르고 쉽게 스폰할 수 있습니다(일부 엔진에서는 이를 “씬” 대신 “프리팹”이라 부릅니다). 개발자는 bsn! 매크로를 사용해 Rust 코드 안에서 BSN을 조합하거나, 에셋 파일에 정의할 수 있습니다(.bsn 에셋 형식은 곧 Bevy main에 도입될 예정입니다).
BSN은 앞으로의 Bevy UI 이야기에서도 핵심적인 부분입니다. UI 개발자, 특히 엔진 분야 밖의 개발자들은 순수 Rust가 제공할 수 없는 수준의 인체공학성을 기대합니다. BSN 덕분에 Bevy에서 UI를 조합하는 일은 그 어느 때보다 쉬워졌습니다!
fn button() -> impl Scene {
bsn! {
Node { width: px(200), height: px(100) }
on(|press: On<PointerPress>| info!("pressed!"))
Children [
Text("Button")
]
}
}
다른 인기 UI 프레임워크와 달리, BSN은 게임 로직, 범용 앱 로직, UI 로직에 똑같이 유용한 범용 ECS 기반 데이터 계층입니다.
BSN은 Bevy UI + BSN 위에 구축되는 일반적인 Bevy 앱인, 곧 출시될 Bevy Editor에 중추적입니다. Bevy Editor는 시각적 씬 편집기를 통해 BSN 에셋도 _조합_할 것입니다.
현장에서 사람들이 BSN을 즐겨 사용하는 모습을 보니 정말 기쁩니다. Exofactory의 개발자는 스폰 코드를 BSN으로 이식한 뒤 7,364줄의 코드를 줄였습니다. BSN은 저에게 수년간의 프로젝트였으며, 마침내 이로부터 “실제 환경”의 가치를 얻는다는 느낌은 정말 좋습니다.
BSN 세부 사항은 블로그 게시글에 맡기겠습니다. Bevy 개발자에게 지금은 신나는 시기입니다!
Bevy의 UI는 올해 크게 발전했습니다. BSN뿐 아니라, 스타일이 적용된 고수준 위젯의 공통 기반으로 쓰이도록 의도된 행동 전용의 “스타일 없는” 위젯인 “핵심 Bevy UI 위젯”도 도입했습니다. 엔티티에 Button 위젯을 추가하면 버튼 이벤트, 누름 및 호버 상태, 키보드 단축키, 접근성 기능을 갖춘 버튼처럼 동작하기 시작합니다!
fn button() -> impl Scene {
bsn! {
Button
Node { width: px(200), height: px(100) }
on(|activate: On<Activate>| {
info!("Button activated!")
})
}
}
버튼, 체크박스, 라디오 버튼, 목록, 스크롤 영역 / 스크롤바, 슬라이더, 모달 대화상자, 메뉴, 팝오버를 도입했습니다. 또한 마침내 업스트림 텍스트 입력 위젯도 도입했습니다:
이제 Bevy UI는 그라데이션, 방향별 UI 테두리 색상, 텍스트 배경색, 자동 방향 탐색, 취소선, 밑줄, 굵기, 합자 같은 글꼴 변형, 가변 글꼴 속성, 더 나은 글꼴 선택도 지원합니다.
Bevy UI의 기능이 상당히 충실해지기 시작했습니다!
올해 초 Talin의 주도로 Bevy Feathers도 도입했고, 이후 한 해 동안 크게 발전시키고 확장했습니다. Bevy Feathers는 앞서 언급한 “핵심 Bevy UI 위젯”을 기반으로 하는, 의견이 반영된 “개발 도구” 위젯 모음입니다.

ECS 인스펙터, 디버그 메뉴 등과 함께 Bevy Editor를 구축하기 위해 이 위젯들을 사용하고 있습니다.
올해는 렌더러 작업으로 _가득_했습니다. Jasmine이 주도한 실험적 실시간 레이트레이싱 렌더러 Solari를 도입하고 발전시켰습니다:

GPU 주도 렌더링에는 정말 거대한 한 해였습니다(@pcwalton 주도). 현대 하드웨어에서 Bevy는 이제 거대한 씬을 처리하며 수백만 개의 엔티티를 플레이 가능한 프레임레이트로 그릴 수 있습니다. 새 bevy_city 예제는 훌륭한 실제 테스트입니다. 기본 설정으로 움직이는 자동차를 포함해 55,000개의 엔티티로 이루어진 도시를 절차적으로 생성하며, 60fps로 렌더링할 수 있습니다! 이를 위해 특별한 “성능” API는 필요하지 않고, 표준의 사용하기 쉬운 데이터 주도 Bevy API만 필요합니다.

“렌더러 통합” 작업도 도입하기 시작했습니다. Bevy의 3D 렌더링은 현재 상당히 발전했으며, 2D 렌더러가 동일한 인프라를 공유하고 우리가 해 온 모든 작업의 혜택을 얻기를 바랍니다.
며칠 전, 자체 제작한 WGSL 방언에서 벗어나 WESL 셰이더를 완전히 채택했습니다. WESL은 WGSL을 확장해 모듈 / 임포트와 일급 조건부 컴파일을 지원합니다. 특수한 설정 없이 Rust 툴체인에서 “기본적으로” 빌드되며, “어디에나” 배포할 수 있습니다. WESL 팀과 긴밀히 협력하여 명세를 다듬고 Bevy에 훌륭히 맞도록 보장하고 있습니다.
import package::{color::palette, shape::star};
import lygia::{draw::fill::fill, generative::snoise::snoise2};
import env::u;
@fragment
fn main(@builtin(position) pos: vec4f) -> @location(0) vec4f {
let uv = pos.xy / u.resolution;
var sdf = star(pos.xy, u.resolution);
@if(noise) // conditions at runtime or build time
sdf += snoise2(uv * 8.0 + u.time) * 0.15;
let shape = fill(sdf, 0.6);
return vec4f(palette(uv, u.time) * shape, shape);
}
현재의 기본 구현은 기존 Bevy 셰이더 경험보다 눈에 띄게 개선되었지만, 이는 시작일 뿐입니다. 제네릭 같은 기능을 구축 중이며, 이를 통해 고수준 Bevy 머티리얼 셰이더를 현재보다 훨씬 쉽게 접근할 수 있게 될 것입니다. 쉬운 작업은 쉽게 만들되, 이것저것 만져 보는 사람들에게서 세부 사항을 숨기지 않는, 독특한 “모든 세계의 장점”을 갖춘 일관된 구현을 목표로 합니다(전형적인 Bevy 방식입니다).
수많은 렌더러 기능도 도입했습니다. 가상 지오메트리(“nanite”) 구현에는 BVH 컬링이 추가되었고, DLSS 지원, 접촉 그림자, 물리 기반 화면 공간 반사, 직사각형 영역 조명, 라이트 텍스처, 실시간 필터링 환경 맵을 도입했으며, 대기 렌더링을 대폭 개선하고, 한동안 우리를 괴롭힌 “PBR 렌더링의 특이한 문제”도 수정했습니다.
올해도 업스트림 Bevy Editor의 토대를 계속 다졌습니다. 이와 동시에 @jbuehler23가 이끄는 Bevy 커뮤니티 구성원들은 이 토대(BSN, Bevy Remote Protocol, Bevy UI, Bevy Feathers)를 사용하여 Jackdaw라는 기능적인 Bevy Editor 프로토타입을 구축하기 시작했습니다. Jackdaw는 위험할 정도로 기능이 충실해지고 있습니다:
이미 시각적 BSN 씬 편집기, ECS 검사, 실행 취소/다시 실행, 동적 플러그인 / 확장 로딩 시스템, 머티리얼 시스템, 지형 편집, 프로젝트 관리자 / 생성기, 지오메트리 편집 도구를 갖추고 있습니다.
이들은 영역을 훌륭히 탐색하고 실제로 Bevy의 토대를 사용해 보았습니다. Assets as Entities와 .bsn 에셋 지원처럼 업스트림에 몇 가지 토대 요소를 더 도입하면, Bevy Editor 워킹 그룹을 시작할 것입니다. 그곳에서 저는 업스트림 Bevy Editor 개발을 이끄는 데 집중하고, Jackdaw 개발자들과 협력해 Jackdaw의 최선의 아이디어를 취하여 마침내 이번에는 정말로 Bevy의 공식 편집기를 만들 계획입니다.
게임 엔진에서 성능, 컴파일 시간, 바이너리 크기 회귀를 추적하는 일은 매우 중요합니다. 역사적으로 우리는 필요에 따라 이를 수동으로 처리했습니다. 관대한 후원자와 François의 노력 덕분에, 모든 Bevy 커밋에서 실행되며 시간에 따른 Bevy 런타임 성능, 컴파일 시간, 바이너리 크기를 추적하는 자동화된 메트릭 시스템 Bevy Metrics를 도입했습니다. 이는 이미 수많은 회귀를 포착하는 데 도움이 되었고, 앞으로 핵심 인프라가 될 것입니다.

Bevy 개발은 매우 “즉흥적”입니다. 각 개인은 원할 때 원하는 작업을 합니다. 프로젝트에서 현재 무슨 일이 진행 중인지, 우리의 우선순위가 무엇인지와 무엇이 아닌지, 프로젝트 리더십이 현재 어디에 관심을 집중하는지를 추적하기가 역사적으로 어려웠습니다. 이 때문에 기여자들이 무언가를 만드는 데 몇 달을 보낸 뒤 “잘못된” 것을 만들었거나 프로젝트 리더십이 기여자의 노력을 업스트림으로 이끌기 위해 필요한 관심을 줄 시간이 없어서 막히는 등, 불필요한 긴장이 많이 생겼습니다. 또한 Bevy 커뮤니티 구성원과 Bevy에 관심 있는 사람들은 흔히 “로드맵”을 요청했고, 우리는 “없다”, “여기서는 그렇게 하지 않는다”고 답했습니다.
올해 저는 가벼운 Bevy 프로젝트 목표 시스템을 만들고 시행했습니다. 이 시스템은 작업의 우선순위를 정하고 함께 협력하는 데 필요한 도구를 제공하는 것을 목표로 합니다(자세한 내용은 기여자 가이드를 확인하세요). 커뮤니티는 새 목표를 제안할 수 있고, 매주 이 제안을 논의하여 승인, 거부, 연기 여부를 결정합니다. 또한 프로젝트 리더십 구성원인 프로젝트 리드인 저, SME(주제 전문가), 메인테이너는 목표에 인력을 “배정”할 수 있습니다. 이는 그 목표가 “신속 처리”되고 즉각적인 관심과 관리가 주어질 것이라는 신호를 커뮤니티에 보냅니다.
이를 통해 리더십은 역량을 솔직하게 드러낼 수 있고(모든 일에 한꺼번에 인력을 배정할 수는 없습니다), 우선순위도 솔직하게 드러낼 수 있습니다(반드시 집중해야 할 일이 있고, 집중해서는 안 될 일도 있습니다).
이는 특히 “로드맵”이 아닙니다. 미래 단계의 순서를 미리 의미 있게 계획하는 것이 아닙니다. 단지 현재 상태를 소통하는 것입니다. 또한 이는 _권위적인 명령_도 아닙니다. Bevy 커뮤니티는 여전히 원할 때 원하는 것을 자유롭게 만들 수 있습니다. 다만 이제는 집단적으로 방향을 정하고 협업에 필요한 기여 진입로와 인프라를 만들 방법이 생겼습니다(예: 워킹 그룹).
저는 개인적으로 목표, 특히 현재 형태에 매우 만족하며, 이것이 우리 작업 흐름에 빠져 있던 중요한 요소였다고 믿습니다. 다만 도입 과정은 마땅히 그랬어야 했던 만큼 완벽하게 순조롭지는 않았습니다(다음 절에서 이야기하겠습니다).
올해는 흥미로운 Steam 출시작, 데모, 비게임 앱을 포함해 새롭게 Bevy를 사용하는 사례가 매우 많았습니다.
bevy_awesome_prod에는 더 많은 멋진 프로젝트가 있습니다!
Bevy 프로젝트 목표의 초기 도입과 설명은 “독재적”으로 느껴지게 표현되었기에, 커뮤니티에 일부 타당한 우려와 불안을 낳았습니다. 이 시스템의 제 목표 중 하나는 “경계”를 세우는 것이었습니다. 역사적으로 우리의 프로세스와 그 부재는 “먼저 만들고, 관심을 얻을 때까지 요구하라”는 문화를 자연스레 만들었습니다. 리더십은 문 앞에 도착한 무엇이든 업스트림으로 이끄느라 우선순위에서 계속 벗어났고, 그 결과 Bevy Editor가 우선순위라고 계속해서 약속하면서도 아주, 아주 여러 해 동안 실현되지 않는 상황이 생겼습니다. 그 특정 사례는 복잡하고 다차원적인 문제이지만, 임의의 관련 없는 작업을 업스트림화하는 일에 우선순위를 둔 것이 문제의 큰 부분이었습니다.
이 문화는 여러 방식으로 독성을 키웠습니다. Bevy에 _필요하다_고 강하게 믿은 작업에서 저를 멀어지게 하는 새로운, 아주 멋진 일이 문 앞에 도착할 때마다 저는 분노를 느꼈습니다. 기여자들은 자신의 작업이 무기한 검토되지 않을 때 번아웃과 배신감을 느꼈습니다. BSN 같은 핵심 토대 요소가 수년간 지연되자 더 넓은 커뮤니티는 환멸을 느꼈습니다(그 특정 사례도 다차원적입니다. 제 작업을 수년 전에 공개적으로 추진하고, 혼자 천천히 다듬는 대신 공개적인 커뮤니티 개발을 받아들일 수도 있었습니다).
이는 근본적으로 _소통_의 문제였습니다. 프로젝트 리더십에게는 하루에 쓸 수 있는 시간이 한정되어 있습니다. 우리는 그 시간을 어떻게 쓸지 선택할 권리와 책임이 있습니다. 프로젝트에 절실히 필요했던 것은 이를 소통할 방법이었습니다.
프로젝트 목표는 처음에 그 점에 초점을 맞춘 방식으로 구성되었습니다. “정렬”되거나 “우선순위가 매겨진” 작업이 아닌 작업이 수행되는 것을 막는 데 말입니다. 워킹 그룹은 현재 리더십이 “인력을 배정한” 노력에 대해서만 만들 수 있었습니다. 목표는 “인력이 배정된” 경우에만 “활성” 상태였고, “인력이 배정되지 않은” 목표는 “비활성” 상태였습니다. 이런 종류의 우선순위화가 어느 정도 필요하다고 생각하지만, 이는 서투르고 Bevy의 “유기적 개발 문화”를 제대로 존중하지 못했습니다.
우리는 아주 최근에 더 느슨한 접근법을 채택했습니다. 이제 상태는 “활성”과 “비활성”이 아니라 “인력 배정됨”과 “인력 배정되지 않음”입니다. 현재 인력이 배정되지 않았더라도 어떤 “승인된” 목표에 대해서든 워킹 그룹을 구성할 수 있습니다. 이것이 올바른 균형이라고 믿습니다. 커뮤니티는 승인된 무엇이든 제안하고 협력할 수 있습니다. 필요한 중앙화된 협업 인프라(워킹 그룹)를 제공할 수 있고, 우리와 함께하거나 우리 없이도 진전을 만들 수 있습니다. 그러나 “인력 배정”은 우리가 어디에 초점을 맞추는지 커뮤니티에 알리는 신호로서 여전히 역할을 하므로, 커뮤니티가 그에 맞춰 기대를 설정할 수 있습니다.
AI는 올해 Bevy 커뮤니티의 지속적인 스트레스 요인이었습니다. 올해 엄격한 “AI 금지” 정책을 채택했으며, 많은 문제를 해결했지만 다른 많은 문제도 만들었습니다(독성적인 마녀사냥 조장, 메인테이너에게 거짓말할 유인 제공, 어렵거나 불가능한 집행 등을 포함합니다). 우리는 모두 매우 지쳤고 감정적으로 예민해졌습니다.
@alice-i-cecile은 저를 포함한 커뮤니티와 함께 새 정책 초안을 작성하고 있습니다. 저 자신도 꽤 AI에 반대하는 편입니다. 개발 작업 흐름에서 사용하지 않고(저는 제 기술을 사랑하며 이를 외주화하는 데 큰 관심이 없습니다), 유능한 엔진 개발자 커뮤니티를 조성한다는 관점에서 AI 도입의 위험을 깊이 우려합니다. 새 정책은 우리 커뮤니티에 알맞은 균형을 이룬다고 생각합니다. 아직 새 정책을 공개하지 않았고(여전히 작업 중입니다), 현재 더 넓은 공개 대화, 즉 Bevy 커뮤니티 밖의 대화를 시작할 생각도 없습니다. 그러나 곧 올바른 궤도에 오를 것이라 낙관합니다.
작년에 이를 개선하기 위한 세 가지 경로를 제시했습니다. 적극적인 모금, 수익 창출 서비스, 엔진을 계속 구축하여 매력을 높이고 도달 범위를 넓히는 것입니다. 올해 처음 두 가지는 의미 있게 수행하지 못했습니다. 대신 올해 Bevy의 토대를 구축하고 곁길로 새는 것을 피하는 데 크게 집중했고, 더 많은 개발자와 자금을 끌어들일 역량과 우아함의 수준에 가까워지고 있다고 생각합니다. Bevy 기술 플랫폼이 어느 정도 완성도에 이르기 전에는 제가 적극적 모금이나 수익 창출 서비스에 집중해서는 _안 된다_고 생각합니다. 그것이 제 역량이 있는 영역이며, 퍼즐의 핵심 조각들이 아직 진행 중인 상태에서는 적극적으로 알리는 일이 특별히 편하지 않기 때문입니다.
더 빠르게 나아가려면 전임 개발자가 더 필요합니다. 기존 개발자들이 떠나지 않도록 장려하는 기본 급여를 지급해야 합니다(현재 지급하는 기본 급여 대비 약 54%의 급여 삭감 대신). 부디도와주세요!
조직과 리더가 실수에서 배우는 일은 중요합니다. 다음은 작년 생일 게시글의 “개선 영역” 목록과, 올해 이를 어떻게 다뤘다고 생각하는지입니다:
BSN은 더 빨리 도입되었어야 했습니다
여기서의 핵심 문제, 즉 @cart가 제 눈에 “충분히 좋아질” 때까지 장기간 고립되어 개발하는 일은 대체로 해결되었다고 믿습니다. 지난 한 해 BSN 개발은 반복적이고 공개적으로 이루어졌습니다. Assets as Entities 작업도 공개된 환경에서 반복적으로 발전했습니다. 한동안 하고 싶었던 엔진 여러 부분에 작지만 목표가 뚜렷하고 가치가 높은 변경을 많이 했으며, 커뮤니티와 즉각적인 피드백 순환을 갖췄습니다. 사람들이 제가 현재 작업하는 것을 추적할 수 있도록 매일 상태 업데이트를 합니다. 예전 패턴으로 돌아가지 않도록 최선을 다하겠습니다. 최근의 전개에 꽤 만족하고 있습니다. 이에 대해 다른 모든 분들이 어떻게 생각하는지 궁금합니다!
Bevy Foundation은 자금이 부족합니다
위에서 이야기했습니다. 이는 여전히 문제입니다! Bevy Foundation에 기부하여 우리의 작업을 후원해 주세요!
작년 생일 게시글에서 다음 해를 위한 몇 가지 예측을 했습니다. 제가 얼마나 맞췄는지 봅시다!
BSN
BSN을 도입했습니다. 성공입니다!
반응성 생태계
Bevy에는 반응성 생태계가 있습니다! bevy_reactor 같은 BSN 반응형 구현과 Jasmine의 다듬어지지 않은 빠른 반응형 BSN 실험이 있습니다. 또한 “함수형 반응형 프로그래밍”을 사용해 자체적인 비BSN이지만 Bevy 네이티브 데이터 API를 만드는 haalka도 있습니다.
아직 올바른 업스트림 구현으로 수렴하지는 않았지만, Bevy UI, Feathers, BSN 모두 상당히 탄탄한 위치에 있으므로 올해 안에 이루어질 것으로 예상합니다.
핵심 / 표준 UI 위젯
이를 도입했습니다! 또 하나의 승리입니다!
기본 편집기 플랫폼
업스트림에 기본 편집기 플랫폼을 도입하지는 못했습니다. 위에서 말했듯 토대에서는 탄탄한 진전을 이루었습니다. ECS Inspector 워킹 그룹에는 기능적인 인스펙터 구현이 있습니다. Jackdaw는 편집기 플랫폼의 모습을 성공적으로 프로토타이핑했습니다. 올해 목표를 향해 의미 있고, 구체적이며, 사용할 수 있는 진전을 이루었습니다. 저는 여러 해 동안 “내년에 Bevy Editor”라고 말해 왔습니다. 지금 가까웠다고 말하는 저를 믿지 않으셔도 됩니다. 하지만 이제 씬 시스템, UI 시스템, 편집기 위젯 라이브러리, 에셋 시스템, 원격 프로토콜, 디자인 언어와 목업, 검증된 동적 플러그인 로딩 모델, 그리고 매우 기능적인 프로토타입을 갖추었습니다. 또한 마침내 편집기 진전을 가로막을 선행 조건이 바닥난 프로젝트 리드도 있습니다(음, Assets as Entities 이후이지만, 이제 마무리 단계입니다). 우리는 착공하기에 좋은 위치에 있습니다. 이것이 우리의, 그리고 저의 다음이자 가장 우선하는 과제입니다. 해낼 수 있습니다!
Bevy 커뮤니티와 저는 Bevy 개발에 비교적 유기적이고 반응적인 접근법을 취합니다. 실제 개발 방식이 그렇지 않은데 긴 “계획” 목록을 제시하는 일은 의미가 없습니다.
그렇긴 해도, 다음은 Bevy의 다음 해에 대한 제 개인적인 희망, 꿈, 우선순위입니다:
@andriyDev와 함께 현재 작업 중인 내용입니다. 복잡하고 중첩되며 템플릿화된 에셋을 BSN + Bevy Editor에서 표현할 수 있어야 하므로, 이는 편집기 이야기의 핵심 요소입니다. BSN은 복잡하고 중첩되며 템플릿화된 _엔티티_를 표현하고, Assets as Entities가 이를 가능하게 할 것입니다. 또한 에셋 시스템 내부를 크게 단순화하고, 에셋 이벤트를 “관찰 가능 / 반응 가능”하게 하며, 일반적으로 에셋이 나머지 Bevy와 더 일관되게 느껴지게 할 것입니다..bsn 에셋 형식: BSN은 bsn! 매크로 지원과 함께 도입되었습니다. 씬 에셋을 위한 “런타임” 지원도 함께 도입되었습니다. 하지만 실제 .bsn 에셋 로더는 도입되지 않았습니다. Bevy Editor는 .bsn 파일을 생성할 것이므로 이는 반드시 필요한 요소입니다. 이를 위한 초안 PR이 있으나 약간의 작업이 필요합니다. 곧 도입할 수 있을 것입니다!@tychedelia는 이 분야에 큰 계획을 갖고 있으며, 이것이 어디에 도달할지 정말 기대됩니다. WESL은 탄탄한 시작이며, 특히 발전하면서 이 작업의 토대가 되어야 합니다.진행 중인 다른 작업도 많지만, 제 개인적인 우선순위를 전달하기 위해 올해도 이를 매우 집중된 상태로 유지하려 합니다.
마지막으로, Bevy 커뮤니티 구성원은 자신만의 Bevy 생일 블로그 게시글을 작성해 주시기 바랍니다. 여기에 제출하세요!
이 중 무엇이든 여러분을 설레게 한다면, 여러분의 도움을 정말 환영합니다! GitHub에서 코드를 확인하고 Bevy 커뮤니티에 참여해 보세요.
또한 이 엄청나게 야심 찬 프로젝트를 계속 구축하고 이끌 수 있도록 부디 Bevy Foundation에 기부하는 것을 고려해 주세요. 자금이 많을수록 Bevy 개발을 더 확장할 수 있습니다!
Bevy와 함께할 더 많은 해를 위하여!
이 게시글의 귀여운 Bevy 새들은 Ed Duck의 유쾌한 Bevy 새 디자인에서 큰 영감을 받았습니다