Book Editorial Pass: Introduction - #2572
Conversation
|
I think the way you use "quotes" is what most readers would expect italics for ;) |
Co-authored-by: theotherphil <phil.j.ellison@gmail.com> Co-authored-by: Adam__ <67244228+Based-A@users.noreply.github.com>
If you're referring to "everywhere", the point wasn't to stress the word, it was to temper the claim. I think quotes are good for that, but it seems that we're 0/3 on "intention conveyance" here :) |
Co-authored-by: Adam__ <67244228+Based-A@users.noreply.github.com>
mnmaita
left a comment
There was a problem hiding this comment.
Leaving just a few small nits, these are good improvements IMO.
|
|
||
| A **component** is a modular piece of data that can be reused across entities in the world. | ||
| In Bevy, components are "just Rust structs" (or enums). | ||
| In Bevy, components are just normal Rust types that implement the [`Component`] trait: |
There was a problem hiding this comment.
| In Bevy, components are just normal Rust types that implement the [`Component`] trait: | |
| In Bevy, components are just regular Rust types that implement the [`Component`] trait: |
For some reason "regular" sounds better to me here.
| Systems interact with and update the data in the ECS. | ||
| Each system is run every frame by default, and repeats in a loop (specifically, in a [Schedule](@/learn/book/the-game-loop/schedules.md)). | ||
| In Bevy, systems are "just Rust functions". | ||
| In Bevy, systems are normal Rust functions. |
There was a problem hiding this comment.
| In Bevy, systems are normal Rust functions. | |
| In Bevy, systems are regular Rust functions. |
Same here.
| +++ | ||
|
|
||
| **Entities** are the fundamental objects of your game world, whizzing around, storing cameras, being controlled by the player or tracking the state of a button. | ||
| **Entities** are the fundamental objects of your game world: players, cameras, levels, user interfaces ... everything is an entity! |
There was a problem hiding this comment.
| **Entities** are the fundamental objects of your game world: players, cameras, levels, user interfaces ... everything is an entity! | |
| **Entities** are the fundamental objects of your game world: players, cameras, levels, user interfaces... everything is an entity! |
Punctuation looks off like this.
| But start simple, and add in new concepts as you encounter the problems they're solving. | ||
| With a bit of persistence, you'll be flying in no time! | ||
| Learning to take advantage of _everything_ a modern ECS has to offer will take time, but Bevy's ECS is actually extremely approachable! | ||
| Start simple, and only add in new concepts and patterns when there is a problem to solve. The basics are straightforward, and if you are coming from a "traditional" engine, you can start by using the general patterns and structures you are used to. |
There was a problem hiding this comment.
While I do agree 100% with the "start simple" statement, some things aren't really "translatable" from other engines/patterns/structures, so
you can start by using the general patterns and structures you are used to
Feels a bit incomplete. As an example, it's not as straightforward to update some UI text piece "reactively" yet, which is something people might be used to nowadays. Or needing CSS knowledge to do UI. Or non-composable patterns like class inheritance to do the typical "Animal -> Cat" specializations (which we achieve with composability instead). Over time we saw people struggling because they were "fighting" against the architecture, which means these general patterns don't work well sometimes (or simply don't work).
I have no clue what to say here instead though, so you can just ignore this comment if nothing more fitting comes to mind. Maybe something along the lines of "The basics are straightforward and will take you far, and if you come from other engines this book will cover the equivalences..." (but properly written 😅)?
I'm starting my read-through and editorial pass of the Bevy Book. My general priority is to add polish, improve clarity and flow, and simplify where possible.