Should I start off this complex?

[crdl_pls]

After I made my first proper...well thing using SFML (https://github.com/Crdl-Pls/Pang), I wanted to see if I could work on my code management a little bit, and work a bit more with the features that C++ has to offer, while getting some tips from the SFML books.

https://github.com/Crdl-Pls/Asteroods
This is what I have so far. I have a very bare-bones entity manager class handling the creation and destruction of entities. I want a texture manager class too, to manage the textures that each entity has. Now looking forward, I think I can do it, but it will take me a bit of time to get right. Am I wasting my time making this overly complex for my second real project using SFML, or will I be better off for it in the long run?

Any tips, based on my code as it stands or for the future, would be a massive help also.

[Mörkö]

You're doing just fine. The very fact that you are worried about over-engineering indicates that you would recognize if you actually started going down that path.

From personal experience, and from reviewing other peoples code, I have noticed that many novice programmers tend to hack together the bare minimum solution required to fix one single problem as quickly as possible. They then go on to build the next thing on top of that hack instead of refactoring the current code into a sane state, thus creating unrefactorable spaghetti code mess.

For a small demo, that is completely okay. But for anything that is more ambitious than the very simplest of games, having some architectural plan is unequivocally beneficial.

These are good things:

• modularization
• separation of concerns
• functional programming
• unit testing

So depending on the scale of your project, thinking about and employing those concepts might end up taking more time than if you just hacked the solution for immediate results. But striving towards those things will help keep your code clean and make you a better programmer in the long run

[crdl_pls]

This is all really useful, I'll take this all into account when working on projects in the future. thanks

[Nexus]

These are good things:

• modularization
• separation of concerns
• functional programming
• unit testing

I'd like to add code reuse, which includes existing solutions to commonly known problems, as opposed to re-inventing wheels. This is probably why we're all in this forum

crdl_pls, you should have a look at how existing libraries implement the managers you're talking of: for example for entity component systems (ECS), or texture/resource managers from Thor.

But if you're more or less new to game development, forget about ECS for the moment. It's a hyped keyword, and many people praise it as the ultimate, one-fits-all solution, even though it brings its own range of problems and complexity. I suggest you go without ECS for a while, because only then you experience some of the problems that led to the creation of ECS yourself. You truly risk getting lost in overengineering when you apply complex patterns as a beginner or intermediate -- this doesn't only apply to ECS. It pays off to encounter new concepts with a bit of skepticism and actually ask yourself (and others), what advantages they bring and if they're worth the learning effort at that stage.

In game development, there's tons of more fundamental things to learn first. A really nice resource is Game Programming Patterns. When it comes to C++ patterns, I have once compiled a list of things I consider important.

Regarding concrete tips to your code: use actual constants in your constants header, use unique pointers, prefer .hpp headers (.h is usually C), have an in-depth look at the STL (which will be your working horse for the upcoming years), replace if (x == false) with if (!x).

[GraphicsWhale]

But if you're more or less new to game development, forget about ECS for the moment. It's a hyped keyword, and many people praise it as the ultimate, one-fits-all solution, even though it brings its own range of problems and complexity. I suggest you go without ECS for a while, because only then you experience some of the problems that led to the creation of ECS yourself.

Completely agree. The ECS brings in enough problems that I'm completely opposed to it's usage in these small projects (such as pong or asteroids clones), yet beginners still seem to try to find ways to do it. Plus, there's overhead to all that dynamic memory allocation, dynamic_cast/typeid's, cache misses, etc. An ECS is mostly there for decoupling large, complex subsystems from one another as well as make it easier to change the behavior or add certain entities without having to re-structure an entire class hierarchy.

[Satus]

Completely agree. The ECS brings in enough problems that I'm completely opposed to it's usage in these small projects (such as pong or asteroids clones), yet beginners still seem to try to find ways to do it.

While I agree, I must say beginners do that because it is easier to learn and get used to ECS on something simple like pong clone instead of starting something more complex later without such experience.

[GraphicsWhale]

While I agree, I must say beginners do that because it is easier to learn and get used to ECS on something simple like pong clone instead of starting something more complex later without such experience.

It seems more suitable to learn about ECS's with something a bit more complex, such as a Mario clone. With a pong game it'd take up most of the code thus obscuring why they're useful (in complex projects).

That and when you're trying to learn the basics of game programming, learning to use an ECS is something you do later on with other more complex things like 3D graphics (at least in my opinion). The ECS pattern's popularity is something that is only relatively recent in the history of game development, so there's a myriad of successful games out there that don't make use of it, which goes to show that it's not totally necessary.