Porter's World

What Not To Do

One of the biggest mistake game developers make, is having a game that isn’t fun, even though it is in fact playable. Sometimes this is caused by something rather simple, such as the game running sluggish. Although lag is a huge issue in many games, that’s not what I’m referring to, I simply mean the game plays too slow, the action doesn’t come fast enough. If ever there was something you don’t want to do in game design, this is it, because today’s players have even less patience than those of the past. In addition, you’ll find yourself working weeks, even months on a game, only to have absolutely no sponsor interest, and not an idea why such is the case. If you really think this doesn’t apply to you, read on. Notice I didn’t say “One of the biggest mistake new game developers make” in my opening statement, that’s because even world famous companies make these mistakes, everyone does time to time.

The best example of a game that has been entirely broken from sluggish gameplay is Final Fantasy VI on the PS1; it came with Final Fantasy V in the Final Fantasy Anthology collection. Final Fantasy VI, as many of you may know, is one of the most impressive RPG’s of it’s time, and by no means a bad game. Aside from being impressive, it also had a lot of random battles, which was fine on the SNES, but absolutely horrid due to load times between battles on the PS1. It never should have been ported in my opinion; the down time spent just waiting is so immense that it honestly ruined the game, I didn’t play more than an hour into it. I’ll remind you that when I first got it, I was psyched to play one of my classic favorites again, and have no problems with turned based battles and random encounters; the remake however, was unplayable to my standards. Although the above issue is mostly due to hardware, the company was aware of the issues before releasing the game, it was just poor judgment on their part to ever port the game.

Final Fantasy may be a console game, but that doesn’t mean that flash games can’t suffer the same consequences. In fact, flash games are more susceptible to failing because of this, due to the low patience of casual gamers. As some of you may know, I review a lot of games over at FlashGameLicense; you would be surprised how many games suffer from slow paced gameplay. Slow gameplay issues I’ve encountered vary. I’ve seen action games where the tank moved far too slow, sliding puzzle games where the block moved too slow, games where the player could outrun the bullets shot by his own weapon, and more. As cool as a game could be where you have some power that allows you to slow down time and run around bullets, that wasn’t what this game was going for, and that called for very obvious failure. You may think all of these are novice mistakes, but there are some very professional games out there with this issue, some that suffer horribly, others that could have benefited from an increase in speed in certain aspects.

All of this may sound like another novice mistake that you’re probably telling yourself you’ll never do, but I guarantee that somewhere in your future works, there will be a time when one of your games is severely hurt, or hindered by such an issue. The biggest reason for this, is that most developers generally don’t even notice these issues, this is usually due to a curtain of illusion that is thrown over a developer when they work on their own games; we as developers become oblivious to some of the most obvious faults with our games and will never notice them until told by an outside source. If you ever suspect that you’re game could in fact suffer from such an issue, take a look at Four Second Frenzy or Grid 16, they are fast paced from start to finish, exactly what the market loves. You may be thinking, well I have a puzzle game, or a defense game, same applies; even tower defense games,  such as Flash Element TD 2 offer the ability to speed up the game once you’ve got things under control. No matter what genre your game is, there are always moments when things can get dull, not always due to gameplay elements, but how slowly they’re presented. No matter how open minded about your game you think you are while testing, get others to test the game and give you feedback; you’re far better off being surprised with testers catching sluggish gameplay, rather than your players when the game goes live.

Part 1 || Part 2 || Part 3

What NOT to do

One of the most important things developers need to keep in mind when creating a game, is that you need to avoid annoying the player at all costs. Whether this be avoiding tedious level design, making sure your player doesn’t have to grind in your latest RPG, or simply making menu items contrast well so they don’t have to squint for navigation, you really need to make sure they don’t get bothered by anything. A very popular mistake many developers make is to combine mouse support with keyboard support, but make both mandatory on the same screen.

Out of all things a quality game can do wrong, this is probably the biggest. There’s nothing more annoying then dying in a keyboard controlled game, and having a menu pop up in which you must grab the mouse and press retry, rather than pressing enter or space to continue. There’s really no excuse for this, it’s simply poor design. It may sound minor, but small aggravations such as this really drive players away. Not only will players stop playing your game, they may even be so angered at the moment of quitting, that they’ll drop you a zero vote as they mutter how much the game sucks before leaving the page. This is clearly something you really don’t want happening with games under your name, it lowers it’s success and builds you a bad reputation.

We’ve now gone over what not to do, so how do we stay away from an issue as gargantuan as forcing the player to use both the mouse and keyboard in places where it’s entirely unnecessary? I have a few ideas, but I’ll share just one of them, don’t. When you design a game that uses either mouse or keyboard (but not both) for gameplay, stick to that throughout the whole game. If you play the game with the keyboard and you die, make it so you can retry with the keyboard, there’s no reason to have your user reach for the mouse only to press a button so they can start over. It’s highly recommended that you always add mouse support to increase sponsor click-throughs, but don’t force it, always permit the player to use what the gameplay uses, as well as the mouse.

It really isn’t hard to avoid, but far too many developers forget how annoying this can be to the player, which is a big mistake. I’ve seen some popular artists do this in some rather large titles, and although these games did great, I find it perplexing that such a great artist made such a novice mistake. That’s about all there is to know regarding this matter, pick a control scheme and stick to it, and always allow the mouse in addition to keep your sponsors happy.

Part 1 || Part 2 || Part 3