I think one of the most frustrating parts of game programming is that you have to test your game for hours and hours untill you eventually convince yourself that it' s good enough (very rarely) or that your game is definetely to change...

I think the time I spend playing the games I' m programming takes about 3 times the time (cool syntax!) I actually spend programming :sorry:

That's my favorite part of game programming! Testing it! If it's no good, that's when you know to trash it. If it is good, you can play it for a while looking for "bugs"

Just be careful you don't make your game too difficult! Shareware game developers have a habit of doing this because they get so good at playing their own game...

Yeah! Thats terrible!!

When doing Headache, I found myself making a change, and then starting the game to test my change only to find an hour had gone by while "testing" and a new high score had been posted. Good, because I enjoyed playing my game, bad because that was another hour less I had to polish it.

I play my game hours and hours to prove to myself they are good games.

WAHAHHAHAHAHAH.

Getting someone else to test your game is worth many hours of testing it yourself... You get to see if it runs on another computer. You get to see a totally different approach to the game, which might reveal all sorts of problems your play style wouldn't find. And the other player might try things you've been unconsciously avoiding because you know they're not implemented yet, or because they trigger bugs you've put off fixing

I've logged hundreds of hours playing my favorite mud with the MUDclient I'm developing. It's ridiculous. It's like, I know I can make it better, finish features, ready it for distribution... but I wanna play! Oh the horror.

I seem to be my best beta tester. As I'm sure Dr. Light will tell you, I am awesome at finding bugs and mistakes. I literally test all cases of my code and know what works and what doesn't. If ANYTHING doesn't work, I make sure a person doesn't do it. Although there is one small exception. I do minimal format handling and making sure my datafiles are correctly done. The reason cause, I don't expect people to mess around with the package content hidden behind the program.
The main reason I let others test it are for playability and make sure it runs on all systems. I've never come acrossed any problems with my games running at all. Of course, one of my games might break (but highly unlikely) since apple is doing a lot of updates to graphics and opengl in X.2.5

Indeed, let beta testers (other users) run your software.
You'll be amazed at what problems other people can find; as the programmer you're so into the program that you hardly ever do anything wrong or new, or adventurous. And in those spots are your hidden bugs!

Self-testing is great since you know where all the edge cases are likely to be, but I want to stress the importance of getting beta testers to test your app on other hardware. Particularly with OpenGL games, testing across a range of GPUs and display devices is CRITICAL.

I found many bugs between the ATI and nVidia hardware, some of which required a complete rework of my strategy (copy from framebuffer to rectangle texture isn't accelerated on ATI, for example...)

And I had to write a chunk of code to deal with display differences-- Apple sells displays with several different aspect ratios (5x4, 4x3, 3x2, 16x10, and "not quite" variants like 1600x1024) and you have to think about multiple display situations as well.

It's good to have an(or some) external beta tester(s) to test your game from another POV. I already have 5 H2O unofficial beta testers, including myself. I always find bugs myself and things that slow down the game (eg: environmental effects processing and heat transmission are two new things in H2O that really slow down the FPS. I'm taking out heat transmission, though, because it's way too slow. It simulates heat being transmitted from certain objects-such as fires-and influencing other objects)

Kind of like being a bartender that samples his drinks?

You should always play your own games (if you're not writing them for you to enjoy, who else will enjoy them ?) but you should always get feedback from trusted testers. My particular group of testers can make a single line print statement crash They're also good at knowing what sort of data is most important and what to note down.

As far as the game design side of testing is concerned, whoever is in charge of the game should always have the final say. Don't get into 'focus group' led design, just take it as input and use your skills as a designer to interpret it.

<quote>
Don't get into 'focus group' led design, just take it as input and use your skills as a designer to interpret it.
<\quote>

My skills? Oh, I didn' t know I had some! Thanks for the info!