16 hours ago, MarcusAseth said:

I would like to know the reasons for this

 

There are a lot of reasons:

- ECS is not a generic solution to solve all game programming problems!

- It overcomplicates everything - especially for beginners because there are so many indirections it requires. Making it debug and follow a nightmare when you dont have the proper tools

- It has runtime performance penalitities, some can be minimized some cannot: You need to be at least aware of that

- Doing it right is hard. Doing it poorly/wrong is really easy.

See @Kylotan answer.

And yet, I totally don't like the idea of wasting time doing something like an rpg with classes where my skeleton swordman inherit from baseSkeleton and also the Skeleton Axeman inherit from the baseSkeleton, and now I want to add skeleton BladeMaster which require stuff from swordman and axeman and there is that diamon inheritance problem I often hear about.

As difficult as composition might be, I would rather learn the difficult thing once and be setup for success, rather than following a path knowing it will eventually lead me to a dead end

Also I realize it doesn't apply to all scenarios, but I always have in mind that sooner or later I'll attempt doing something roguelike, so I plan for that.

This is a totally false dichotomy. There is no reason why you have to have a massive inheritance tree just because you don't use components. I've worked on many games with no components and they never went down to levels like 'baseSkeleton' or 'skeletonAxeman'. More common might be PlayerCharacter and NonplayerCharacter, derived from Character. That's very manageable.

If you don't see how it's possible to make multiple enemy types from a single NonplayerCharacter class without needing extra inheritance, then you're not ready to recommend components as the solution. Most games in history did not and do not use component-based entities. Choosing not to use component-based entities is not a dead-end.

I shouldn't have used the word "dead end", poor choice of expression, but I meant that inheritance complicate things as well. At least with components (from my understanding) you simply move all the complications upfront so that for the rest of the project you are more free to put your ideas into practice without having to worry as much about coupling, which seems to be exactly the OP problem (he even said he was passing objects down 10 layers of inheritance or something like that...)

Components create extra coupling problems, because now you have to do it within a class as well as between them. There's a pipe-dream of having a useful set of components that are loosely coupled, but the threads on this forum prove that it's incredibly hard to achieve that. It's much easier just to start with an Entity class and work from there.

The original post said nothing about chains of inheritance, just chains of construction. That's composition. You were the first poster to mention inheritance.

2 hours ago, Kylotan said:

If you're struggling with program organisation, components ADD problems. Now, instead of just working out how your Entity relates to things, you also have to decide how to decompose your Entity. Don't do it.

Ok, I agree with this. Trying to break things down, and then somehow reconnect them differently when everything kind of a mess anyway isn't a good idea.

However, I've just started making a game engine, and none of my components are coupled with each other, and I have only one Actor class. I have tranform, model(s), stats, inventory, and abilities components. I haven't actually implemented the physics component yet, but the actual logic is going to take place in my GameLogic class. Just like with the other components. I got the idea to do this from "Game Coding Complete". I took what they had a little further. Also this requires an event system, at least the way I have it setup, that sends events that the GameLogic listens for. GameLogic then calls the appropriate function.

Not trying to argue, I completely agree with this:

26 minutes ago, Kylotan said:

It's much easier just to start with an Entity class and work from there.

That is actually how I started my engine, after the 3rd/4th time of turning it into a complete mess. Its a lot easier to set things up if you start small.

Why is "easier" so important anyway?  

I mean, is like that tutorials that do stuff like "using namespace std;"  instead of explaining about std:: and other stuff like that, doing all they can to insulate the begginner from "scary" knowledge... to those people I would say : don't assume the begginner in question is so fragile, if things are explained properly even "hard" stuff can be made into easy.

So here the problem is not that composition is hard, here the problem is that there is not good learning material coverage, from what I can tell. If there was, assumed the begginner had the patience to go trough all the given material (let's sat a thome about it made out of 1000 pages), then the journey would be easy.

Go write that book guys, there is an open market and $profit$ to be made

"Easier" is important because programming is hard, and learning is hard.

Tutorials do stuff like "using namespace std;" not because they think you need insulating from scary knowledge, but because that knowledge is not directly relevant to the thing being taught at that time.

Composition as a concept is not hard. However, component-based-entities are a very specific and opinionated use of composition where there is no consensus at all on how it should be done. I'd argue that makes it a very poor paradigm for anyone who doesn't already have a strong opinion on how to proceed.

2 hours ago, MarcusAseth said:

Why is "easier" so important anyway?  

I mean, is like that tutorials that do stuff like "using namespace std;"  instead of explaining about std:: and other stuff like that, doing all they can to insulate the begginner from "scary" knowledge... to those people I would say : don't assume the begginner in question is so fragile, if things are explained properly even "hard" stuff can be made into easy.

So here the problem is not that composition is hard, here the problem is that there is not good learning material coverage, from what I can tell. If there was, assumed the begginner had the patience to go trough all the given material (let's sat a thome about it made out of 1000 pages), then the journey would be easy.

Go write that book guys, there is an open market and $profit$ to be made

Easier is extremely important in the starting phase. In the 15+ years I've been programming, majority of those years has been devoted to game programming and it wasn't an easy ride by any means. I've noticed that a lot of books, and tutorials will over complicate the process of game programming by either over engineering from the start, or using methods that are not beginner friendly causing even more confusion.

There is a good reason that many new programmers never finish a game, or even stick around for a long period of time. I've known people who've quit programming all together because it was just too much of a struggle to wrap their head around all the many concepts to what goes into creating a full game. It didn't matter if they read the 1000 page book, or watched the "best" YouTube series showing them how to create games because they still couldn't wrap everything together in their mind on how it works, and why it works. When it comes to learning not everyone looks at the same material and can see and understand what is going on. Some people take much longer to grasp the material, while others understand quickly what is occurring.

Game programming isn't easy, this is why we see a market for things like GameMaker, and other such tools. There is a market to create games, but many people are not willing to put the many years into learning. One of the main suggestions I've always said is that the more you code, the more you'll learn. Truth be told I got most of my knowledge from doing, and learning from other people. I would learn a basic concept and code several little programs, and move onto the next concept repeating the same process until I understood how to use it. If I had questions, I could ask seasoned programmers for help to understand the problem. This takes a lot of time and devotion to the craft, and will pay off if you progress through.

I'm still going to stick with my initial suggestion, keep it simple. You're better off creating different classes for what you need as opposed to getting into a big web during the starting phase.

I've never had an issue in which I couldn't make an RPG, World Designer, or any other project because I didn't use components. This is a misconception that it's required. In my prior example, you can create a basic enemy class with general attributes, and even abilities, without doing any of this. I've created classes that would pass through enemy IDs that would determine which states the creature would obtain on object creation, and in the attack function, depending on the monster ID, it might double attack, triple, or add poison, ect... You don't need components to do this. Keep it simple when starting out.

I'll try and force myself to listen then, since you guys all agree 

Sorry for hi-jacking the topic