C in game development

I am big fan of C, not so much devoted to c++.

Does maybe someone know how much widely used is old good (and fast) c in game development (in relation to c++ usage) ? In big games?

[And besides that are here maybe fans of C who much prefer it than c++

like me, here? Asking for curiosity]

Not much at all, C doesn't provide any advantages over C++ these days when it comes to performance and has several disadvantages when it comes to security and productivity, C99 and C11 compiler support is still awful on Windows. (MSVC only supports C89) and using C++ still allows you to write c style code in areas where it is beneficial to do so.

I am big fan of C, not so much devoted to c++.

Does maybe someone know how much widely used is old good (and fast) c in game development (in relation to c++ usage) ? In big games?

[And besides that are here maybe fans of C who much prefer it than c++

like me, here? Asking for curiosity]

Not much at all, C doesn't provide any advantages over C++ these days when it comes to performance and has several disadvantages when it comes to security and productivity, C99 and C11 compiler support is still awful on Windows. (MSVC only supports C89) and using C++ still allows you to write c style code in areas where it is beneficial to do so.

c offers a 'different style' - the main points for example

- procedural

- not using templates

- static arrays way

it has some advantages for me

You can do that in C++ too, so that's no advantage.

You can do that in C++ too, so that's no advantage.

This is c-way, And if this is both c and c++ (as a c heritage) I call it a c not c++ (c++ would be oop, templates, constructors and such stuff - way of writing)

[so here if I am talkimg about c, I think about such "c-way" of writing against "c++/oop way" of writing (coding)]

after that jump to my first question, is such procedural "c - style" coding present in this day big games debelopment or not too much ?

I'm like you. I prefer the style of code that comes from C. C++ of course can be used for the same style, but as soon as you start taking advantage of its features, using inheritance, virtual functions, templates, smart pointers, RAII... it's like the language is herding you toward a particular coding style. Which is fine, and I do like it for windowed apps such as my map editor. But for games, I like C.

It's hard to quantify exactly why. I think it's the same flaw in my brain that makes me want to use hand tools in woodworking rather than power tools. I know I could probably get the job done about just as well in less time other way, but it's more direct and satisfying the old fashioned way. It feels more freeform, plus you can get away with more hackerly mischief

I wouldn't want to use C on a large and complex team project though (say an MMORPG). It's ok for reasonably small teams (2-4 programmers), but mostly I like it for solo projects where I have absolute control over every detail..

I do still use OOP in C. Make a struct, and a set of functions that go with it. It's just the natural way of things a lot of the time. But I use static allocation rather than dynamic as much as possible, which feels less natural in C++ most of the time.

But one of the main things I miss when coding games in C is weak pointers. Just not elegant enough to try to implement them without templates, so I end up using "dead" flags and clean up the carcasses on the next run through a list or whatever, rather than just deleting something on the spot and knowing that anything referencing it will be nulled automatically. Not a big deal, but just more to think about, whether you need to check if something is dead before interacting with it or whatever..

C does have a few indirect advantages:

it is easier for "mere mortals" to write parsers and compilers and similar for it (whereas a "reasonably complete" C++ compiler is a much bigger undertaking);

it has a simpler set of ABIs which are more consistent between compilers, making it a little more reasonable to interface with C from ASM or dynamically-generated machine code, ...

granted, some of this can also be handled via 'extern "C"' as well (so the tools can mostly ignore that they are interacting with C++), or via a C++ subset, but this has a few other issues (now it is more necessary to qualify which sets of features are supported, ...).

this is not to say that everything is perfect in C++ land, as on the internet, one can usually run into lots of (usually pointless) arguments about elements of coding style.

in C land it generally tends to be a lot closer to a "whatever goes" mindset. granted, a person can do so in C++, but then get hated on a bit more than if they did so in C, where one mostly just gets looked down on for using the "archaic" C language.

...

I wouldn't want to use C on a large and complex team project though (say an MMORPG). It's ok for reasonably small teams (2-4 programmers), but mostly I like it for solo projects where I have absolute control over every detail..

There is at least one large and complex MMORPG engine that is programmed mostly in C.

In a way, C is easier for a large team than C++ because there are fewer ways to obfuscate behavior, intentionally or unintentionally. It is a much smaller shared language to learn than C++. There is an advantage in not having certain features.

There are certainly large games that are filled with C-style programming, even with a C++ compiler. First, there's all the legacy code still around from before studios switched over to C++. Second, there are plenty of game programmers who still use C-style a majority of the time. Third, there are often style guides that help deter against templates and virtual functions.

In my experience with large software projects, the C-based ones have been easier to read for me than C++ projects. Maybe it's just because I'm better with C (though I learned C++ first and then went back to C). I think that it's due more to how programming in C is relatively more explicit. People can get fancy in C++ doing things automatically in destructors, assignment operators, custom memory allocators, templates, and all sorts of other language constructs that have potential for hidden meaning. In C there are some clever tricks with macros but even then I haven't worked on any code that really goes nuts there.

In C++ I often have to use a debugger to step into code to know what's actually being called, before even reading through the code I need to work with. In C I am usually able to grasp what's generally going on in a text editor before diving deeper into a problem.

I don't mind elegance when everything works, but if I have to look at a piece of buggy or slow code, I'd rather it be as dull and procedural as possible.

Does maybe someone know how much widely used is old good (and fast) c in game development (in relation to c++ usage) ? In big games?

In the United States, at least, the primary language used for AAA games right now is C++. If you want to make AAA games, you should be comfortable using C++. If you do not wish to use C++, this is going to really limit your options.

Many studios tend to favor the use of composition over inheritance, and Entity Component Systems are very popular (http://en.wikipedia.org/wiki/Entity_component_system). Some studios have, in recent years, moved towards a more "functional" style of C++ programming (http://msdn.microsoft.com/en-us/magazine/jj553512.aspx), so it is worth being conversant in recent innovations in that area.

However, many people are completely abandoning C++ for non-AAA projects. OO-languages are still fairly dominant, but really, your options are pretty wide open, if you're working on indie games.

The following is going to be a bit of a rant. Before I start, my intention is not to offend anyone, everyone is entitled to their own opinion. With that out of the way, here is my story:

I seem to agree with most that (this about boilerplate and overcomplex weak design) (probably)

Personally I am writing almost exclusively c so I dont even know c++ to much. (I am moderately experienced, 100k lines in the backpack at my back)

As to communities I am personnaly the one c-liker person in my community (I use c++ compilers like mingw but do not use c++ features)

The people i talk with are always c++/oop people, (c++ community people) so I would be curious how it is in these days big game development (are such projects c++ oop stuff mostly or there is some big percentage of oldskul procedural c these days also)

I know it can be hard to answer because of people have their own experiences not neccesary 'statistic' of wide view of the 'industry' or something like that.

As to communities do you think that c++ community is much larger than c community in general these days? I have no idea on that.

Does maybe someone know how much widely used is old good (and fast) c in game development (in relation to c++ usage) ? In big games?

In the United States, at least, the primary language used for AAA games right now is C++. If you want to make AAA games, you should be comfortable using C++. If you do not wish to use C++, this is going to really limit your options.

Many studios tend to favor the use of composition over inheritance, and Entity Component Systems are very popular (http://en.wikipedia.org/wiki/Entity_component_system). Some studios have, in recent years, moved towards a more "functional" style of C++ programming (http://msdn.microsoft.com/en-us/magazine/jj553512.aspx), so it is worth being conversant in recent innovations in that area.

However, many people are completely abandoning C++ for non-AAA projects. OO-languages are still fairly dominant, but really, your options are pretty wide open, if you're working on indie games.

well, nice

I could stand c++ but I am not to much devoted to it.

Not sure if I would like to go into big game bussines but it is always nice to coding person to know what 'they' are doing/coding.Tnx for info in the 2nd paragraph, I will check it.

OOP is successful in big project because it can offer the possibility to "prove" that a certain piece of code to do something "works" and it's immune from misinterpretations and abuse.

This is, of course, possible in most every language, but OOP seems to expose the basic concepts in a more direct way.

In languages like C, you can have a struct with functions doing "work" on them and, if use correctly, they work. The problem is that if you forget to call some "init" on your struct, or some "release" on your struct, or if you go there and change a value in that struct ignoring the fact that there are 3 more members that need to be changed to keep the struct in a "valid" state.

C++ (OOP in general) is an attempt to solve this by exposing objects with an interface that guarantee the validity of the data in every situation.

Now this seems to be the obvious way to go when writing programs in the large.. you see somebody's else class, you assume once you create it it'll be "ready to go" and that it'll be valid no matter what methods you call on it.

There goes the theory.. in practice, there seems to be a growing community of programmers that think that's not really the case.. and that all this bureaucracy in the languages is just moving the responsibilities around, from the user of the "black box" to the implementer of the "black box".. which sort of makes sense because the implementer should know better. But when there is a problem , then it is often hidden under countless layers of abstractions and constructs.

But in a perfect world, if you can choose between a mindset that goes:

// In C

// Instantiate a struct

MyStruct data;

// How I initialise this? Look for a function that looks like InitMyStruct.. found it

InitMyStruct(&data);

// Right, what can I do with this one? IDE can't help me, I have to guess a naming convention or potentially look in every possible .h

// for functions taking a MyStruct* as parameters.. ok got one

UpdateMember(&data);

// But... would this work too?

data.member=10;

// No way to know

// Now I am done with it... should I clean this up somehow? Start my endless search for something that looks like, cleanup, release, destroy.. you name it.

// Got it

ReleaseMyStruct(&data);

As opposed to the C++ "way":

MyClass c;

// No thinking, c is initialised and readu

// What can I do with this? Just write c. and get the IDE showing you the methods callable on c

c.UpdateMember();

// Can I do this?

c.member=10;

// If member is public, then it means it is possible to assume the member has no dependent members, so good to go

// Done with it? Should I worry about anything else? nope.. if there is clean up the destructor will take care of it

Why would you ever choose the C way?

Personally, I would feel "lost" in C after so many years of C++, but, I love coding in Google Go... and I really think that you guys in love with C should check Go out because reading your posts I had this feeling I was reading or listening to somebody of the Go team explaining the reasons behind the simplicity of Go and its relationship with C.

The mindset I have when using a Go library is totally different.. I dont rely on intellisense to suggest me the usage of a particular class, I open the implementation or the docs and read how to use it... as someone smarter than me put it: it looks like a polite conversation between engineers.. where, in C++ it often looks like the conversation between a paranoid father and a demented kid.

I could stand c++ but I am not to much devoted to it.

It seems to me that you want to flame and/or complain about c++. There's no problem with that, but it won't come to an end, either. The points that are mentioned here as disadvantages of c++ are more or less problems of the people using it.

Sure the, oop-fizzbuzz example is funny, but that's because it is completely exaggerated.

I think there's no point in "being a fan of language x". It's a question of what feels best, what is best for the project in aspects that are important for the project.

...

in that struct ignoring the fact that there are 3 more members that need to be changed to keep the struct in a "valid" state.

...

In c i do not use such approach you mention - as a c++ object as a shield interface for some "its internal state inconsistency" against weak users

(probably I used to evade internal states in such type modules at all. (I would be must think a little about that to explain the difference)

Do not have to fight with that because it does not seem to appear at all.Though I do not work in a team , I never handed a module/c-file to somebody and said use it such-and-such, so i do not know. But probably as I said I prefer the stateles modules (As speaking of some side-internal-state to spoil)

Also I do not use such alone object structures you mention:

I do not used just one of it - all my data practicaly are few big global tables of instances only - got initialisations but got no 'destruction' at all - when I need container for thousands of bullets which are of short living I use something like a pool of structures in the static array - its quite efficient and clear (though is staticaly limitted to some arbitrary limit - so it is some kind overflow prone)

I could stand c++ but I am not to much devoted to it.

It seems to me that you want to flame and/or complain about c++. There's no problem with that, but it won't come to an end, either. The points that are mentioned here as disadvantages of c++ are more or less problems of the people using it.

No I really do not want to flame, If it goes it way it was no my intention. I do not want to convince somebody not to use c++ use c or something like that. Im mainly curious what is in use in big titles production thise days and what it look like,

(And mainly if procedural c is in usage here 'yet' - becouse I am personaly liker of that) If somebody does know. Thats all Do not want to flame on that.

all my data practicaly are few big global tables of instances only

ya sure, globals everywhere.. why not?

Surely it's faster to hack together a small simple program like this... but do you really think companies investing millions should approach their software with the same careless attitude you show here?

Global state is a proven major source of bugs and general impossibility to maintain a software that grows beyond a certain size.. most modern language design is targeted towards eliminating global state and shared state. They DO require more thinking and pre-design of your code, but that's what might save the company from ending up with an unmanageable mess of spaghetti code.

I hope you understand that trying to propose a bunch of big global state in C-style as solution to any problem is going to get you out of any decent job interview in 30 seconds.

all my data practicaly are few big global tables of instances only

ya sure, globals everywhere.. why not?

Surely it's faster to hack together a small simple program like this... but do you really think companies investing millions should approach their software with the same careless attitude you show here?

Global state is a proven major source of bugs and general impossibility to maintain a software that grows beyond a certain size.. most modern language design is targeted towards eliminating global state and shared state. They DO require more thinking and pre-design of your code, but that's what might save the company from ending up with an unmanageable mess of spaghetti code.

I hope you understand that trying to propose a bunch of big global state in C-style as solution to any problem is going to get you out of any decent job interview in 30 seconds.

I do not know how would it be in a very large game project

I was not talkin on that, this would quite different topic

Many big systems are written in c so they probably are build around some global tables [?] and it is not necessary a mess

But this is different topic - (though interesting to: are big c-code system build around of bunch of some big global tables with data ?- this 'globalness' is no problem for me necessary, worse thing is that they are static sized tables and i do not know how achive flexibility in such static array approach, If they use a linked list with heavy malloc free it would be slow i think, maybe some mixed approach linked arrays or something like that - I do not know)

[but this all is maybe a kind of digression so maybe I will cut it here - though if somebody do know (depth architecture of some big c-based systems) I would like to know about it its interesting to learn]

Using C for games certainly isn't impossible but I find myself just recrafting a toy version of C++ with macros etc...

The following was a small prototype game developed using C a while back (compiled using Clang/Emscripten)

http://50.57.98.84:8080/legfria/

Some notes...

- I really missed exceptions.

- One level of inheritance is possible (using update, draw function pointers) but more gets really fiddly

- Works great with SDL (and OpenGL) and don't need to worry about fiddly unique_ptr deleter functions etc...

- Compiles in a fraction of the time as C++. Probably about 10% time taken (with Emscripten).

- Much smaller output size (matters more with Emscripten than a .bin for Linux or .so for Android)

- Compiles with minor tweaks in any "C family compiler" Objective-C, C++ (so quite portable perhaps)

- glm maths library is C++... this was a pain because I like using a "standard" maths library rather than a hand rolled one.

- Debugging C with lldb or gdb is trivial compared to C++.