[HN Gopher] I write games in C (yes, C) (2016)
___________________________________________________________________
I write games in C (yes, C) (2016)
Author : valyala
Score : 154 points
Date : 2026-02-07 17:45 UTC (5 hours ago)
(HTM) web link (jonathanwhiting.com)
(TXT) w3m dump (jonathanwhiting.com)
| Keyframe wrote:
| 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.
| uecker wrote:
| Why do you think working with a group of people on a C codebase
| introduces pain unlike other languages? Working with a group of
| people always causes pain, but I found the pain much less
| severe for C than for C++.
| dragonelite wrote:
| In my mind using a simpler language should be less painful
| given there is less to argue about given syntax and versions
| etc. Take c# for example you have multiple ways to do the
| same sort of things.
| Keyframe wrote:
| Your question also hides an answer. You don't often get to
| chose a group of people you work with, and unlike projects
| that self-attract and self-distill ideal profile (like linux
| mentioned in sister comment), you're left with people usually
| not used to ye olde C idioms. With C++ it's a bit easier
| since it is more widespread and supports some of the idioms
| people get used through schools and other projects. Of
| course, projects (should) always dictate a certain discipline
| by different mechanisms, but if certain way of thinking isn't
| ingrained then it introduces just that much more pain to the
| communication layer between people.
| NuclearPM wrote:
| > Having said that, I can't disagree since as I said, I'm also
| inclined towards
|
| Say more with less.
| heliumtera wrote:
| >Working in a group of people on a C codebase tends to
| introduce pain on multiple levels unlike some other languages
|
| linux attracted 2,134 developers in 2025
|
| that kinda weakens your argument a little bit
| jonahx wrote:
| Maybe (and I like C, for the record), but it doesn't follow
| necessarily. It's possible most of those devs were attracted
| by "working on linux," and are putting up with the pain of
| collaborative C. I know there's a movement pushing for more
| Rust.
| Keyframe wrote:
| It proves the argument as an outlier. I explained in another
| comment. You often don't have the luxury of selecting the
| group of people you work with and more often than not,
| especially these days, people aren't used to (C) way of
| thinking which just introduces more noise to the
| communication between people.
| vascocosta wrote:
| 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.
| pjmlp wrote:
| The language is called Go, golang is the website domain.
| ternaryoperator wrote:
| The use of "golang" for posts and comments is desirable IMHO
| because it greatly facilitates search, especially on sites
| such as HN that cover many languages.
| 9rx wrote:
| Searching "site:news.ycombinator.com go" on Google didn't
| yield any results that weren't about the Go programming
| language even after going several pages deep. What kind of
| search problems are you having, exactly?
|
| And why is it unique to Go? I am sure there are comments on
| HN about metal oxidization, making sharp changes in
| direction, Norse gods, and letters of the alphabet.
| pjmlp wrote:
| I suggest admins to rename the post title as " I write
| games in Clang (yes Clang)", given how hard it is to find C
| content.
|
| It might end up finding stuff about a compiler though.
| vascocosta wrote:
| I know, but I often use Golang for two reasons: 1. avoids
| confusion, no matter how unlikely it is in a context like HN,
| and 2. search engine "findability".
| 9rx wrote:
| _> 1. avoids confusion, no matter how unlikely it is in a
| context like HN_
|
| Who would be confused by "Go", but not "Rust" and "Zig",
| which are also common English words not usually associated
| with programming languages?
|
| _> 2. search engine "findability"._
|
| What kind of search engine are you using in 2026 that isn't
| capable of understanding context?
|
| And where one is still using some weird antique thing like
| a steampunk character, "C" is going to be the least
| findable, yet it didn't receive the same treatment. Why is
| that?
| Melonai wrote:
| At least with regards your second point, Google,
| DuckDuckGo, all other search engines. I always have to
| add "golang" because otherwise it just fucks up. I have
| to say that googling for "C", is a lot more dire, and
| because the LLVM people called their frontend "clang" I
| can't even use that, otherwise only clang stuff pops up.
| And even then, once I did manage to convince the search
| engine that I'm looking for the programming language, it
| still decides to just give me results for C++. It sucks.
| win311fwg wrote:
| _> because the LLVM people called their frontend "clang"
| I can't even use that_
|
| Said frontend is for the C programming language. Isn't
| that perfectly appropriate? I did a web search for
| "golang" and the first result was a download page for a
| Go compiler, so there is precedent.
| direwolf20 wrote:
| What's the first result for "clang"? How about in private
| browsing?
| webdevver wrote:
| 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.
| namuol wrote:
| > UI in C
|
| Try Clay!
|
| https://www.nicbarker.com/clay
| pansa2 wrote:
| There's also CimGUI. I know the underlying C++ library is
| well-regarded - I'm curious to hear people's experiences
| using the C wrapper.
|
| https://github.com/cimgui/cimgui
| pengaru wrote:
| For quite some time even games technically written in C++ were
| more appropriately described as C compiled by a C++ toolchain
| with a minimum of actual C++ syntax - more like C with classes.
| glimshe wrote:
| Rollercoaster Tycoon was written in assembly! C was easy mode
| back in the day...
| NewsaHackO wrote:
| >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.
| QuantumNomad_ wrote:
| The first capture of the page on Internet Archive Wayback
| Machine is from January 9th, 2016. So it's at least that old.
|
| Also here is a snapshot of the main page of his website from
| that time, which has screenshots of his games and thereby
| provides context into what kind of games he had made and
| published when the blog post was written.
|
| https://web.archive.org/web/20160110012902/http://jonathanwh...
|
| This one looks like it's 3d and has a pretty unique style:
|
| https://web.archive.org/web/20160112060328/http://jonathanwh...
| edu wrote:
| I think it would be apropiate if @dang added a (2016) to the
| title
| leecommamichael wrote:
| Come try Odin!
| andai wrote:
| +1 for Odin
|
| Did a bit of game dev in Odin last year and it was a wonderful
| experience. It's very much game dev oriented and comes
| batteries included with many useful libraries. And the built in
| vector stuff is very helpful there too.
| doublerabbit wrote:
| I've been doing theory and really want to myself.
|
| Time escapes me before I get a chance to type Hello World.
| Working in front of a screen eight hours a day leaves me
| exhausted that the least things I want to do is code more on my
| day off.
|
| Although wanting to dive in to WASM has been a priority and
| checking Odin for wasm their 3D model example is super cool.
|
| May just have to take a poke. TCL for web frontend; Erlang for
| DB and potentially Odin for wasm? This could be a cool mix.
| andreldm wrote:
| 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.
| dismalaf wrote:
| Haxe is a great language but it feels like the ecosystem has
| been stagnant for 10 years. No Vulkan bindings, no SDL3, still
| trying to be a web language that happens to compile to native
| code instead of getting with the times and going fully native +
| maybe wasm. Part of me wants to write my own bindings to SDL3
| in Haxe but it's far easier to just use Odin these days.
| stephc_int13 wrote:
| "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.
| graemep wrote:
| > when it comes to compilation I can't think of anything faster.
|
| What languages compile fastest?
| arcologies1985 wrote:
| Rust can be up there with C depending on the project.
| NewsaHackO wrote:
| is that a joke?
| enricotr wrote:
| Any language can be, depending on the project. Rust compile
| is slower than C, on more than average. That's it.
| gfody wrote:
| nothings faster than turbo pascal
| levodelellis wrote:
| IIRC go wasn't that fast but can feel like it in vscode. IIRC
| vscode compiles go using the lsp which is faster than launching
| a process because for some reason, vscode stalls for a second
| or more before launching a process.
|
| I can't remember how fast D was but iirc it was fairly fast.
| Actual fastest is my compiler which I don't work on anymore and
| isn't ready for production. It's the only compiler I know of
| that hit millions of lines <1s in a non trivial language
| https://bolinlang.com/
| tmtvl wrote:
| Not every compiled language has a de facto standard compiler,
| but with SBCL Common Lisp compiles pretty quickly. The Pascals
| (and Delphi) also tend to have rather fast compile times. I
| believe Jai is supposed to compile quickly but I'm not in the
| beta so I don't know. C can be quite good if you know what
| you're doing and use a decent compiler.
| drnick1 wrote:
| 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++.
| jiggawatts wrote:
| DirectX is C++ (technically a set of COM interfaces) and most
| game engines are also C++.
|
| Unlike, say, Linux programming where C is the standard, almost
| all games have been written exclusively in C++ for a long time
| now, probably three decades.
| cedilla wrote:
| There are a few exceptions though, like most mobile games,
| visual novels (many of which use Python of all languages, due
| to an excellent framework called ren'py), and of course games
| written using Unity or XNA, which use .NET languages.
|
| Also, three decades is going a bit too far back, I think. In
| the mid nineties, C was still king, with assembly still
| hanging on. C++ was just one of several promising candidates,
| with some brave souls even trying Java.
| pjmlp wrote:
| In J2ME feature phones Java was all there was, and even
| today many indies do use it on casual titles on Android.
|
| Which is why after so much resistance not wanting to use
| the NDK for Vulkan, and keeping using OpenGL ES from those
| devs, Google is bringing WebGPU to Java and Kotlin devs on
| Android.
|
| Announced at last Vulkanised, there is already an alpha
| version available, and they should talk more about it on
| upcoming Vulkanised.
| jiggawatts wrote:
| > Also, three decades is going a bit too far back
|
| My memory was wrong: I was thinking of the Quake 1 engine,
| but I just looked it up and it's C with some assembly code,
| no C++. The reason I remember it being C++ was because
| Visual C++ was the compiler tooling required on Windows.
| direwolf20 wrote:
| COM was designed to be compatible with C. Linux games are
| also often written in C++. The ones written in C are just
| old.
| jiggawatts wrote:
| Sure, but in practice COM is almost never used from C
| programs unless there is some integration into a very
| legacy codebase. Games are newly developed, they're not
| enterprise database platforms.
| pjmlp wrote:
| Khronos APIs are C, DirectX is C++ exposed via COM or WinRT,
| Metal is Objective-C with C++ for shaders and Swift bindings,
| on Nintendo and PlayStation depends on which console generation
| you talk about.
| indy wrote:
| Additionally SDL3 is also C and the most recent version of the
| Box2d physics library was rewritten in C
| torlok wrote:
| 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.
| pansa2 wrote:
| Yeah, you could argue that choosing C is just choosing a
| particular subset of C++.
|
| The main difference from choosing a different subset, e.g.
| "Google C++" (i.e. writing C++ according to the Google style
| guide), is that the compiler enforces that you stick to the
| subset.
| ninkendo wrote:
| C's string handling is so abominably terrible that sometimes
| all people really need is "C with std::string".
|
| Oh, and smart pointers too.
|
| And hash maps.
|
| Vectors too while we're at it.
|
| I think that's it.
| teo_zero wrote:
| I agree on the former two (std::string and smart pointers)
| because they can't be nicely implemented without some help
| from the language itself.
|
| The latter two (hash maps and vectors), though, are just
| compound data types that can be built on top of standard C.
| All it would need is to agree on a new common library, more
| modern than the one designed in the 70s.
| uecker wrote:
| why not std::string?
| direwolf20 wrote:
| It's a class, so it doesn't work in C.
| uecker wrote:
| Sure, but you can have a similar string abstraction in C.
| What would you miss? The overloaded operators?
| teo_zero wrote:
| You can surely create a std::string-like type in C, call
| it "newstring", and write functions that accept and
| return newstrings, and re-implement the whole standard
| library to work with newstrings, from printf() onwards.
| But you'll never have the comfort of newstring literals.
| The nice syntax with quotes is tied to zero-terminated
| strings. Of course you can litter your code with
| preprocessor macros, but it's inelegant and brittle.
| ninkendo wrote:
| I think a vec is important for the same reason a string
| is... because being able to properly get the length, and
| standardized ways to push/pop from them that don't
| require manual bounds checking and calls to realloc.
|
| Hash maps are mostly only important because everyone
| ought to standardize on a way of hashing keys.
|
| But I suppose they can both be "bring your own"... to me
| it's more that these types are so fundamental and so
| "table stakes" that having one base implementation of
| them guaranteed by the language's standard lib is
| important.
| WalterBright wrote:
| When I developed D, a major priority was string handling. I
| was inspired by Basic, which had very straightforward,
| natural strings. The goal was to be as good as Basic
| strings.
|
| And it wasn't hard to achieve. The idea was to use length
| delimited strings rather than 0 terminated. This meant that
| slices of strings being strings is a superpower. No more
| did one have to constantly allocate memory for a slice, and
| then keep track of that memory.
|
| Length-delimited also super speeded string manipulation.
| One no longer had to scan a string to find its length. This
| is a big deal for memory caching.
|
| Static strings are length delimited too, but also have a 0
| at the end, which makes it easy to pass string literals to
| C functions like printf. And, of course, you can append a 0
| to a string anytime.
| pantalaimon wrote:
| C is not a subset of C++, there are some subtle things you
| can do in C that are not valid C++
| uecker wrote:
| Some subtle and some not so subtle.
| randomtoast wrote:
| I've seen this play out a lot. People say they "write games in
| C" and then quietly rebuild half of C++ anyway with vtables in
| structs or giant switch statements, just without the compiler
| helping. That's fine if it makes you happier, but it's not
| obviously simpler or safer. Also, C++ compile times are mostly
| a self-inflicted wound via templates and metaprogramming, not
| some inherent tax you pay for having virtual functions.
| direwolf20 wrote:
| It's important that you do these things yourself before you
| utilise the compiler to do them for you, so you have real
| understanding.
| sandpaper26 wrote:
| This reads like an LLM generated response that simply
| restates the comment it's replying to
| randomtoast wrote:
| Heck the LLM accusations get a bit out of hand lately here
| on HN. I could delve into it now ... but I want to safe our
| time.
| mjburgess wrote:
| A switch statement is how you do ad-hoc polymorphism in C --
| i dont thinks an own against C developers to point that out.
| If they wanted to adopt the C++ style that immediately
| requires the entire machinery of OOP, which is an incredibly
| heavy price to avoid a few switch statements in the tiny
| number of places ad-hoc poly is actually needed
| whizzter wrote:
| You don't usually do C++ subsets if you want the full
| shebang.
|
| I have a "mini-std" headerfile that's about 500 LoC
| implementing lightweight variants of std::vector,
| std::function, a stack-local std::function (unsafe as hell
| and useful as hell to avoid allocations), a shared-ptr,
| qsort and some other nifty stuff.
|
| That does a lot of things, but even then I use other
| patterns that brings a lot of bang for the buck without
| having to go full C (hint: the stack-local function
| equivalent gets a lot of mileage).
| gf000 wrote:
| > but it's not obviously simpler or safer
|
| On top of likely having worse performance.
| uecker wrote:
| I think it is simpler and "the compiler not helping" ==
| "things are more transparent". int a = 3;
| foo(a); // What value has a ?
|
| There are various things one does not have to worry about
| when using C instead of C++. But the brain needs some time to
| get used to it.
| wasmperson wrote:
| I think I get what you're trying to say, but you may have
| picked a bad example, here: #define foo(a)
| a = 12
| uecker wrote:
| Yes, but this is more a theoretical problems while
| references are common in C++.
| pron wrote:
| > Complaining about a language having features you don't want
| is silly.
|
| It might be silly if you're working on your own. Software that
| delivers a lot of value is usually developed and evolved not
| only by team, but by a team with changing members and changing
| leadership over the project's lifetime. The features used will
| be the union of all features used over the years, and while
| it's easy for team leads to allow the use of more features than
| their predecessors, it's quite hard to reduce them.
|
| Also, you may be forced to use language features you don't want
| if they're used by libraries whose functionality you do want.
| For example, when doing low-level programming, I don't like
| implicit calls that I can't clearly see on the page (e.g.
| destructors or overloaded operators). But if libraries I want
| use them, then I'll have those implicit calls. But if the
| language doesn't have those features, libraries obviously won't
| use them.
| karamanolev wrote:
| > It might be silly if you're working on your own.
|
| That's exactly the case when it's easiest. If you don't need
| a feature, just don't use it and case closed. With a team
| it's harder - you have to force/enforce others not to use a
| given feature.
|
| > if they're used by libraries whose functionality you do
| want
|
| If you're using C++ you can just use the C library you
| would've used otherwise, no?
| adastra22 wrote:
| There are linters to do that enforcement automatically.
| etrvic wrote:
| I feel like, for me, it's that I am more familiar with writing
| in C and switching to C++ seems rather difficult. So, sure I am
| reimplementing features that already exist in anoter language,
| it just so happens in this case is C++. Why not use python if
| you want to avoid reimplementing the wheel as much as possible.
| And sure python is not suited for game development but I just
| wanted to make a point with it. I think in the end ising a
| language you are most familiar with results in the most amount
| of enjoyable coding.
| cogman10 wrote:
| For a solo dev, it's not difficult. C++ is nearly a superset
| of C. You don't have to adopt all of C++ to start using it
| and to get immediate benefits from it (for example,
| unique_ptr, shared_ptr, and vector would all be things that I
| think any C dev would really appreciate).
|
| A reason I can think of to not move to C++ is that it is a
| vast language and, if you are working on a team, it can be
| easy for team members ultimately forcing the whole team to
| become an expert in C++ simply because they all will be
| familiar with a different set of C++ features.
|
| But for a solo dev? No reason not to use it, IMO. It's got a
| much nicer standard library with a rich set of datastructures
| that just make it easier to write correct code even if you
| keep a C style for everything.
| krapp wrote:
| >Writing games in C is not harder, you just have to implement
| modern language features by hand.
|
| I feel like if you need to implement modern language features,
| you shouldn't be using C. The entire point of C is to not be
| modern.
| tomcam wrote:
| > just to feel better about themselves.
|
| Mindread much?
| whizzter wrote:
| Exactly, not even do you need to religiously need stick to your
| subset, separate modules can be using supetsets that import
| useful libraries and if they're used for code that is seldomly
| changed (such as model importers) then the longer compile time
| will only matter for rebuilds and not quick tests.
| petters wrote:
| > C++ doesn't take longer to compile if you don't abuse
| templates.
|
| Surprisingly, this is not true. I've written a C++ file only to
| realize at the end that I did not use any C++ features.
| Renaming the file to .c halved the compilation time.
| levodelellis wrote:
| I don't believe you, I measured compile times in c compilers
| and my own. If you provide more information I'd be more
| likely to believe you
| levodelellis wrote:
| In fact, I don't believe you so much that I'm willing to say
| you're full of shit. No compiler capable of both C++ and C
| will be twice as fast renaming the file to C
| jsheard wrote:
| I agree it shouldn't really matter if there's no C++
| features in play, but I suppose third party headers could
| bite you if they use #ifdef __cplusplus to guard optional
| C++ extensions on top of their basic C interface. In that
| case the compiler could be dealing with dramatically more
| complex code when you build in C++ mode.
| uecker wrote:
| Maybe it is similar for the same compiler (but one should
| check, I suspect C could still be faster), but then there
| are much more C compilers. For example, TCC is a lot
| faster than GCC.
| levodelellis wrote:
| I measured once and to my surprise templates aren't (directly)
| the reason for long compile times. It's function bodies in
| headers, and obviously templates are in headers and they call
| other templated functions/classes which explodes code
| generation and time. But if it's only a few lines and doesn't
| call other templated functions it's likely fine. I wrote about
| it here https://bolinlang.com/wheres-my-compile-time
|
| After writing that, I wrote my own standard library (it has
| data structs like vector, hashmap and sets; slices, strings,
| rng, print, some io functions, and more) which uses a lot of
| templates, and it compiles in <200ms on both clang and gcc.
| Many standard library headers take much longer to compile than
| that. It's not a terrible idea to have your own standard lib if
| you need quick compile times.
| direwolf20 wrote:
| Your website seems to be blocking Tor
| rustyhancock wrote:
| Another option can be if you have a core set of headers your
| project will use (and is stable) just precompiling them.
| HoldOnAMinute wrote:
| It's possible to use only a subset of the language. You could
| write a Java program without classes if you really wanted to.
| Just put the whole thing in main().
|
| A lot of smart people pick and choose what they want from the
| language, just like religion, they keep the good parts and
| discard the bad.
| direwolf20 wrote:
| main is also in a class in Java.
|
| Even with the recent extension where it looks like it isn't,
| the compiler adds one for you.
| bobajeff wrote:
| I remember the creator of Kaiju engine stating something about
| C++ compilers producing slower code with C-style C++.
| wasmperson wrote:
| For every person who says on the internet that you can just use
| a C++ subset, there's another who insists that C is the _bad_
| C++ subset. So compiling C code with a C++ compiler promotes
| your code from "good C code" to "bad C++ code" (most C code
| isn't "exception safe," for example).
|
| It's arguably irrational to evaluate a language based on this,
| but you can think of "this code could be better" as a sort of
| mild distraction. C++ is _chock full_ of this kind of
| distraction.
| akoluthic wrote:
| 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/
| trueno wrote:
| I've been working religiously for like 2 years on the jedi
| academy codebase which is c & c++. It's Ravensofts variant of
| the idtech3 engine and it's insane how fragile the games combat
| is to precision and timing changes, I can't get away with
| adding much without destroying the lightsaber combat qualities.
| There are certain spots where I can't even add an incrementing
| i++ counter lmao it presents just enough of a slowdown or
| shifts something around that I haven't been able to track down
| that bleeds into the rest of the gameplay, but I am also
| sticking with the ancient compilers from 22 years ago so as to
| preserve the fpu characteristics of the game. There are some
| modern attempts at using this codebase with modern tooling but
| they've kind of bastardized/refactored all of it and it just
| feels different/unbalanced wrong. idtech3 is such an incredibly
| foray into c it's really something else and carmack and team
| really sent it back in the day.
| lylejantzi3rd wrote:
| Are you working on the original codebase or the OpenJK fork?
| trueno wrote:
| original codebase
| ethin wrote:
| 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.
| mapcars wrote:
| >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
| pjmlp wrote:
| 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.
| kahlonel wrote:
| Wrong. I'm still doing it.
| pjmlp wrote:
| Linux kernel also keeps using C.
| HeavyStorm wrote:
| 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.
| brokencode wrote:
| Nobody claimed it was impressive. It's a little unusual to use
| C instead of C++, but that's about it.
| quotemstr wrote:
| 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.
| enricotr wrote:
| "Practically speaking" means nothing. Use "from my confused
| point of view", instead.
| quotemstr wrote:
| If GDB could switch its C codebase to compiling as C++
| without major surgery, it's close enough.
| wudangmonk wrote:
| If he doesn't use C++ features then there's no point of
| bothering with C++ at all. C++ is kinda but not really a
| superset of C. There are some nice features that are lacking in
| C++.
|
| The fixie example wants to make the comparison that using C
| instead of C++ is deliverately done just to brag about doing
| something in a way that is more difficult than in should be. In
| reality the issue is that C++ might not offer you any benefit
| at all and it could potentially bring you issues later on for
| things such as interfacing with other languages.
|
| I personally do not see the point of using C++ if you do not
| use any of its features.
| quotemstr wrote:
| > 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.
| nasretdinov wrote:
| Yeah I was a bit surprised by this too. I think the post was
| written around 10 years ago, when it still was a genuine
| problem in Go.
| quotemstr wrote:
| Good eye. This is why HN titles have year tags. :-)
|
| Yeah, this is from 2016. I don't think choosing C over C++
| was defensible even back then, but the critique of Go makes
| more sense now.
|
| https://web.archive.org/web/20160109171250/http://jonathanwh.
| ..
| pyrolistical wrote:
| 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.
| p0w3n3d wrote:
| 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
| direwolf20 wrote:
| That's the neat thing about C++. You don't have to use any of
| it that you don't want to.
| 9rx wrote:
| Oh, perfect! I was getting tired of using functions. goto
| ought to be enough for anyone. Except I keep getting a
| compiler error when I don't use them. A little help?
| andai wrote:
| (2016)
| Bengalilol wrote:
| 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.
| Mikhail_Edoshin wrote:
| 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.
| guerrilla wrote:
| 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.
| giancarlostoro wrote:
| Were not most games back in the day in C?
| pantalaimon wrote:
| Quake and Doom sure come to mind
| bowsamic wrote:
| Most games back in the day were written in assembly
| guerrilla wrote:
| Back in what day? Quake II I would say is the best good
| looking thing written in pure C. id Tech 3 is partly C++.
| Everything after that era was pretty much C++. Even GoldSrc
| is partly C++. Source was pure C++.
| giancarlostoro wrote:
| I guess back in my day, early to mid 90s. My understanding
| is C became more common.
| tuhgdetzhh wrote:
| I think the productivity question hinges on what you count as
| the language versus the ecosystem. Very few nontrivial games
| are written in "just C". They are written in C plus a large
| pile of bespoke libraries, code generators, asset pipelines,
| and domain-specific conventions. At that point C is basically a
| portable assembly language with a decent macro system, and the
| abstraction lives outside the language. That can work if you
| have strong architectural discipline and are willing to pay the
| upfront cost. Most teams are not.
|
| I agree on C++ being the worst of both worlds for many people.
| You get abstraction, but also an enormous semantic surface area
| and footguns everywhere. Java is interesting because the core
| language is indeed small and boring in a good way, much closer
| to C than people admit. The productivity gains mostly come from
| the standard library, GC, and tooling rather than clever
| language features. For games, the real disagreement is usually
| about who controls allocation, lifetime, and performance
| cliffs, not syntax.
| guerrilla wrote:
| > I agree on C++ being the worst of both worlds for many
| people. You get abstraction, but also an enormous semantic
| surface area and footguns everywhere.
|
| Not only that, but who even knows C++? It keeps changing.
| Every few years "standard practice" is completely different.
| Such a waste of energy.
|
| > Java is interesting because the core language is indeed
| small and boring in a good way, much closer to C than people
| admit.
|
| I know. I used to be a Java hater, but then I learned it and
| it's alright... except the whole no-unsigned-integers thing.
| That still bothers me but it's just aesthetic really.
| tombert wrote:
| 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.
| howToTestFE wrote:
| 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.
| anatoly wrote:
| raylib is one possible starting place. Also might look at dos-
| like (https://mattiasgustavsson.itch.io/dos-like).
| lylejantzi3rd wrote:
| If you have patience, the first 30 or so episodes of Handmade
| Hero are pretty good.
|
| https://guide.handmadehero.org/code/
| ddtaylor wrote:
| I need RAII and refuse to debug ugly macros as a workaround. The
| STL isn't perfect but it's a good guiding principle.
| zuluonezero wrote:
| Nice looking games though.
| JamesTRexx wrote:
| 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.
| teunispeters wrote:
| I like C. You can take away all memory management (yes, including
| some of the unsafe glibc calls that have hidden memory
| management) and everything can be so smooth and clean. Since
| rules like MISRA require up-front allocation - if any is in use -
| this can be tightly controlled.
|
| Very useful if you don't want (or need) surprises anywhere. Or if
| you want all the surprises (exceptions, errors, etc) all better
| tied to the hardware that provides such.
|
| It's also fairly easy to write unit tests for everything.
| parasti wrote:
| What does "vanilla C" mean? Asking as a maintainer of 20 years of
| a game written in C.
| nottorp wrote:
| Btw, in the wannabe indie gaming scene it doesn't matter what
| language or tool or framework you use. It matters if you finish
| the fucking thing.
___________________________________________________________________
(page generated 2026-02-07 23:00 UTC)