Hacker News Reader

Comment by _cart | Hacker News Reader

Creator of Bevy here. I just announced Bevy yesterday and the response so far has exceeded my wildest expectations.

I'm happy to answer whatever questions people have!

Awesome work! I love how it feels so easy to make a system (I'm actually digging your crates wondering how the hell did you achieve that Trait Extension).

I just hope that the `Turtles All The Way Down` philosophy won't hinder game devs from supporting scripting language of their choice. Because at some point someone is going to need domain specific language somewhere.

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?

1. 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.

As 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!

Console 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.

You 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#.

Video games don't really care about binary size.

Some 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.

I 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.

For 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.

The 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.

Is this a game engine dedicated to making games for people living out in the sticks, or a game engine for making some serious games?

On a console every 1mb of binary is one less mb for assets.

We ran LTCG on every game I shipped.

When your game is 125GB it does not really matters if your dll is 20MB instead of 30, it was the case 15 years ago now it's a much different story.

It does a bit when you have 8GB of shared memory between the graphics card, OS and your game. Download size isn't the only memory constraint affected by binary size.

I think you might be underestimating the binary size by at least an order of magnitude

You're thinking about on-disk space and not in-memory space which is much smaller.

Sure they do, when targeting consoles and mobile devices.

Their overlords always stress on developer conferences how install size is the number one reason for users to remove applications and games from their devices.

How much control do you have over rendering without having to discard Bevy's renderer and asset server entirely? A big problem I had with Amethyst (and, honestly, other big engines like Unity and Godot) is that you have very little ability to use custom formats that have prebaked visibility, lighting and so forth because there’s no good way to efficiently control how the renderer gets called. You can only convert your scene to their format, usually discarding useful information. I want to use BSP as the level format in my games because I’m familiar with it and it allows for modders to easily create content, but no engine with a pre-built renderer allows you to render them anywhere close to efficiently. This isn’t just being able to have custom file format loaders and render pipelines, you need to be able to have a single vertex buffer while creating a number of index buffers based on various precalculated visibility clusters, and then be able to choose the index buffer to be rendered based on the camera's location.

Hi _cart, creator of Planimeter's Grid Engine (a Lua game engine) here. Congratulations on your phenomenal work! I'm very familiar with the fact that posts like these on HN that help drive adoption, so thanks to adamnemecek as well.

I'm quite excited to give this a try. I'd just point out that I'm seeming to run into errors, even on the examples. I love debugging just as much as the next developer and will probably figure this out, but I thought I would suggest that you get a forum like Stack Exchange or something custom. Most people develop via Google or DuckDuckGo and not being able to Google an error code or make a post is a serious hindrance to development. (Discord is great but not a replacement)

The error that I am currently facing (if you're curious):

EDIT: This is because I was using Rust 1.40 rather than 1.45. Oops.

  $ cargo run --example breakout
     Compiling glam v0.9.3
     Compiling same-file v1.0.6
     Compiling anyhow v1.0.32
     Compiling once_cell v1.4.0
     Compiling adler32 v1.2.0
     Compiling anymap v0.12.1
     Compiling crc32fast v1.2.0
     Compiling remove_dir_all v0.5.3
     Compiling pin-project-internal v0.4.23
  error[E0599]: no method named `map_or` found for type `std::result::Result<std::string::String, std::env::VarError>` in the current scope
   --> /home/myname/.cargo/registry/src/github.com-1ecc6299db9ec823/glam-0.9.3/build.rs:7:10
    |
    7 |         .map_or(false, |cfg| cfg.split(',').find(|&f| f == "sse2").is_some());
    |          ^^^^^^ help: there is a method with a similar name: `map_err`

  error: aborting due to previous error

  For more information about this error, try `rustc --explain E0599`.
  error: could not compile `glam`.
  warning: build failed, waiting for other jobs to finish...
  error: build failed

I hope you don't mind a piece of constructive criticism about the web page but: the syntax coloring scheme you're using makes the comments nearly invisible. Code comments are useful, and therefore should be easily readable, IMHO.

I didn't see anything about networking - is that a feature you intend to include eventually?

Yup! High level and low level networking is definitely on our radar, but it also isn't our immediate priority.

Wow! What great timing. I've been working on CRDTs for the last couple years and realized the structure we're settling on is similar to ECS. Last week, I figured I'd dive into ECS and also scratch my game-making itch by trying out Amethyst. I've had a suspicion that the API could be a bit simpler, and well, you nailed it! After an afternoon of playing around, Bevy has been a pleasure! Really great work!

Congrats! This looks great. The website and the info presented looks very well thought out!

In the features section would really like to see about how Text rendering is handled by Bevy. It is a big feature.

Edit: To clarify, I wanted to know if it uses any known lib (Skia) or technique (signed distance fields) for some fancy text rendering.

Everything is beautiful so far, the website is nice looking, the overview is self-explanitory. If I wasn't so in love with Godot I would use this. I think one thing that would sell this would be an editor like Godot has, it's one of the strongest selling points with Godot for me.

Hey! An editor is definitely on the roadmap. Bevy want's to dogfood here and make the editor using bevy!

That's what I figure, I saw that Bevy does support UIs, which is how Godot makes their own UI, and how RPG In a Box[0] was born from Godot itself (I'm not affiliated with RPG In a Box nor Godot, just someone who is learning Godot). I think it's going to be wonderful to see a spawn of powerful and open source game engines in the coming years.

[0]: https://www.rpginabox.com/

Bevy even mentions Godot as an inspiration for building the editor using Bevy itself. The creator of Bevy has a lot of experience with Godot, so I'd assume we're going to see bits and pieces resembling how Godot works.

I realized that recently, the author is working on a game in Godot as you said. It makes a lot of sense. Godot is a good standard to look up to. I can't wait to see this project as it matures.

For anyone curious this is the game from the author:

https://www.youtube.com/watch?v=FxW4PcX0fa8

It looks like a lot of fun honestly!

The integrated code editor in Godot is actually something I don't like. The text editor doesn't support the usual Mac keyboard shortcuts, scrolling isn't always responsive and it can't be used to view text files such as json files.

I hope that Bevy users won't be forced to use the Bevy editor for coding. VS Code, vim, emacs and other editors have lots of extensions and work well for coding. I'd rather see some kind of project builder UI for Bevy, which would allow using existing code editors.

You're technically allowed to edit code elsewhere I thought? The editor for Godot is there out of convenience. It's also Open Source and I'm sure you could raise issues about these problems. If they're not voiced in the proper channels they might not get resolved.

This is really cool. As someone who doesn't know a lick of Rust I was surprised at how fast I was able to get it installed with the demo running.

The engine really looks awesome and docs are a pleasure to read. Great job!

Reply on news.ycombinator.com