Live data from Hacker News

Why I Write Games in C

jonathanwhiting.com

141–150 of 303 posts

Re: Why I Write Games in C

#141
post #129

Earlier quoted context omitted.

That's partly true. However, you do get rid of the complexity you never wanted in the first place. For me this is OOP, RAII, C++ allocators, exceptions, references, vtables (see my post about runtime recompiling), templates (mostly), C++ standard library (I'd have to write my own vector for fast compilation. I'd have to write my own hash map to get contiguous storage (IIRC)) C is by no means optimal, but it's still o…

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 C++ gives is not really tempting. A language designed for demanding game development doesn't exist (yet), so one evaluates which is the least worse option.

Re: Why I Write Games in C

#142

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

Better yet, avoid STL altogether and use Qt. It makes C++ very manageable and uncomplicated.

I can't agree with this, though I do have respect for Qt. But, having to put magic macros inside all your subclasses doesn't really make things simpler... and, Qt's own libraries for doing many of the things that the STL does are mostly of the same complexity as the analogous tools in the STL.

Re: Why I Write Games in C

#143
post #137
post #116

Earlier quoted context omitted.

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).

if you don't want to watch the video, here is a basic overview tldw; of the technique: on every run of the game loop(usually every frame), reload a dynamically linked module (dll for windows, .so for linux), which contains the actual code you want to run every frame. The function you then invoke from the module must be passed the entire block of memory allocated for the game state. You then just recompile the dll/so…

I assume you'd be using techniques discussed here?

http://stackoverflow.com/questions/384121/creating-a-module-...

Re: Why I Write Games in C

#144
post #141

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…

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?

Re: Why I Write Games in C

#145
post #124

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

>The ability to have objects doing things C-structs work fine. In my experience, for things like games, C-structs are capable of doing everything you need objects to do. The lack of polymorphism and other OO stuff, makes C code easier to reason about and maintain.

The original creator of the C++ STL has said in interviews that after a long career of C++ development, he still never uses -- and sees no use for -- any model of inheritance for anything. I've since learned that my own C++ code is much better when I very sparingly, or never, subclass anything. This has the added benefit of also never using vtables.

Re: Why I Write Games in C

#146
post #116

Earlier quoted context omitted.

>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).

Really great feature. But it doesn't tell anything about the quality of the code.

Through out his complete series haven't seen any unittests for example.

So I my book. No unittests => crappy code.

His use of vtables is completely unrelated to the feature.

Re: Why I Write Games in C

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

As good advice as this is, waiting 10 or 20 for compilation is just sad.

Re: Why I Write Games in C

#148

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?

Generally speaking , people tend to re-use the code . I have a complete folder filled with tons of reusable snippets which I keep optimizing there and there if some new idea comes up , otherwise they are good .

Put those puppies up on github for the rest of us to enjoy! or, if not, can you recommend some good repos that showcase great C snippets that help in a lot of situations?

Re: Why I Write Games in C

#149
post #138
post #129

Earlier quoted context omitted.

That's partly true. However, you do get rid of the complexity you never wanted in the first place. For me this is OOP, RAII, C++ allocators, exceptions, references, vtables (see my post about runtime recompiling), templates (mostly), C++ standard library (I'd have to write my own vector for fast compilation. I'd have to write my own hash map to get contiguous storage (IIRC)) C is by no means optimal, but it's still o…

- OOP you only get if you use it. - RAII you only get if you use it. - exceptions you only get if you enable them. - references. no overhead. - vtables. you only get them if you need them. - templates. no overhead runtime. - C++ standard library. you only get it if you need it. - what's wrong with vector ? hash map ?

Yeah, and what's left is not much of C++. See my post about runtime recompiling for arguments to use C compiler instead of a very limited subset of C++.

(References make the type system more complex for little benefit. Templates create massive amounts of complexity and slow down my iteration loop. Already explained what's wrong with std::vector and std::unordered_map.)

Re: Why I Write Games in C

#150
post #112
post #92

Earlier quoted context omitted.

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 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 assumption...

Post reply on HN