next »

[Greg]

I'm not really advocating dirty or clean code, or id for that matter, though I did start out reading Doom too.  and it is relatively small, fairly readable, and you get to see a classic design of how a main() game loop is structured, so that's good.  I'm still learning. If I ever finish a game...I might actually know something.

Although I would recommend the Uplink source code.  It's pretty well done, but yet it still looks like something that a college kid started writing in his dorm room while he was taking his sophomore AP C++ class.

[muku]

Although I would recommend the Uplink source code.  It's pretty well done, but yet it still looks like something that a college kid started writing in his dorm room while he was taking his sophomore AP C++ class.

I haven't looked at it personally, but on the Introversion forum it seems to be notorious for its code quality and difficulty of modifying it.

[Greg]

Yeah, Uplink probably isn't ideal, though I learned a few things from it. It was their first game, and while even Delay is slightly embarrassed of it, it's definitely my favorite.

but yeah, Uplink's OpenGL draw functions section is downright ugly. I found it actually kind of inspiring that my OpenGL code now is a lot cleaner than Uplink's.

I've gotten a lot of code from the libSDL.org site.  some better than other, some great though.  If you look here: http://www.libsdl.org/projects/ there are links to code for Doom, Quake, Hexen, and others that Sam Lantinga ported to SDL. They compile right out of the box on any Linux computer (with SDL & gcc installed).  There's also a games page where users submit projects. 

It really depends on what you're trying to do.  My advice is just get everything you can find.  Some projects will make more sense to you than others, use those.  But reading is definitely key here.  Read everything.

[Crackerblocks]

@Crackerblocks: Check the Doom3 SDK.  id's style has changed quite a bit since Quake3, which was 1998, to put it in perspective.  Now it's tight C++, further abstracted, and typical line length is ~120 characters.

I think the README from the Descent 1 sourcecode sums up the relationship between clean code and shipping a game pretty well:

That quote is hilarious. I don't know if it's the same guys, but when the Freespace 2 source got released, it was a pretty eye opening moment. That such a good game could have such messy code.

I was more impressed with the Doom code way back when it was released. I think at that time I was learning C++ how to be all abstract and write hundreds of lines of class architecture without actually getting any work done. Doom is pretty much all work. And Carmack used goto a lot, that got my head in a tizzy.

[Hayden Scott-Baron]

The code in my game is a mess, and it's something I really want to make efforts to tidy up for my next project (it's too late for this one, haha).  Is there any sources for 'advice' on code style for games in general?

[Hideous]

do this

Code:

int function(int awesome, float rockin)
{
    callthishit();  //fuck yes
    rockin = lol + awesome; 
    return rockin;
}

format it like that and call the functions understandable names and I'm happy.

[diwil]

do this

Code:

int function(int awesome, float rockin)
{
    callthishit();  //fuck yes
    rockin = lol + awesome; 
    return rockin;
}

format it like that and call the functions understandable names and I'm happy.

I do this:

Code:

// @a	first value
//@b	second value
template <typename T>
T add(T a, T b) {
	// lets do stuff
	T temp = a + b;
	return (temp);
}

Fairly standard, although I seem to be the only one who likes his starting squiggly brackets at the end of the statement. :D

[Hideous]

No, I used to do that too, until I tried that and found it was way cleaner.

[diwil]

Might be cleaner, but poppycocks, I will never submit to the masses!

[increpare]

The code in my game is a mess, and it's something I really want to make efforts to tidy up for my next project (it's too late for this one, haha).  Is there any sources for 'advice' on code style for games in general?

It's quite programming-language dependent I think.

[TheMeatyBall]

I think Half-Life(1) has pretty well written code.

[Cymon]

do this

Code:

int function(int awesome, float rockin)
{
    callthishit();  //fuck yes
    rockin = lol + awesome; 
    return rockin;
}

format it like that and call the functions understandable names and I'm happy.

I do this:

Code:

// @a	first value
//@b	second value
template <typename T>
T add(T a, T b) {
	// lets do stuff
	T temp = a + b;
	return (temp);
}

Fairly standard, although I seem to be the only one who likes his starting squiggly brackets at the end of the statement. :D

