I write games in C (yes, C)

I write mostly like I would in C, but use C++ features as needed. It ends up looking similar to Rust if you squint. All these "I write games in C" people complain about C++ features, and then end up reimplementing virtual interfaces manually with struct headers or massive switch statements, just to feel better about themselves. Writing games in C is not harder, you just have to implement modern language features by hand.

Complaining about a language having features you don't want is silly. C++ doesn't take longer to compile if you don't abuse templates.

I'm pulling apart and rewriting so far a little in C a personal fork of OpenTTD 12.2. I began on it a few years ago for the first time for the heck of it after patching for realtime, began again while adding features I wanted until I hit a bad enough snag, and now began again by first extracting most used functions and profiling with Valgrind inbetween.

Things I noticed are inconsistent coding styles, overly complex processes, unused(!) functions, inefficient data use, nothing surprising with a project worked on by various people in their spare time and their own ideas on how to code. And this isn't even talking about later versions. To me it's an example of how unrestricted access to bling features causes a mess.

Eventually I want it converted to C (C23), split apart in seperate functions with a decent source code organisation, and simplified processes to make it easier to understand what's going on and extend fuctionality. For this I need it simplified as possible and weed out the layer of complexity caused by C++ first. Going to take plenty of time, but I'm still having fun doing it (most of the time anyway :-p ).

I'm not advocating anything, but it's satifying to me to bring clarity to code and see small improvements to performance during the process at the same time. It also gave me an opportunity to develop a unique syntax style that visualises parts of the code better for me.

>Death of flash

>The library support for games[in Go] is quite poor, and though you can wrap C libs without much trouble, doing so adds a lot of busy work.

I can't see when this was written, but it has to be around 2015. So, about 10 years ago. I wonder what his opinion is today.

It's not unheard of, but you have to be a little crazy to do this in 2026. I developed Chrysalis entirely in C (with GLFW3 and FMOD for audio): https://store.steampowered.com/app/1594210/Chrysalis/

I always liked C. I enjoyed how brutal it is, except the preprocessor.

This is why zig is a godsend. It is actually simpler than C while being more precise than C!

For example zig can distinguish between a pointer to a single element vs a pointer to an array of unknown length. Where as in c abi, it is all T*

When importing a c lib, you can make it more ergonomic to use than c itself.

Being able to easily import c lib is especially important to game dev, as practically all so called c++ libs also export a c header as they know how important it is.

https://github.com/zig-gamedev has a lot of repos of ziggified c libs used in games.

As for the preprocessor, zig comptime is so much better. It’s just more zig that runs at compile time.

I totally resonate with the author of the post. My main requirement to enjoy a language deeply is often simplicity, so I love languages like, C, Golang, Odin and Zig.

That said, I also acknowledge that often times I need to solve problems that can benefit from a language that embraces what I call necessary complexity, but do it in elegant ways. Whenever I need to prioritise code correctness, especially memory and concurrency safety, using a mostly functional pattern instead of OOP, but without going as extreme as say Haskell, I unquestionably choose Rust, my favourite complex language. I often work with network code that is highly concurrent, must be as correct as possible and benefits from good performance, so then again, Rust feels natural here.

On the other hand, I love coding simple indie games and for that particular case, I like a simple and performant language using an imperative, non-OOP style. In my opinion C, and in particular Odin more recently are quite a good fit. If Jonathan happens to be reading this comment, since he mentioned Golang, I would suggest him Odin as perhaps the best of both worlds between C and Golang. It has all the simplicity of Golang, but without a garbage collector, plus it is quite easy to code a game using Raylib.

"nobody does this"

Well, this should be reformulated a bit. Using C is not the norm, but it once was and many people are still using C to write games, myself included.

In my core I'm the same. C is my language and served me well for decades. There's nothing inherently major wrong with it until you reach one of the two (or both). Working in a group of people on a C codebase tends to introduce pain on multiple levels unlike some other languages (yes, including C++). The other is that anything takes a long-ass time to do compared to modern alternatives, which might also be an issue if you're developing a game; Especially if you're developing a game. Having said that, I can't disagree since as I said, I'm also inclined towards it's siren call of simplicity.

Literally thousands of games have been written in C, and all graphics APIs (OpenGL, Vulkan, DX) are C APIs, so it isn't weird at all. All major game engines are also written in C/C++.

I did read the whole article thinking "who is he, his name reminds me something, but why isn't he providing game names?" and so on. Then I clicked on "back to main site". Revelation. A lot of his games are jewels. I have a special thing/relation with Sportsfriends. So many hours of fun while playing with my son.

C has very low entry level, providing that you have some knowledge about memory management. When, as a Java developer, I had to quickly deliver some exchange connector using given .h and .so, I chose C, because C++ had too high entry level. If C is a sharp knife, C++ is a rotating pell post full of sharp knives. You can cut yourself even if you think you're safe.

But I find string management in C awful and would like to borrow it from C++. Only the string management

Has anyone got any good resources for something like this? I haven't touched C in years, and never worked on anything game-like. But it does look like a really interesting project to start something like this.

I need RAII and refuse to debug ugly macros as a workaround. The STL isn't perfect but it's a good guiding principle.

