Tutorials give you a start, but don't forget that you need to write code to learn to write code well. If you read through the tutorial series from start to finish, without stopping to write some fun programs in between, then you'll probably fail to develop intuition and fluency. Slow down, write some cool toys, and when you finish the series it will be with far higher fluency than otherwise.
At first breaking problems down into explicit enough subproblems to start solving them will be difficult. This will become easier with experience. Soon translating from thought to code will become easy, and the main burden will shift from how to write something, to what you ought write.
For learning, I'd advise writing a bunch of tiny games, without an engine, increasing in complexity with your skill.
You can get started right away (well, after functions/variables/printf/scanf/if/while) if you make small and simple CLI CYOA/IF games.
Then make something more complicated, a tiny CLI roguelike maybe (see nethack if unfamiliar). You'll want to become more familiar with C at this point (malloc, free, intuition for pointers (literally just memory addresses), structs, and linked lists (just implement them, don't go find a library or copy/paste, it's short and good practice)). Eschew ncurses and portability here in favour of system("clear")/redraw the game/getchar() and a simpler interface.
You're looking to practice and have fun here, not make a cross-platform user-friendly game with a complex and slick interface. ncurses and the like would be overkill, boring, and probably frustrating for having to deal with antiquated faux-teletype shit. Just hardcode the width/height if you like, you're just learning here and will never need to support other sizes since this is just a fun and useful stepping-stone not a polished product.
While you could probably go straight for an engine at this point, writing a small 2D game using SDL will give you a nice big chunk of experience. You'll want to be comfortable with breaking down problems and solving them in terms of code by now, this will come with practice. SDL is nice and easy IIRC, http://lazyfoo.net/tutorials/SDL/index.php
At this point you'll be wondering if you should use opengl instead of SDL's functions. No, fuck that for now, you don't need it and it would only slow you down without benefit. Do it later, when you have good reason (e.g. 3D graphics/constrained by SDL), or never (if you like engines or don't feel constrained by SDL).
This will get you some experience writing a decently complex program where you can't just throw it out and rewrite it all on a whim. Don't bother making menus, just make the gameplay and worry about the rest later. You're here to learn and have fun, not make a product, so fuck the menus. Worry about UX when you have something worth polishing, until then YAGNI.
Never throw code out because you read something along the lines of "X is bad, code which uses X is bad, X considered harmful." Rewrite code only after it causes you pain (buggy/hard to work with/leaves too much busywork for the caller), or when it significantly improves something you care about (speed/memory/beauty (but don't get too into this, code is ultimately a means to an end)).
Most importantly don't decide that something is above your understanding and fail to pursue it. Look for example code that uses it, and figure out what each line does. Don't copy/paste without understanding, take the time to understand and you'll save time in the long run. The last thing you want in your work is code you don't understand. Read the docs until they're no longer intimidating. Sometimes it isn't you, documentation can just suck.
NB: Don't try to write an engine, just write the game. YAGNI.
FYI: You only have to learn to program once, moving between languages within a paradigm is easy. Moving between paradigms is just exciting because of all the new ideas you get to try out.
Have fun making stuff, and good luck.