Why I Write Games in C • Hacker News Board

Re: Why I Write Games in C

#131

Post by chii » Sat, Jan 09, 2016, 3:49 PM UTC

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.

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 setting up a rendering environment ought to be the same for most, if not all games (i can't imagine initializing directx or opengl would be different for different games).

Game logic is one area that is going to change a lot between games. However, if you partitioned your game logic well, wouldn't it make the next game easier since you're "just" swapping game logic?

Re: Why I Write Games in C

#132

Post by hellofunk » Sat, Jan 09, 2016, 3:51 PM UTC

crafn wrote: post #129

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

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?

Re: Why I Write Games in C

#133

Post by Grishnakh » Sat, Jan 09, 2016, 3:51 PM UTC

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

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

Re: Why I Write Games in C

#134

Post by seba_dos1 » Sat, Jan 09, 2016, 3:52 PM UTC

strangecasts wrote: post #98

jeremyjh wrote: post #91

Earlier quoted context omitted.

>I would say the same for C, honestly. Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines: https://en.wikipedia.org/wiki/List_of_game_engines

Another nice library is SFML[1], which has bindings for C and several other languages (including OCaml). [1]: http://www.sfml-dev.org/

There's also Allegro[1]. While its popularity peak was on older versions, Allegro 5 has been completely redesigned and it's a pretty great modern C library now.

[1]: http://liballeg.org/

Re: Why I Write Games in C

#135

Post by Narishma » Sat, Jan 09, 2016, 3:56 PM UTC

douche wrote: post #102

pandaman wrote: post #14

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.

They were dead after the last generation too. And the one before it as well.

Re: Why I Write Games in C

#136

Post by je42 » Sat, Jan 09, 2016, 3:58 PM UTC

lmedinas wrote: post #85

je42 wrote: post #51

no auto in C. no standardized data structures. no lambda. no exceptions. and C++ still compiles actually fast. at least on my machine.

For years developers used C++ without most of these features and built great code. So this is not the problem of C. There are still lot's of great code done in C.

Really ? Look at this code: https://github.com/danfis/libccd/blob/master/src/ccd.c Looks like great C code doesn't it?

Still you see lots of plumbing: 1. call of init functions 2. unsafe array/pointer usage 3. goto

I rather use C++'s functional constructs rather than the imperative ones. It is less code, that directly self-explains the business logic; instead of being littered with (unsafe) plumbing code.

And IF I find a performance bottleneck - I can still opt to use/develop an unsafe lowlevel version.

Re: Why I Write Games in C

#137

Post by chii » Sat, Jan 09, 2016, 3:59 PM UTC

adrusi wrote: post #116

hellofunk wrote: post #107

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

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 module when you make a change, and the game would execute the new code on the next frame. Adding new data structures is OK as long as you don't mangle an existing data structure...but because a game can expect to work with a constant block of pre-allocated memory, this actually works fine most of the time...

Re: Why I Write Games in C

#138

Post by je42 » Sat, Jan 09, 2016, 4:02 PM UTC

crafn wrote: post #129

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

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 ?

Re: Why I Write Games in C

#139

Post by nautical » Sat, Jan 09, 2016, 4:04 PM UTC

hellofunk wrote: post #132

crafn wrote: 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?

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 .

Re: Why I Write Games in C

#140

Post by seba_dos1 » Sat, Jan 09, 2016, 4:04 PM UTC

johnydepp wrote: post #68

I write games as well (Written more than 10 games, though they are not very large at scale) and I write them in C++. Reasons being writing networking code (TCP/UDP) is much easier & efficient in C/C++ than any other language IMHO. And most of the code works across platforms.

Just my 5 cents: Although there's nothing wrong with it in the context of your comment alone, C and C++ are so distinct languages it's weird to see them aggregated as "C/C++" given that the article is about C and it explicitly recognizes C++ as a bad alternative.