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 don't suffer from insanity, I'm enjoying every minute of it.The voices in my head may not be real, but they have some good ideas!

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

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.

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 used to do all my game/engine development in C++, but switched over to C about 1.5 years ago. I can say with great certainty I will never go back to C++ (for indie work).

My reasons for choosing C have nothing to do with performance, dislike for OOP, or the need for a standard ABI. My reasons are purely social and empirical. Here are some of them:

The C++ Community:

I find the C++ community to be ridiculously divided on what is "proper" C++. I can't tell you how many times I've read posts criticizing the subset of C++ chosen for a project. "Oh, that's not C++, that's C with Class!", "Why aren't you using templates?", "Manual memory management is for grandpas, hipsters like me are using smart pointers!", and it goes on and on... Is proper C++ boost style with template meta-programming everywhere, IsItJustLikeJavaWith = new UsedEverywhere?, is it c_with_classes_style, etc... I think the chaos among the C++ community is merely a reflection of how large, divided, and diverse the design of the C++ language is.

Let me end this argument once and for all: If the code compiles with a standards compliant C++ compiler, then it is C++. Period. End of story. Just because you don't like the subset chosen, does not mean the code is not C++. There is no such thing as "Modern C++" or "Modern Java", "modern" is just a buzzword used to sell you on said individuals favorite subset.

C++ Design:

One of the philosophies of C is to trust the programmer. This rule is broken numerous times in C++. The fact you have to cast between pointer types just creates unnecessary noise in the code, nothing more. The fact you have to prefix the implementation of a class's method with MyClass:: is dumb. Objective-C got this right by allowing you to wrap your class method implementations in a @ClassName { } block. Seriously, prefixing the class on a method is data redundancy. It is not simple, it is not minimal, it is not DRY. I'm sure some developers think that because their typing more code their solution is better. This is not true and C's idioms encourage the complete opposite of this.

C++ requires lots of boilerplate. When I write C++, I end up spending about 40% of my time in the header file and/or writing boilerplate. With C its about 5%. Because of this, I do find myself developing faster in C than I do C++. If you find C slow to develop with, it could be because your using C for a task which would be better suited to another language or you just don't understand C idioms and are trying to apply Java/C++ idioms. For engine development, I never once felt the need for C++ features once I understood C's idioms.

Simplicity and the C community:

C is simple, small, and elegant. The C community encourage simple designs and solutions. This is one of the big reasons to not use C++. I see most C++ developers creating over-architected solutions. For a humorous example of this, check out enterprise fizzbuzz. I notice there is a lot of reinventing of the wheel among the C++ crowd, not so much with the C crowd. The majority of C++ libraries I have used proudly roll there own strings, containers, data structures, and often ignore the C++ standard library. In my experience, C programs and libraries tend to use the C standard library and 3rd party libs instead of rolling their own solutions.

C requires very little boilerplate. When I write in C++ I find my train of thought is constantly broken. When I write classes, I have to constantly switch between .h/.cpp files, I have to constantly repeat the class name in front of every method, etc... These interrupting tasks take my mind off the solution at hand. Contrast this with C where I can focus on solutions instead of boilerplate.

One more thing:

I am not Linus Torvalds, I do not believe that C should be used everywhere. You should use the right tool for the right job. I love using C for the low-level audio, graphics, and input handing (the engine) and a high-level scripting language for the AI and GUI (the game).

I hope this has given you some insight into my decision to use C instead of C++. I'm sure there are many C++ programmers who do not over-design, but my experience tells me they are the minority (either that or their not loud enough).

TL;DR The C community is abundant with simple libraries, simple APIs, and simple solutions. There is very little to no bickering over the proper language subset and very little reinventing of the wheel. C requires very little boilerplate allowing you to focus on solutions uninterrupted.

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.

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.

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.

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

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

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.

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]