The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
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.