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

Why I Write Games in C

jonathanwhiting.com

Post reply on HN
Print view View original

181–190 of 303 posts

Re: Why I Write Games in C

#181

Post by loup-vaillant »

cLeEOGPw wrote: post #95

I see one of the core reasons C is chosen over C++ is the speed of compilation. My question would be, to what extent is compilation speed relevant? What time differences are we talking about? I agree that every second counts, and I understand that fast compilation just feels good to work with for a hobby project, but what serious relevancy it has? At least the way I do it is divide program (a game for example) into s…

Most C++ projects I have worked with, regardless of their size, had re-compilation times that routinely exceeded 20, sometimes 30 seconds. There are various reasons for this, among which uncontrolled use of templates and nested header inclusions where a forward declaration would have sufficed.

C, with its simpler grammar and the absence of template, tend to re-compile under 5seconds even for sizeable projects.

Re: Why I Write Games in C

#182

Post by crafn »

je42 wrote: post #163
crafn wrote: 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…

To me it looks like it you would like to use plain C as scripting language for game logic code. Your arguments make sense there and the trade of looks reasonable. However, it doesn't make necessarily sense put the restrictions across the complete source code of game, just because the game logic benefits from it.

Maybe, I don't know. This is just me trying to minimize the unnecessary pain and suffering while waiting for a better language to arrive. In that context arguing which bad solution is less worse seems somewhat pointless, and also depends on personal taste. I'll have to see this project through to know better.

Re: Why I Write Games in C

#183

Post by loup-vaillant »

ivanca wrote: post #39
scrollaway wrote: post #16

Earlier quoted context omitted.

If you're going to write a TL;DR for others, you should at least read the article yourself, don't you think?

I did, it is so abstract to pretend you can do better that there is no way to discern. He didn't even mention "unity" in his post, thats just ridiculous in 2016, but yeah, keep down voting, your implementation of 2d graphics, sound, collision, physics, plugins, marketing, sprites, menus is gonna be so much better than hundreds of engineers at unity withing 10 years straight.

Try and implement http://jonathanwhiting.com/games/knossu/ with Unity.

My guess is, the author would have taken more time learning Unity than implementing this game.

Re: Why I Write Games in C

#184

Post by hjek »

Absolutely amazing games on the webpage, especially Knossu, a "A non-euclidean horror game." Crisp and trippy graphics and sounds. Good gameplay, no "installation" required.

But running a closed-source binary can be a bit sketchy; whereas you don't have to trust a publisher to the same degree running a game in the browser.

Re: Why I Write Games in C

#185

Post by sklogic »

Rusky wrote: post #174
sklogic wrote: post #65

Well into C++14, but yet this outdated myth of an unbearable "complexity". This is not the language you knew.

C++11 and 14 make it possible to avoid or ignore much of the complexity of old-style C++, but they also introduce plenty of complexity of their own and they don't deprecate any of the old stuff. It's not a myth.

Yes, but now you can safely use a nice and clean subset without ever touching any dark corners.

Re: Why I Write Games in C

#186

Post by je42 »

crafn wrote: post #172
je42 wrote: post #155

Earlier quoted context omitted.

- Compile times with templates are on my system under 10 seconds. - I missed your vector and unordered_map discussion. - "more complex" is not a useful metric to compare the language systems. Similar, I can easily say, that C pointer arithmetic is creates more complex situations when verifying that code is safe to use.

Compile times are not a problem in small codebases. Try to compile a 100kloc codebase using templates generously. Even your link times will easily grow over 10 seconds. Maybe even a minute. And 100kloc is still a pretty small codebase in terms of AAA development. It's true that complexity somewhat depends on the context. Complexity of a language is a useful metric when talking about mental overhead of the programmer…

Yes. your link times will grow. But link times are not depended on choice of language. It depends on how big your set of object files is. Depending on your platform you can optimize your build.

I.e. - use dynamic link libraries

- use create static libraries

- carefully manage your dependencies. i.e. only include what you actually need.

- hot reload game logic (where quick iteration is more important)

- compile cache.

- ssd disk

- fast processor

- and yes, agreed. 100kloc is still small.

Re: Why I Write Games in C

#187

Post by je42 »

crafn wrote: post #182
je42 wrote: post #163

Earlier quoted context omitted.

To me it looks like it you would like to use plain C as scripting language for game logic code. Your arguments make sense there and the trade of looks reasonable. However, it doesn't make necessarily sense put the restrictions across the complete source code of game, just because the game logic benefits from it.

Maybe, I don't know. This is just me trying to minimize the unnecessary pain and suffering while waiting for a better language to arrive. In that context arguing which bad solution is less worse seems somewhat pointless, and also depends on personal taste. I'll have to see this project through to know better.

C++ 14 is pretty awesome as a language.

Actually, swift, es6, C++ 14, C# come very close these days. in terms of language features.

In my experience, the runtime/build system/packaging/community become bigger factors when choosing between them than the language itself.

Re: Why I Write Games in C

#188

Post by je42 »

vardump wrote: post #50
ivanca wrote: post #39

Earlier quoted context omitted.

I did, it is so abstract to pretend you can do better that there is no way to discern. He didn't even mention "unity" in his post, thats just ridiculous in 2016, but yeah, keep down voting, your implementation of 2d graphics, sound, collision, physics, plugins, marketing, sprites, menus is gonna be so much better than hundreds of engineers at unity withing 10 years straight.

Unity games I've tried seem to stutter often. Any idea why? GC cycles?

GC cycles.

Re: Why I Write Games in C

#189

Post by fsloth »

chii wrote: post #150
Kenji wrote: post #112

Earlier quoted context omitted.

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 diffi…

> That being said, Haskell is not well suited for things like games. It's just not the right paradigm. is that really true? i feel like a game ought to fit into a functionally pure paradigm much better, because a game should really only depend on player input, and that can be modelled much easier as RenderIO (WorldState b -> PlayerInput a -> WorldState b) , but not having actually written any, this is just my assumpt…

Haskell seems to be really nice for data structure transforms. A game can be modeled as such. But, it appears to me Haskell is used in programs which do a few large transforms whereas games do hundreds to thousands transforms per second. Games usually want to be mutable and using immutable language probably means there will be considerable effort in fighting against language features.

Ocaml and F# are more forgiving (some would say more practical) since they employ mutability as first class design element.

Re: Why I Write Games in C

#190

Post by [deleted] »

loup-vaillant wrote: post #164
chii wrote: post #131

Earlier quoted context omitted.

> Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. i feel like this is somehow perpetuated like folklore, but there shouldn't be any reason why game code should be inherently less reusable than other areas of software development. For example, code that deal with geometry data shouldn't really be any different for games, or code that deal with settin…

> code that deal with geometry data shouldn't really be any different for games Counter-example: http://jonathanwhiting.com/games/knossu/ (Highly recommended if you have 20 minutes to spare.) The geometry of this game is unlike any I have seen so far. There is common logic with that of a Doom-like ray caster, but I'd argue not much. The time spent rewriting the generic parts of a ray caster probably pales in comparis…

[deleted]
Post reply on HN