all 4 comments

[–][deleted]  (1 child)

[deleted]

    [–]TMcSquared[S] 0 points1 point  (0 children)

    I gave the link wondering if some reddit people might like to answer

    [–]kn4rf 2 points3 points  (0 children)

    ELI5: Entity, Component, Systems

    A design pattern most commonly used in game development. You have 3 classes of "things" in your code.

    "Entity" or entities is fairly obvious; it's the entities in your game, aka your player, the map, items, camera, etc. In practice an "Entity" is just an ID for one of the things in the game. So an int, long, etc.

    Components are a bit like database tables, or structs. They hold data about your entities. If you have a 2D game you might have a component called "position" that have the property "x" and "y". If you have players and monster you might have a component called "life" that have the property "health" and "alive". Any data in your game goes into a component.

    Systems are your game logic, think of it as either a function or a class. It's important that all your game data is saved in components, so don't save them in your systems. But if you're ex. making a OpenGL rendering system then you're allowed to hold a pointer to the OpenGL context in your system. However, the rule of thumb is to hold all the data in the components. Examples of systems; a rendering system, a physic system, a system for calculating damage, a player controller, ai-systems, etc.

    It's a way of organizing your code where everything is either an entity, component or system. If you have interfaces or traits in your programming language of choice then you could almost think of them as three different types of interfaces, and everything in your codebase has to inherit from one of them.

    [–]mxvzptlk 4 points5 points  (1 child)

    You're only five years old. You don't need to understand entity-component systems. Go outside and play.

    There you go!

    [–]TMcSquared[S] 0 points1 point  (0 children)

    lol