Design Patterns – Is Experimenting with Them a Good Idea?

cdesigndesign-patternsengineeringgame development

I have been reading a lot about different design patterns, their pros, cons, main usage etc. However, I like to experiment and try to invent my own ways of the implementations (even if they are not the best). Now I am facing a problem with my Entity component system implementation.

Despite of the pros of this pattern I want to do some of the things in my own way, for example:

1.) Components are wrapped into bigger interfaces for data manipulation. In most of the cases i read that ECS components must contain only data and the systems are their main manipulators. In my system I intend to use a wrapper classes for the components

Little example: Lets say we want to have a Sprite component, that represents the visual component of each entity in game. I wrapped it inside the RenderableEntity class that can be a component of an entity and has additional functions and variables.

2.) I don´t use a system for every type of component.

Again an example from game engine : We have a CollidableEntity, that is put in some spatial data structure and doing its collision checks, but for RenderableEntity there is no system that manages it (I assume that we are in 2D now). Reason? I want the user to have the power of rendering the sprites of each entities, because of specific order or using different batches.

3.) Entities can have more than 1 component of the same type and no bitsets are used for checking if is the system interested in given entity. The components are assigned to systems at their creation via the data type.

Little code:

template<class DataType>
DataType* createComponent(GameEntity* mainEntity)
{
    //Create it via default constructor
    DataType* component = new DataType();

    //Add it to the back of the component vector
    mainEntity->_entityComponents.emplace_back(component);

    //Assign it to system
    ECS::assignToSystem<T>(component);

    //Return it to access its functions
    return component;
}

The assignToSystem function does following : checks if is the given data type in our map and if not, it adds the component to the system and from now is the system the maintainer of the component. Also the gamesystems are attached to given data types via a function and it looks like this :

class ColliderSystem:public ECS::System
{
    void assignSystem() override
    {
        ECS::assignSystemToComponent<CollidableEntity>(this);
    }
};

Can you tell me if its a good idea to experiment with given patterns and try to do things your own way? Especially I care about this because want to use this approach in my graduation work and wonder if it will be a problem if I "break rules" of some patterns. Also , what do you think about my "changes", are there any cons? Thanks.

Best Answer

People have experimented with different mechanics of implementing a design pattern in the past with differing results. For example, the definition of a singleton is that there is only one instance of a class for your entire application. There is nothing in that definition that requires you to implement it with a static accessor, even though that's how the example in the GoF book is written. Folks that use components like the Spring framework let the component container guarantee that there is only one instance and a reference to that instance is injected everywhere you need access.

That example leads to a few points:

If what you are doing is fundamentally different from the pattern, call it something different. There is nothing worse than two people using the same words that are talking about different concepts. Nothing but confusion happens after that.
If what you are doing is following the pattern, make sure your differences are actually solving a problem. Being different just to be different is not helpful 9 times out of 10.
"playing" with implementation details can help you understand the pattern better, and why the example code looks the way it does.
Mixing all the patterns into one project leads to an incomprehensible mess. Just use what you need to use.

At the end of the day, no user is going to praise your judicious use of the flyweight pattern or even know that you used a decorator pattern in there somewhere. Patterns are called that because they are common solutions to common problems that happen to have very similar implementations. Many times the details of the implementation are less important than the concept that inspired it. Just make sure that your code is comprehensible to someone else, or even your future self 3 months down the road.

I'm not going to get preachy, but I will encourage you to look at the impact of what you are doing as objectively as you can. Users only care that the application/game/tool/etc. works. Developers on your team care about whether they can understand it and fix it when they find things that are broken. Every time you deviate from the norm, it increases the amount of time it takes to understand the code. Make it annoying enough and your development team will rewrite everything so that it is more familiar.

Introduction

Entity–component systems are an object-oriented architectural technique.

There is no universal consensus of what the term means, same as object-oriented programming. However, it is clear that entity–component systems are specifically intended as an architectural alternative to inheritance. Inheritance hierarchies are natural for expressing what an object is, but in certain kinds of software (such as games), you would rather express what an object does.

It is a different object model than the “classes and inheritance” one to which you’re most likely accustomed from working in C++ or Java. Entities are as expressive as classes, just like prototypes as in JavaScript or Self—all of these systems can be implemented in terms of one another.

