When you go to break your problem into managable chunks, do you think "what parts make this up?" (OO), "what steps do I need to take?" (procedural), or "what operations make this up?" (functional).

One reason for that is that is a lack of definition. There is no clear line because making any kind of line requires a definition.

I have never seen any group -- from rooms of engineers to standards groups -- define what OOP means with any clarity. "Proper OOP" has no definition. It means one thing to somebody, another thing to somebody else.

That's what I was afraid of .

Still... what might "well-coded" games in C look like? Or would it be quite close to a game in C++ but mostly just without the encapsulation given by things like access modifiers, and semi-advanced concepts like templates?

Pretty much. You'd mostly see well-designed independent modules and libraries using either PIMPL (= opaque structures in C) or stack-allocated "please don't mess with the internals" structs, or a mix thereof, mutable state would be minimized instead preferring to pass data back and forth in arrays of small compact structures, any dynamic dispatch would probably be implemented either through function pointers or jump tables (most likely though you would instead see composition via structures of structures and possibly tagged unions, which tend to be easier to manage in terms of complexity especially if your build system doesn't suck - protip, offloading some work to your build system can often go a long way in simplifying details of your implementation). Templates would be a bit of a problem, macros can be made to work in some limited sense. The code would probably also be interfaced with a scripting language such as Lua to overcome some of the lacking bits of the language and get the best of both worlds.

It can be quite readable, honestly, you have to go without many of the conveniences (and optimization avenues!) available to C++, in exchange you get a reasonably compact language that can for the most part be learnt inside out, a relatively uniform way of doing things without many syntactic features, and I suppose faster build times in most cases. It may not necessarily be the optimal choice by any metric, but it's certainly not the worst one I can think of. It's ridiculous how many people seem to equate C with spaghetti procedural code with globals and gotos everywhere, I personally find well-written C code to be quite pleasing actually. And it's not "OOP", it's just the sensible way of doing things given the tools at your disposal.

Still... what might "well-coded" games in C look like? Or would it be quite close to a game in C++ but mostly just without the encapsulation given by things like access modifiers, and semi-advanced concepts like templates?

Being someone who is currently coding a game in C for the lulz, I think I can answer this.

The structure of code is quite different than what I'd do in C++, but the same basic concepts apply. For instance, a lot of systems have system_init() and system_deinit() functions instead of constructors/destructors. There are no classes with methods, but there are structs for holding data and functions which act upon the data of these structs. Templates don't exist, but you can implement the majority of what templates are used for with macros. Compositing can be done with structs.

Polymorphism doesn't exist per se. I've seen my fair share of home made polymorphism in C, but I believe it's not really necessary. Most of the time you can composite.

macros?

Still... what might "well-coded" games in C look like? Or would it be quite close to a game in C++ but mostly just without the encapsulation given by things like access modifiers, and semi-advanced concepts like templates?

Being someone who is currently coding a game in C for the lulz, I think I can answer this.

The structure of code is quite different than what I'd do in C++, but the same basic concepts apply. For instance, a lot of systems have system_init() and system_deinit() functions instead of constructors/destructors. There are no classes with methods, but there are structs for holding data and functions which act upon the data of these structs. Templates don't exist, but you can implement the majority of what templates are used for with macros. Compositing can be done with structs.

Polymorphism doesn't exist per se. I've seen my fair share of home made polymorphism in C, but I believe it's not really necessary. Most of the time you can composite.

Can I say that.. I really hate macros? Of course I'm not talking about _DEBUG... but macros "abusing" like in the low level parts of the UE4 (e.g. RHI)

Still... what might "well-coded" games in C look like?

Still... what might "well-coded" games in C look like? Or would it be quite close to a game in C++ but mostly just without the encapsulation given by things like access modifiers, and semi-advanced concepts like templates?

You can download the source code for most of the older Id games on GitHub. Prior to Doom 3, they used plain C (or C with assembly in the older titles). I'm not a C jock, so I won't speak for how "well-coded" these are by modern standards, but its clear enough that I can read through and understand most of what is happening without struggling too hard.

From what I remember, at least the Quake engine is laid out in a sorta-vaguely object-oriented fashion, although it would probably be more correct to say it is component-oriented. There are variables associated with the memory allocator, and functions that perform various actions operating on them, allocating chunks of memory, freeing chunks, getting the next available chunk, and so on. Same for the renderer, or the resource loader, or the console, etc. So you can still have separation of concerns, but you have to enforce them. Again, IANACJ, but I believe you can also use static globals in a .c file to restrict visibility of a variable to just code within that file.

You can also do some templatey stuff if you use macros in C. Whether that is a good idea, well...

EDIT: Ninja'd!