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.

Static on the Radio

I was doing a C# revision lecture yesterday and I was talking about static class members. I mentioned the fact that every year some students write “Static means that the value of the variable cannot be changed” in the exam, which produces an anguished cry from me and zero marks. I was trying to think of a better way to explain what static really means. And I thought about the radio. If you turn on your am radio and tune it away from a station you will hear static. And that static hiss is always there. It has been there since before radios were invented and it will be there until the universe cools right down. Static class members are a bit like this. They are always there. They exist whether you make an instance of the class or not. Static in this situation doesn’t mean “can’t change” it means “always there”.

We use them in programs when we want a data member that is part of a class but not part of each instance. For example, in a bank we might have loads of accounts, but the minimum amount you can withdraw, the maximum size of the balance we can have and the minimum age for an account holder are all relevant to accounts, but not stored in each account instance. Static works well in this situation.