15

What is often used is an intermediate Intent System which abstracts the input and keeps track of the context and relevant gamestates. The Intent system will stop transmitting inputs when the simulation is paused for example. It also handles the mapping between controller events and intents (move in direction, run, shoot, reload...). This way your other ...


15

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 ...


13

You are over-complicating things. I would go so far as to say that even using component-based design is just overkill for such a simple game. Do things the way that makes your game quick and easy to develop. Components help with iteration in larger projects with a huge variety of behaviors and game object configurations but their benefit to such a simple ...


12

You've probably heard of the God/Blob object anti-pattern. Well your problem is a God/Blob loop. Tinkering with your message passing system will at best provide a Band-Aid solution and at worst be a complete waste of time. In fact, your problem has nothing specifically to do with game development at all. I've caught myself trying to modify a collection while ...


12

Any way that works is a way that works. That sounds snide, but really, your game is 1000x more important than your architecture. Pick any approach you like and find easy to use. The ones I've seen in real shipping games (using component-based design, not ECS specifically; I've never seen pure ECS "in the wild", though many component designs have ECS-like ...


12

Short version: no, your job as an engineer is to evaluate all applicable solutions to problems before choosing a solution Long Version: "ECS" is an overloaded term. It had a somewhat clear definition at first but it's been overly muddled since. It doesn't matter much, though, since the answer is the same either way: every architecture has pros and cons. If ...


11

The sole constraint of an identifier in an entity component system is that the generated identifier be unique. That's the only criteria. If it's unique, it's good. Any method which satisfies this one constraint is a proper way to assign IDs. guid? Fine. integer from an incrementing counter? Provided the counter isn't going to overflow during play, ...


11

Yes, you're thinking too complicated. It sounds like a lot of your problems could be solved with a messaging system and some additional attributes that allow you to specify some filters, and finally not worrying about being so strict with entities/components. Messaging will help you with some aspects like triggering particles, powerups, and so on. For ...


11

Applying the RequireComponent decoration to a script will ensure that the GameObject has the specified component. If the component is missing: Unity will attempt to add a component of this type for you, If this fails (e.g. mixing RigidBody/RigidBody2D) then the script will refuse to attach. C# sample: [RequireComponent (typeof (Rigidbody))] public class ...


11

The simple version: don't. One could argue that you have perhaps a slight misunderstandings about how to build an ECS (why would you sent a list of Entity* to a system to update? the System is supposed to have its own self-contained collection of the components it cares about, and the global entity list should barely ever even be used... a "true" ECS doesn'...


10

In C#, having an instance (non-static) method in a class does not copy the instructions for each object created from that class. Static or not, the data that represents the instructions only exist in one place. The member variables, or state, of each of the instantiated objects do get their own space in memory. When you write a non-static method on a ...


10

What's an object? What we call an object or an entity depending on the model is, fundamentally, made of two parts: data, and behaviour. Game objects have properties and do things. Let's take a simple, free-falling ball as an example. A ball's data is: Its current position Its current speed Our ball can do a single thing: fall. When a ball falls, it does ...


9

In ECS everything is broken down to components that describe functions. A weapon is a physical item so one component will be a physical position. If it is on the ground or thrown at an enemy (sword / throwing knife) then you need the physical position component to decide if it was picked up or hit something (e.g. wall or monster). When a weapon is held you ...


9

First, you should not have a strict 1-1 mapping of Components to Systems. It's unclear to me from your question if that's the case already. You may very well have singular systems that use or interact with numerous components. Rendering, physics, AI, etc. are all Systems (they perform a cohesive set of updates and logic) but interact with many Components. A ...


8

Im late to the party here but I spent A-LOT of time researching this. First why I don't use the following: XML: Excessively verbose. Tons of redundancy. Repeating field names? GROSS JSON: I think JSON is great for a UI layout but for a database, hell no. It will have the same problems as XML, redundancy, and deep nesting. GROSS. SQL: This is a great ...


8

To add to the other answers here, you can use something like in the following code to have a bit set of arbitrary length that grows on demand. This method even lets you do a simple form of compression; if your most common components have the lowest ID values, the majority of your entities will use a small amount of bitset memory to track their components, ...


7

If anything, the first option might be better for cache misses since generally you'll be iterating through, say, all the Renderable components at once. Just copy the data you need into that component to avoid cache misses due to looking up data. But it seems like you're suffering from design paralysis. Do you actually have a working game yet? Are the ...


7

Your class tree in general confuses me, namely the fact that you have multiple "Application" derived classes that presumably get implemented all in the same application. It further seems to be a grab bag of all sorts of unrelated functionality... simulation state management, layout, rendering, input... which seems to be why you have so much forwarding: ...


7

Sort at rendering time if you sort at all. You don't need to keep the list sorted during every operation; in fact, this may be harmful. What happens if you spawn 20 enemies at once? Sort 20 times? They sorted quality doesn't matter until rendering, so why ever do it more than once per frame? Furthermore, with an entity-component system, it can be handy ...


7

The entity component system (ECS) is great. There are plenty of misunderstandings about it though. For example, it's perfectly fine to use event/messages in an ECS. People often think you're supposed to completely avoid inheritance too. Also not true. The ECS methodology is just a strategy for avoiding issues that come with a large hierarchy of inheritance. ...


6

It sounds right to me. There are some benefits to doing it this way: You're not duplicating data. The information about the entity is always up-to-date (i.e. using the entity ID to get the position of the entity will always return the current position of the entity). Those two essentially mean the same thing. If you were to store the position of the target ...


6

Partly to allow data-driven operations, and partly because an ECS is a specific subset of all possible component-based designs. A main point of component-based approach to aggregation (be it ECS or another use of components) is to allow you to reconfigure game objects without needing a recompile. You have an editor that your designers and game scripters ...


6

Taking the example of the guitar: (...) a player you can, for example, not only play on guitar as a Musical Instrument, but use it as a Weapon or, what is perhaps more unobvious, throw it right to the furnace to get some heat in a cold winter night. First off, move away from using object inheritance to model this. Although, I want to note that using OOP is ...


6

Components are just a collection of data and logic. How you store and relate them to the logical entity is where you gain or lose performance depending on the strategy you choose. My example and explanation is in Java, but the theory can be applied to any language. The way I usually handle custom Component engines is with HashMap registries of components. ...


6

Games typically approach this type of issue using a transformation hierarchy. In this model, each entity can be treated as a "child" of a "parent" entity. The entity's local position and orientation components are interpreted to be relative to the position and orientation of the parent. Parent entities may in turn have their own parents, grandparents, etc.,...


5

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 ...


5

If you're actually trying to get make use of the data-oriented-design nature of ECS then you might want to think about the most DOD way of doing this. Take a look at the BitSquid blog, specifically the part about events. A system that meshes well with ECS is presented. Buffer all events into a nice clean per-message-type queue, the same way systems in an ...


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