8 ms·
Great start here and a very compelling intro post. A couple of things I wondered about and didn't see answers to: 1. How ambitious is Bevy as an engine? Do you
by mrec 6y ago
Great start here and a very compelling intro post. A couple of things I wondered about and didn't see answers to:
1. How ambitious is Bevy as an engine? Do you see it as aimed squarely at the casual-game space like ggez, or do you think it could eventually compete with Godot, growing more advanced features like GI? (I appreciate that competing with Unreal is probably, well, Unrealistic for the forseeable future.)
2. You talk a lot about keeping the build light, which is great to hear. Does this extend to deployment too? What kind of binary filesizes are you looking at for a "hello, world" game?
- _cart 6y ago1. I want to be ambitious while also being realistic. AAA studios won't even consider using Bevy until it has more features and has stood the test of time. So in the short term our market is essentially "indies and enthusiasts". I want Bevy to cater to those people, but with an eye toward larger projects. We don't want to design ourselves into a "locally optimal" corner that prevents us from appealing to large studio. That being said, even in the short term I am extremely interested in advanced rendering techniques and will be investing a good portion of my time on adding things like GI and PBR. 2. Small binaries is absolutely something I care about. Last time I checked we could produce a "hello world" game with windowing + rendering thats just a little bit over 1 MB. I think we could probably make that smaller with some effort. edit for some additional clarity: this involved running a post-processing "strip" process on the binary.
- guscost 6y agoAs someone who may be tinkering with a game this decade, one big factor which favors “use prebuilt engine” in my thinking is that some of them abstract away the work required to port between different systems. Is this really a very big hurdle in your opinion? And do you see console ports being part of this engine in the future? The API looks great in any case, and I’ll try it out, at least as a starting point to get back into Rust and ECS. Nice work!
- meheleventyone 6y agoConsole adoption and porting essentially require a game or games that need to be ported. Typically this happens through third party companies for games built on open source projects.
- Thaxll 6y agoYou can't just port something to work on Sony / MS / Nintendo platform, only them manage the toolchain and they just don't usually support things outside of C++ / C#.
- Thaxll 6y agoVideo games don't really care about binary size.
- mrec 6y agoSome don't, some do. Users living out in the sticks with poor satellite connectivity care about binary size. The HTML5 platform, which I see becoming increasingly important as things like wasm and webgpu mature, cares about binary size because you're potentially downloading it every time you play. It's slightly surreal poking about on itch.io where practically every game is 50 MB, even when most of them are simpler than a 4k demo.
- necubi 6y agoI would expect that for most games the vast majority of bytes will be assets (textures, models, sounds, etc.), not code. Even reducing the code size to 0 is unlikely to make much of a difference in the total size.
- mrec 6y agoFor AAA titles, sure, but there's a long tail of indies, game jam entries etc. For something retro-styled like Dwarf Fortress or Baba Is You, I can absolutely believe that asset size is relatively minor compared to e.g. a Unity baseline footprint. Harking back to ancient history for a moment, Frontier: Elite II was a AAA title for its day and was basically all code.
- sitkack 6y agoThe days of all code AAA games is over. Binary sizes are still mostly irrelevant. They matter to you, but they don't matter to the market.
- xwdv 6y agoIs this a game engine dedicated to making games for people living out in the sticks, or a game engine for making some serious games?