As a hardcore C programmer and zealot myself... How in the hell can you be productive like that? C is a systems programming language, not an application programming language, let alone relevant to the levels of abstraction you'd want in game development.

That said, "I am dead" is a very real video game indeed... and his arguments are very sound. I also can't stand C++. I disagree with him on Java though. The core language of Java is actually super simple, like C.

>I really dislike javascript, it is so loose that I marvel that people are able to write big chunks of software in it. I have no interest in trying.

Because they use Typescript.

>The stop-the-world garbage collection is a big pain for games

There is a number of languages that allow manual memory management: Zig, Nim, Rust and few others

I want to write general apps in C. Such as a raster image editor. I have some idea and C has exactly the right mix of simplicity and flexibility that I need. C is a constructor, and as a constructor it places few limits on what you can do. Other environments are way more rigid. E. g. I find Python way too rigid compared to C.

People did do that, 30 years ago.

Then Watcom C/C++ made it quite easy to use C++ for game development on PCs, PlayStation 2 introduced support for C++, quickly followed up by XBox and Nintendo, and that was it.

Yes, C. Like all id games up to... Doom 3, if I'm not mistaken? Only then they switched to C++. There's absolutely nothing impressive about this fact.

Nice looking games though.

Come try Odin!

I've been writing a good chunk of C lately for some stuff that has some relatively high memory constraints (lower than I could squeeze out of GraalVM).

I know I could do C++, and you could argue that's better, but I find C++ to be exceptionally irritating to use. Every time I've used C++ I get people telling me I'm using it "wrong", sometimes in contradictory ways. Sometimes I should use a "friend" function, sometimes "friend functions are evil". Sometimes multiple inheritance is fine, sometimes it should be avoided like the plague. Sometimes you should "obviously" use operator overloading, sometimes you should avoid it because it's confusing because you don't know which functions are being called.

I'm sure someone here can "educate" me with the best practices for C++, and maybe there will be some reasoning for it, but ultimately I don't really care. I just found the language annoying and I don't enjoy using it. I know that I could "just write it mostly like C and use the C++ features when I need it", but I have just found that I have more fun thinking in pure C, and I've kind of grown to enjoy the lack of features.

Maybe it's just a little bit of masochism on my end, but I like the fact that C gives you so little. You kind of have to think about your problem at a very fundamental and low level; you have to be aware of how memory is allocated and deallocated, you don't get all these sexy helper functional-programming constructs, strings aren't these simple automatic dynamic things that you have in basically every other language. You have a dumb, simple language that will give you exactly what you need to write programs and very little else.

Most stuff I write uses a garbage collector, but the safety and easy of writing stuff with garbage collectors like Java makes it very easy to be lazy. I've grown to appreciate how much C makes you actually think about problems.

I was also really surprised with Haxe, I share the author’s concerns about its future, other than it’s quite fun to work with.

(2016)

> when it comes to compilation I can't think of anything faster.

What languages compile fastest?

I write all of my games in pure C++. C++ all the way. FMOD for the audio engine, Steam Audio or Atmoky TrueSpatial for HRTF/geometric occlusion, and Jolt Physics for, well, physics. I'm sure many might say I'm a bit insane to do that, but eh, I do it anyway because it's fun.

> I like Go a lot. In many ways it is C revisited, taking into account what has be learnt in the long years since it was released. I would like to use it, but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do.

I'm no Go fan, to be clear, but GC isn't the problem with Go. It has a pretty decent GC with sub-millisecond pause times. People who complain about GC pauses while extolling the virtues of manual memory management are running on a set of prejudices from 1999 and are badly in need of a mental firmware update.

its funny how writing games in C is now seen as some kind of 'hardcore mode', despite the fact that a huge number of excellent titles up to and including the 2000s were written that way.

the core of games tend to be a 'world sim' of sorts, with a special case for when a select entity within the world sim gets its inputs from the user.

where C becomes a chore is the UI, probably has to do with how theres many more degrees of freedom (both in terms of possibilities and what humans consider appealing) in the visual plane than there is in the game input 'plane', which might be as little as 6 independent inputs plus time.

Plenty of people cycle on a fixie too. So what? C, especially modern C, does provide metaprogramming and abstraction facilities. In practice, you can even get things like the "defer" construct from other languages: https://lwn.net/Articles/934679/

The question isn't "Can I write a game in C?". Yes, of course you can, and it's not even that painful. The question is "Why would you?", and then "Why would you brag about it?"

> C++ covers my needs, but fails my wants badly. It is desperately complicated. Despite decent tooling it's easy to create insidious bugs. It is also slow to compile compared to C. It is high performance, and it offers features that C doesn't have; but features I don't want, and at a great complexity cost.

C++ is, practically speaking, a superset of C. It being "complicated"? The "insidious bugs"? It being "slow to compile"? All self-inflicted problems. The author of this article can't even fall back on the "well, my team will use all the fancy features if I let them use C++ at all!" argument pro-C-over-C++ people often lean on: he's the sole author of his projects! If he doesn't want to do template metaprogramming, he... just doesn't want to do it.

I don't read these sorts of article as technical position papers. People say, out loud, "I use C and not C++" to say something about themselves. ISTM that certain circles there's this perception that C is somehow more hardcore. Nah. Nobody's impressed by using it over a modern language. It really is like a fixie bicycle.

[dead]