All my code does that. It saves on so many lines, and I just can't stand formatting that takes up so many lines that when you print a 3 command function that between commenting and gratuitous spaces takes a page to print. No sir. I go the other extreme. Okay, maybe not extreme, but I do it all the time.

Latest example: buttons.c. For more examples see the rest of Cymon's Games.

[diwil]

Latest example: buttons.c. For more examples see the rest of Cymon's Games.

We code in a very, very similar fashion. :D

I use the tab for intending similar structures, for clarity. But I hate when there's too much space vertically.

[muku]

Latest example: buttons.c.

I find that very, very dense and hard to read. I personally don't like to write an entire do/while loop in one line, or to keep the if condition and the following statement on one line. Sure, you save some vertical space, but in my opinion at the expense of readability. I mean, vertical space is practically free; it's not like we print out our code on paper all the time. And as long as you keep your functions within one page of code (actually I prefer keeping them even shorter), you don't have to scroll to read any one function in its entirety anyway.

[increpare]

I personally would have preferred more comments in that file, and to have it spaced out.  (either would be good).  It would save me having to digest the whole file from top to bottom.

[Ryan]

I used to prefer less lines over more, a typical example being:

Code:

int do_something(int a, int b){
  for (int i = 0; i < 10; i++)
    a += b;
  a /= b;
  return a*7;}}

My goal was to get as much code on the screen as possible. Since I've started having to do maintenance more and more on my code bases, I now do things like this:

Code:

int DoSomething(int a, int b)
{
    for (int i = 0; i < 10; i++)
    {
        a += b;
    }

    a /= b;
    a *= 7;

    return a;
}

To me, the extra structure (the for-loop brackets) and vertical line space is worth a bit extra scrolling. I can quickly scan and see what a function does far better when it's laid out like the latter. Also, If I have to add something within the for loop, the structure is already there.

As for the question, sadly I have never seen a game with beautiful source code. A finished game is a finished game, and most of the time as long as it works programmers trudge on.

[David Pittman]

Sweet, are we talking about code style instead of architecture now?

In the last few years, I've adopted the habit of using as much whitespace as humanly possible. Besides using curly braces everywhere and always putting them on their own line, I also add spaces inside nearly all parenthetical elements.

Code:

void Foo( int A, int B, int C )
{
    A = ( B + C );
}

This seems to be polarizing even for programmers who agree on most other style issues. I also treat tokens like if, for, while, etc. as if they were function calls, e.g.:

Code:

if( ... )

As opposed to:

Code:

if (...)

But I'm also a style chameleon. If I'm working in a code base that's not entirely my own, I tend to adopt the patterns in use in that code. I'd rather keep things consistent.

[Golds]

Most of Carmack's code is pretty amazing. I've learned quite a bit of what I know now hacking around in quake2's source code.

I agree.  I was super impressed with some of the tricks present in the Wolfenstein 3d codebase in my unfinished attempt to bring a polished GL port to Mac OS X a couple years back.

[Cymon]

Latest example: buttons.c.

I find that very, very dense and hard to read. I personally don't like to write an entire do/while loop in one line, or to keep the if condition and the following statement on one line. Sure, you save some vertical space, but in my opinion at the expense of readability. I mean, vertical space is practically free; it's not like we print out our code on paper all the time. And as long as you keep your functions within one page of code (actually I prefer keeping them even shorter), you don't have to scroll to read any one function in its entirety anyway.

It is very dense, but I'm from the old school where BASIC was even denser!

But you want to know the beauty thing? Load up Code::Blocks and you get a style formatter. At the push of a button any code can be as dense or as spread out as you like. Works great for de-obfuscating code.

[Hayden Scott-Baron]

dphrygian, very neat and readable code! I wish I could say the same for your username!

One interesting thing about working with Unity is that you tend to adopt some of the style habits of Unity itself. For example, they encourage you to write your variables like this:

var numberOfLives = 5;

This is because it will extract this variable and make it visible in the GUI as

"Number Of Lives"

So you tend to use their rules of capitalisation. Same goes for capitals on Function() stuff.