QB CULT MAGAZINE
Vol. 2 Iss. 2 - May 2001

30 tips to make your game more fun to play

By Terry Cavanagh <terrycavanagh@eircom.net>

You don't need to be a great programmer to make cool games. Likewise, you could be a fantastic programmer and make terrible games - I know of people who fall into both cagogories. This tutorial aims to remind you of the things that accually make games fun to play. It's not language specific, or even genre specific. Some of the tips may seem quite obvious, but we all sometimes need to be reminded of these things.

If you don't think your game is fun to play, most people will agree with you. If you're stuck with a game that's boring, you can spice it up by adding new features such as bonuses, time limits, puzzles, or something else totally original.

Before you write your first line of code, know exactly where you're going with the game. You don't need to know everything, just enough of a vague idea to give you a constant set of achievable goals. Always plan ahead, as it keeps you from losing interest in your project.

Puzzle games should nearly always have a time limit. Despite constant protests that you may hear about time constraints, They do the game a great service by introducing an easy form of varible difficulty and add substantially to the overall challenge of your game. That said, some puzzle games simply will not work with a time limit.

Don't ever try to write a game that you don't think you'd play. You're only going to end up getting hurt.

When making an RPG, there's a hundred and one things you can do to make your game more fun. Introducting something new to the stale (F)ight, (M)agic, (I)tem and (R)un battle options is a good start, but nowhere near a good enough finish. Make every character have something different to offer - Magic, strength, etc. If you've got the time, program a few suitable mini games into the code. Add plenty of sub quests - a good RPG can rely entirily on this - take the Exile series as an example. Take time with the game's conversations. Make sure the story offers something more original than 'Every 500 years the demon of the underworld wrecks havoc on earth.' Heh - I've fallen into this trap myself. It's more than possible to recover a story from this - take a look at Final Fantasy V. But it would be better to eliminate this altogether. Finally, ensure that all your characters have different personalities. It's the key to writing enjoyable dialog. If in doubt, FrozenEmu has a tutorial at the Game Devolpers Refuge on RPG design - You've gotta read this - It's funny as hell! From memory, I think you can get to GDR at gdr.swoo.net/index.pl.

When making an action game, if you do nothing else, make sure your weapon is upgradable. Nothing makes a shoot-em-up more fun that collecting a liquidiser add-on for your gun and using it. Make sure there's plenty of blood too. Plenty of it. Humans are bloodthirsty creatures - we jump at the chance to kill as many people in as violent a manner as possible when we don't have to pay the price for it - it's human nature :)

Always try to ensure that your game has a few features that you havn't seen anywhere else. Keep it original.

Ask somebody you hate (I use my little brother) to tell you what he thinks about the game. Practice tells me that it's the only way to ensure a decent critical commentry - most friends will only praise you unless there's something really baddly out of place. Or at least mine do. I once asked a friend of mine on the internet to play one of my games - he said it was brilliant, but about a month later I found out that he never even downloaded it. If somebody asks you to playtest thier game, give them your honest opinion.

Try and have some idea of the size of the project you're taking on. I used to program 'Mini-Games' all the times - It seems I work better that way, because the only games I've ever completed are all mini games. But everyone is different, and If you think you can take on a major project, go right ahead. But if you start making excuses as to why you arn't working on the project, maybe it's best to drop it and try something smaller.

Don't start with the title screen. You won't believe the amount of gameless title screens I have wasting space on my hard disk. Or at least did have, before the crash.

Make the game reasonably easy - easy enough to get relitivly far in your first attempts. Then add difficultly levels, the hardest being finishable but challenging. I only know three people that have finished the 'hard' game setting in one of my old games, Black Hole.

Go above and beyond. If your game requires scrolling, don't stop at tile by tile - research pixel by pixel if you can't already do so. If you're making a space game, learn how to make a proper 3D starfield. By doing this, you'll find that in a few games time you'll have built up an amazing amount of knowalge.

If it's one of your first games, you should probably release the game as open source freeware. If you're lucky, you might find somebody generous< enough to offer you some coding tips.

Learn ASM. Knowing ASM and using your own routines is the most valuable programming step you might ever take. ASM will come in useful, regardless of which higher level language you choose to use. If you know ASM, you'll learn so much more about the way your computer works and be the better for it - you won't have to abondon projects half way because you're having problems with DirectQB, Allegro or Windows :)

Don't form the do all end all programming group to work on the biggest project ever as your first big game. You should be well fit to make the entire game yourself. If you are, then you're ready to really use co workers properly. In other words, don't hire somebody to make a pixel by pixel coding engine for you if you can't do it yourself.

When you've finished a game, don't rush it out onto the internet. First take another week to add some graphics features. Take as long as you've got to program it.

Don't release the game until you're happy with it.

Graphics are no way as important as you might think. Never ever sacrifice a gameplay feature for a graphical feature.

If you're learning to code, listen to everything that more practised coders tell you. Likewise, if you're a seasoned coder, try and help out beginners.

Make your game user friendly. It's quite unprofessional to ask the gamer to search the keyboard for the (f)ight, (m)agic and (i)tem commands. Instead, make a miniture menu in the corner when you simply press up and down and select with either space or enter. It makes a lot more sense to the average gamer, who will likely not be a very good typer. Simple console controls like this can be implemented all over the game.

Always tell the player what you're doing - for example, if you're loading graphics, print that on the screen so that people with slow computers won't think it's crashed.

Spelling mistakes are normal enough - its impossible to get away without any. However, you should check all your game text to ensure that there arn't many.

When you're finished, have someone else play the game. Ask them what they like and don't like about the game. Ask them if there's anything that could be done to make the game more fun to play - and take any suggestions you get seriously.

Your game should be bug free. When finished, make sure you play the game through, doing different things each time to find possible bugs. Fix everything, regardless of how long it's going to take.

If you have the time, add multiplayer options. If the game allows, see if it's possible to have even more than two players. I once made a game that supported up the eight players.

Spend more time on things like the control system and the game's difficulty settings than on bells and whistles like unnessicary graphics and sound. But of course, Graphics and sound are important in a game as well.

Try and make the game have a progressive learning curve, so that you can get the basics of the game quickly and the game quickly becomes difficult enough to pose a real challange.

If possible, make a tutorial level, where you are commentated on each indivual game element, told to perform it, and proceed to the next when you've done that.

If your game gets reviewed and you don't get 100%, don't fret. Always aim to improve something with each game. Eventually people will run out of things to critise. That should be your aim. Perfection.

Bottom line, your game must be fun to play. If you've made modifications based on the tips above and still find that your game is too boring, perhaps you should just upload it as freeware and move on to something else.

I hope this information is of use to you. If it is, let me know. It's all obvious stuff, but even the best of us can forget alot of this stuff. If in doubt, think back to the days when you were playing games rather than programming them. Until next time,

- Terry Cavanagh