Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Write Games in C (yes, C)

jonathanwhiting.com

Post reply on HN
Print view View original

61–70 of 556 posts

Re: Why I Write Games in C (yes, C)

#61

Post by xamuel »

lurquer wrote: post #49
xamuel wrote: post #12

The author despises OOP, and I agree with him there. I would add that OOP can be particularly bad for games , because often times the OOP vocabulary clashes with the game's own vocabulary: the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game. All support for OOP would vanish o…

> the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game. Am I an idiot for not knowing for sure this is a joke, or is the poster an idiot for not intending a joke? I'm so confused...

It's not intended as a joke, and please have patience with me if I'm an idiot.

Imagine you had a program involving, say, chairs. It has things called chairs, which you pass around to functions which take chair arguments. Suddenly, the next version of the language comes out and now "chair" is a reserved keyword, and all your code is broken. To fix it, you have to go through your whole codebase and rename all your "chair"s to "ChairStruct" or "_chair" or something.

I didn't say it was a major world-stopping difficulty. It's just one additional nitpick against OOP for games (added to an already gigantic stack of much bigger problems caused by OOP).

Re: Why I Write Games in C (yes, C)

#62

Post by wwright »

jchw wrote: post #31
unnouinceput wrote: post #14

Quote: "I want to produce less bugs, so I want strict typing, strong warning messages and static code analysis". Yeah, at strict typing you lost me buddy. Let's just go with somebody else reply, as in you like C and that's why you do your hobbies in. Nothing wrong with that in the end.

Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does pre…

Personally I interpreted the parent as pointing out that C does not offer strict typing.

Re: Why I Write Games in C (yes, C)

#63

Post by stephc_int13 »

cwyers wrote: post #44
stephc_int13 wrote: post #21

The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a…

> there are simple ways to avoid shooting yourself in the feet with those A cursory look at the CVE list for any C software in the wild indicates that no, there are not simple ways to avoid shooting yourself in the feet with manual memory management in C. It's _incredibly hard_ even for "elite" programmers who have a lot of incentive to avoid these problems. The counterpoint is that people are probably going to spend…

Yeah, I am not talking about vulnerabilities. I am simply talking about ease of use and avoidance of leaks and crashes.

Writing super secure code is usually not a requirement for gamedev, and I completely agree, this is hard and potentially harder in C than, say, in Rust.

Re: Why I Write Games in C (yes, C)

#64

Post by choeger »

zemo wrote: post #46

> 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 love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

I had the very same thought. It is unsubstantiated. But if you consider how a game actually uses memory, it is really not suited for your run-of-the-mill GC: Most assets are allocated once per level/scene/whatever and have a pretty well-defined lifetime. What's left happily lives on the stack frame. There is may some room for reference counting of some structures (think multiplayer et. al. where the engine does not have full control of the flow). But in general, a GC can provide very little here, at quite some cost.

Re: Why I Write Games in C (yes, C)

#65

Post by mruts »

kabes wrote: post #41
jchw wrote: post #31

Earlier quoted context omitted.

Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does pre…

I'm sure typing prevents some bugs. But if I'm looking at the bugs we find in the JS projects I work on, only a very few would have been avoided with typing. The vast majority of bugs are about unsound business logic, wrongly understood requirements, etc.

That’s because the thousands of errors were manually fixed before committing.

I’ve programmed professionally in both Haskell (strongly statically typed) and Racket (dynamically typed). The number of bugs I encountered at runtime with Haskell was very close to 0 per 1000 lines of code. For Racket on the other hand, I would get maybe 5-15 per 1000 lines. Most of these were easy to catch and never made it into production, so it really only wasted my time instead of making the app unstable. But there would be a few very stupid bugs that would have been easily caught with static typing on the unhappy/rare path that wouldn’t be found until weeks or months later.

