Fatal Flaws in Flash Game Design and Development

Yesterday Jim Greer (CEO of Kongregate) and I gave a talk at Casual Connect in Seattle titled Fatal Flaws in Flash Games. I also talked a bit about common flaws in entry-level Flash development philosophies and practices.

There are already a few summaries of the talk, and I thought I’d take a moment to post my raw preparation notes, which include some stuff that I didn’t get a chance to discuss.

#1 You're Making a Game, Not a Homework Assignment

We live in a culture of being assigned a task, producing something that is asked of us, and being evaluated based on the level of quality of that product. We've spent at least a decade writing book reports, solving math equations, and analyzing the reasons behind the American Civil War.

Once we enter the real world, in most jobs, this mindset transfers over pretty well. Your boss gives you an assignment, you get it done, and the timeliness and level of quality is evaluated.

This doesn't cut it with making games. Your player only cares about how fun your game is, not the amount of work you put into it. They don't even necessarily care about its objective level of quality. The distinction is important. Rarely does a 7th grade teacher mark down a book report on account of it being too boring, but that’s the #1 potential failure that you now face. When making games, you must toss aside your lifelong training regarding what's important in a product.

There's a scenario I see time and time again – a game that's well-made, but simply not fun to play. Sponsors rarely offer significant money for them, and players rarely react well to them. Developers are often shocked, and respond to uninterested sponsors with, "But I spent X amount of time on this."

But we don't care how long you spent on it. It wasn't a homework assignment. We only care about whether your game is enjoyable to play. Whether it took one day or six months is irrelevant. Just as a great game isn’t penalized for being developed quickly, a poor one is not credited for being developed slowly.

#2 Ask the People Who Matter

If your sister told you one day that she had been studying Flash and she managed to put something together, odds are pretty good that you'd be legitimately impressed by her work regardless of how the game actually turned out.

We all look upon work more favorably if it's done by someone we know, care about, or can simply relate to. These are not the people you should be relying on for feedback for your game. No matter how bad a game is, it almost always has its fan group of friends and family beta testers. These people build up a developer's confidence about his game without ever conveying honest criticisms, intentionally or not.

Find people you don't know. Talk to other developers, or even just random people on a forum. Get them to play your game, and ask a million questions about their experience. Get a feel for their patience level. Your mom will carefully read the instructions to understand the counterintuitive controls of your game, but the average player will not.

#3 "Controls, Controls, You Must Learn Controls" - Yoda (paraphrased)

No one reads instructions, ever. In fact, if someone somehow IS reading the instructions of your game, then it is likely because they are already confused and frustrated. Developers love to place the blame on players who don't read instructions – but it is the game that is being made for the sake of the player's enjoyment. The player does not "owe" the game anything.

Intuitive controls are critical. If movement is done with WASD, and the arrow keys are not being used for anything, why can the arrow keys not also be used for movement? Tinker with your interface to make something quick to pick up; merely providing instructions for a confusing control scheme is NOT an excuse.

If the player skips an optional tutorial and ignores the instructions, have a quick message flash on the screen with the buttons anyway. Have signs in the background that explain the game's controls. If the player picks up a new weapon, have a dialogue box pop up with a BRIEF explanation of how to use that weapon.

The longer and more out of the way something is, the less likely the player is to read it. When long-winded instructions for counterintuitive controls are tucked away on a menu screen, you're virtually guaranteeing that the player has a negative first impression with your game.

#4 Calling Your Game Art/Hardcore Is Not an Excuse

There is absolutely no reason for beautiful and artistic games to be mutually exclusive with fun and intuitive ones. It's a common defense that developers have. If a player is confused by their game, they’ll say, "Well, it's my artistic vision – I don't expect everyone to get it." Really? Since when is giving the player easy access to the control scheme compromising an artistic vision? What exactly about having user-friendly progress checkpoints and save files is less artistic than forcing the player to enter a password or restart the entire game upon death?

