Writing a Game in C

[ledow]

Fun thing: I actually learned C while/by doing Quake (and Q3A) modding. The C one can find there is pretty elegant and kinda close to OO.

QuakeC was one of my early forays into C-like languages when I was younger. I remember coding my own mod to fix something-or-other in Co-op but can't remember exactly what it was - my brother and I played multiplayer mods and it was something to do with the way you picked up weapons, I think (maybe the weapon-switching? I can't remember). And I stripped apart the Wyrm mod and cut out a lot of the features that we found too buggy to play multiplayer - damn that had a lot of different mods thrown into it.

 

[pisiiki]

There is no reason today to avoid c++. Most of the libraries are just headers. Some people here mention that c++ is bloated and you end up messing with oop/patterns, not with code. The point is that you can't learn c++ with some books, you can't learn c++ doing a computer degree and you can't learn c++ modifying code. The only way to learn c++ for a normal human being is spending years programming in c++.


Most modern languages are not real oop on purpose, avoiding basic elements like multiple inheritance or references/pointers to smooth the learning curve. The biggest problem that you may find as a c++ programmer is that some guy in your team may break your code while "adding something" and silently commit it causing a disaster two weeks later. In C you would need just one week to realize.


To make this post even more funny, lets just put that most people that claim to understand c++ don't even understand c (which is a subset). So it is more safe to trust someone who claims to know c. A good way to check if someone has decent c++ is to ask him what is virtual inheritance and what components of the stl/boost/c++11 he uses.


cheers.

 

[sebt3]

Some people here mention that c++ is bloated and you end up messing with oop/patterns, not with code.

read the content of this tarball to understand their points : http://sourceforge.net/projects/plee-the-bear/files/Plee%20the%20Bear/0.6/plee-the-bear-0.6.0-light.tar.gz/download

 

[Letalis Sonus]

(which is a subset).

Well, not really. Even the old C89 standard has incompatibilities with C++ and with the new features of newer C standards they are drifting apart even more. But usually you only run into small issues as most people limit their code to some C89 based variant (i.e. including some smaller new things like C++-style comments).

 

[Ziz]

Resurecting a 8 months old threads... But why not, I didn't mention it and I love to write C.


I think C is a fine way for developing small, fast games for handhelds like the pandora or slower hardware like my gp2x.


In C++ you have to better know, what you do, because much things are done in a black box. E.g. lists, vectors and deques. Their are all some kind of a list, but one is a linked list, which is very fast with adding something and iterating over the data, and one is a classic array, which is very slow with adding another element, but very fast with accessing an element by it's number. You have to KNOW these. In C you know it, just because you do it yourself. XD That was just an example. There are more classes, where you should exactly know, how their work.


Furthermore C++ is a little bit slower than C. I tested it. It is not much, but if I have the choice betwen 19 and 20 frames per second. ;-)


The last point - which many people told before - is, that you get a result very fast and it is easier to let it grow (from prototype to the finished game).


Sometimes I just don't NEED and WANT OOP.


greetings, Ziz

 

[bzar]

In C++ you have to better know, what you do, because much things are done in a black box. E.g. lists, vectors and deques. Their are all some kind of a list, but one is a linked list, which is very fast with adding something and iterating over the data, and one is a classic array, which is very slow with adding another element, but very fast with accessing an element by it's number. You have to KNOW these. In C you know it, just because you do it yourself. XD That was just an example. There are more classes, where you should exactly know, how their work.

Not exactly disputing this, but it's true for all C libraries as much as STL in C++. Basically all you should worry about regarding containers is asymptotic complexity for the operations you plan on using and in edge cases memory usage. Asymptotic complexity is IIRC documented for STL containers.

Furthermore C++ is a little bit slower than C. I tested it. It is not much, but if I have the choice betwen 19 and 20 frames per second. ;-)

Yes, by a tiny fraction. It's true it may mean the difference between something like 58 and 59 FPS, but I wouldn't go as far as 19 and 20.

The last point - which many people told before - is, that you get a result very fast and it is easier to let it grow (from prototype to the finished game).


Sometimes I just don't NEED and WANT OOP.

You can do C++ without OOP . There are still nice features like function overloading, templates, foreach for regular arrays, and a host of other things.

 

