Preface: The ECS model
ECS is a software architectural pattern used commonly in video game development. It is a data-oriented approach to game development that creates a clean break between data and logic. It does this through the separation of Entities, Components, and Systems:
- Entities are the basic units of a game, and they can have any number of components. In a typical MUD implementation each entity is assigned a unique 32 byte identifier that is used as a key to the component tables (see next item).
- Components are small pieces of data that define an entity's behavior (such as position or health). In a typical MUD implementation components are implemented as tables. The table key is the entity identifier, and the value is the data that defines an aspect of the entity such as position.
- Systems are functions responsible for updating the game state and performing operations on entities and their components.
This is what the game needs to support:
- Create a 2D map with three types of terrain: none, long grass, and boulders.
- Long grass randomly generates encounters with Emojimon.
- Boulders prevent movement.
- Allow players to spawn in and move around the map.
- Allow players to either capture Emojimon or flee during an encounter.
You'll notice that in the scope above there are a few key interactions that we need to account for. Let's use a basic one to begin—the interaction between a player moving and a boulder blocking its movement.
In the ECS model both the player and the boulder can be thought of as entities, both of which have components that give it certain properties. For example, the player may have a
movable component and the boulder an
In a vacuum these components don't do anything, they are just data (in this example, booleans). However, when we bring a system into context—the
MoveSystem—this allows us to operate on an entity’s
position component to move them. It would also have the logic to know that
position cannot be moved onto a spot on the grid in which an entity with
obstruction is present.
There is one last concept to understand before we begin—how to actually implement the ECS model using MUD and its mental models.
In MUD there are tables instead of components (MUD is a general database protocol, not specific to onchain games).
However, for the sake of this tutorial, these can be mostly thought of interchangeably.
To apply the ECS model for the example above you'd use
bytes32 as an entity identifier, and create both a
movable table and an
obstruction table, both of type
bool (for boolean values).
You would then create a system,
MoveSystem.sol, and write up the logic required to interact with the tables (i.e. components) accordingly.
That is all that is required! After this is done, simply call the systems from the client and vóila—you have movement.
That's enough theory and abstraction, though. Let's dive into it.