next »

[cpets]

I'm looking for games with especially well-written source. Language and platform don't matter, but if you've seen something noteworthy, I'd like to take a look. Even a part of something is worthwhile; if the animation system is nice but the game logic is spaghetti, I'm still interested.

From the browsing I've done lately, Secret Maryo Chronicles (http://www.secretmaryo.org/) stands out for clean design and very readable source. What else is out there?

[Terry]

I don't really know, to be honest, but I remember thinking that the source code for Alex the Allegator 4 was pretty neat

certainly neater than my code, anyway

[increpare]

Passage is rather neat code-wise.

[Ivan]

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.

[Crackerblocks]

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.

The Doom source always impressed me with how vertical it is. Not many lines longer than 60 columns.

[ஒழுக்கின்மை (Paul Eres)]

Isn't that kind of normal? It's pretty rare to see lines longer than 60 characters any anyone's source code.

[Farbs]

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.

Really? I haven't looked at this for a few years, but I remember being surprised at how little the game code was kept apart from the engine. Also there weren't enough comments

[Ivan]

Really? I haven't looked at this for a few years, but I remember being surprised at how little the game code was kept apart from the engine. Also there weren't enough comments

Well, if you're talking about good programming standards, it's probably a pretty awful example of it. It's chaotic, undocumented and messy. But! It's beautiful in what it accomplishes with so little code (and straight C code at that). Also, you're incorrect about the game code being kept apart. It's actually in a separate DLL altogether. Pretty much every FPS engine made since quake has based itself on that model and for good reason.

[ஒழுக்கின்மை (Paul Eres)]

It's too bad there aren't more open source indie games, we could then read each other's code for fun.

I do have my game Alphasix's code here (coded in GML): http://gmc.yoyogames.com/index.php?showtopic=302475

But it's coded relatively badly to what I am capable of today because it's actually the first game I ever made in Game Maker, and I was just learning the language at the time. But it might be useful to anyone learning Game Maker.

With my current game I am trying something interesting: I was reading about a method of coding where only very small functions are used, so I intentionally try to keep the code in small bite-sized pieces. The vast majority of the functions are less than 20 lines long, and about half of them are less than 10 lines. In contrast, in Alphasix I had functions sometimes hundreds of lines long.

[cpets]

With my current game I am trying something interesting: I was reading about a method of coding where only very small functions are used, so I intentionally try to keep the code in small bite-sized pieces. The vast majority of the functions are less than 20 lines long, and about half of them are less than 10 lines. In contrast, in Alphasix I had functions sometimes hundreds of lines long.

Ah, this is exactly the kind of thing I try to do and am trying to find more examples of. Small functions help with testing and usually make it easier to decouple different systems. I have yet to see a game released along with a decent suite of unit tests. This is understandable, but I would love to see what happens when a full game gets written test-first. I'm working on doing this myself, but I'm still figuring out how to write meaningful tests for code which results in animation and complex entity behavior.

Thanks for the suggestions so far!

[bateleur]

I would love to see what happens when a full game gets written test-first.

Oh, I can easily nswer that one for you: it never gets finished.

This is the thing people always, always forget about:

* Code comments.
* Code documentation.
* Testing.
* Rewrites/refactoring.
* Design documents.

...and all that other good stuff.

Of course there are benefits, but there are also costs. If you adopt a dogmatic approach concerning what is good you will soak too many of these costs and kill your project.

I've yet to see any beautiful game source for a game I considered playable. But then that may be a good thing, since my idea of beautiful code is the TinyWiki source!

[isaac]

I've yet to see any beautiful game source for a game I considered playable. But then that may be a good thing, since my idea of beautiful code is the TinyWiki source!

Haha, beautiful like Guernica.

I've gotta agree. Writing beautiful code is one thing, but thinking too much about the form of things that other people rarely look at means taking valuable time away from working on things that actually have effect on what people see when they play the game.

[muku]

I've yet to see any beautiful game source for a game I considered playable. But then that may be a good thing, since my idea of beautiful code is the TinyWiki source!

Haha, beautiful like Guernica.

I've gotta agree. Writing beautiful code is one thing, but thinking too much about the form of things that other people rarely look at means taking valuable time away from working on things that actually have effect on what people see when they play the game.

I have to disagree here. Beautiful code to me means clean, concise, readable, self-documenting, expressive code, and all these things mean code that is easy to maintain and extend. So, keeping your code clean isn't just a matter of self-gratification, it helps you move forward with the project and makes adding unforeseen new features feasible.

