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

281–290 of 303 posts

Re: Why I Write Games in C

#281

Post by tome »

Jach wrote: post #269
pcwalton wrote: post #193

Earlier quoted context omitted.

> And this does not mean that the compiler is preventing unsafety; there are many safe programs that the compiler rejects. Two nits: 1. The compiler does prevent safety problems. It just happens to rule out some safe programs while doing so. (Although I think this is a bit of a misconception, because with the aliasing rules being used for optimization many things that the Rust compiler rejects that people think are s…

I think game programmers don't like type systems -- or rather, they prefer the minimal typing necessary for speed improvements and their ability to simplify basic static analysis (with tools or in their heads). I don't blame them, games are a lot of work even for relatively simple things, and to get anything done at a reasonable pace you just need to be able to churn out lots of code that compiles on the first try, a…

> the mistakes should be easy to fix and minimize the time you're spending fighting with the type system

In Haskell you don't fight the type system. It fights your bugs.

[Yes, yes, this isn't an absolute truth, but it is a relative truth when the point of reference is C++'s, or even Java's, type system.]

Re: Why I Write Games in C

#282

Post by melted »

Rusky wrote: post #171
dunkelheit wrote: post #26

Earlier quoted context omitted.

Maybe in ten years. Great thing about old mature technology such as C is that all gotchas have been tripped over innumerable times and are all well known and codified. Meanwhile new exciting technology like Rust contains unknown number of bugs like http://www.wabbo.org/blog/2014/22aug_on_bananas.html , undiscovered antipatterns and subtleties. My comment is not meant to bash Rust, on the contrary it is very promising…

That bug was almost a year before Rust 1.0 was released. At this point, Rust is being used in production outside of Servo- for example Dropbox is even using it for their core data storage code. It's certainly not as old-and-boring stable as C, but it's a lot closer than you'd think.

That doesn't inspire a ton of faith in Dropbox, TBH.

Re: Why I Write Games in C

#283

Post by loup-vaillant »

Jach wrote: post #271
loup-vaillant wrote: post #183

Earlier quoted context omitted.

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.

I'm looking forward to playing that next time I boot into Windows (couldn't get it to even create a window on my Linux machine after satisfying its dynamic dependencies (really old libpng for one), or even the Windows exe via Wine -- one of the perils of custom engine development) but I know Antichamber ( http://www.antichamber-game.com/ ), which has the similar concept of a non-Euclidean world, was built in Unreal.…

From the author of Knossu himself here http://jonathanwhiting.com/games/knossu/press.html

> [Knossu is] an answer to the question: What can you do with a Doom style raycasting engine if you're tired of realism and shooting things?

So it's a Ray caster. Which you can confirm by playing the game and looking up and down: the distortions are typical of a ray-caster.

Too bad you're using an old GNU/Linux distribution. For the record, it worked out of the box for me (Debian Testing, 32bits).

Re: Why I Write Games in C

#284

Post by dottrap »

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…

John Carmack thinks there is potential in Haskell or other functional languages for game dev, so much so that he ported Wolfenstein 3D to Haskell as a summer project.

I think he talks about in in this QuakeCon 2013 segment: https://www.youtube.com/watch?v=1PhArSujR_A

Re: Why I Write Games in C

#285

Post by loup-vaillant »

krapp wrote: post #224
loup-vaillant wrote: post #183

Earlier quoted context omitted.

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.

For that to be a valid comparison, you would have to compare the learning curve for Unity to the amount of time it took him to learn how to implement the original.

Yeah, this was a wild guess. I stand by my wild guess, though.

Re: Why I Write Games in C

#286

Post by loup-vaillant »

cLeEOGPw wrote: post #221
loup-vaillant wrote: post #181

Earlier quoted context omitted.

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.

So, roughly speaking, you can expect for a difference in the order of tens of seconds. But my question was, how relevant is this? At least in my experience, and I have worked with projects that took up to 50 minutes to fully recompile (before we moved to newer ms compiler) when taking all dlls, the full recompilation is rarely required. Sometimes you have to recompile project, which can take minute or so, but most of…

Sorry, I didn't make myself clear. My bad.

By "recompilation", I actually meant incremental compilation. I have yet to see a C++ project in my day job that takes less than 10 seconds. Not a deal breaker, but kinda flow-disrupting. As for full re-compilation, I have known one C++ project that took less than 5 minutes. The rest always took more than 10 minutes.

Re: Why I Write Games in C

#287

Post by hellofunk »

crafn wrote: post #141
hellofunk wrote: post #132

Earlier quoted context omitted.

I really like this idea of using C as a main language, but when you mention writing your own vector and hash map implementations (and undoubtedly many other fundamental tools that are otherwise provided for you by STL), doesn't that get quite time-consuming to re-invent the wheel in those areas that it's great to have a wheel already there for you?

When you drop the semantic silliness of C++, like having the container to take care of constructing, copying, moving, and destructing, not to mention exception safety, a basic implementation of a "templated" dynamic array implementation in C comes down to like 100 lines. Hash map will be a bit more, and is not so trivial to write. It's true that there should be no need to write these things yourself. The alternative…

I'm curious what you mean when you say "not to mention exception safety" ... What is the general argument against exceptions in C++?

Re: Why I Write Games in C

#288

Post by pjmlp »

ksk wrote: post #212
cies wrote: 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…

Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell? Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I'd love to be proven wrong though...

Professional game studios only change when forced to do so.

It was straight Assembly until console and OS SDK became mostly C.

Then it was straigh C until the said SDKs became C++.

Nowadays it will be C++ until they get forced to change again.

Re: Why I Write Games in C

#289

Post by ksk »

pjmlp wrote: post #288
ksk wrote: post #212

Earlier quoted context omitted.

Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell? Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I'd love to be proven wrong though...

Professional game studios only change when forced to do so. It was straight Assembly until console and OS SDK became mostly C. Then it was straigh C until the said SDKs became C++. Nowadays it will be C++ until they get forced to change again.

In your mind who is forcing them and why?

Re: Why I Write Games in C

#290

Post by pjmlp »

ksk wrote: post #289
pjmlp wrote: post #288

Earlier quoted context omitted.

Professional game studios only change when forced to do so. It was straight Assembly until console and OS SDK became mostly C. Then it was straigh C until the said SDKs became C++. Nowadays it will be C++ until they get forced to change again.

In your mind who is forcing them and why?

I said it on my comment already, OS and console vendors SDKs.

Contrary to common belief among current generation of young developers, C compilers did not always generated good code.

In the 8 and 16 bit days, proper games were done in Assembly. Any language you can think of, were the managed languages of the day.

At the end of the 16bit days, C had widespread enough outside UNIX, that OS vendors started adopting it. So SDKs were then in C.

So many were forced to use C, even if their code was mainly composed of C functions wrapping inline Assembly.

Similarly, around the PS3 time, SDKs started to move to C++. So many didn't had other options than moving along to C++ compilers. But, just like the Assembly generation, many still use mainly C code compiled by a C++ compiler.

So when an OS or console vendor says the language X is the platform's language, they either adopt it, even if only partially, or ignore the platform until they cannot avoid it anymore.

Post reply on HN