When you create a great game, you earn the right to call it art. When you create a poor game, calling it art does not earn you the right to excuse giving it another coat of polish and implementing common beta tester requests.

Additionally, making your game hard just for the sake of being hard does not automatically make you and your players hardcore (with some exceptions, including “I Wanna Be the Guy”). Anyone can take their game and give the player fewer lives, or less health, or less damage, etc., and make it more difficult. There is nothing hard about making a game hard – the difficulty comes from making your game actually fun.

There is a true art form to creating a game with a proper difficulty curve – a game that starts out simple, gets progressively more difficult, and makes the player feel challenged and rewarded without feeling frustrated (there is indeed a very significant distinction between challenge and frustration, and it all has to do with the player’s perception of fairness within the game’s rules, how much control he has over the situation, and how harshly he is punished for failing). Striking this balance is incredibly difficult, and no, "I'm hardcore" is not a free ticket out of having to do it.

There is a way to transcend this principle, however. If you make a game that’s incredibly good with extremely smooth controls and a very high SKILL component, then you can likely get away with making it stupidly difficult, but only if you’re quite sure that the player will feel rewarded from this difficulty. “N: The Way of the Ninja” is a game that pulls this off extremely well, but if the controls were any less tight, the experience would be miserable. Conversely, if a game has a very low skill component to progression (such as a traditional single-player RPG in which your character’s power is based more on experience points than on player input), then high difficulty is more likely to frustrate than to intrigue.

#5 Start from the Bottom Up, Not the Top Down

Why is anyone playing your game? It's not because they're broke and your game is free or cheap – almost everyone on Kongregate has console titles. They have Halo sitting a few feet away. So why are they playing your game instead?

The answer: because it's fun. And why is it fun? That's a question that needs to be answered BEFORE development has begun. Start with the fun, then add the graphics and music later – not the other way around.

Begin with your central idea – the hook to your game. Play around with it without any graphics. See if it's fun. If it's not, tweak it. Figure out what works and what doesn't, and build on that core mechanic. Don't start with the character artwork, the music, the level tilesets, etc. You can spend months doing this for a game that is ultimately simply not enjoyable to play. When that happens, you'll likely end up with is a game that would get an A+ as a homework assignment, but not such a stellar review from someone looking for actual entertainment.

#6 Focus on Your Strengths, Not Your Weaknesses – Don’t Try to Do Everything

Final Fantasy X-2 director Motomu Toriyama once said that FFX-2 was packed with minigames because "if you bought FFX-2, you wouldn't need any other game." It’s a completely absurd idea.

We all loved the snowboarding minigame in Final Fantasy 7, but I don't think a single person on the planet loaded it up and immediately thought, "Sweet, now I don't need to buy SSX!"

But Toriyama's mindset is one that's incredibly common among game developers, even if they don't explicitly realize how they're thinking. Game developers want to be good at everything. They want to be the best at every genre. If there were a nuclear holocaust tomorrow, they'd want to be able to supply the cave-dwelling survivors with every type of game they'd ever want to play. They want to have true, diehard fans – people who will play their games and ONLY their games.

It's a flawed, inefficient mentality, and one that should be broken as soon as possible (sorry Dirge of Cerberus). If you're great at making shooter games but terrible at making platformers, then don't make platformers. Let other people make them – no one expects you to dip your talents into every imaginable genre.

Knowing your true strengths and weaknesses is one of the most important things you can learn about yourself. Figure out what you're good at, then do it. Don't waste time trying to be the Renaissance Man of game developers. Sure, if you keep releasing the same game over and over again, people will get tired of it, but that doesn't mean that your games can't share a common theme that highlights what you do best.

Just because you spend all your time making games of a similar genre doesn't mean that players have to spend all their time playing them. Don't develop tunnel vision with regard to the diversity of experiences that your player will be having across the entire industry.

Keep in mind, also, that even if you do create a successful game, this does not mean that you can do no wrong. At least 90% of your players will have absolutely no idea what your past games were. If you make a really successful shooter game, this does not mean that your next RPG project will also be automatically successful. It’s extremely common for developers to build something they’re good at, have a big success, get cocky, then do something completely different, only to be completely shocked that they’re still very much capable of failure.