[elwing]

I've written lot of both C and C++... in the end you can do anything with both language, what it boils down for me is that:

• you can also do OOP in C, but writing big OOP system is a pain in C compared to C++.
  
• C++ provide lot of useful standard library, and there's BOOST.
  
• arguments about performance between both language are moth, to do the same thing both language perform roughly the same if written correctly (through some OO mechanism and some library are quite heavy... heavier than what you can write in C if you somewhat limit your implementation to what you exactly need). when you have hard constraints avoid using OOP, just write your code like you would in C and still profit of templates and other "free" C++ goodies...
  

To me the only reason to write C only code is the lack of (good?) C++ compiler for your specific target.

 

[klapse]

As a procedual coder from the DOS days, I find amusement in this OOP discussion. Here for example are filesizes of programs that do the same thing:


C/asm: 98k AVATAR.EXE + 45k TITLE.EXE = 143 kbytes


C++: u4 = 2017 kbytes


I hate you bloated fat OO people. I hate the way you think. And I hate the excreted executeables that result from it.


I just found a method that gets called 10 times in a row in xu4 upon a single keyboard input, uselessly, and cannot figure out why the hell it gets invoked 10 times upon entering return.


I know I belong to a different generation but you damned kids manage to make a modern PC (which is a -supercomputer- by 80's standards) bogged-down slow just entering text (into a webpage with active JS input parsing for e.g.).


Programming should be taught to kids via procedural languages, on 8-bit systems with 64kb RAM along with enough assembler to give them an understanding of the CPU work required to execute basic high level language commands.


/rant

 

[Rockthesmurf]

The 'rough' way I try to develop games is to keep the high level code (what bits driving the game) accessing a simple interface, both for how the game talks to other parts of the game, and also how the game interacts with the engine. We develop nearly everything in c++ however this high level code doesn't really use much in the way of c++ features.


A level down from the top level game code, the 'game engine' if you will, does have some bits of more 'advanced' code, and by advanced, I really mean code that uses more 'fancy' c++ features. However, it typically only does this when that really feels like the best way to implement something.


Getting more towards the low level code, the nuts and bolts of the generic engine, and delving right down into the platform specific parts, code performance becomes more an a driving factor. There isn't any speed difference between C/C++ per se, but it is probably fair to say there are more ways built into the c++ libraries that allow you to make your code run slow with a single line of code (and that single line can look relatively innocent). But just running the profiler over code from time to time quickly highlights any silly mistakes, and is generally a very good idea on a reasonable sized code base.


With regards to the argument about applications being less optimized these days, well yes maybe there is some truth there, but there are lots of things that help explain this, for instance, programming is a huge amount more accessible now than it was when writing assembly in the 80's, so you are going to have a lower entry point, therefore potentially lower 'quality' programs. I strongly believe that developer time is the most important aspect of making computer games (possibly all software, but I only have strong expertise in the games field). I would always favour code readability, debugability and reliability over performance. Ultimately you have to ship the product, but the time saved by developing code in this way, saves more than enough man power to perform profiling towards the end of the project, and profiling is so much better for optimizing a game rather than guess work, or a desire not to use some language feature that has potential performance consequences. On top of this, requirements change, features get added and removed, code gets used in ways it initially wasn't intended for and so on, so being able to quickly adapt (and I hate the world, but..) be 'agile' generally seems to be a winner.


There is one argument that all software should be optimized, but there is another argument that software so just run reasonable on 'reasonable' hardware (reasonable hardware maybe hardware that x% of the intended potential user base own), why waste man hours (money/time) optimizing when the software is 'good enough' (sure reasons like pride factor in, but perhaps more on a hobby front, rather than a business perspective). As for executable size, I can't help but feel, within reason 'who cares', storage/bandwidth/etc. is all pretty cheap these days, there are specific places where a very small foot print is going to be useful (perhaps an embedded system running on a wrist watch) but other than these cases I am not sure it is that much of an issue. Compilers now really are rather good, and often the basic optimization flags used mean they generate a lot of code (loop unrolling or inlining functions for example) which means larger executables, but generally faster ones too.


Finally (just to complete my derailment of this thread), I spent a relatively substantial amount of time developing with Python (and relatively large application, multithreaded, running over several machines with a central server, processing large volumes of data (a TB per hour perhaps), interfacing with lots of libraries. I think the same program would have required a team of people to get the same job done in C/C++, and not performed any better (as in if it ran faster, I could see it saving 10 minutes in a 24 hour period or something).


There was a bunch of things in Python I didn't like, but one day I'd like to have a little play with using Python for working on a game, it was just one of those languages where I often said "Wouldn't it be cool if Python could do XXXX" and after a some google help, I often found "Oh, Python *does* do that, well that makes my life easier!". I don't see it ever being something I'd use professionally for developing games, at least not any time soon, but I certainly found code more 'fun' in Python, more time solving interesting issues.


Sorry for the long post that isn't overly about C...!


Steve

 

[klapse]

Steven,


thank you for an interesting and considerate post: i cannot disagree with any of your points.


I think the biggest problem I have when I have to modify someone else's C++ project is that there is so much abstraction. I need to read pages of class definitions, and remember what they do, before being able to understand what the "procedural part" is doing. With C on the other hand I can usually just read the code to see what is going on, keeping another window open to drill down to the occasional opaque function call.


Hacking someone else's C++ game (xu4) seems to require the brain to hold a LOT more state information. It makes my head hurt. I just want to store the last conversation fragment to a journal when user presses 'j'... (all I wanted was a pepsi)

 

[bzar]

klapse: I disagree. In simple cases of changing some small part of code that does not touch the "big picture" it may be easier with procedural code, but when you have a complex data model with lots of interconnects and overlapping concepts OOP tends to produce a simpler model to grasp. You can do OOP wrong, of course, but that does not discredit the entire paradigm.


Reading class interfaces is really no different from reading function module interfaces. Some C libraries (like enlightenment) are darn near OO code. The "methods" are just functions that take the "object" struct as the first parameter. Implementing what the actually nice parts (like polymorphism) in OOP accomplish in procedural languages gets you something like GObject, in which case you could just be using a language that supports OOP and get a clean syntax with less chances to mess up.


The more complex your application gets, the more you get out of OOP. In simple cases you may get away with less overhead using procedural paradigms, but with well designed OO code the intersection point of the overhead/LOC curves is IMO quite low.

 

[diligentcircle]

C++ is not necessarily harder to read than C at all. Just look at The Ur-Quan Masters (Star Control II), which is in C; that game is a mess. I still don't understand what's going on in it. The big problem is C and C++ both don't force or even encourage the use of namespaces to make it obvious what file a function call comes from, so in a project like UQM where there's dozens or maybe hundreds of source files and almost no comments to help you navigate, it's a tiring hunt-and-peck operation.


Perhaps it's because I was introduced to OOP very early (Game Maker uses it, though it calls classes "objects", so you have "instances of objects"), but I don't find classes (used properly) to make anything any more confusing. They can be confusing if the code is messy or lacking in comments, but anything can in that situation.

 

[Rockthesmurf]

It reminds me of the whole 'Guns don't kill, people do' only changed to 'Programming languages don't make bad code, people do'


Steve

 

[diligentcircle]

.

 

[sswam]

There is no reason today to avoid c++.


...


The point is that you can't learn c++ with some books, you can't learn c++ doing a computer degree and you can't learn c++ modifying code.


The only way to learn c++ for a normal human being is spending years programming in c++.

This does sound like a good reason to avoid C++.


I like OO, but I find C++ very far from ideal, so I'd rather use C.

 

[PokeParadox]

C++ Hard to read?


Bad C++ can be hard to read just as bad C code can be hard to read... seriously there is so much FUD spread.


I have to code in C and C# at work - my own projects use C++.


I prefer OO mentality of inehriting common code and functionality. C is mainly used here at work simply because we are dealing with an embbedded system and so they need to save codespace (I'm talking like 512kB RAM and 1MHz ARM here) it's nothing to do with C bwing any more readable, it's just that the compilers still have a little edge and get the binary a little bit smaller and ever bit counts.


Once you get used to each way of doing things good code will almost always be readable - I say almost since sometimes you need hacks for performance, but they will often have a comment nearby.