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

changing some language

pull/1/head
Evan Hemsley 2020-03-02 00:29:23 -08:00
parent 5d992e257e
commit 19e5835987
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -30,8 +30,8 @@ That's right! With the power of graph theory, we can construct an order for our
Of course, to accomplish this, there are some restrictions that your Systems must follow.
Systems are not allowed to create message cycles. If System A sends Message B, which is read by System B which emits Message C, which is read by System A, then we cannot create a valid ordering of Systems. This is not a flaw in the architecture: A message cycle is simply evidence that you haven't quite thought through what your Systems are doing, and can generally be easily eliminated by the introduction of a new System.
Systems are not allowed to create message cycles. If System A sends Message B, which is read by System B which emits Message C, which is read by System A, then we cannot create a valid ordering of Systems. This is not a flaw in the architecture; a cycle means you have a feedback loop of data which can usually be easily eliminated.
The other restriction involves two separate systems which Write the same Component. They may do so, but they must declare a priority. Obviously, 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.
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.