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

rename Hyper ECS to MECS

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

2
content/pong/introduction.md
View File

@ -8,7 +8,7 @@ Everyone has played, or at least heard of, Pong. Right? Right...
![pong](/images/pong.png) ![pong](/images/pong.png)
Pong was one of the first video games ever created and as such, it is extremely simple. We're introducing a lot of new concepts with Encompass and the Hyper ECS architecture, so I think it's a good choice to try re-implementing this game in Encompass as an example. Pong was one of the first video games ever created and as such, it is extremely simple. We're introducing a lot of new concepts with Encompass and the MECS architecture, so I think it's a good choice to try re-implementing this game in Encompass as an example.
We'll be developing this with the Encompass/LOVE starter pack. Go ahead and [set that up](/getting_started/case_study_love/) if you haven't already so you can follow along. And please do follow along - you can do it! We'll be developing this with the Encompass/LOVE starter pack. Go ahead and [set that up](/getting_started/case_study_love/) if you haven't already so you can follow along. And please do follow along - you can do it!

8
content/why/architecture/hyper_ecs.md → content/why/architecture/mecs.md
View File

@ -1,10 +1,10 @@
--- ---
title: "Hyper ECS" title: "MECS"
date: 2019-05-21T15:56:13-07:00 date: 2019-05-21T15:56:13-07:00
weight: 30 weight: 30
--- ---
Hyper ECS is a new architecture pattern that attempts to address some common issues with standard ECS. This is the architecture that Encompass implements. MECS is a new architecture pattern that attempts to address some common issues with standard ECS. This is the architecture that Encompass implements.
The core of the architecture is the introduction of a new construct to ECS: the **Message**. The core of the architecture is the introduction of a new construct to ECS: the **Message**.
@ -24,7 +24,7 @@ Now we have our **MotionSystem**. The MotionSystem declares that it Mutates the
You might be wondering: how does the game know which order these systems need to be in? Well... You might be wondering: how does the game know which order these systems need to be in? Well...
**Hyper ECS figures it out for you.** **MECS figures it out for you.**
That's right! With the power of graph theory, we can construct an order for our Systems so that any System which Sends a certain Message runs before any System that Reads the same Message. This means, when you write behavior for your game, you *never* have to specify the order in which your Systems run. You simply write code, and the Systems run in a valid order, every time, without surprising you. That's right! With the power of graph theory, we can construct an order for our Systems so that any System which Sends a certain Message runs before any System that Reads the same Message. This means, when you write behavior for your game, you *never* have to specify the order in which your Systems run. You simply write code, and the Systems run in a valid order, every time, without surprising you.
@ -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. 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. 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.
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 Hyper ECS 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. But once you learn to think in a MECS way, you will be shocked at how flexible and simple your programs become.