-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve book, add diagrams #412
Conversation
Ah yeah, I stole your idea @WaDelma 😄 |
When I made a presentation on ECS last year, I needed to explain the relationship and tables did work very well :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not actually sure which part you stole from me :O
I added some edits that made it flow better for me, but be free to ignore any or all of the changes.
(Only really critical thing is that it says that diagram is below even though it's above :P)
book/src/01_intro.md
Outdated
|
||
In fact, an entity does not even own the components; it's just | ||
This is where ECS comes into play: Components are *associated* with entities; you just insert some component, whenever you like. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/you just insert some component,/you can just insert components/
book/src/01_intro.md
Outdated
|
||
In fact, an entity does not even own the components; it's just | ||
This is where ECS comes into play: Components are *associated* with entities; you just insert some component, whenever you like. | ||
One entity may or may not have a certain component. You can see an `Entity` as an ID into component tables, as illustrated in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/component/component associated with it/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I had initially, but then the sentence sounded a bit unnatural and I didn't want to repeat "associated" as it's already used in the line before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm with @torkleyy here, the extra words don't add to comprehension.
book/src/01_intro.md
Outdated
In fact, an entity does not even own the components; it's just | ||
This is where ECS comes into play: Components are *associated* with entities; you just insert some component, whenever you like. | ||
One entity may or may not have a certain component. You can see an `Entity` as an ID into component tables, as illustrated in the | ||
diagram below. We could theoretically store all the components together with the entity, but that would be very inefficient; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/below/above/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the one I'm referring to is below actually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well then you are not referring to this one at all, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I don't think I am.
book/src/01_intro.md
Outdated
|
||
In fact, an entity does not even own the components; it's just | ||
This is where ECS comes into play: Components are *associated* with entities; you just insert some component, whenever you like. | ||
One entity may or may not have a certain component. You can see an `Entity` as an ID into component tables, as illustrated in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be clarification that metaphors tables are referring to database tables? So that a reader unfamiliar with databases wont get confused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was actaually the idea I borrowed from you. I thought simply talking about a table is clear enough.
book/src/01_intro.md
Outdated
Now we're only missing the last character in ECS - the "S" for `System`. Whereas components and entities are purely data, | ||
systems contain all the logic of your application. A system typically iterates over all entities that fulfill specific constraints, | ||
like "has both a force and a mass". Based on this data a system will execute code, e.g. produce a velocity out of the force and the mass. | ||
This is the additional advantage I wanted to point out with the `Player` / `Npc` example; in an ECS, you can simply add attributes and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/is/has/
s/simply add attributes/easily add new attributes to existing entities/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm these changes you suggest here, I don't really get how they improve the text. I think "is" fits better here because I want to regard specifically the advantage, not the way systems work.
As for the second change you propose, I chose "simply" to describe how plain the whole concept it is, yet it allows for such patterns. The difficulty of adding the attribute is not what I wanted to describe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I'd leave the "is"
I'd actually prefer a hybrid for the second request though
"simply add new attributes to entities"
book/src/01_intro.md
Outdated
systems contain all the logic of your application. A system typically iterates over all entities that fulfill specific constraints, | ||
like "has both a force and a mass". Based on this data a system will execute code, e.g. produce a velocity out of the force and the mass. | ||
This is the additional advantage I wanted to point out with the `Player` / `Npc` example; in an ECS, you can simply add attributes and | ||
that's also how you define your behaviour (this is called [data-driven] programming). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/ and that's also how you define your/. Because the systems processing depends on the components associated with an entity this is also the way you define your entities/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion seems a bit wordy and doesn't add any new information imo.
book/src/01_intro.md
Outdated
the data-oriented way, I have to disappoint you; there is none. | ||
ECS libraries are best-suited for creating games; in fact, I've never | ||
heard of anybody using an ECS for something else. | ||
In case you were looking for a general-purpose library for doing it the data-oriented way, I have to disappoint you; there is none. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/is/are/
book/src/06_system_data.md
Outdated
|
||
## Specifying `SystemData` | ||
|
||
As mentioned earlier, `SystemData` is implemented for tuples of up to 26 elements. Should you ever need |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/of //
book/src/06_system_data.md
Outdated
## Specifying `SystemData` | ||
|
||
As mentioned earlier, `SystemData` is implemented for tuples of up to 26 elements. Should you ever need | ||
more, you could even nest these tuples. However, at some point you can't keep track of all the elements anymore. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/you can't/it becomes hard to/
s/ anymore//
book/src/06_system_data.md
Outdated
|
||
As mentioned earlier, `SystemData` is implemented for tuples of up to 26 elements. Should you ever need | ||
more, you could even nest these tuples. However, at some point you can't keep track of all the elements anymore. | ||
That's why you can also create your own `SystemData` bundle using a struct: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw what happens if you try to derive it for enum? I realised you could try to do this after reading this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't work, which variant should it select?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guessed as much :D
r? @WaDelma |
book/src/01_intro.md
Outdated
systems contain all the logic of your application. A system typically iterates over all entities that fulfill specific constraints, | ||
like "has both a force and a mass". Based on this data a system will execute code, e.g. produce a velocity out of the force and the mass. | ||
This is the additional advantage I wanted to point out with the `Player` / `Npc` example; in an ECS, you can simply add new attributes | ||
to entities and that's also how you define your behaviour (this is called [data-driven] programming). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was changing the your here, because for me it sounds like you are talking about coders behaviour, but it's fine.
Ah missed that, thanks! bors r=Xaeroxe,WaDelma |
412: Improve book, add diagrams r=Xaeroxe,WaDelma a=torkleyy Fixes #327 [Rendered](https://torkleyy.github.io/specs/) <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/slide-rs/specs/412) <!-- Reviewable:end --> Co-authored-by: torkleyy <torkleyy@gmail.com>
Build succeeded |
Fixes #327
Rendered
This change is![Reviewable](https://camo.githubusercontent.com/1541c4039185914e83657d3683ec25920c672c6c5c7ab4240ee7bff601adec0b/68747470733a2f2f72657669657761626c652e696f2f7265766965775f627574746f6e2e737667)