Nowadays, I try to avoid all jobs that use languages with dynamic typing on production software simply for the reason that they make me anxious and upset. Maybe everyone else is just so much better than me that they never produce typing relating bugs, but I kinda doubt it.

Re: Why I Write Games in C (yes, C)

#66

Post by F-0X »

mumblemumble wrote: post #35

I'm currently trying to decide if Nim is my C replacement. On the one hand, it isn't C++, and it has real type safety, and it interfaces with existing C libraries very easily. On the other hand, it is rapidly getting very complicated, and seems almost eager to become another C++ in terms of sheer volume of language features.

>On the other hand, it is rapidly getting very complicated

This seems to be the case for almost any "C replacement", and it will be (my prediction, at least) the reason they all fail.

I feel I might be a bit of an outlier in this respect, but I have only ever enjoyed using languages which are small and simple - C, Go, Scheme. The times I've tried Rust, it's been nice to have code that cannot segfault, but I find it such a chore to deal with. Whenever I've read open-source projects in Rust it's always a readability disaster. Also the compiler emitted warnings because functions were not snake case, which I found obnoxious.

Re: Why I Write Games in C (yes, C)

#67

Post by xamuel »

eternalny1 wrote: post #34
xamuel wrote: post #12

The author despises OOP, and I agree with him there. I would add that OOP can be particularly bad for games , because often times the OOP vocabulary clashes with the game's own vocabulary: the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game. All support for OOP would vanish o…

> the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game. This makes no sense to me. By that logic, it would be difficult for me to create a scheduling system for classes being taught in factories with OOP, which it's not.

For a program about classroom-scheduling, it would be nice if you could use "class" as a structure name. Then you could declare a function as taking a "class" as an argument. But if "class" is a reserved keyword in the language, you have to come up with some other name like "_class" or "ClassStruct".

I didn't mean to say it's an earth-shattering obstacle. Just one minor additional nitpick to add to the gigantic pile of problems caused by OOP.

Re: Why I Write Games in C (yes, C)

#68

Post by choeger »

pier25 wrote: post #58
stephc_int13 wrote: post #21

The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a…

> I do write games and game engine code and tools in C++ without using any of the OOP features. Excuse my C/C++ ignorance, but why not simply use C?

There is still the STL, there are still templates and data structures have a very well-defined lifetime.

Re: Why I Write Games in C (yes, C)

#69

Post by oldmanhorton »

pier25 wrote: post #58
stephc_int13 wrote: post #21

The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a…

> I do write games and game engine code and tools in C++ without using any of the OOP features. Excuse my C/C++ ignorance, but why not simply use C?

Because c++ without OOP still gives you RAII (which is neutered a bit if you don't write your own classes but still), safe pointers, references, lambda, and an immense standard library, to name a few.

Re: Why I Write Games in C (yes, C)

#70

Post by bcrescimanno »

zemo wrote: post #46

> 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 love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

Disclaimer: I'm not a game developer; but, I've worked on a lot of projects with tight frame time requirements in my time at Netflix on the TVUI team. I also have no experience in Go so I can't comment on the specifics of that garbage collector vs. V8.

I don't think it's necessarily that it "can't" work as much as it takes away a critical element of control from the game developers and the times you find yourself "at the mercy" of the garbage collector is pretty damn frustrating.

The problem we ran into with garbage collection was that it was generally non-deterministic both in terms of when it would happen and how long it would take. We actually added an API hook in our JS to manually trigger GC (something you can do when you ship a custom JS runtime) so we could take at least the "when it happens" out of the picture.

That said, there were often fairly large variances in how long it would take and, while frame time budgets may seem to accommodate things, if you end up in a situation where one of your "heavy computation" frames coincides with a GC that runs long, you're going to get a nasty frame time spike.

We struggled enough that we discussed exposing more direct memory management through a custom JS API so we could more directly control things. We ultimately abandoned that idea for various reasons (though I left over 6 years ago so I have no idea how things are today).

Post reply on HN