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

161–170 of 303 posts

Re: Why I Write Games in C

#161

Post by JoeAltmaier »

Tistel wrote: post #160
je42 wrote: post #152

Earlier quoted context omitted.

Don't mix language features with engineering mistakes.

Oh, I agree. Its not the language's fault. You can write a good or bad program in any language. No language can save you on its own. But, as the expression goes: some programming languages give you enough rope to shoot yourself in the foot, other, enough rope to blow off the whole leg. I have done C++ for 14 years. It can be great and fast if you are careful.

I use C++ because of the leverage. It automates so much that folks do by hand in C. Like a power tool vs hand tools. I know, lots of folks are nostalgic for handmade crafts using only simple tools. But I'll never go back.

Re: Why I Write Games in C

#162

Post by theseoafs »

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…

Well, obviously, a game state can change even if a player had no input. So you would have to have some concept of an empty player input on your model. (Also, modern games often require pulling from databases, remote servers... It's not just about transforming game states and rendering them any more.)

The problem with games are that they have a lot of state, and a lot of loopy state. You end up in a place where you have a set of entities which are organized into a graph and you need to traverse this graph and destructively update some elements in a way that is visible immediately to all elements. You can do this in Haskell, but... It won't be easy. Definitely much tougher than doing it in C, and at the end of the day your game written in idiomatic Haskell will be more complicated and less performant than the C solution.

Also, see: http://prog21.dadgum.com/3.html http://prog21.dadgum.com/23.html

Re: Why I Write Games in C

#163

Post by je42 »

crafn wrote: post #58
raverbashing wrote: post #6

I understand the want for simplicity in C (and Go gets closer, but has its issues), however, it seems in the end it drags you down. Just having the C++ ability to have objects doing things is very helpful. But yeah, C++ has the ability to get very complicated But it's your choice to have "complicated C++". Limit yourself to some functionalities and it's much more manageable. Use basic STL and keep it simple (also C++…

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.

Re: Why I Write Games in C

#164

Post by loup-vaillant »

chii wrote: post #131
fennecfoxen wrote: post #103

Earlier quoted context omitted.

> their own private code framework that is too complicated for anyone else to make use of Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. The real sadness is when you get corporate websites, technology platforms, and the like that decide they need their own framework to make their own set of tradeoffs, and do a mediocre job of it, and end up with a…

> 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 comparison to the specific parts of his graphics engine.

(Of course, your point stands in general. But for Jonathan Whiting in particular, I have the feeling that it may not.)

Re: Why I Write Games in C

#165

Post by chongli »

fennecfoxen wrote: post #103
petke wrote: post #96

You don't really get rid of complexity by using a simple language. You just move the complexity into your own code. Say if your language doesn't have dynamically sized containers, you will end up writing your own. You hack it so you can store different types in it. You have reinvented polymorphism. And then you need sort functions, and everything else that is missing from the language. And it wont be simple any more.…

> their own private code framework that is too complicated for anyone else to make use of Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. The real sadness is when you get corporate websites, technology platforms, and the like that decide they need their own framework to make their own set of tradeoffs, and do a mediocre job of it, and end up with a…

Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed.

Huh? I don't know what the numbers are but I'd hazard a guess that the majority of games out there (at least those written by more than one person) use a 3rd party commercial game engine.

Re: Why I Write Games in C

#166

Post by typedef_struct »

hellofunk wrote: post #144
crafn wrote: post #141

Earlier quoted context omitted.

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…

Considering that vector, map, etc are widely used and expected features of software development, I would think that good libraries in C exist for these already, so you don't have to even write your own 100 lines. Are there any?

http://troydhanson.github.io/uthash/

Re: Why I Write Games in C

#167

Post by Rusky »

chii wrote: post #131
fennecfoxen wrote: post #103

Earlier quoted context omitted.

> their own private code framework that is too complicated for anyone else to make use of Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. The real sadness is when you get corporate websites, technology platforms, and the like that decide they need their own framework to make their own set of tradeoffs, and do a mediocre job of it, and end up with a…

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

That sort of code does get reused a lot, when games are built on third-party (or in-house) engines. But I don't think it would make sense to just consolidate all of it- engines make different tradeoffs on how geometry data is formatted, laid out, and processed, and that continues to be an area of optimization and innovation.

As far as initializing the hardware, that's a relatively small, one-off piece of code that's different for every platform (including consoles) anyway.

Re: Why I Write Games in C

#168

Post by claystu »

shurcooL wrote: post #74

> The library support [in Go] for games is quite poor, I'd like to know the author's familiarity of Go libraries. Perhaps he's unaware of what does exist and makes false claims, or perhaps he's saying accurate statements and just has really high standards. I help maintain many of the Go libraries/wrappers for games, so I might be biased, but I'm happy with what is available. Almost more so than when I was using C++,…

Can you point to some blog posts on this subject? I would love to see what's out there.

Re: Why I Write Games in C

#169

Post by Rusky »

Keyframe wrote: post #109
dom96 wrote: post #66

How about Nim? [1] [2] To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more. 1: http://nim-lang.org 2: https://github.com/nim-lang/nim 3: http://nim-lang.org/docs/gc.html#realtime-support

If Nim compiles down to C and then you compile/link that.. How in the hell do you debug that?

Nim seems close enough to C that you should be able to use the #line directive to map lines of C to lines of Nim source, keep variable and type names the same, and just use gdb.

Re: Why I Write Games in C

#170

Post by stinos »

jb1991 wrote: 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…

10 or 20 seconds waiting for compilation .. but more importantly it breaks my flow

Luckliy the OP doesn't build for microprocessors etc. There you wait for compilation (of C, for instance) but than the damn thing has yet to be flashed.. Thing is, it actually learns you how to not let it break your flow. Which is a valuable skill.

Post reply on HN