How many of you use C for game programming?

I use it myself because of its simplicity and less haggling with accessor functions, member access, etc.

If that's your problem with C++ (or OOP?), then you're using C++ wrong.

I voted sometimes -- I mostly only use C for gluing different systems/modules/languages together.

You're missing an option "Hell no!"
Seriously, after working with std::string and the other STL containers it's hair raising annoying having to resort to C instead of C++. I sometimes have to at my work place and I'm glad if I can keep the C parts short.

I occasionally dip into standard/ANSI C, but only rarely. I much prefer C++ for things like RAII because as Endurion mentioned it really helps avoid certain classes of nasty problems.

Which is not to say I have any love whatsoever for C++.

Only in C. Because I only know C. And I like it, I like "immediate mode" style, and that I can tinker the shit out of it.
But I'm not by any means a programmer.

I tend to stick to higher level languages so C++ is rather nice especially when using boost. I don't tend to use inheritance in languages so I can see where C looks nice. The main problems I have with working in it for extended periods is string functions and lack of standard containers. I'd need to a really valid reason to choose C or C++. I can do anything in C++ in C so there's no real advantage for choosing C. Oh and one of my big gripes is malloc and free are annoying as hell to use with all their casting clutter.

Got forced to for a month or so once - found lack of destructors for RAII the most annoying part. In some ways, I tended not to be as guilty of over-engineering when using C, but equally projects were far more brittle and buggy.

I use C for some of my game programming. Mostly this is because it's one of the languages I'm strongest with, it works well if I plan the architecture in advance and I'm better at debugging C than some other languages. Libraries are easier to use too. Downside is the lack of namespaces and the need to find libraries to do basic things like working with strings (although if I'm doing a lot of string work I'd use another language like Python).

I sometimes use it for small development tools, for instance a small command application that converts one binary format into another, but that's it.

I'm very curious. I use it myself because of its simplicity and less haggling with accessor functions, member access, etc. Though many may not agree with me. I'm just curious about what people's take on this is.

I have this crazy idea sometimes that I want to program in C so at one point I rewrote my latest project to C. I may go back at some point but I am thinking that if I need a high level language I would embed Lua instead of using C++.

I was thinking about what you say about accessor functions. You don't have to use them in C++ and you can, and sometimes should, have them when programming C. But it was quite a relief to get away from idiomatic C++ and just solve the problem. But this limitation is just our heads.

I also think C is quite fun. It is nice to find different solutions to the problems. But having to write container classes is a mess. It takes a few iterations to get them right. I know I am talking against my last paragraph where say "just solve the problem" because I would get some stuff done faster if I would stick to C++ and code with an open mind.

Also C code compiles a lot faster than C++. I think 2 or 3 times faster!

I use C++ at work, but like to write my personal game projects in C. When I write code in C, I tend to put the data first and be a little more pragmatic about architectural decisions. I don't waste time on building complex class hierarchies with the intent of reusing them again - I just make the damn game. C is also a lot easier to bind to other languages like Lua, Python, or Mono, and in those languages you can do all the OOP you want. C is also a little easier to throw on an SPU.

I avoid C like the plaque. It doesn't have anything that C++ has like templates, smart pointers, containers, string classes, etc. I personally C a waste of time anything above system/hardware level.

Yes. For an iOS game.

Yes. For an iOS game.

iOS uses Objective-C

[quote name='Tachikoma' timestamp='1295885819' post='4763935']
Yes. For an iOS game.

iOS uses Objective-C
[/quote]

To be clear, the iOS APIs are written in Objective-C, but your game code doesn't have to be. You can mix C and C++ with Objective-C very easily.

Never, I see very few advantages in using it. If accessors are a pain then just make the variables public.

I find C too low level to get any real work done efficiently. The lack of standard containers really drags things down.

Other than that, it's a much nicer language than C++ to use. It's simpler and doesn't have nearly as many caveats, which allows you to better focus on the problem at hand. C tends towards minimalism: "what's the simplest way to make this work?" C++ entices you to think big: "how can I make this more general reusable"? (This is a trap, don't do it!)

That said, given a choice I avoid low-level languages completely. You don't need to use C++ to create a game and you don't need C to create a reusable component. Once you manage to accept that (it's harder than it sounds) a bright new world of possibilities opens up! Life is too short to spend it working on yet another container (or waiting for it to compile).

Well, I can work pretty fast with C. Reusable (or easily modifiable) stuff has been gathered through the years of coding. Okay, I usually don't give a shit about nice design (and I'm too lame to go multithread). I need stuff to load? A global 1million sized array! I need a flag or a state variable? A global variable, huhhh

Oh and one of my big gripes is malloc and free are annoying as hell to use with all their casting clutter.

If you need to cast, then you're trying to compile a C program as C++. My favorite idiom is:
Type *var = malloc(sizeof *var);
free(var);
This is less brittle, more readable, and the compiler will tell you if there's no prototype for malloc(). I don't know how relevant that last part is anymore. Maybe it could cause a problem if sizeof(int) isn't the same as sizeof(void*)?

But, I still agree that there's not much use for C in game programming. The only place I could see using it would be as a lighter choice than C++ to drop down to from a higher level language, whether for speed or gluing bits together. In those cases, I see myself using mostly the C subset of C++, and C++ isn't as good at being C as C is.

I might get flamed for this, but oh well, I'm used to it. I think C++ promotes alot of bad programming practice and laziness, especially for beginner programmers. I don't hate C++, but I prefer straight forward C over some class/template crazy C++ code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in C++, you can do in C, but just requires a bit more effort.

I wrote my first 3rd person shooter game in C. Saw no advantage in using C++ whatsoever, and it was easier to follow/maintain.