3
\$\begingroup\$

I am trying to learn more about Entity-Component Systems, and something that kinda stuck out at me was the question of how to represent the world in such a system? More specifically, I'm trying to do a version of Tetris with such a system, and I was wondering how I would put the board, and the fallen pieces in place?

I was thinking of having each piece be an Entity, and it would store a number of Block Components, which would represent the individual blocks that make up the pieces, and it's relative position to the center of the piece. Would it be a good idea to simply transfer this component to some Board Entity, which would hold many of these components in the board?

Improve this question
\$\endgroup\$
4
  • 11
    \$\begingroup\$ This feels abusive to me. You don't need to make everything an "entity" in these sorts of systems (and in fact, you probably shouldn't). You have a Board, a board can have Pieces on it (which may or may not be entities) -- you don't need to overengineer it to cram it into a trendy paradigm. \$\endgroup\$
    – user1430
    Jan 9, 2013 at 2:06
  • \$\begingroup\$ @JoshPetrie: I believe I'm in the same boat as the OP. I am trying to learn more about ES to make a decision of whether or not to use it for game (a non-trivial one). But without knowing how to implement it for a simple game, how can I confidently make that choice for a game that will end up taking a lot of my time? All ES tutorials sort of gives you a very basic information, but fails to provide some of the most important info, which only we can find out by trying it on our own. If you already have a good resource for ES, I'm all ears! \$\endgroup\$
    – Vite Falcon
    Jan 9, 2013 at 3:32
  • \$\begingroup\$ @JoshPetrie: I did codename it as the Extremely Over-Engineered Tetris clone :p \$\endgroup\$
    – s73v3r
    Jan 9, 2013 at 4:31
  • 1
    \$\begingroup\$ @JoshPetrie: So on a more serious note, for the world/board/whatever, I suppose I could just have a regular class with update() and draw() calls. I imagine the rest of the UI would be done in this manner as well. It just seems weird to have such a big part of the program to be done in a different manner. \$\endgroup\$
    – s73v3r
    Jan 9, 2013 at 4:35

2 Answers 2

Reset to default
5
\$\begingroup\$

The Piece

Rather than having several BlockComponents that represent blocks, consider having a single ShapeComponent that has a 2D array of blocks - these can be a simple binary matrix ('true' where block present, 'false' where not). You will find rotation around a point much easier to implement mathematically this way, and collision is a breeze. Your ShapeComponent can then expose methods to manipulate it (ShapeComponent.RotateClockwise(), for example).

A Piece entity would be defined as:

  • PositionComponent (integer X,Y co-ordinates)
  • ShapeComponent (as described above)
  • RenderComponent (marks the entity as renderable, probably defines a colour)
  • MoveableComponent (marks the entity as moveable each game tick)

The Board

The 'board' doesn't really exist...! All you need to do is implement two constraints on your active piece:

  • it may not move below 0 on the Y axis
  • it may not move outside of 0-10 on the X axis

This logic should be performed by the system in charge of updating piece position. If the piece violates #1 it should be stopped as if it had rested on top of another block. If it violates #2 the movement should simply be ignored.

Bear in mind that you need not completely eschew the OO paradigm when implementing an Entity-Component-System architecture. Rather, the ECS approach is based on one of the basic principles of good OO design, Prefer composition over inheritance.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

I was thinking of having each piece be an Entity, and it would store a number of Block Components, which would represent the individual blocks that make up the pieces, and it's relative position to the center of the piece.

Sounds like it would be far too complex. The aim of using components is not to see how many different components you can have! It's to improve modularity by packaging units of functionality together which can be combined to change the functionality. Each of your proposed Block Components would have pretty much no functionality and you'd need a separate component to manage the whole lot when it comes to rotations etc.

Far better would be to have one component that represents the arrangement of blocks. It would contain data that specifies the exact arrangement, current rotation, etc. Each Piece would have one Blocks component to manage all that.

Would it be a good idea to simply transfer this component to some Board Entity, which would hold many of these components in the board?

There is certainly an argument for having a Board entity, which has some sort of Board component to manage the game environment, and which also contains all the Piece entities.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ +1 for "The aim of using components is not to see how many different components you can have!" Personally I would adjust his suggestion slightly to the Board also has a Blocks component just like pieces, and so when a Piece lands it simply tells the Board what blocks to add and then the Piece is removed. \$\endgroup\$
    – jhocking
    Jan 9, 2013 at 16:31
  • \$\begingroup\$ My thinking wasn't to have as many components, I just figured that there really is nothing different between the various blocks in a piece, and on the board. However, having the entire arrangement in one component does sound like it would be much easier to handle. \$\endgroup\$
    – s73v3r
    Jan 10, 2013 at 18:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .