forked from amethyst/amethyst
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added missing changelog link. Made new section for next release and r…
…enamed current to 0.8.0 Update contributing to new guidelines. Updated readme to be more welcoming Adds subtitles to readme Updated features. Updated contributing section of the readme file Added linebreaks to the readme file Fixed language being a _bit_ too strong Removed part comparing it to other engines Writing concepts for the book Fixed bullet points in state.md. Fixed typo Readme changes readme changes Wrote a couple more concept pages. Updated readme again Added the systems concept documentation Fixed intro errors. Added warning in state for overriding the update method not updating world. Completed the world chapter. Added event-channel page. Added warning in resource about fetching component as a resource using defaults english hellooooooooo Added forgotten stuff in system concept doc Added section in component Concept doc for systems (amethyst#6) * Added the systems concept documentation * english hellooooooooo Massive book update! Added tutorial, fixed outdated stuff, added new guidelines. Added dispatcher theory concept doc join join join no more prelude Fixed unclear passages. Testing subtitle links quick fixes Added System::setup Fixing text all around Removed _ in book filenames Added notice for derive default Fixed unclear passages in event channel Added requirement to update tutorial and examples when doing a feature PR Fixed broken links Moved images. Fixed old links Fixed some things in system page s/optionnal/optional/ Addressed reviews Massive book update!
- Loading branch information
1 parent
847bcce
commit 455d5da
Showing
36 changed files
with
1,024 additions
and
77 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,4 @@ | ||
[book] | ||
title = "Amethyst Documentation" | ||
author = "Eyal Kalderon" | ||
author = "Eyal Kalderon, Jojolepro (Joël Lupien), Moxinilian (Théo Degioanni)" | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,59 @@ | ||
# Component | ||
|
||
## What is a `Component`? | ||
|
||
A component is any struct that can be "attached" to an `Entity` (we will cover entity in the next chapter). | ||
|
||
## Usage | ||
|
||
The relationship between an entity and a component closely ressembles the relation between a real-life object and its properties. | ||
|
||
For example, a bottle of water has a shape, a volume, a color and is made of a material(usually plastic). | ||
|
||
In this example, the bottle is the entity, and the properties are components. | ||
|
||
## Creating a component | ||
|
||
Creating a component is easy. | ||
|
||
You declare a struct: | ||
|
||
```rust | ||
pub struct MyComponent{ | ||
some_property: String, | ||
} | ||
``` | ||
|
||
and then you implement the `Component` trait for it. | ||
|
||
```rust,ignore | ||
use amethyst::ecs::{Component, VecStorage}; | ||
impl Component for MyComponent { | ||
type Storage = VecStorage<Self>; | ||
} | ||
``` | ||
|
||
## Storages? | ||
|
||
`Component`s, in contrast with popular belief, should not be stored directly inside of a `Entity`. | ||
|
||
They are instead stored in different types of `Storage`, which all have different performance strategies. | ||
|
||
When implementing `Component` for a type, you have to specify which storage strategy it should use. | ||
|
||
Here's a comparison of the most used ones: | ||
* `DenseVecStorage`: Elements are stored in a contiguous array. No empty space is left between `Component`s, allowing a lowered memory usage. | ||
This is less performant than `VecStorage`. | ||
* `VecStorage`: Elements are stored into a contiguous array. Uses more memory than `DenseVecStorage` but is more performant when you use a `Component` type a lot. | ||
Only use this when you know that a LOT of your entities are going to have that `Component` type. (More than 90%, for example). | ||
* `FlaggedStorage`: Used to keep track of changes of a component. Useful for caching purposes. | ||
|
||
For more information, see the [specs storage reference](https://docs.rs/specs/latest/specs/storage/index.html). | ||
|
||
## Tags | ||
|
||
Components can also be used to "tag" entities. | ||
The usual way to do it is to create an empty struct, and implement `Component` using `NullStorage` as the `Storage` type for it. | ||
Null storage means that it is not going to take memory space to store those components. | ||
|
||
You will learn how to use those tag components in the system chapter. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
# Dispatcher | ||
|
||
## What is a `Dispatcher`? | ||
|
||
Dispatchers are the heart of the ECS infrastructure. They are the executors that decide when the `System`s will be executed so that they don't walk over each other. | ||
|
||
When a dispatcher is created, it is associated with the systems that it will execute. It then generates an execution plan that respects mutability rules while maximizing parallelism. | ||
|
||
## Respecting mutability rules | ||
|
||
When a system wants to access a `Storage` of a resource, they can do so either mutably or immutably. This works just like in Rust: either only one system can request something mutably and no other system can access it, or multiple systems can request something but only immutably. | ||
|
||
The dispatcher looks at all the `SystemData` in the systems and builds execution stages. | ||
|
||
If you want to have the best performance possible, you should prefer immutable over mutable whenever it is possible. (`Read` instead of `Write`, `ReadStorage` instead of `WriteStorage`). | ||
|
||
_Note: Please however keep in mind that `Write` is still preferable to interior mutability, such as `Mutex` or `RwLock` for example. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
# Entity | ||
|
||
## What is an entity? | ||
|
||
An `Entity` is simply a collection of `Component`s. At least conceptually. It represents a single object in your world. | ||
For example, a car could be an entity, with its properties being `Component`s. | ||
|
||
## Creating an entity | ||
|
||
There are two common ways to create entities: | ||
* From a `World` instance. See the relevant chapter in the book. | ||
* From a `System` using `Entities`. See the system chapter in the book. | ||
|
||
## Getting components of an entity | ||
|
||
You can't! Well, at least not directly from an `Entity` instance. | ||
As mentioned in the component book page, `Component`s are not directly attached to entities; they are inserted into storages. | ||
|
||
`Storage` access and modification will be covered in the resource, world and system sections of the book. | ||
|
Oops, something went wrong.