Since it is claimed that suckless games are more efficient, I got a try at anarch.
First thing, it required me to install 2 development packages that I didn't had yet (sdl backend): libdrm-dev and libgbm-dev. And when playing, I noticed that the clipping is broken as can be seen in those screenshots:
and
(the lightbulb disappears).
Overall, the lack of proper lighting makes it difficult to notice movable stuff correctly, and there is this constant bouncing when moving which really feels awful. The text of the main menu is barely readable. When playing, my CPU runs at 2400MHz in average, compare with unvanquished (a game you would probably despise) which makes it run at roughly 2800MHz.
Indeed, anarch uses less, but compared with the difference of features, anarch is obviously slow.
I stopped playing after few minutes, because the game feels empty and rather boring.
Now, to the topic.
No unicode.
Well, unicode, or at least UTF-8 is indeed more complex than fixed byte size characters, since each character can have a varying size. Still, the features it brings are more than worth it, because it allows people from other cultures to use the softwares.
Built-in configuration.
When I play a game with those, most of the time they have qwerty bindings. Incompatible with my keyboard, and no, I will not switch my layout to please those games: I will just remove the game from my disk and play one with a config file instead. I had the nice surprise to see that anarch is not affected by that problem, because it (problably) uses "hardware key numbers" or whatever the name. This still means that one would have to rebuild the game to change setup. And learn C, the only lang you deem worthy, but also the lang which makes it the most painful to write code which does not leak.
Only C99, use global vars, all code in one unit.
This is sick. If you want a maintainable codebase, you will really want to have proper "public" API.
In C, this is done by using "modules", aka: split the code into multiple files, and only have the public API in the header. This way, it is much easier to change something without the fear of breaking something unrelated because all use damned global variables. Oh, I would be sad to forget this: C++'s std::sort is faster than C's sort. This is one of the examples which show that C actually sucks (at writing fast code, at writing code fast, at writing safe code...).
No Object Oriented Programming, only imperative programming.
Well, if you want the game to be moddable, why not just give an interface class and make the mods inherit from it? This way, the compiler, not you, can check that there is no nasty error. You confuse OOP and bad practices.
I can make C++ programs run on baremetal which have no FPU, so that you know.
By saying "only imperative" do you also close the door to other paradigms like component base systems? Those (like OOP) were invented to ease the task, why do you reject them just because people tend (in my experience) to abuse them?
To me, programming paradigms should be used reasonably when they are efficient. This includes OOP, CBSE, imperative, relational databases, and much more. All must not be used every time, of course. They have to be used wisely, or the code will become a huge spaghetti mess. This is true in all paradigms, all architecture models.
I, like you, consider that dependencies should be avoided when unnecessary, and be kept at a sane number. I, like you, strive for more efficient computing. I also agree that complex codebases makes it harder to benefit from FOSS freedoms.
But those points are not achieved by sticking to old tech which makes it painful to write code which actually works flawlessly and being elitist (yes, I also think you are elitist "all should know how to code C99, all should learn english, all should.... other is bullshit, other is bloat, other is shit" <- this is how your words can be interpreted).
Years ago, even GCC people started to accept embedding C++ in the compiler, because it would allow them to get rid of their garbage collector, which was slow and written in C, to handle their C code (because clang was, in comparison, using a lot less ram and a lot less time, they had to move their asses out of "simple" C tech a bit).
What is, in my opinion, important to write maintainable code bases is to split the problems in multiple parts, with clear, documented, API.
Those parts can be C "modules", classes, CLI interface, sockets, it's not important. What is important is that those API must be documented and as generic as possible. This makes the code easier to work on, easier to reuse, and thus easier to optimise.
Since the topic here is about games, I'll add few things:
Games are meant to be fun and easy to use. Asking players to patch the game themselves will not work. Even with me, it won't work, despite the fact I'm a dev (mostly using C, C++ and bourne shell).
Many games require AIs of some sort. If you do 3D games, how will you implement path finding? With raytracing? With A*? That can work, to some extent, but there's a reason why some people try to use navmeshes, despite the tech being more complex (I'm trying to improve that part in a game, I can at least tell that DetourRecast is complex, it have rather bad documentation, and still require other means of "computer vision" to implement correct stuff): it makes the AIs find their path with less runtime CPU resources.
Player's ability to cheat in multiplayer games is a real problem (on solo games, nobody should care). Thus, I am curious to see how you would implement network in your suckless way.
Note that, when doing networking, you might want to allow people to share their mods and maps, so having all built directly inside client's code will be hardly a good way. Games like Red-Eclipse rely on scripting, others like Unvanquished rely on virtual machines. RE1.6 is more vulnerable to cheating, due to AIs being ran by clients instead of server, plus the server does not do anything, it more or less just broadcast stuff. Unvanquished have AIs server side, and server checks a lot of stuff. The tech is, though, a lot more complex.
As you see, both approach have pros and cons, but both approaches would not fit into your guidelines. What would you do? I have seen someone mentionning building a MMO RPG. On that, I thought "Well, a new mana world I guess" but even that is not really easy. The notion of server-side stuff is rather important here, so I'm really curious at how this would work with those guidelines.
I intend to write some game from scratch, too (instead of contributing to old codebases which actually work), in a near future (after completion of lot of other dev projects... ok, maybe not near future I guess). I intend to implement the gameplay in prolog. Thus, will it sucks according to your "guidelines"? Probably.
Still, prolog have some advantages you should consider: the program is very, very close to a configuration file. Unlike C, it is reasonably easy to modify it for non-dev people, which is normal considering the fact it was a design goal of the lang.
Basically, I would write "servers" in prolog and "clients" in C++ probably, because "clients" require performance (prolog is not good to do calculus) and there are more libs already available for GUI stuff in C++ than in most other languages (and clearly more that in C, since all C code can be included in C++).
This is the problem when you put guidelines which are too specific.
Why do C have UB? Because not specifying things allows it to be more portable and more efficient. You should apply that principle of genericity to your guidelines, too, even if that means that you can not promote "The Best Language Of All Times Lol".
There is also that "let's fight worldwide economy" thing which.... hmmm... let's see that it does not help.