1 minute ago, Horscht said:

The Caves of Qud video was informative but the other one waaaaay too complicated, especially since it involves template metaprogramming which is super hardcore hard and I have no experience at all with that.

He made a "slower" explanation of it which is actually part of a playlist, the video is this one below.

You got to learn sooner or later anyway, right?! The video above will probably be still too complicated, so I might as well drop you some more links to watch before it, so that you get to know what you need to know. Watch them when you're ready 

First one, you need this below. It is a gentle introduction to template, it starts explaining std::abs() and why it works, but be sure you follow along, write the example and compile. It gets interesting when he show the print function with variadic template arguments, and  it gets insane when he shows an implementation of tuple, I had to watch the whole thing twice to start getting my head around it

Then next is the series below. You can skip the first video and go to the second, it is about template argument deduction, you need to understand it if you want to get more confortable with what templates are doing. The third is about overload resolution so maybe you can skip that too, the laters one are again about template.

Also, if you are more of a book guy, today actually C++ Templates: The Complete Guide (2nd Edition) was released, should be 600 pages or something, you'll be an expert on it by the time you finish reading I bet. And then, you can go back to the first video of this reply and probably it will look easy  

The rest I guess is just practice

Thanks for all that learning material, I'll look into it over the next few days, but I think before I'll try to make my own ECS from scratch I'll start by just using an existing, well designed and tested one to get a feel for how it all fits together.

15 minutes ago, Horscht said:

Thanks for all that learning material, I'll look into it over the next few days, but I think before I'll try to make my own ECS from scratch I'll start by just using an existing, well designed and tested one to get a feel for how it all fits together.

I'm going to throw this out there because I really believe new game programmers need to keep it simple, and spend more time creating their games with a more straight forward approach. Game programming alone is cluster of problems waiting to happen for new coders, and you don't need more webs to tangle you up during the process.

Unless you have a good reason, why don't you just create standard classes and make due until you're more experienced. Here is an example:

Enemy Class - has name, type, hp, attk, def, gold, alive, ect... You will have functions that will manage those attributes, along with collision checking, attack status, and alive status. You will also have a setup function that will match the enemy with the desired monster name, stats, ect... as defined by type id. Then when you create the enemy you can just do Enemy Orc1(1); - 1 being the orc function so in your constructor it sets up the enemy attributes based on the assigned enemy id, or Enemy Dragon1(2); In your constructor you would have something like a switch statement that sets the attributes depending on which value is being fed.

Then make your player class to handle everything you need and make those functions as well.

When you're playing the game you can just pass one object through another to make changes as needed.

player.attack(Orc1) as an example. Then in your attack function for player you will  take the values from Orc to decide your health, gold on kill, ect... and during this process you will either die or kill off the Orc, and update the Orc object directly, and so forth. Make sure you're not passing copies, so your functions need to be created with that in mind under attack(Enemy& a), then pass Orc1 into player.attack().

Don't over complicate or over do anything at this stage. Even if you have to make a ton of different classes to represent objects in the game, you'll still be better off in the starting stage so you can at least make a basic 2D game without worrying about templates, inheritance, components, ect... The more you program the better you will become, and overloading yourself isn't the way to go regardless of what people consider the "best way", it's not the "only way".

I want to point out that, from what I've understood the OP is facing the same problem he faced 2 years ago, without progress... So if the more obvious suggestion to keep it simple and avoid composition didn't "cut it" for him  in the past 2 yers (here I am assuming the OP asked for help at the time and also practiced programming since then), maybe a different strategy is required... maybe what works well for one might not work so well for another, imho 

Well my cycle is something like this:

Get the desire to make a game, start a new project and program for a few weeks, hit a brickwall, get a feeling that I'm doing it all wrong, ask on some forum, still can't figure it out, give up, pause for 2 years and then it starts all over ;P

