1. No pause feature. There's absolutely no reason whatsoever to exclude an option to freeze the action. A pause feature is extremely easy to write while one is coding a game, no matter what language is being used. The tiniest amount of memory would be required. The only things I can think of to attribute such an omittance to are laziness and a lack of ability to perceive the execution of a game as a whole.
Maybe in worlds where there really are invaders or huge-nosed bouncy guys, nobody has to stop to light a smoke, get a drink or go to the bathroom. Alien physiology is probably much different from ours. But Earthling players appreciate a way to stop the onscreen activity once in a while. The most inexcusable instance of this sin: no way to freeze long or multi-level games. Thundervision's Crystal Castles for the C-64 is a prime offender here, excellent as it otherwise is.
2. No way to restart. Hewson's stunning Uridium, MicroProse's superb Airborne Ranger and, I'm sorry to say, Thundervision's great Crystal Castles again are just three examples of otherwise terrific games that each provide no way to escape from a session in progress so that it can be immediately re-undertaken from the beginning. This is especially frustrating in games that rely on carefully conserved lives for tougher, later levels. If you make a bad move on, say, the first screen, and lose a life, the only way to restart a game guilty of this sin is to deliberately get your poor onscreen hero killed over and over until the game ends and you can start again. It takes too long, especially when you're angry and you want to get on with beating the thing. And such a senseless waste of fictitious lives!
3. Title screens that take longer to load than the actual games. Everyone likes nifty graphics, and any game player can appreciate the detail and sensory satisfaction of a well-done scene. But many programmers attempt to cover up mediocre games with pretty title screens. Doesn't work. And an aggravating side-effect is that a lot of opening screens are part of the actual booting programs for the main games, and those first, graphics-only files often take longer to load than the games themselves! So you're waiting twice as long for a hundred extra blocks to crawl through that serial cable. Good examples of this sin are First Star's so-so Superman and Broderbund's barely passable attempt at the 8-bit version of Star Wars. But some really good games suffer from this needless, annoying delay as well; Electronic Arts' Skyfox and Demon Stalkers: The Raid on Doomfane both contain boot programs that, while boasting neat title screens, take far too long to load themselves. When someone invents something that allows you to actually play these gorgeous title screens, FINE!
4. Music that you can't turn off. I don't know why some programmers opt to skip sound effects in favor of background music. It seems that the latter would require more effort, doesn't it? Maybe it's the challenge of getting a nice tune out of an 8-bit, especially one that's not a Commodore 64. But what about Amiga, Mac, PC, Nintendo or Genesis games that drive you nuts with tedious songs that can't be silenced with the press of a key or button? Creative challenge isn't an excuse here. Most of that stuff is digitized, not manually programmed.
Game music is bound to be repetitious. I have yet to play one of those melodic platform games and actually enjoy the music. An old, extreme example is every version of Sega's Congo Bongo coin-op. They put a three-note refrain of percussive sounds into the game, and that "song" plays over and over and over until you want to hold the disk over open flame. And experienced, thorough game designers like David Crane should know enough to include options to silence the repetitious harmonies in adventures like the otherwise remarkable Pitfall II (I know you can just turn the volume knob down, but then you miss out on the sound effects -- which I've always felt are important elements of the atmosphere and feel of any game).
5. Spectacles that attempt to distract from the actual game play. A bad game is a bad game, no matter how good it looks.
6. Too many bad guys/projectiles. I know this sounds like a complaint from anyone who's ever played a challenging game, but hear (read?) me out. It would seem that a lot of game creators felt, at the last minute, that their games were too easy. Whether due to self-importance or paranoia about putting a quickly won contest on the shelves, these people couldn't handle the weak-looking possibility of easy play when it came to their creations. The lack of consistent imagination, or simple programming laziness after a couple months' hard work on a big chunk of code, has often caused inventors to take the easy route and favor irrelevant difficulty over further creative effort. In short: More bad guys or quicker bullets were stuck into a lot of games, and this made them tedious instead of challenging.
Synapse's free, huge-feeling Shamus should have been a fantastic game; it involves exploration, brainwork and smoothly animated shoot-outs. But very, very, VERY huge clusters of droids fire such overwhelmingly accurate, fast, densely-packed swarms of bullets at you as soon as you enter a room, the fun is replaced with frustration. Succeeding has more to do with luck than skill, and anyone can sit around rolling a pair of dice. This is a video game we wanna play here, folks.
Taito's Sky Shark and Hewson's Uridium both contain enemy fire that appears too abruptly and moves too fast to be evaded (I've been playing the latter for a decade; believe me, skill has nothing to do with avoiding the more unpredictable, blindingly fast-entering bullets). The end of Electronic Arts' otherwise wonderful Dan Dare, and the lightning phase in Creative Software's excellent Joust clone Dragonhawk, are examples of the same thing. Some players love to be challenged until they're swearing, but nobody likes monotony.
7. Frequent disk switching. There's a lot of room on a disk -- even an old floppy. That's the whole point of disks, really. They were invented because the potential for a ton of space was evident, along with the speed (as compared with cassettes).
Regardless, the makers of a lot of old computer games (TSR's ho-hum Dungeons and Dragons series, Electronic Arts' Project: Firestart and that same group's mammoth Adventure Construction Set all come to mind) felt that their products would look more appealing and command bigger prices when spread across three or four disk sides, to be switched between constantly throughout a single session. Having to switch disks once while using a large program, or loading from a data disk, is obviously perfectly reasonable. But stopping the action itself so the player can flip over or exchange disks several times has no practical reason. All of the games I've mentioned could have easily fit onto one disk side apiece. This is all not to mention disk wear.
It's likely that the programmers were able to fit everything into single directories, but their sales-division coworkers felt that their buyers were gullible enough to think that they were getting more for their money ("Look, Marge! This one has THREE DISKS, and it's STILL only sixty bucks!").
8. Anything having to do with Karate (or what looks like Karate). The exception is DataSoft's Bruce Lee, which comprises numerous screens and focuses much more on exploration than repetitious martial-arts workouts. Also, it's got a green Sumo. Any game with a green Sumo is okay.
9. No chance for extra lives. This is obviously exclusive to those games in which it matters, but it's just plain mean to make a game with changing or increasingly difficult levels and not include the occasional chance at a backup protagonist (or a "Continue" option, at the least).
The people in financial control of arcade machines had businesses to run, and so the almighty dollar was of course the bottom line, no matter how much sweat and dreaming was put into the games by the actual designers. Attention, home video-game makers: The minimum-extra-lives thing (i.e. only at the first 10,000-point mark) was a constraint placed on coin-operated contests to draw continuous quarters. You do not have to worry about this aspect of your game. The person has ALREADY BOUGHT IT.
Satan's Hollow, Wizard of Wor, the Pac-Mans and countless other arcade-to-home adaptations are guilty of this. It's pointless and frustrating.
10. Copy protection. I know that this doesn't technically concern the games themselves, but it has to be mentioned. Whether encased in flexible plastic or hard, thin cases, disks are flimsy, sensitive pieces of frozen magnetism that are easily worn-out. The idea of someone spending twenty to sixty dollars on a single program and not being able to make himself a safety copy is ludicrous. It's stupid to deliberately include errors on a disk to prevent its duplication. It makes the drive head knock around a million times more than it normally would, and drives are expensive.
It's also needless; we've seen that pirates are going to copy a game if they want to, no matter what underhanded procedures are utilized. In fact, copy protection has actually always encouraged cracking, like a double-dog dare. Heavily protected software is a game in itself to pirates; they love it. So much for prevention. Creators who concentrate on producing solid, longetive products needn't worry about such easily defeated techniques in the first place. Their games will sell, no matter how many illegal copies are passed around. -- CF