Making Great Games

I’ve spent pretty much the entire day marking. I’m now giving grades to everything I see. I’ve been impressed with what our students have been getting up to this year, it always surprises me how many different takes you can get on the same problem. This year we were making Breakout. Many of the games that they made were good enough to go to market. Some have had really poor presentation but fantastic gameplay. Others went the other way, with lovely graphics but nothing worth playing. Some thoughts for game writers:

Get someone else to play. You might spend so much time admiring your scrolly graphics and particle effects that you forget that it has to be fun. Get other folks to play. You know you are on a winner when you find people playing who become better at your game than you are. And won’t let you back onto the machine to work on it.

Embrace serendipity. Some of the games had really strange collision behaviour that I’m sure wasn’t intentional. Their ball careered through bricks in really odd ways. However, this made the gameplay much more interesting than some of the better behaved ones. If this sounds like some folks got more marks for writing imperfect code I must add at this point we weren’t marking gameplay as such, this was strictly a programming exercise. But it did bring home to me that if something strange happens you should investigate what is going on and not always fix it. Sometimes these things make good features.

Give the player control. Some games had fantastic graphics, sound, etc etc but the ball always bounced the same way off the paddle. Boring. Other games had very poor graphics but amazing ball and paddle interaction that really let you aim at things on the screen. Much more fun. Consider what happens at your average game of table tennis in real life. Not much happening graphically, but a fantastic range of shots available from a simple ball and bat combination.

Put the graphics on after the gameplay is sorted. In real life game developers often use empty “placeholder” graphics when building the game. This forces them to think about gameplay first. No amount of graphics will compensate for poor gameplay. So get the gameplay right before anything else, and then use the graphics to add value afterwards.

Enjoy your games. I got the feeling from many of the games that the students had really enjoyed writing them. There were little touches and flourishes that you would only add if you were really having fun writing the code. This is great, and just how it should be.