I've mostly programmed small stuff, where I don't need a big complex system working together. (Chrome extensions, an addon for world of warcraft, a level editor (in C# .Net) for my last attempt at making a game).

The only thing I never understood is how to seperate everything out logically to not have one monolithic class and then wire it back together.

A level class that loads a level from file, player class that takes care of moving, shooting etc, enemy class with some AI... Somehow I always end up with the same structure everytime where everything needs a reference to everything else where I might as well put EVERYTHING in Singleton classes...

17 minutes ago, Horscht said:

Well my cycle is something like this:

Get the desire to make a game, start a new project and program for a few weeks, hit a brickwall, get a feeling that I'm doing it all wrong, ask on some forum, still can't figure it out, give up, pause for 2 years and then it starts all over ;P

I've mostly programmed small stuff, where I don't need a big complex system working together. (Chrome extensions, an addon for world of warcraft, a level editor (in C# .Net) for my last attempt at making a game).

The only thing I never understood is how to seperate everything out logically to not have one monolithic class and then wire it back together.

A level class that loads a level from file, player class that takes care of moving, shooting etc, enemy class with some AI... Somehow I always end up with the same structure everytime where everything needs a reference to everything else where I might as well put EVERYTHING in Singleton classes...

If you've made a level editor with C#, you should be able to make a basic PacMan game. Didn't you create classes that handle save, load, tile selection, tile loading, painting, object attributes, ect...? You just create a class for PacMan, the Ghosts, Items, and Dots, and use Tile Collision with a 2D array for the map.

Then your game loop

Game Loop {

Input() -> Keyboard commands move PacMan (Keyboard.Up) { pacman.moveUp(); }

Logic() -> Move Ghosts - Check Collisions - Item Pickup Check - Dots - Game Over? - Next Level?

Draw() -> Render sprites based on Tile Map + Object locations + PacMan and Ghosts

}

"A level class that loads a level from file, player class that takes care of moving, shooting etc, enemy class with some AI... Somehow I always end up with the same structure everytime where everything needs a reference to everything else where I might as well put EVERYTHING in Singleton classes..."

I don't see this as a problem. You need to interact objects. How else does the player know if they've been hit by the enemy with a sword? You're going to be doing a lot of comparing in programming, this isn't a new or unordinary process. I've programmed a lot of editors and 2D games by using classes to handle level loading, enemies, items, ect... I can just re-use and slightly modify the code to make my next project even quicker.

Yes you can use spaghetti code even, but I don't recommend this.

Well I wish you the best in moving forward. I really cannot help you if you've been stuck for that long as I don't know how to change your thought process. If you post code I can assist more, but the rest has to come from you. If you're new to game programming then stick to the basics, don't skip ahead unless you want to cause more confusion. Maybe look into using GameMaker as opposed to programming games if you're already at the last straw.

3 minutes ago, Rutin said:

If you've made a level editor with C#, you should be able to make a basic PacMan game. Didn't you create classes that handle save, load, tile selection, tile loading, painting, object attributes, ect...?

I think for that I misused my MainForm as a giant "Service Locator" ;D With tons of properties for getting a reference to anything and a static "GetInstance" so from anywhere I could just type MainForm.GetInstance().ActiveTool to, for instance, get or change the active tool from anywhere... It kind of worked but there was basically almost no encapsulation whatsoever.

I'm far from an expert, but the most useful bit of advice that I've ever gotten was to know exactly what you want. If a problem seems huge and intractable, then it is only because you don't fully understand what you're trying to do. In reality any challenge can be overcome with enough work; true problems only arise when we start working in circles because we don't really know what we're trying to achieve.

Therefore, for any large or difficult project the most important thing is to have a design document. Decide exactly what you want and write it down in full detail. Imagine that you're going to pay someone else to make the game, and they'll only do the absolute minimum to get their check, so anything you don't put in the design document won't end up in the game. The process of making that document will clarify countless issues that you never even realized were issues. All the relationships and interactions between entities will be laid out explicitly,  and all the mysteries and confusion will be gone, and all that's left will be to straight-forwardly implement the plan.

The abstractions and names that you create for things while explaining what you're trying to achieve will serve you well during implementation because they will become the data structures and classes, and so it will be obvious which classes must naturally talk to which classes based on their role in the design.

In other words, it's easier to tell Visual Studio what your game should be if you first tell it to Word.

1 hour ago, Horscht said:

Somehow I always end up with the same structure everytime where everything needs a reference to everything else where I might as well put EVERYTHING in Singleton classes

You can just make one singleton, a main class that holds shared_ptr pointers to the other class: Input, logic, rendering, etc. Then logic can be in control of managing the actors.

1 hour ago, Rutin said:

I don't see this as a problem. You need to interact objects. How else does the player know if they've been hit by the enemy with a sword?

Also, use an event system. This makes it so that the other classes don't need to know much or anything about the other classes. Here's a link to a c++ version of it.

https://stackoverflow.com/questions/7464025/designing-an-event-mechanism-in-c

Also, check out my post below. I don't want to retype the same thing as before. Its about c++ instead of c#, but it might help.

15 hours ago, MarcusAseth said:

I would like to know the reasons for this

 

Because they're a mess. Because it adds complexity, rather than removes it. Because nobody on these forums or elsewhere has any sort of consensus on how best to approach them. Because the only people who are productive with them are people who don't need to ask questions on forums like these.

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.

Horscht, my initial advice applies - stop worrying about how to structure the whole app. Just make what works and refactor as you go, asking specific questions about your code if necessary. People here are happy to help on your journey, but they can't give you a full roadmap.