Hi All

Very novice programmer here, so please bare with me.....I'm just starting a new game in dx11/c++ for practice. I decided to give a component based architecture a go to try it out on something simple.

In most of the articles I have read, the focus has been on game objects; their collision, rendering, physics, input etc, and how an object is just a container declaring which components are relevant to itself (creating instances of them) - thus components have very little knowledge/dependency on each other.

However, in the articles/examples....very little is said in terms of things I viewed as outside this scope. i.e. initialisation of wider elements (windows, dx devices) or game states.

In previous little games I have made, I have created a main dx class which dealt with this and was used throughout the game. It would inherit render and update functions from the game state it was in.

How would I tackle this using components? I'm worried I haven't really grasped the point of this methodology and am missing something obvious.

Hopefully that makes sense.

Cheers.

Very novice programmer here, so please bare with me

What? You haven't mastered programming yet? Me either.

What articles have you read? Using a component base system is preferred by some. Instead of a system built around types of object: BaseClass, ChildClass, ChildChildClass, objects can be constructed as a bunch of components.

As you've already discovered, you might need to structure your program in a different way. For example:

Drawable - is rendered to the screen.

Movable - moves.

Colladiable - registers collisions

The Dx render engine will render all the "Drawable" components. The Physics engine will move the "Movable" stuff. The collision detection system will check for collisions with "Collidable" objects.

Now lets think about all the different things we can do with just these three components.

Camera - movable

Player - movable, drawable, collidable

Door - movable, drawable, collidable

Wall - drawable, collidable

Ghost - movable, drawable

Sky - drawable

Trigger Area - collaidable

With just a few types of components, you can create a bunch of things. And it's easy to create new versions, add components, remove components, or even have debugging components only added for testing. Imagine the possibilities.

This can become a huge task to create all these objects. Usually, you will end up with some kind of data-driven object creation. For example:

"ghost" : {
   "movable" : {
      "velocity" : 12
   },
   "drawable" : {
      "mesh" : "path/to/mesh",
      "mat" : "path/to/materials",
   },
}

You get the idea.

The other part you need to think about it notifying objects or game states when something happens to an object. In the above example, the Player can collide with a wall. So have to figure out if you want to send messages to objects, register event listeners, mark some state, or something.

Together, all these things can get quite complicated. So give it a try...

Just because you're using components in some places doesn't mean you have to (or should) use it everywhere. Most of the time when people say they're using the component-based architecture, they just mean that their game-objects (Entities/Pawns/whatever-you-want-to-call-them) are implemented through components -- they don't usually (ever?) mean that all their underlying subsystems use or are components too (though, usually, there is a game-object component that corresponds to most of the subsystems). For example, Unity3D uses a component-based architecture in this sense -- GameObjects are bags of componenets, but there's an underlying engine that isn't.

While Ravyne is correct, not that composition is a key element of good object oriented coding. Your Engine can be thought of as a composition of systems (like graphics, audio, game logic, etc); resources can be thought of as a composition of subresources (e.g. LOD levels in a mesh, shaders for different GPU back ends in a material, or even more complex things like the various resources in a .hkx or .dad file); and so on.

Composition can be achieved in the naive OOP manner with Java-esque interfaces and containers, in a dynamic/prototypical manner, a structured manner with containers, a tedious procedural manner, a data oriented manner combined with any of the above, and several others. The key to composition is to accept light coupling and dynamic aggregation, which is pretty easy in just about any language (though many offer a lot of syntactical shortcuts to use inheritance or static aggregation, making the dynamic approach appear hard in comparison).

Will you get an advantage from making things now compositional? Maybe, maybe not. Knowing which case you have requires knowing a ton of details about your project, it's goals, timelines, your teams strengths and weaknesses, and project management that nobody here can answer for you, and you just need to practice before you'll learn on your own (which is why working under another very experienced developer or two on a real project is so important to your growth as a programmer).

It's entirely valid to only use composition for game objects (there is no one true way to design a game engine), but it's rather telling that experienced game programmers so often only think about it in that context (and then only because one blog article on it got popular).

Thanks for the opinions guys.

As I said this is purely for practice, my only goal is to actually finish it

Any suggestions on game states specifically?

My mind just wont get itself around how this could work as a component.

I was thinking about somehow using a system for states (components for data, systems for logic), where I change (enable/disable) or add certain components in all the entities based on state changes. Or perhaps I don't need to touch or create components, but just send messages to other systems so they know that I'm in X state so should do certain things? (i.e. I'm paused so don't update physics components or accept commands in the input component etc?)

Any suggestions on game states specifically?

My mind just wont get itself around how this could work as a component.

I was thinking about somehow using a system for states (components for data, systems for logic), where I change (enable/disable) or add certain components in all the entities based on state changes. Or perhaps I don't need to touch or create components, but just send messages to other systems so they know that I'm in X state so should do certain things? (i.e. I'm paused so don't update physics components or accept commands in the input component etc?)

Don't try to fit a square peg in a round hole.

Game states shouldn be outside of your component architecture. Use components for your game entities, but don't let it rule every piece of your system. When you're in your pre-game states (start menu, options, etc.) don't bother calling into your entity component system. Only when you start your game would I bother with the component systems.

Components work really well for in-game entities (players, enemies, objects, triggers, etc.) but don't fit well with other parts (menus, etc.).

Good luck and have fun.

Hi All

In most of the articles I have read, the focus has been on game objects; their collision, rendering, physics, input etc, and how an object is just a container declaring which components are relevant to itself (creating instances of them) - thus components have very little knowledge/dependency on each other.

However, in the articles/examples....very little is said in terms of things I viewed as outside this scope. i.e. initialisation of wider elements (windows, dx devices) or game states.

they dont talk much about that cause its general consensus to not use the component system everywhere, and use where it is mainly funcional, for example large collision systems

so they system knows only a lot of position components and doesnt care about the many other info, like their textures, who is moving them, their HP and so on, here component is very efficient

there are even possible system where the component methodology isnt very efficient at all, like some kind of ai etc

you just have to adapt your game to your needs not follow brainless a system you read about

that said after i implemented an entity component system in my game its very very handy, manipolating data its much much easier and also being my game a rpg its less headache to add new items, proprieties, equipment and spells with strange behaviours etc etc

just try it out and dont worry too much, if something seems too hard or not worth, keep your old model and use that