@JoeJ & @fleabay Yeah, all that is mainstream means of working around issues. By the way, I realize that at least a few tools will have to be used by me, both third-party & my own built ones.

I actually want to make a few tools, but later down the road, like a months or a year or two. There are even libraries for making tools, of course, on any need.

Tomorrow I begin downloading everything, building, and installing, I am on Linux, so some of it must be built from source, which is easy for me most of the time.

Time to get to work at it! My goal is that by the end of the day tomorrow, I will have made a simple application with 1 texture, sound, and input.

I think that I just have to bury myself in work and sort thru the mess of beginning development according to my goals and tools. Nobody has assembled a development flow for me like I envision, so I will do it myself.

Thank you, everyone!

Do you want to spend your time making games, or making tools and libraries?

The existing libraries are already built and debugged. Some represent years of work, some represent work-decades or even work-centuries from large teams of experts and specialists.

There's nothing wrong with doing it all yourself, but don't expect to be making great games when you go that route.

C-Research said:
Tomorrow I begin downloading everything, building, and installing, I am on Linux, so some of it must be built from source, which is easy for me most of the time.

I'd start by just using the package manager for getting libraries, dev-tools, build-tools etc etc. In my experience you have to go into a very niche area before a package manager of the major distributions doesn't have a pre-built and maintained answer for your question.

For 2D sprites, I'd say libpng will work, although you may not even need to handle that yourself, as pretty much anything that produces or needs 2D sprites understands PNG files.

Why does it have to be C? I see from time to time people are interested in developing bigger applications and games in it, but why? I had my first job in C and tried to build software in my spare time using it as well. When I left for other jobs with other languages I realized how tedious it was to code in C and how futile it was to try to build something that runs on a desktop computer in it. If you want to see what you are in for you should look up Randy on Youtube. He had a prototype in Unreal Engine 5 years ago but decided to start over with C. I think he uses the engine made by the creator of Handmade Hero. From the looks of it he is just now starting to get to the same point as he was 5 years ago with the project on this engine. A more experienced developer would of course have gotten to that point a lot faster, but developing games in C coupled wtith not knowing much programming beforehand seems like a long road to travel.

C is of course still running strong in bare metal embedded and operating systems but it's pretty niche these days. I am more in favor of structural programming than OOP and I like the simplicity of C so I'm not saying this as someone who dislikes the language. It's just a bit dated at this point and has very limited tooling.

C has the performance I need to offset the heavy demand of a lot of art assets. My first video games were written in 1984 - 1986 in college using BASIC, then COBOL. I think more functionally and structurally with math abstractions. It is simply the way my brain prefers to operate in regard to coding. I want to spend most of my game dev time with art assets, maybe 2 / 3.

A professor of mine in 1986 showed the class two programs which implemented the exact same video game in COBOL. One code was wordy and the other had a big math algorithm in the middle. The wordy one was about 1000 lines of code and the one with an algorithm at its core had around 300 lines of code - about 1 / 3 ! …. obvious implications in loading, performance, and coding productivity. The coding productivity, he said, is particularly established in reusing modules of math algorithm in future projects. That has always stuck in my mind.

If I can develop games with about 6 to 10 third party libraries, I will be happy and focus on coding and art assets. Very long term, I will create some of my own algorithm and other libraries, including a tool or two. Also, after a couple years of this, I can see introducing a scripting language.

I have intuition that many developers underestimate the power and reuse of aglorithm modules in increasing productivity, which is a major reason why C is often overlooked.

I am strong in math. It is much more efficient for me to depend on my math skills, rather than learning another coding language such as C++. I already know enough about C to develop simple games. Add a few libraries and my games will really POP, given that I am a skilled artist

C is a downright bad language for reusable high-performance algorithms. The main problem with C in this area is that it has no good way to express algorithms generically, without tying them to concrete data structures. Compare C's qsort with C++'s std::sort. Both express the same basic idea, but the latter is both much faster and much easier to use.

There are areas where C shines, and I use C libraries all the time, but reusable high-performance algorithms really isn't one of them.

There are areas where C shines, and I use C libraries all the time, but reusable high-performance algorithms really isn't one of them

Not to be argumentative, but higher languages must generally be slower than C in algorithms, beginner reckless speculation, unless math based algorithm libraries are being used. As an extreme example, would not C# algorithms be usually slower than C ones? I understand that C++ is quite a bit better performing in almost all instances than C#.

It sounds as though you have experienced the difference in C and C++ algorithm performance.

Where does C actually shine, in your view?

C-Research said:
I am strong in math. It is much more efficient for me to depend on my math skills, rather than learning another coding language such as C++.

My bet: You totally overestimate the burden of learning some basic C++. I would try it, along any need for it where it comes up.
Basically that's what i'm doing for decades. After using Basic and Assembler on home computers as a kid i had learned C, which felt like the perfect language to me and i was happy with that.
I learned about C++ soon after that too, but initially used only a few of the new features. Sticking at a C with classes style for many years, it did not really change much for me, nor did i adopt a general OOP paradigm shift.
Only in recent years i started to understand modern C++ better, making my life a lot easier actually. It really helps with producibility and maintenance once the projects become larger.

My point is: You can approach this slowly, pick up only what feels useful right now. Nothing forces you to use or know all features. No big deal, not hard, not much effort.
But - by actually using the language, there is no more barrier to use libraries written in it, or to learn from C++ code of others. APIs are usually in C anyway, or require only a very basic amount of C++.
So you can be still a C programmer at heart, and you can keep your effort on programming languages as low as you want. Imo, it's not the most important thing anyway, just C alone is indeed quite old school, you know ; )