Examples

Let’s say that Player is an entity with Position, Velocity, and KeyboardControlled components, which do the obvious things.

entity Player:
  Position
  Velocity
  KeyboardControlled

We know Position must be affected by Velocity, and Velocity by KeyboardControlled. The question is how we would like to model those effects.

Entities, Components, and Systems

Suppose that components have no references to one another; an external Physics system traverses all Velocity components and updates the Position of the corresponding entity; an Input system traverses all KeyboardControlled components and updates the Velocity.

          Player
         +--------------------+
         | Position           | \
         |                    |  Physics
       / | Velocity           | /
  Input  |                    |
       \ | KeyboardControlled |
         +--------------------+

This satisfies the criteria:

No game/business logic is expressed by the entity.
Components store data describing behaviour.

The systems are now responsible for handling events and enacting the behaviour described by the components. They are also responsible for handling interactions between entities, such as collisions.

Entities and Components

However, suppose that components do have references to one another. Now the entity is simply a constructor which creates some components, binds them together, and manages their lifetimes:

class Player:
  construct():
    this.p = Position()
    this.v = Velocity(this.p)
    this.c = KeyboardControlled(this.v)

The entity might now dispatch input and update events directly to its components. Velocity would respond to updates, and KeyboardControlled would respond to input. This still satisfies our criteria:

The entity is a “dumb” container which only forwards events to components.
Each component enacts its own behaviour.

Here component interactions are explicit, not imposed from outside by a system. The data describing a behaviour (what is the amount of velocity?) and the code that enacts it (what is velocity?) are coupled, but in a natural fashion. The data can be viewed as parameters to the behaviour. And some components don’t act at all—a Position is the behaviour of being in a place.

Interactions can be handled at the level of the entity (“when a Player collides with an Enemy…”) or at the level of individual components (“when an entity with Life collides with an entity with Strength…”).

Components

What is the reason for the entity to exist? If it is merely a constructor, then we can replace it with a function returning a set of components. If we later want to query entities by their type, we can just as well have a Tag component which lets us do just that:

function Player():
  t = Tag("Player")
  p = Position()
  v = Velocity(p)
  c = KeyboardControlled(v)
  return {t, p, v, c}

Entities are as dumb as can be—they’re just sets of components.
Components respond directly to events as before.

Interactions must now be handled by abstract queries, completely decoupling events from entity types. There are no more entity types to query—arbitrary Tag data is probably better used for debugging than game logic.

Conclusion

Entities are not functions, rules, actors, or dataflow combinators. They are nouns which model concrete phenomena—in other words, they are objects. It is as Wikipedia says—entity–component systems are a software architecture pattern for modeling general objects.

Design – How to allow for custom Rules in a Entity Component System designed game engine

To begin with, a caveat: even more than other domains of programming, every design decision in game development is a tradeoff. The "right" answer is "whatever works for the game you are making."

Okay. There are a few approaches we can take:

If there are a small, known set of general behaviors, write them inline and allow the user to tweak parameters. (i.e., which enemies does this tower avoid, how far away does it need to be, etc.) This is the most straightforward and maintainable approach, but it scales poorly the more different behaviors you have.
Functions can be data! In C, this is a function pointer, other languages have equivalents. The code that creates the entity is responsible for giving it a function telling it how to act.

In C it'd look something like this:

// Define a function pointer type.
typedef void BehaviorFunc(Entity * this);

struct FooComponent {
    BehaviorFunc * my_behavior;
    // Other data as needed...
}

// User code:
void MyBehaviorFunc(Entity * this) {
    DoTheThing();
}
// ...
{
    FooComponent * f = AddFooComponent();
    f->my_behavior = MyBehaviorFunc;
}

// Update:
void UpdateFooComponent(FooComponent * f) {
    // stuff
    f->my_behavior(GetEntityFromComponent(f));
    // more stuff
}

We actually have other options here as well. If you need to allow non-programmers to define behaviors, you could replace the function pointer with a behavior tree, compiled script code, etc. All of these are much more complicated, though, so don't bother unless you actually need the extra flexibility. Keep in mind that the more general you make the system, the harder it is to implement (and optimize), for both the engine and client code.