#7 The Player Does What's Efficient, Not What's Fun

Your goal is to make a game that is fun. But somewhat contrary to intuition, having fun is NOT the goal of the player. The goal of the player is to conquer whatever the game throws at him. Fun is the expected byproduct of this endeavor. The player wants to have fun without having to seek it out.

The player will do what is most efficient and effective, short of doing what he perceives as cheating. Consider a side-scrolling brawler in which the player has two attacks. The first attack causes the character to leap into the air, dive down onto an enemy, grab him, spin him around, then toss him into a group of other enemies, knocking them down. A developer could put quite a lot of time into tweaking this maneuver, and have lots of fun executing it during playtesting. The second attack is a simple punch.

But here's the problem – the simple punch deals five times the damage. Why would the player bother using the former attack when the punch is so effective? "Because it's so much fun!" the developer would interject. Then why are you not forcing the player to use it?

We've all played a game like this. We're having lots of fun using a bunch of really cool attacks, abilities, maneuvers, etc. Then we find the infinite ammo rocket launcher that kills everything onscreen instantly, and the game is suddenly less fun. But why? We could always choose to put the weapon away. The problem is that manually handicapping ourselves within the game's rule structure is not fun either.

When testing your game, play it to win. Don't play it to have fun. It's your job to make sure that the two overlap.

There are exceptions to this, of course, where players will just mess around with a game to have fun rather than to progress. But the players who reach this point of exception are the people who are already hooked into your game. It's the new players who need to be won over. Force them to have fun, whether they like it or not!

#8 Show that You're Human

Humor and personality go a long, long way with Flash games. Give the player something they can relate to, make them laugh, and make sure they know that you're an indie developer. Games like Button Hunt, Achievement Unlocked and Upgrade Complete were big hits on Kongregate purely for their humor element – the latter two games targeting their humor specifically at the over-achievement-ing of every game recently made, and the necessity for all Flash games to be filled with copious upgrade screens.

And yes, your game CAN look "too good." You cannot impress your audience. They're playing Halo. They know what amazing graphics look like, and you can't touch that in Flash. No matter how long you spend on your 3D models, you will probably never create something that makes the player truly say "wow." In fact, more likely than not, you will simply alienate your players with graphics that are between indie and truly professional.

What you CAN do is create something aesthetically pleasing and still relatable. "Sonny" is an RPG that strikes the perfect aesthetic balance of looking great, but still believable as something that was created by a single college student.

"World of Goo" is probably the greatest example of a success in this area. The game looks great, but it still retains a down-to-earth cartoony style. Plus, the game is completely overflowing with humor and personality – and it was all built on a core mechanic that’s fun just on its own, even without these things.

#9 The Final 10% Is Most Important

When your game is technically done, there's a tremendous urge to release it immediately. It's like finishing a book report and not wanting to proofread it. It's done! I can turn it in! I can be finished! The light is here!

But resist it. The final 10% of polish is by far the most efficient use of your time, even if it's the most annoying and feels the least productive (since you're changing things rather than building them).

But its importance cannot be understated. Maybe the boss on level 1 has too much health, and 40% of the people who play your game give up at that point. Five minutes of tweaking a health number could have been the best five minutes of time you ever spent in your entire life.

Don’t forget to add the little things! Having a mute button (separate for sound and music) and an intuitive save system will go a long way in making players like your game (or, more accurately, in preventing them from hating it).

Play your game. Play it again and again and again. Get others to play it. Get their feedback. Tweak, tweak, tweak. Continue polishing and ironing out bugs. Don't be afraid to cut something out entirely if it's not beneficial to the game – yeah, I know, you already put the work into it, but the player doesn't care how much work you've put into it. If something is there that's not fun, it simply shouldn't be there. There is no advantage to your game being big and long purely for the sake of being big and long. Again, it's not a homework assignment.