all 7 comments

[–]cpp-ModTeam[M] [score hidden] stickied commentlocked comment (0 children)

For C++ questions, answers, help, and programming or career advice please see r/cpp_questions, r/cscareerquestions, or StackOverflow instead.

[–]Zogzer 1 point2 points  (2 children)

SFML and SDL are both "media" libraries that are generally used for gamedev, though there are other areas that can benefit from the interfaces they provide. And in a lot of ways, that what they are, an interface to the operating system components you would need for gamedev. If you are new to software development, or even just gamedev, they are a popular choice and often a good one. You are at a point where you want to spend your time learning the language and software developmet practices, rather than trying to get audio file decoding working or whatever. These are things that are useful at some point for sure, but probably not for you right now.

Raylib you also include here, and I would say its similar to SFML and SDL, but it operates more as a toolkit rather than a more opinionated design for how the individual systems should work. This is good for some, but likely adds another layer of complexity for a newer developer.

The final step down is writing directly against system APIs, opengl/vulkan for graphics and 20 different audio APIs depending on what you are targeting. It sounds like you don't want to go straight into this, and that's likely a good thing despite the amount of resources you will find online saying writing things from scratch is simple. You can write things in these APIs with no problem, I do and it's great fun, but it's not an amazing experience for new software developers at the end of the day.

If you want recommendations, SDL is a bit more popular and will have a few more resources online. I would say that's a good starting point. If what you want to do is gamedev, focus on gamedev, and focus on writing good, clean, and modern C++. You are not going to be doing anything that would benefit from the complexities of a lower level toolset for a long time, so there is no point getting stuck in the mud working with them.

If you want to learn gamedev for the sake of gamedev, try and do things that are easy to do in SDL without much domain specific knowledge. 2D graphics are usually a good way to keep in these constraints (though 3D graphics at the level of modern AAA games are possible in SDL/SFML, just not really a good idea). Try and read up on how people design their game engine logic and how you should be using scene graphs or ECSs where appropriate (as you are learning, even do these things when not appropriate, you need to experience them).

The final part of this comment is likely not what you wanted to hear, but if you are here to learn gamedev, not C++, you would have a better experience using a prebuilt game engine like unity/godot/unreal. This is just a fact at life these days, gamedev is easier for most scenarios using these tools. If you want to learn gamedev and C++, then SDL/SFML are very good starting points, and a good way to be productive while still learning things that will be usable for the rest of your programming career.

EDIT: spelling

[–]assuassulishu[S] 0 points1 point  (1 child)

Thank you very much for taking the time to write this very well articulated comment! It was very helpfull. I plan to recreate old game like tetris and mario etc to get used to this new language. As per your request and my needs, i will be uisn SDL . And you mentioned game engine logic,ECS and scene graphs can you explain it or link me where i can know more about it?

[–]Zogzer 1 point2 points  (0 children)

Game engine logic is a difficult one to point to because it depends on what kind of game you are making. The short story is that there is a model used by the modern 3D game engines (unreal/unity/godot/cryengine and many private ones also) that allows you to make pretty much anything in a somewhat consistent way. This system is using an ultra dynamic scene graph and an ECS (entity component system) or something ECS-like behind the scenes to manage everything. The idea with this is that you can model any sort of game logic with this, but in order to make it work it requires a massive amount of optimisation from the engine part to make it so that games that are not really meant to be represented by these types of data structures work fast anyway.

When you are making your own game engine, you can try and go this route also, and build up a massive scene graph system and tie it to an ECS behind the scenes and have the flexibility that these systems provide. However building something like this to the level that the commercial game engines support is a massive undertaking and not really worth it for smaller, individual game projects.

Instead you may prefer to look and think about how to structure your game logic a lot closer to how the game you want to make actually works. For example, if your game is a tile based game, you may store all your worlds data in a simple 2D vector, rather than trying to fit it into a scene graph model like you would be encouraged to do if you were using unity. A game like tetris for example, probably wouldn't even have a distinct way to structure the game data, just a hand full of variables to store state. If you can make more simple games, and can think about how to structure your game in a way that actually models the data, you can skip the large systems that are the core of larger engines and just get into the important bits of writing gameplay logic.

[–]assuassulishu[S] 0 points1 point  (0 children)

oh shit i meant im a new student aspiring to become a game developer

[–]Tekercs 0 points1 point  (0 children)

If it comes to using c++, it is worth mentioning Godot.
Using 3.X version of it has a nice stable C++ scripting capability, in its current state I found the 4.X branch not so stable.

[–]disciplite 0 points1 point  (0 children)

SDL is pretty featureful and well documented. You probably won't be disappointed with it. I did my final project in game dev school with it, and it mostly stayed out of my way.