Of course, for a small project you're just going to hack on a couple of days, that isn't really essential. But for everything that I expect to spend more than one week or two with, I always strive to maintain my standards of code beauty. It really pays off in the long run. Or would you want to maintain that TinyWiki code for months or years?

[Cymon]

I've yet to see any beautiful game source for a game I considered playable. But then that may be a good thing, since my idea of beautiful code is the TinyWiki source!

Haha, beautiful like Guernica.

I've gotta agree. Writing beautiful code is one thing, but thinking too much about the form of things that other people rarely look at means taking valuable time away from working on things that actually have effect on what people see when they play the game.

I have to disagree here. Beautiful code to me means clean, concise, readable, self-documenting, expressive code, and all these things mean code that is easy to maintain and extend.

Meh, all code is self-documenting. If you can't read it you're just not good enough.

Comments are for humans.

[muku]

Meh, all code is self-documenting. If you can't read it you're just not good enough.

Comments are for humans.

I was talking less about comments and more about stuff like using telling names. If all your functions and variables are well-named, you need very little in the way of comments to still have readable code.

[increpare]

If all your functions and variables are well-named, you need very little in the way of comments to still have readable code.

Not a big fan of literate programming then, eh?

[cpets]

I was talking less about comments and more about stuff like using telling names. If all your functions and variables are well-named, you need very little in the way of comments to still have readable code.

I just checked out the code to healthy wave, and it's definitely one of the cleanest games I've seen from a time-limited competition. Nice job!

As for the crowd singing that tests, comments, and descriptive variables are for sissies, I'm not going to try and convert you in this thread. But you still must have some sense of code aesthetics, and some experience working with "good code," however you define it. Which games have you enjoyed reading?

[Robotacon]

I'm with muku, I only use comments when I write some weird optimized function that is counter intuitive. The rest of the code should be self explaining. I hate coders that put a comment on every other row stating the obvious.

I tend to never do more that one thing on one row but I have two exceptions to that rule. I use the ? operator even though I think the if-else statement is much less error prone and I always write getters and setters on a single row simply because they take up so much space if I don't and getters and setters shouldn't have any side effects so anyone seeing one shouldn't be confused about what it does.

[muku]

If all your functions and variables are well-named, you need very little in the way of comments to still have readable code.

Not a big fan of literate programming then, eh?

I think it's an interesting concept, but to be honest I've never seriously tried it. It seems like one of those things I wouldn't have the stamina to go through with for anything larger than a toy project.

Although I do believe that by keeping your functions no longer than a couple of lines and naming them descriptively, you can achieve a similar (if less pronounced) effect with much less effort.

I just checked out the code to healthy wave, and it's definitely one of the cleanest games I've seen from a time-limited competition. Nice job!

Huh, thanks
I think that's the thing actually: once you get in the habit of writing clean code, it really isn't much slower than going the hackish route. It might even be faster (it certainly is for larger projects).

Then again, this whole issue is sort of a personal obsession of mine, and I'll admit that I do get a certain amount of self-gratification out of an elegant design and clean code, so it isn't all rationally grounded I must also be in the minority in that I actually enjoy refactoring code. Many people I've talked to hate touching code once they've written it. I'm just weird like that.

[Greg]

@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:

Interview with Matt Toschlog and Mike Kulas regarding the release of the
Descent source code:

Q: Why are you releasing the source code?

Mike: The main reason is we figured a lot of people aspiring to work in the
game industry would like to see production "quality" code.  There are two
reasons for this.  One, you can learn a lot by looking at working code.
Two, people will see that you can write a decent game without writing
beautiful code.

Matt: That's a good thing?

Mike: Not really, except that it might make people think writing production
quality code isn't that hard.

Matt: That's a good thing?

Mike: Well, not really, unless they learn that they have to focus on
designing a brilliant game, rather than writing brilliant code.

Matt: Ah, that's a good thing.

Mike: Yeah, I don't think I understood that until we started working on
Descent.  At first all I cared about was writing technically good code.

Matt: Then we ran out of money and all we cared about was finishing our game.

Mike: Right.  Our code got ugly, but our game got done.

Matt: Writing code is easy.  Finishing is hard.

Q: Is there any code you're particularly proud of?

Matt: No.

Mike: No.