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.

What NOT to do

Having your players not know how to play, complain, then rate your game down is something we all hate. One solution I see people doing far too often is forcing a tutorial upon the players, bad move. As much as you may hate reading comments about your players not knowing how to play, especially after they skip the tutorial, forcing one upon them still isn’t the way you want to go about it.

Let’s face it, 90% of players aren’t going to read our tutorials, especially if they’re not forced to. This creates a huge problem however, if our game is complicated even in the slightest, or has odd controls, or both, we’re about to run into some trouble. Having players not know how to play your game is just as bad as having a horrible game, it’s all the same in the eyes of the player. Throwing in a tutorial as the first level and making it mandatory works, but it also turns a lot of players away, that is, when they know.

Where a forced tutorial may turn players away, you can still throw a tutorial in your first level, or levels, and get away with it. An example of a game that had mini tutorials within levels that weren’t forced is Super Mario World. If you recall the game, there were help boxes (Blue and Red Boxes) all over the place when new concepts were introduced, it was up to you click on them or not, which often happened when a player died right after skipping one of those boxes. This strategy allows players to completely skip the instructions and have a good time, but have instructions right there in the gameplay before the area they died in if needed. This method really is a lot more powerful than it sounds, because it works. I almost never go into an instructions menu or tutorial menu in a flash game, I do however read signs or background instructions when they’re embedded in game, which is proof the method works. Raider Episode 1 for instance has signs throughout the game explaining things. I skipped these signs all together for my first attempt at the game, but when I died I started reading them to see what advice they had to offer, and I did this because I didn’t have to go out of my way to do so. Games such as Star Fox 64 told you to “Do a barrel roll!” mid action, the instructions popped up on screen and you followed them, but never did you go out of your way to learn how.

It really is a simple concept, but I can’t stress how much this can make or break a game. One of the most difficult decisions I find myself making in game design is how to get the instructions out to the player. Figuring out how you’ll ensure even the most novice of players can understand what to do and what is going on is incredibly important, and the above is generally the best solution. If you find yourself having problems getting your instructions across to players, pick up one of the above mentioned games and check them out, you’ll see how it’s done.

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.