Live data from Hacker News

Why I Write Games in C

jonathanwhiting.com

111–120 of 303 posts

Re: Why I Write Games in C

#111
post #54

The thing I miss most in C when I don't cheat and use a couple C++ features is templates. Specifically, a dynamically sized List implementation that is type-generic. If you do this in pure C, you have to pick your poison: 1. preprocessor abuse 2. void * 3. multiple redundant implementations of the data structure Dynamically sized lists are used so often, that this tends to be a problem in almost every C project. I wo…

BAH! 4. The "intrusive" containers, but of course. The one true way to do it in C. For one, you can keep items in multiple containers, all being on equal footing. None of that typical C++ mess, when this list is a primary storage for items, and those maps are secondary indexes, all sprinkled evenly with iterators. Intrusive containers don't own items, they merely organize them, which is exactly the right way to go ab…

Are you aware of Boost intrusive containers?

Re: Why I Write Games in C

#112
post #92
post #89

Because he claims that reducing the possibility for bug is a main concern I feel two languages, in his nicely written write-up, are left out: Rust -- low-level like C, fast like C, more modern than C, specific ways to reduce categories of bugs (borrow checker), promotes a more functional way for programming Haskell -- not as low-level as C, but pretty fast (best possible performance was not his main concern), many wa…

How is the Haskell stability nowadays? Simon Peyton Jones joked at one point that Haskell is not meant for production from the point of view that they are tinkering with it constantly. At some point the Haskell landscape looked like the GHC core and an endless desert of abandoned projects (which imply strongly it's not as good towards the librarys purpose as some other language).

I have worked with GHC for more than half a year and never encountered any compiler bugs or instabilities. Haskell is surprisingly solid. That being said, Haskell is not well suited for things like games. It's just not the right paradigm. Some people may disagree with me but the fact that most games (and also other programs) are not programmed in Haskell speaks for itself. Haskell is a fun and playful (and also difficult) language but I'd never start a large serious project in it again.

Re: Why I Write Games in C

#113
post #102

Earlier quoted context omitted.

Is Rust available on consoles? (AFAIK, no) Is it going to be around? (Who can tell?)

Who cares? Consoles are dead after this generation.

Why? Do you have any evidence to back up this claim?

On the contrary, it seems both the Xbox One and PS4 are doing a roaring trade, with gaming overtaking Hollywood in terms of market size and revenue

Re: Why I Write Games in C

#114
Since game development often requires interfacing with robust C++ libraries in graphics or physics (i.e. Bullet), I'm curious how you do that... are you either not using physics or writing your own basics physics engine? Or, are you writing parts of your app in c++ just to wrap the interface in a way you can do the rest of the work in C?

Re: Why I Write Games in C

#116
post #58

Earlier quoted context omitted.

There are some arguments to stick with C instead of a very C-like subset of C++. Off the top of my head: - Recompiling and reloading parts of your game at run-time is quite easy in C. In C++ you have to make sure (at least) that nobody has pointers to vtables of the dll at the time of reload. This can be a bit tricky if you're using things like std::function in your dll code. Yes, you could be using a scripting langu…

>Recompiling and reloading parts of your game at run-time is quite easy in C. This is cool to hear. I've never done anything like this, but it almost sounds like REPL-driven development is a possibility in C?

Check out the first few episodes of Casey Muratori's Handmade Hero series where he implements an extremely simple hot code reloading system in C (actually C++, but he doesn't use almost any C++ features, certainly not vtables).

Re: Why I Write Games in C

#117
post #58

Earlier quoted context omitted.

There are some arguments to stick with C instead of a very C-like subset of C++. Off the top of my head: - Recompiling and reloading parts of your game at run-time is quite easy in C. In C++ you have to make sure (at least) that nobody has pointers to vtables of the dll at the time of reload. This can be a bit tricky if you're using things like std::function in your dll code. Yes, you could be using a scripting langu…

>Recompiling and reloading parts of your game at run-time is quite easy in C. This is cool to hear. I've never done anything like this, but it almost sounds like REPL-driven development is a possibility in C?

It's quite restricted still. For example changing datatypes during recompilation is problematic, at least if you don't destroy the instances before reloading, and re-instantiate afterwards. I don't bother to do that, because I see most of the value in things like tweaking game object logic repeatedly, which fits the restrictions nicely.

Re: Why I Write Games in C

#118
post #78
post #75

Earlier quoted context omitted.

I can't speak for the article writer of course, but the Python-like syntax / significant indentation would be a deal-breaker for me. I'd suffer through a lot to avoid that. And back when I used C a lot myself, I found that even more objectionable. I often care more about syntax than many other language features - with a good syntax you can sugar over a lot of other deficiencies, but a syntax you dislike will stare yo…

I am in some ways the same, but the other way around. I like Python-like syntax more than C-like syntax. But not to the same extreme as you, I wouldn't mind using a language with a C-like syntax. What are your reasons for disliking Python-like syntax?

I want strong visual cues for the end of blocks most importantly. And I want the freedom to adjust indentation in ways that to me improve readability without consideration of whether or not it matches language expectations.

But also because I've yet to work in any environment where broken indentation due to tools with different ideas about how to handle it has not been a regular occurrence - indentation is brittle.

Re: Why I Write Games in C

#119

Since game development often requires interfacing with robust C++ libraries in graphics or physics (i.e. Bullet), I'm curious how you do that... are you either not using physics or writing your own basics physics engine? Or, are you writing parts of your app in c++ just to wrap the interface in a way you can do the rest of the work in C?

I don't know about game libraries in particular, but in general, it's pretty common for C++ libraries to ship with a C api, and for most non-C++ languages to use that as the basis for their integration.

It looks like several (https://code.google.com/p/bullet/issues/detail?id=43) people (https://github.com/bulletphysics/bullet3/issues/130) have written C apis for bullet already, for that reason. Vala, .NET, LuaJIT and Rust all get mentioned.

Re: Why I Write Games in C

#120
post #105

>Even more than that I care about the speed of the compiler. I am not a zen master of focus, and waiting 10+ seconds is wasteful, yes, but more importantly it breaks my flow. I flick over to Twitter and suddenly 5+ minutes are gone. Quick suggestion, has really helped me: take that 10 or 20 seconds waiting for compilation, and stare out a window. This gives your eyes much needed break from focusing on a computer moni…

A "focus" application (there are many for macs/pcs) that block certain websites, applications is also helpful. You can set it for an hour at a time, or whatever. It breaks that knee-jerk habit of wasting minutes on twitter/news/etc.
Post reply on HN