Preface: the ECS model

Preface: The ECS model

What is ECS?

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.
  • Components are small pieces of data that define an entity's behavior (such as position or health).
    • (We are currently working on an ECS plugin to make the concept of components more explicit in Obelisk, but for now, components on the contract side will be implemented as schemas.)
  • Systems are functions responsible for updating the game state and performing operations on entities and their components.

Using ECS in Constantinople

We will be using ECS mental models in conjunction with Obelisk to bring Constantinople to life. Before we get into the specifics of this, let's lay out the functionality of what we're about to build:

Scope of this project

  • Create a 2D map with three types of terrain: none, long grass, and boulders.
    • Long grass randomly generates encounters with Constantinople.
    • Boulders prevent movement.
  • Allow players to spawn in and move around the map.
  • Allow players to either capture Constantinople or flee during an encounter.

Applying the ECS model

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 obstruction component.

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 move_system—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.

ECS in Obelisk

There is one last concept to understand before we begin—how to actually implement the ECS model using Obelisk and its mental models.

In Obelisk there are schemas instead of components (Obelisk is a protocol for more than just onchain games, after all). However, for the sake of this tutorial, these can be mostly thought of interchangeably. In order to apply the ECS model for the example above one would create a movable table and an obstruction table then set both of their types to boolean.

You would then create a system, move_system.move, and wire up the logic required to interact with the schemas (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.