Tag Info

Hot answers tagged

205

There are a multitude of ways to represent and implement entity component systems, but here is an explanation of one way. Keep in mind there is no concrete definition of entity/component/system architectures, so this is just one implementation. I'm going to introduce an analogy for entity/component/system architectures that might help. Let's think of an ...


38

Components are great, but it can take some time to find a solution that feels good to you. Don't worry, you'll get there. :) Organizing components You're pretty much on the right track, I'd say. I'll try to describe the solution in reverse, starting with the door and ending with the switches. My implementation makes heavy use of events; below I describe ...


36

If there are no popular ones, then why not? Because there is nothing resembling a consensus on how such a framework would operate. On a thread on Gamedev.net I determined that when people talk about component-based game systems there are actually at least 8 possible permutations of how they expect them to work, based on 3 different factors: Inboard ...


31

A comment: The Artemis implementation is interesting. I came up with a similar solution, except I called my components "Attributes" and "Behaviors". This approach of separating types of components has worked very nicely for me. Regarding the solution: The code is easy to use, but the implementation might be hard to follow if you're not experienced with C++. ...


29

First of all, you when build component-based systems, you don't have to take the approach of turning everything into a component. In fact, you generally shouldn't -- it's something of a neophyte mistake. In my experience the best way to tie together rendering and physics systems in a component based architecture is to make those components little more than ...


20

If I were in this situation, I would create each part of the boss as a separate entity. These "sub-entities" would include some kind of AttachmentPoint or ParentEntity component. This component would include a reference to the parent entity and an offset from the parents position. When updating the position, they check the parent position and apply the ...


17

I think it's totally fine to have simple methods for accessing, updating or manipulating the data in components. I think the functionality that should stay out of components is logical functionality. Utility functions are just fine. Remember, the entity-component system is just a guideline, not strict rules you need to follow. Don't go out of your way to ...


17

Camera: Making this a component would be pretty neat. It would just have a isRendering flag and depth range like Sean said. In addition to "field of view" (I guess you might call it scale in 2D?) and an output zone. The output zone could define the portion of the game window that this camera gets rendered to. It wouldn't have a separate position/rotation ...


17

Materials are a graphics concept, and belong in your renderer. A renderer is too low-level a piece of architecture to be built on top of an entity system. Entity systems should be for higher-level game objects. Not everything needs to be a component, and in fact, it's generally a bad idea to try to force everything into a single paradigm like that. It ...


16

Dungeon Siege by Gas Powered Games Scott Bilas released a lot of information about Dungeon Siege which featured component-based systems, amongst other things. Dungeon Siege was released in 2002.


16

Resistance 1-2 (possibly 3) (2006-2008) by Insomniac Games Terrance Cohen lists these games in his A Dynamic Component Architecture for High Performance Gameplay talk from GDC Canada 2010. Not sure if this was applied to the recent Ratchet & Clank games.


13

It might not come up so much for a small personal game, but one hard problem when it comes to game data is multi-user editing/versioning. We use a lot of small text files that get baked down to a small number of binary blobs by a build process. This makes life easier for designers since they have a lot of flexibility in their workflow. CCP, as a counter ...


13

There's a line between complete granularity, leading to no code wastage or blob-like state (which is why component architectures are favoured), and usability. Obviously things may have a Position, but they're not necessarily dynamic (so why have Velocity and Acceleration?). However, something with a Velocity is going to be a moving object, so it makes sense ...


13

I would suggest starting by reading Mike Acton's 3 big lies, because you violate two of them. I'm serious, this will change the way you design your code: http://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html So which do you violate? Lie #3 - Code is more important than data You talk about dependency injection, which may be useful in ...


12

Unity3D uses a component-based system by default. It is superb for creating game entities from a text file and dependency injection. function createEnemy() { // extract AI type for enemy // definition is a custom structure holding parameters to create the enemy var aitypename = definition.ai; // AIType can be an interface or abstract class ...


12

One of the things that Unity does is provide some helper accessors on the parent game object to provide a more user friendly access to common components. For example, you might have your position stored in a Transform component. Using your example you would have to write something like e.GetComponent<Transform>().position = new Vector3( whatever ); ...


12

You already accepted an answer, but here's my stab at a CBS. I found that a generic Component class has some limitations, so I went with a design described by Radical Entertainment at GDC 2009, who suggested separating components into Attributes and Behaviors. ("Theory and Practice of the Game Object Component Architecture", Marcin Chady) I explain my ...


12

Your Position component could have a "parent/children" logic, where any Entity with a Position may have a parent and their position is relative to their parent. Instead of having several meshs on the same entity, you can make more than one entity, each with its own mesh and link them together. You can even make the children entities listen to their parent ...


11

We have a similar situtation in our project, and we solved the problem by saving components (not functions) to LUA metatables. Basically, when we are creating an entity (or game object as we call them) on LUA side, code looks something like: function createShip() ... self.transform = registerToComponent("transform") self.sprite = ...


11

If you're talking about a moddable game, then you might want to follow one of your suggestions above. But if you are concerned about rolling over your own errors, I'd say don't do it. I have become an advocate of Fail-Fast. If this is an error that you have created and must resolve before releasing, you should make the error obvious. The article that is ...


11

The major advantage that comes to my mind is that it allows the configuration to be edited/managed by a non-programmer without requiring them to touch any of the game scripts.


11

Not everything has a dynamic set of properties. In fact, much of software engineering is about trying to pin down a precise and static specification of something. Static hierarchies are easier to reason about because they're broadly fixed in the code. Components can lead to an explosion of possible permutations - great if you need that flexibility, but ...


10

No lie, architecting games (or any other simulation-style program) is harder than your average business app. When you have lots of different entities that all need to interact then in the code they'll need to, well, interact. Letting them do that in a maintainable way is tricky. A component pattern can help, but even then figuring out how to wire the ...


9

Please check out the links that I put in the bottom of this answer. A good number of them thoroughly answer this question, and I'd rather not duplicate the information here. In particular, there is a question, "Component based game engine design" which I think directly answers your question.


9

Should the shield be its own entity that tracks the location of the player? That might make it hard to implement the damage filtering. It also kinda blurs the lines between attached components and entities. Edit: I think there's not enough "autonomous behaviour" for a separated entity. In this specific case, a shield follows the target, works ...


9

It seems like what you want is a factory. http://en.wikipedia.org/wiki/Factory_method_pattern What you can do is have your various components register with the factory what name they correspond to, and then you have some map of string identifier to constructor method signature to generate your components.


9

If you think a 2D RPG is so complicated that you not only need a database, but also a ORM to simplify the interfacing to that database, then I'd suggest you probably haven't yet studied the game mechanics yet. Do bear in mind that we had Zelda in the cartridge era where you might have had 256 bytes of battery-backed RAM to save the current state of the game ...


9

This is a god damn (pardon) beast of a question with lots of details +1 there. Definitely enough to help people who stumble upon it. I just mostly wanted to add my 2 cents about not sending physics data!! I honestly can't stress this enough. Even if you have it so far optimized that you can practically send 40 spheres that bounce around with micro collision ...


9

'That' article is not one I particularly agree with, so my answer will be somewhat critical I think. This seems really practical in many situations, but the part about components being just data classes is bothering me. For example, how could I implement my Vector2D class (Position) in an Entity System? The idea isn't to ensure that nothing in your ...



Only top voted, non community-wiki answers of a minimum length are eligible