DEV Community: Toni Petrina

Entity Component System in TypeScript

Toni Petrina — Tue, 26 May 2020 00:00:00 +0000

Games can be architected in different ways, but Entity Component System, also known as ECS, is one of the more popular ones. I won’t spend too much time explaining why one should pick ECS over OOP or any other style, there are better resources out there.

In this series I will document my experience building ECS in TypeScript and why I did what I did.

To begin, we need a Component:

// All components must identify themselves.
type Component = {
  type: string;
};

Entities are composed of components and merely identifiers. However, I want to start with something easier:

type Entity = {
  id: number;
  components: Component[];
};

let nextId = 1;
function createEntity(...components: Component[]) {
  return {
    id: nextId++,
    components,
  };
}

So far, so good.

It’s important that components carry state and there should be no logic in either components or entities. So where is the logic? Inside Systems.

System will receive a list of entities and process them in some way. They should have no state and merely operate on components/entities. They can read them, update components, create or remove components or even whole entities.

The simplest abstraction is as follows:

// something we need to supply every frame
// can be current time, current frame number, both or more
type TickInfo = number;

type System = {
  update: (tickInfo: TickInfo, entities: Entity[]) => void;
};

And that’s it! Let’s build something with this!

An example

The first useful component we can think of is position:

class PositionComponent implements Component {
  type = 'position';
  constructor(public x: number, public y: number) {}
}

// easy way of creating position
const position = new PositionComponent(10, 10);

So how would we render it? Our game loop should be rather simple. Given a list of systems we call update on every one of them per frame.

const systems: System[] = [];
const entities: Entity[] = [];

function render() {
  const now = new Date().getTime();

  systems.forEach((system) => system.update(now, entities));

  requestAnimationFrame(render);
}

render();

Let’s create a simple rendering system:

function createRenderSystem(): System {
  const canvas = document.createElement('canvas');
  document.body.appendChild(canvas);
  const ctx = canvas.getContext('2d');

  return {
    update: () => {
      ctx.save();
      ctx.setTransform(1, 0, 0, 1, 0, 0);
      ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
      ctx.restore();

      entities.forEach((e) => {
        // so how do we get the rendering data
      });
    },
  };
}

So…given a list of entities we only care about a few select components. Let’s introduce a new helper function: getComponent:

function getComponent<T extends Component>(e: Entity, type: string) {
  return e.components.find((c) => c.type === type) as T;
}

Now we can finish our render system:

entities.forEach((e) => {
  const p = getComponent(e);
  ctx.fillRect(p.x, p.y, 1, 1);
});

Running this code yields a black rectangle on screen. Nothing exciting yet.

Source code for this code can be found at https://github.com/tpetrina/ecs-ts-test/blob/master/examples/ecs1.ts and live demo at https://ecs-ts-test.netlify.app.

I don't trust unit tests with mocks

Toni Petrina — Fri, 22 May 2020 16:23:00 +0000

Dave Farley asks why TDD hasn't conquered the world:

Dave Farley

@davefarley77

Why hasn’t TDD taken over the world? Anyone have any ideas? 🤷‍♂️

17:15 PM - 21 May 2020

Besides the obvious, and correct, reasons like:

People don't know how to do write tests.
People don't have enough time to practice testing.
Most of the code we write is untestable.

I find the following reason especially true for myself:

Unit tests with heavy use of mocks are terrible and I don't trust them!

Some example

TDD advocates unit tests should be written before the implementation. It is also considered that units refer to single methods. In modern C# Web applications these methods typically refer to service methods. Typical service is stateless and various methods do not share anything but being part of the same class. The only reason we have service in C# is to use constructor based dependency injection in order to simplify dependencies. An example:

sealed class UserService : IUserService
{
    private readonly IUserRepository userRepository;

    public UserService(IUserRepository userRepository)
    {
        this.userRepository = userRepository;
    }

    public void ChangeUsername(string userId, string newName)
    {
        if (string.IsNullOrEmpty(newName))
            throw new ArgumentException(nameof(newName));

        User user = userRepository.GetUserById(userId);
        user.Name = newName;
        userRepository.Save();
    }
}

By using constructor injection our public interface is simpler.

interface IUserService
{
    void ChangeUsername(string userId, string newName);
}

I would argue that this kind of code is much easier to write and reason about. However, testing is deceptively easier. And in that deception the problem lies.

TDD...is impossible?

Forget the above implementation and just focus on the method we need to test:

void ChangeUsername(string userId, string newName);

How should we approach implementing this method using TDD? Once we test the obvious validation which just tests that the method throws, we need to test the happy path. Thus we start by creating our system under test (SUT):

void NewName__IsSaved()
{
  // Arrange
  string userId = "FAKE-ID";
  string newName = "new-name";
  var sut = new UserService(Mock.Of<IUserRepository>());

  // Act
  sut.ChangeUsername(userId, newName);

  // Assert
  // ???
}

In the above sample, mocking is done using Moq, but other libraries could be used as well.

What matters is that it is extremely hard for a developer to correctly continue implementing this test. First of all, how do we verify correct behavior? How do we write that code intuitively? What does it mean for this code to succeed.

void NewName__IsSaved()
{
  // Arrange
  string userId = "FAKE-ID";
  string newName = "new-name";
+ var user = new User();
+ var userRepoMock = new Mock<IUserRepository>();
+ userRepoMock
+   .Setup(r => r.GetUserById(userId))
+   .Returns(user);
+ var sut = new UserService(userRepoMock);

   // Act
   sut.ChangeUsername(userId, newName);

  // Assert
+ user.Name.Should().Be(newName);
+ userRepoMock.Verify(r => r.Save(), Times.Once);
}

Added lines are marked with +.

Ouch

The first issue is the explosion in complexity of our arrange phase. The second problem is that it is not obvious what to do withour prior knowledge of the implementation. This point cannot be stressed enough - for TDD to work it should be easy to write tests beforehand just by reasoning. And the above test cannot be written before the implementation - thus TDD won't help you.

And that code is typical in most applications.

The code is testable, code coverage is high, some regressions are prevented...but personally, this style of coding and testing is ugly, nonintuitive, heavy, and not in the spirit of TDD.

In fact, the test suite comprised of tests like that one often trigger memes where unit tests pass, but the system doesn't work.

Is there a way out of here?

Sure, use TDD to unit test pure methods with black box testing where the output is easy to test and comprehend just by looking at the input and method name.

If you need to open the method to correctly mock stuff then you'll face issues.

Some points to consider:

For complex features use BDD testing on a higher level instead of focusing on individual methods like this.
Mocking doesn't necessarily mean using a low-level mocking library - an in-memory DB is a valid mock. If you are testing feature interaction, the database implementation is literally mocked away by using an in-memory representation. How DB works is not the point of those tests.
Consider only mocking code you don't own - thus interior part of your module/assembly shouldn't be mocked away.
Learn your tools - testing should be done and some proficiency of tools is required before knowing what and when to test.
Learn the difference between state testing and property testing.
Learn the difference between mockist and non-mockist schools of TDD. If you are learning about TDD, the not-so-subtle difference of these schools of thought is usually hidden from the text. This is extremely dangerous when paired with naive examples like testing ICalculator.Add method which is a pure method and is extremely easy to TDD. Unlike the above example typical in most line of business applications.

TDD is an extremely powerful technique, but it is not a silver bullet. Practice and learn where it can be applied with ease for a big gain, and where it is just a hindrance and waste of time.