6 ms·
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 peop
by _cart 6y ago
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!
- giancarlostoro 6y agoEverything 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.
- GabLotus 6y agoHey! An editor is definitely on the roadmap. Bevy want's to dogfood here and make the editor using bevy!
- giancarlostoro 6y agoThat'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/ https://www.rpginabox.com/
- Xevi 6y agoBevy 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.
- giancarlostoro 6y agoI 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 https://www.youtube.com/watch?v=FxW4PcX0fa8 It looks like a lot of fun honestly!
- gardaani 6y agoThe 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.
- giancarlostoro 6y agoYou'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.
- mrec 6y agoGreat 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 ago
- deleted 6y ago[deleted]
- andrewmcwatters 6y agoHi _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.
- mhaberl 6y agoThe engine really looks awesome and docs are a pleasure to read. Great job!
- Tossrock 6y agoI didn't see anything about networking - is that a feature you intend to include eventually?
- _cart 6y agoYup! High level and low level networking is definitely on our radar, but it also isn't our immediate priority.
- valand 6y agoAwesome 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.
- jeffpeterson 6y agoWow! 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!
- dingoegret 6y agoYou presented your thing very very well. I expected to to just take a glance at this, as I'm not interested in game engines, but ended up reading the whole thing. Very well done!
- doodpants 6y agoI 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.
- srikz 6y agoCongrats! 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.
- Lambdanaut 6y agoThis 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.
- 8jy89hui 6y agoI'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
- nonsince 6y agoHow 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.