Mirrors/bevy
2
0
Fork 0
mirror of https://github.com/bevyengine/bevy synced 2024-11-10 07:04:33 +00:00
Code Issues Projects Releases Packages Wiki Activity

add move roadmap, readme, and faq to the bevy website

Browse source
This commit is contained in:
Carter Anderson 2020-04-04 21:02:31 -07:00
parent f089df3a49
commit 5b83698738
3 changed files with 17 additions and 111 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

77
README.md
View file

@ -9,66 +9,40 @@ Bevy is a modern data-driven game engine built in Rust
## WARNING
Bevy is still in the _very_ stages of development. APIs can and will change. Important features are missing. Documentation is non-existent. Please don't build any serious projects in Bevy unless you are prepared to be broken by api changes constantly.
Bevy is still in the _very_ early stages of development. APIs can and will change. Important features are missing. Documentation is non-existent. Please don't build any serious projects in Bevy unless you are prepared to be broken by api changes constantly.
## Design Goals
* Provide a first class user-experience for both 2D and 3D games.
* Easy for newbies to pick up, but infinitely flexible for power users.
* Fast iterative compile times. Ideally less than 1 second for small to medium sized projects.
* Data-first game development using ECS (Entity Component Systems)
* Data-first game development using ECS (Entity Component System)
* High performance and parallel architecture
* Use the latest and greatest rendering technologies and techniques
## Features
## About
* Cross Platform: Windows, MacOS, Linux
* Modern Renderer
* Multiple Backends: Vulkan, DirectX 11/12, Metal
* Modern and flexible low level "Render Graph" api
* Easy to use high level defaults for beginners
* Experts can create their own Render Graphs or modify the defaults
* Powerful data-driven shader system
* Define your shaders in either GLSL or SPIR-V
* Automatically generates pipelines for shaders using SPIR-V reflection
* Easily and efficiently bind ECS component data to shader uniforms
* Use component data to define macros in shaders and automatically recompile them if the shader has changed
* Expressive UI System
* Fast iterative compile times
* the example projects have less than 1 second iterative compiles
* Dynamically load plugins at runtime
* "script" your game in Rust or extend the engine with new features
* **[Features](https://bevyengine.org/learn/book/introduction/features):** A quick overview of Bevy's features.
* **[Roadmap](https://bevyengine.org/learn/book/contributing/roadmap):** The Bevy team's development plan.
## Planned Features
## Docs
See our [ROADMAP.md](ROADMAP.md) for the current list of planned features.
* **[The Bevy Book](https://bevyengine.org/learn/book):** Bevy's official documentation. The best place to start learning Bevy.
* **[Bevy Rust API Docs](https://docs.rs/bevy):** Bevy's Rust API docs, which are automatically generated from the doc comments in this repo.
## Getting Started
We recommend checking out [The Bevy Book](https://bevyengine.org/learn/book) for a full tutorial. You can quickly try out the [examples](/examples) by cloning this repo and running the following command:
```sh
# Runs the "scene" example
cargo run --example scene --release
```
### Nightly Compiler
Bevy requires nightly rust right now. It currently uses [specialization](https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md) features, which are unstable. If specialization goes stable soon then we can go back to a stable compiler. In the meantime, we will try our best to remove specialization usage so we can go back to stable.
### Examples:
```
cargo run --example simple
```
### Fast Compiles
* Bevy can be built using default configuration (ex: ```cargo build```), but for optimal build times we recommend using a nightly compiler with the following settings:
* LLD Linker: ```-Clink-arg=-fuse-ld=lld```
* LLD will significantly speed up compile times in Bevy, but it doesn't work out of the box on some platforms / os-es.
* See [this issue](https://github.com/rust-lang/rust/issues/39915) and [this issue](https://github.com/rust-gamedev/wg/issues/50) for more information.
* Generic Sharing (nightly only): ```-Zshare-generics=y```
* Most of the generics you will use in Bevy apps are also used by the Bevy engine code. Generic sharing is a nightly feature that lets your Bevy app re-use generics used in Bevy engine.
* Oddly in some cases compiling in release mode can actually reduce iterative compile times with the settings above. In our experience this is true for most of the examples in this project.
* You can set these flags in one of two ways:
* [.cargo/config](https://doc.rust-lang.org/cargo/reference/config.html)
* We have included an example configuration in ```.cargo/config_fast_builds```. Try renaming it to ```.cargo/config``` and see if it works!
* [environment variables](https://doc.rust-lang.org/cargo/reference/environment-variables.html):
* For example, in Bash you would run this command: ```RUSTFLAGS="-Clink-arg=-fuse-ld=lld -Zshare-generics=y" cargo build --release```
## Libraries Used
@ -83,23 +57,4 @@ Bevy is only possible because of the hard work put into these foundational techn
* [spirv-reflect](https://github.com/gwihlidal/spirv-reflect-rs): Reflection API in rust for SPIR-V shader byte code
Additionally, we would like to thank the [Amethyst](https://github.com/amethyst/amethyst), [coffee](https://github.com/hecrj/coffee), [ggez](https://github.com/ggez/ggez), and [Piston](https://github.com/PistonDevelopers/piston) projects for providing solid examples of game engine development in Rust. If you are looking for a game engine to build Rust games in, it is worth considering all of your options. Each engine has different design goals and some will likely resonate with you more than others.
## F.A.Q.
#### Why build Bevy instead of using INSERT_GAME_ENGINE_HERE?
@cart (original creator of Bevy) speaking: I decided to build Bevy after years of contributing code to other engines (ex: Godot). I spent over four years building a game in Godot and I have experience with Unity, Unreal, Three.js, Armory, and Game Maker. I built multiple custom engines using Rust, Go, HTML5, and Java. I have also closely followed the other major players in the Rust gamedev ecosystem, namely [Amethyst](https://github.com/amethyst/amethyst), [coffee](https://github.com/hecrj/coffee), and [Piston](https://github.com/PistonDevelopers/piston). I am currently a senior software engineer at Microsoft which has also affected my opinions of software and what it should be.
These experiences led me to want the following from a game engine:
* It needs to be free and open source with no strings attached. Games are a huge part of our culture and humanity is investing _millions_ of hours into the development of games. Why are we (as game developers / engine developers) continuing to build up the ecosystems of closed-source monopolies that take cuts of our sales and deny us visibility into the tech we use daily? As a community I believe we can do so much better.
* It needs to have fast build/run/test loops, which translates to either scripting languages or fast compile times in native languages. But scripting languages introduce runtime overhead, cognitive load, and a barrier between me and the actual engine, so my preference here is a native language with fast compile times.
* Ideally the engine is written in the same language as games are. I found myself loving engines where game code is written in the same language as engine code. Being able to run an IDE "go to definition" command on a symbol in your game and hop directly into the engine source is an extremely powerful concept. And you don't need to worry about translation layers or lossy abstractions. Also, if an engine's community builds games in the same language as the engine, they are more likely (and able) to contribute back to the engine.
* It needs to be easy to use for common tasks, but it also can't hide the details from you. Many engines are either "easy to use but too high level" or "very low level but difficult to do common tasks in".
* It needs to have an editor. Scene creation is a large part of game development and in many cases visual editors beat code. As a bonus, the editor should be built _in the engine_. Godot uses this approach and it is _so smart_. Doing so [dogfoods](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) the engine's UI system. Improvements to the editor are also often improvements to the engine. And it makes sure your engine is flexible enough to build tooling (and not just games).
* It needs to be data-driven/data-oriented/data-first. ECS is a common way of doing this, but it definitely isn't the only way. These paradigms can make your game faster (cache friendly, easier to parallelize), but they also make common tasks like game state serialization and synchronization delightfully straightforward.
None of the engines on the market _quite_ line up with what I'm looking for. And the changes required to make them meet my requirements are either massive in scope, impossible (closed source), or unwelcome (the things I want aren't what the developers or customers want). On top of that, making new game engines is fun!
Bevy is not trying to out-compete other open-source game engines. As much as possible we should be collaborating and building common foundations. If you are an open source game engine developer and you think a Bevy component would make your engine better, one of your engine's components could make Bevy better, or both, please reach out! Bevy is already benefitting massively from the efforts of the Rust gamedev ecosystem and we would love to pay it forward in whatever way we can.
Additionally, we would like to thank the [Amethyst](https://github.com/amethyst/amethyst), [coffee](https://github.com/hecrj/coffee), [ggez](https://github.com/ggez/ggez), and [Piston](https://github.com/PistonDevelopers/piston) projects for providing solid examples of game engine development in Rust. If you are looking for a Rust game engine, it is worth considering all of your options. Each engine has different design goals and some will likely resonate with you more than others.

49
ROADMAP.md
View file

@ -1,49 +0,0 @@
# Bevy Roadmap
Here is the current list of planned features. All items are sorted in approximate priority order, but actual implementation order will vary based on individual interest and/or funding.
* UI Framework
* Text
* Styling
* Rendering
* Textures
* Physically based rendering
* Skeletal animation
* Add runtime type safety to uniform bindings (and maybe compile time)
* Inject layout set/bindings into shader source so they don't need to be defined in-shader. Specify set / binding indices in resource providers?
* Pull as much logic as possible from wgpu_renderer into a "render orchestrator" struct/trait
* Separate original/uncompiled/no_defs PipelineDescriptor from compiled PipelineDescriptor conceptually
* Try to make Renderer a resource + system
* Docs
* Add doc comments to code
* Add tutorials
* Add feature docs
* Add "template" projects
* Add ```#![deny(warnings, missing_docs)]``` to ensure future contributions meet style/doc standards
* ECS
* Remove as many references to Resources as possible in favor of resolved resource types
* Consider adding Renderer and World to Resources
* Error Handling
* Custom error type?
* Remove as many panics / unwraps as possible
* Input
* Keyboard and mouse events
* Gamepad events
* Assets
* Load GLTF files
* Scene
* Define scene format
* Load scenes from files (likely RON)
* Plugins
* Live plugin reloading
* Editor
* Editor <-> game communication protocol
* Build UI using bevy UI framework
* Consider supporting embedding parts of the editor directly into games
* Physics
* High level physics data types
* Integrate with nphysics
* Platform Support
* Android
* iOS
* Web

2
src/window/winit/mod.rs
View file

@ -40,7 +40,7 @@ pub fn winit_runner(mut app: App) {
&mut create_window_event_reader,
);
log::debug!("Entering render loop");
log::debug!("Entering winit event loop");
event_loop.run(move |event, event_loop, control_flow| {
*control_flow = if cfg!(feature = "metal-auto-capture") {
ControlFlow::Exit