MoonsideGames
/
encompass-cs-docs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

some terminology tweaks
continuous-integration/drone/push Build is passing Details

main
Evan Hemsley 2020-07-20 17:30:09 -07:00
parent 3675db32ea
commit 0681448f1e
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/concepts/component.md
View File

@ -4,7 +4,7 @@ date: 2019-05-22T12:51:29-07:00
weight: 5
---
A Component is a collection of related data.
A Component is a structure of related data.
To define a Component, declare a struct which implements the **IComponent** interface.

6
content/why/architecture/mecs.md
View File

@ -16,11 +16,11 @@ Let's go back to our earlier example.
We have TransformComponent, which contains position and orientation data, and VelocityComponent, which contains an *x* and *y* component for linear motion.
Our MotionDetecterSystem reads each Entity that has both a TransformComponent and a VelocityComponent, and emits a MotionMessage, which contains a reference to the Entity and the *x* and *y* velocity given by the VelocityComponent.
Our MotionSystem reads each Entity that has both a TransformComponent and a VelocityComponent, and emits a MotionMessage, which contains a reference to the Entity and the *x* and *y* velocity given by the VelocityComponent.
We also have a **TeleportSystem** that needs to teleport the character forward a bit. Let's say when the player presses the X button, a TeleportMessage is fired. The TeleportSystem reads this message and emits a MotionMessage in response.
Now we have our **MotionSystem**. The MotionSystem declares that it Mutates the TransformComponent, reads the MotionMessages that apply to each TransformComponent, and applies them simultaneously, adding their *x* and *y* values to the TransformComponent. Voilà! No race conditions! We can re-use similar behaviors easily without re-writing code by consolidating Messages.
Now we have our **MotionSystem**. The MotionSystem declares that it Writes the TransformComponent, reads the MotionMessages that apply to each TransformComponent, and applies them simultaneously, adding their *x* and *y* values to the TransformComponent. Voilà! No race conditions! We can re-use similar behaviors easily without re-writing code by consolidating Messages.
You might be wondering: how does the game know which order these systems need to be in? Well...
@ -34,4 +34,4 @@ Systems are not allowed to create message cycles. If System A sends Message B, w
The other restriction involves two separate systems which Write the same Component. They may do so, but they must declare a priority. If we allowed Systems to Write components willy-nilly, we would introduce the possibility of two Systems changing the same component on the same frame, creating a race condition. If we have two Systems where it makes sense to change the same Component, we can either create a new Message and System to consolidate the changes, or we can declare write priority so that one System's changes always override the other's. This way we can avoid race conditions.
If you are used to programming games in an object-oriented way, you will likely find the pattern counter-intuitive at first. But once you learn to think in a MECS way, you will be shocked at how flexible and simple your programs become.
If you are used to programming games in an object-oriented way, you will likely find the pattern counter-intuitive at first. You will have to completely invert how you think about constructing game objects. But once you learn to think in a MECS way, you will be shocked at how flexible and simple your programs become.