A many aspiring game devs fetch the latest version of Unity, and get a surge of motivation when they manage to instantiate their first cube. Henceforth follows multiple hours of failing at creating a car using the inbuilt physics engine and rigidbody system. The Unity application lays dormant...
If you identify yourself in that paragraph, I implore you to try a more minimalist framework. I was hesitant to try them, since I was scared that it would be even harder than using the more complete engines, or at the very least more work. It wasn't before I was assigned to create any project for a university course.
While browsing the previous years projects, looking for inspiration, I found a game made in SFML in C++. Having tinkered a bit with C++ in a previous course, I thought that would be interesting, and boy did it change my view on the usage of frameworks and libraries.
I was under the impression that larger and more complete frameworks gave you a boost in the early stages of a project, with ready made systems and components that could be used to prototype and iterate on. This would then come at the cost of vendor lockin and lack of flexibility at the later stages of development.
While in theory this may not be false, in practice you will achieve a lot higher velocity in a lighter and more minimalist framework. The way I see it now is that larger game engines are better for larger projects, usually with multiple contributors. It's with these preconditions where a larger framework will assist you in the long run.
If you are making something yourself however, you will probably save time (and motivation) that would be used to tinker with and read up on how to use the engine. Instead you can use that time to just implement it yourself.
We want to create a top down racing game, original I know (I you want to get started with gamedev, but haven't made anything yet, I heavily recommend starting with a top down racer. It is easy to implement a MVP, while still having a lot of room to iterate). Here are the steps for a initial MVP:
Done. You now have a MVP of a top down racing game. Now comes all the things where you might think you want a game engine for, but actually you don't. A good place to start is to add momentum, you might think you need some physics simulation, but you really don't. There are many ways to achieve this, but to start with, I would add another rotation variable, to seperate the cars physical and movement direction. Every tick the car moves in its movement direction, but the movement direction tends towards the cars physical direction.
You get the idea, you can achieve a lot with small and concise solutions, rather than monolithic systems. To continue, you probably want to add a max speed, or atleast limit acceleration in relation to current speed. Another feature is to add debris in the form of sprites that eventually despawn. You also want to scale the rate that movement direction follows physical direction based on current speed (higher speed -> slower movement turning).
The reason I provided this example is to show you how approchable a basic game flow really is, and while you can implement this in a large framework, you won't be using any of the built in features that signify these frameworks, hence you don't even need to use said framework. Go ahead, take the plunge, it really isnt that deep.
Here is the frameworks that I personally recommend:
Also, if it isn't obvious, this applies to all software sectors, not just gamedev. The fastest site to build is a raw HTML page. The easiest API to build is probably a PHP script alongside a SQLite file.