Bob Churchill, Game Designer: For Crash: Mind over Mutant we used the Agile process and divided our designers up into specialties such as Locomotion, Combat, Level design, Story, Prop Interaction, AI etc. We also assigned designers to mission scripting which includes object and enemy placement and level design support. Even though each member of the design team had a specific part of the game to look after there was plenty of crossover, not just from a feedback perspective but also from the actual building of the game.

Within Scrum, the designers focus on these specialties and attend morning Scrums with all the relevant coders and artists for that aspect of the game. The people in that scrum break down their objectives into smaller tasks and work for two weeks on that feature. At the end of every Sprint we have a full review where the entire team gets together to view and provide feedback on the work from all the Scrums combined. The beauty of this system is that we can adapt very quickly to changes in the design or any issues that pop up.

What was the inspiration for the cutscenes and their humor?

Yousuf Mapara, Art Director: When we made Crash of the Titans, we wanted an intro that was very playful and fun to watch, and that told the backstory quickly without a lot of spoken explanation. To that end, we used the shadow puppet cinematic. To work with 2D was such a refreshing change from a typical NIS with a lot of speaking, as it had different rules, felt more stylized and to the point.  Above all it was so fun to see Crash drawn in a different style. This led to Mind Over Mutant, where we thought it would be so much fun to explore Crash in other styles that we decided to represent each cinematic with a different style from television.

Although it was a lot of work to redesign the characters and sets in 13 styles, it was exciting seeing it all come together. We wanted to leave the audience with a feeling of excitement about unlocking the next movie, anticipating “what will the next movie look like”.   Ironically at the end of satisfying our curiosity, it left us more curious about other avenues, like what would Crash be like if we used clay-mation, or real puppets.

How did the level-based gameplay from former Crash games evolve into the mission-based gameplay in Mind Over Mutant?

Kasan Wright, Game Designer: It was a system developed from the desire to do more with less. We had a vision for a game where you could recirculate through levels with a different jacked monster each time so that gameplay would change depending on the powers and abilities of the mutant you had under your control. So we designed the mission structure to provide multiple scenarios that took advantage of pre-existing play spaces.

What was the inspiration for the free-roaming environment?

Wright: To make Wumpa island feel like one huge and wholly connected place, more circuitous and Escher-like than a series of unrelated stages.

What were some challenges working with a pre-existing IP?

Mapara: There is an enormous amount of creative flexibility working with a character like Crash. Some IP’s dictate a pre-defined world and look that must be adhered to, like a movie license for instance. But Crash has so many elements to innovate on. So we were able to introduce a feature like Jacking and build on that through two games. It made perfect sense for Crash to have these creatures behave as weapons and for him to collect an arsenal of them to use when he liked by upgrading them then storing them to carry forward with him. Plus we were able to write a fresh story each time, add tattoo’s to the character if they were required to show his affiliation with the mutants he jacked, and select an art style that suited the story and character.

How did Radical tackle development for multiple platforms and what were some of the design differences?

Ian Gipson, Lead Programmer: Designing for multiple platforms can be tricky, especially considering that the PS2, Wii and Xbox360 are very different platforms. We focused our attention first on the Wii, which we decided early on was to be the lead platform. We wanted to make use of the Wii remote’s motion sensing and pointing capabilities, to add variety to the player’s interaction with the game. At the same time, we wanted the PS2 and Xbox360 versions have excellent controls that were fun without the motion sensing capabilities.

The other area that shows a great difference across the three consoles is graphical quality.  It’s no secret that the Xbox360 has superior graphical capabilities to the Wii, and that the PS2 lags behind both of them in terms of raw graphics power. We concentrated our feature set on the Wii, trying to push its rendering as far as we could take it with our specialized art style. We wanted to add as many features as we could to the Xbox360 version, without making it look drastically different from the other versions of the game. Some of those features just weren’t possible on the PS2, for example, reflections on the water are not present on the PS2. Using the 360’s extra bandwidth, we were able to spend some time adding features such as depth of field.

What was the process for getting Mind Over Mutant ported to PSP?

Glenn Dphrepaulezz, Producer: It is usually a straightforward development challenge to move a PS2 game over to the PSP, but in our case, since Wii was Mind Over Mutant’s lead sku, and therefore the platform that got the most love from coders (meaning we could rely on it to be stable and crash free), we chose to move the Wii code and content over to the PSP, which was a little more interesting.

Our process was to deliver Wii builds to Virtuos, our external developer and give them two months to integrate. The minute they finished, we’d review and send another batch of source. We did this in stages through development until they had to branch out on their own and fix the last remaining bugs. Then presto chango, a PSP game is born.

What is your favorite feature in the PSP version?

Dphrepaulezz: Well, aside from all the features in the console versions of Mind Over Mutant, like the Jacking of course, and getting to keep your Mutants with you, the thing I like most about the PSP version is how good it looks. Particularly the 2D cut scenes which are screamingly funny anyway, and work particularly well on the PSP since you’re usually in a waiting room somewhere when you’re playing your portable and you get to laugh out loud and make everyone wish they could join your party.

Design: A meeting between the Artist, Lead Artist and Designer ideally should place to review what happens in the level and go over the map to establish where any environmental features will be positioned. Some technical knowledge of what is possible on the destination platforms is required at the initial design stage, as a level designed without this in mind may have to be redesigned later when engine can’t handle it. Some of the questions which usually need answers are: What are the goals of the level? What is required from the level in terms of game play and atmosphere?

Planning & Modularity: Any re-useable level sections and features need to be decided upon so they only need to be modelled and textured once (unless something similar has already been created that can be re-used). These modular environment features can then be copied around the map where required before being tweaked individually if needed at the end.

Assets: Using the design as a guide, the Lead Artist and Designer can produce a list of assets required to populate the level. The knowledge of where these props are positioned will be needed initially by the Environment Artist to make sure enough space is left for them, especially important for game-play related props. Re-useable and more generic props such as litter and vegetation are handy for quickly populating at sparse level. Some of the more unique props can only be a few times.

Schedule: Once the tasks are quantified, time estimates can be allocated to each one. Although initially these may not be very accurate, especially if an Artist has never done some of the tasks before but these should get more accurate as the project progresses.

Block-out: The Block-out (also known as a White Room) is a rapidly built, simplified early version of the level defining the main environment features and structures for testing game play and getting a feel for its size and dimensions. Basic texturing and rough props can show where features will be and what materials are needed. The level can be divided into portalled-off zones at this stage to allow for higher polygon counts as only a few zones usually need to be drawn by the game engine at any one time.

First Pass Lighting: A quick lighting pass on the Block-out will give an early indication on the best approach for lighting it as well as making navigation easier for play-testing. Once ready the Block-out can then be used by the Designer to test and tweak the game-play before giving the go-ahead to start the final geometry production.

Concept Art: Any concept art created based on the level design should be received, ready to begin creation of the final geometry.

Final Geometry creation & prop placement: Once the Block-out has been tested and agreed upon, it can go into full production. Creating the final geometry for the game based upon the concept art created with the features, layout and atmosphere in mind. Modelling repeating geometry such as pillars and walls only once before copying them around the environment can help speed-up this process. Textures creation may done by the Environment Artist or a dedicated Texture Artist.

Optimisation & Collision: To speed up the collision detection between the environment and the dynamic elements of the game such and the player and enemies, a highly optimised collision hull is created to limit the number of polygons the engine code needs to check against.

Final lighting pass & atmospheric effects: Once the final geometry is in place the lighting can be adjusted to take best advantage of the features modelled. Atmospheric effects such as fire, mist and volumetric lights can be placed where required. Light maps can be generated and / or static shadows modelled in.

Some of these stages may have to be revisited if any fundamental design changes to the level are required.

Tales of Vesperia is the 10th title in the ‘Tales Series’ and is developed specifically by Namco Tales Studio. Every moment of Vesperia is filled with direction that makes you fell like you are watching a fast paced anime, which is refreshing next to the well-deserved stigma that JRPGs tend to drag on in the story department. The characters fit traditional stereotypes and the humor is on par with titles like Maison Ikkoku, Cowboy Bebop or Naruto. Tales of Vesperia does not break the mold of a JRPG but instead defines and enhances the genre to exceed expectations and maintains a solid feel and art direction for the entire world. Simply put: it raises the proverbial “bar” for a balanced and fun video game experience.

One way Tales of Vesperia perfects the genre is bringing back the good parts of role playing games that have predominantly gone MIA over the last few generations of games. Since Final Fantasy VII I have adored the over world map and it has gone missing in recent titles. Recent titles show a map and then plot the points to your next destination ala Indiana Jones which means no control to explore the world that surrounds you. It’s basically another linear experience forged out of convenience. Give me the ship, the airship, the submarine, whichever… I just want my open over world to explore and Tales delivers a huge and beautiful world for players to discover. The game remains on par with an intuitive menu system, great battle design, highly customizable characters and a predictable yet entertaining story. I particularly love the add-ons in the menu for plot synopsis and the battle book- the latter elaborates on the many ways you can defeat your enemies with different characters and how to achieve high-level combos and the ever-evolving tactical challenges that the game presents. In addition there are a plethora of settings, choices and options that it’s hard to believe there could be a fan that couldn’t find the right combination for their game play style.

Speaking of just the right combination… Tales of Vesperia really shines in the battle department. I grew tired of random battles and turn based battle systems a while back and luckily Tales provides entertaining and efficient alternatives. The game does load a battle screen but the blip of a load screen loses is regained within the battle itself. Highly engaging and dynamic, control defaults to the main characters actions with the rest of the team backing with automatic AI and once unlocked you can select to control any of your comrades within a 3D environment. There are always choices and different ways to play Tales according to your own personal taste. Replete with combos, finishing moves, decent AI and fantastic effects for both magic and physical actions the combat systems completely delivers on a satisfying experience. Utilizing the free run and camera modes empower the players to feel as though they are really in control of the battle and outcome- this makes traditional turn based combat look awkward in comparison. Additionally, as in other Tales games, there is a two-player mode that allows people to play in battle mode at the same time and this remains an entertaining alternative if you’re forced to share.

I have to say Tales of Vesperia is one of the most appropriately designed and balanced role-playing games to date. It’s a refreshing change, as games seem to have become overly worked and complex in art and interface in order to make a notch on the ‘notable game art tally.’ Don’t get me wrong—it is definitely entertaining to see creative solutions to design issues but all too often either art or design is compromised and the experience ultimately fails to come to fruition. The sad result is a game half-realized that you stop playing maybe after an hour of trying (you know what I am talking about). Luckily Tales is not of that stock and delivers smart design decisions and a stylized art that doesn’t actually overpower the other aspects of the game.

One of the best and natural decisions for Tales of Vesperia was to make it a cell shaded game. (much like Naruto, Okami, Viewtiful Joe, and Ultimate Spiderman) This is a trend we’re seeing more often in games based on animation and one that I welcome whole-heartedly. Cell shading is a fantastic way to bring people who love animation into those worlds and let them explore—not only the world itself—but also the art director’s vision for that realm.  Needless to say, I believe it to be a sign that we are at the pinnacle of animation translating effectively into 3D game engines when Studio Ghibli is working on their first console title. It is now possible to emulate the animation artistically to the last letter while letting players have the control of the action—halleluiah. Tales looks as though you are genuinely playing an anime and the characters shine with outstanding voice acting in vignettes that makes the entire story and the character’s personalities come alive.

I strongly believe that art direction and stylings should be iconic for a franchise but also keep in mind all of the aspects that produce a well-balanced title. So much goes into crafting a fantasy realm’s look and feel that it would be easy to lose sight of what makes an overall satisfactory game experience. For instance in Tales you have traditional fantasy themes: magic, elves, monsters, magic, castles, airships, etc but these honored fantasy institutions are constructed uniquely and help to craft the feel of the fantasy. There’s a balance in their world that unifies art and function. From battle screen attack effects to the physical appearance of Ba’ul, the giant flying whale dragon, everything in Tales of Vesperia feels unique and captures the quintessential soul of a JRPG without over designing/art directing the entire experience.

As I said in the beginning I really wanted to write about Tales because when I picked it up I found myself really enjoying a RPG which hasn’t happened in a very long time. Tales of Vesperia offered me everything I loved about RPGs but without clumsy design, overworked art or forced linear path through a fantastic world that begs to be explored. I found myself as addicted to the story and entertained by the mechanics, as I once was when I discovered the genre as ten year old. I may not know all readers personally or vouch for different taste in video games but I can say:

If you like watching anime and find entertainment in the cliché of a line-up of archetypical characters, and/or you love animation and breathtaking artwork crafted around a recognizably themed yet perfectly stylized fantasy world—Tales of Vesperia is worth the purchase price.

There are many techniques which can be employed to make an environment more visually interesting. Some that I use are:

Shapes & Structures: Breaking up simple linear outlines (for example, roofs, fences or walls) with other objects to keep the scene unpredictable for the players eye (non-uniform shapes stimulating the brain more).

Lighting: This can be used to guide the player from one area to another as well as being used to dramatise the scene; picking out strong shadows and highlights to prevent the scene looking flat and helping define the shapes of the main structures. This is important as the player is viewing it on a flat screen so distances to background features can be difficult to read, its dimensions can be made more visible at a glance with good use of lighting.

Colour: Colour (or lack of it) can be used in a variety of ways. Use slightly exaggerated colour saturation for a more pleasant, lush feel and washed-out colours for a bleaker slightly depressing feel.

Texture: Having textures with a baked in light direction of subtle use of Normal Mapping can make the scene look far more detailed than it actually is (unless Normal Mapping is being used). Using to much can detract from the overall effect though and the scene ends up a noisy mess.

Sense of weight: Including features in an environment which give the objects a sense of weight is good way to add believability. Placing solid objects leaning on flexible objects such as wood against a mesh fence, causing them to sag or lean. Ropes, chains or material draped over solid objects.

Animation: Movement can dramatically bring a scene to life and should be used where-ever possible. Things like animating flags, swinging ropes or chains or smoke rising from chimneys can all help to create a feel of a living breathing world.

A lived-in feel: If a game environment is supposed to be inhabited it should reflect this in the environment graphics. Not just by people but anything alive in the environment, plant growth around objects can give the scene a cohesive feel, rather than a series of objects that seem to have been placed together and seem to interact with each other. Ideally every object should look like it has a history, a story to tell. Why is it there? Why is it dislodged?

Who broke it?

Video games as they currently exist are, for the most part, creatures of plot.    Now, there is a difference between Plot proper and Story proper.  Plot is the individual events that happen in a narrative.  Story is the pattern of the narrative, a function of characters and their interaction with each other and their environment.  Finding a plane full of money in the woods is Plot.  Claiming it for yourself and the interpersonal mayhem that ensues is Story.

In plot-driven games, the player is led by the nose through a cascade of events, monsters and puzzles, all disparate threads having little to do with each other save the player-character experiencing them.  These games, like the Grand Theft Auto franchise or dungeon-grinding role playing games, fail to create an emotional connection with the player because the various elements of the game do not build into a coherent whole.  That missing continuity of characters and events is the missing Story element.

Some games do build themselves around a plot-and-story narrative.  But it often takes over the game, with long cutscenes and a rigid structure. The path is set, and the actions of the player have very little effect on the outcome, beyond the binary choice to win or lose. The player is left with the feeling he is playing a movie instead of playing a game.  Because he is expecting a gaming experience and not a movie-watching experience, the chance for emotional connection is lost.

Obviously, a game narrative will not be a film or book narrative.  Novels and films both place the consumer in a passive state where it is easy and attractive to let oneself fall into the hands of the author or director and to feel what the characters feel.  Playing a video game requires much more activity on the part of the consumer, and though the player believes he controls the game’s outcome, he does not.  The illusion of player-control must be maintained as game herds him towards its scripted end.  A way to maintain this illusion is to make the player-character change during the course of the game: give the player character a traditional character arc.  As the character acts, the environment necessarily changes in its reactions to him, and the player is forced to adapt to the consequences of choices he has made in the game.  The technical demands of such a plastic environment are great, but it has already been attempted in games like Mass Effect and Fable II.

Character development and continuity of any kind is a major problem in video games.  More often than not, in games where NPCs play a large role, the shorthand of mono-myth and classical fantasy is used: he’s the Mentor, she’s the Fair Maiden, he’s a Thief, and they’re on a Quest.  The narrative design trend seems to be towards simplicity, which is to me a shame.  Narrative complexity, in terms of characters and story-lines, rewards both the player and the creator.  Emotional connection requires continuity, and rational narrative build to a dramatic climax.  Interweaving narrative continuity with gameplay is a design challenge.  But that does not mean it can’t be done.  Narrative cannot remain relegated to cutscenes between bouts of gunplay and puzzle solving.

As the stories told via video games get better, the emotional connection between player and game grow stronger.  Players return to games they have a connection with, and to studios that produce those games, just as authors, film directors and actors collect fans.  It is in the economic interest of the industry to encourage narrative development in big-budget games.  Game writers and designers have a millennia of story-telling history to draw on.  While the mono-mythic Hero template is popularly co-opted for video-game plot-lines, it is not the only story out there.  The tools of story-telling are out there.  We just have to adapt them for our medium.

The Good

You get to play the game before the public does - Sometimes this is a good thing, sometimes not. But being able to know all of the ins and outs of the latest great game before your friends, can be a fun experience. QA Team multiplayer tests can be really fun too.

You get your name in the credits - I know this kind of contradicts what I put on the bad list, but that doesn’t happen all of the time. Seeing your name in the credits inside the game, or in the instruction manual (those who took them out, boo!!), is a humbling experience and gives you a great sense of pride and accomplishment (provided the game is actually good).

You learn about the game development process - Whether through just the bugs you find, what you read in the bug DB, or what extra things that you do outside of regular QA duties to help the dev or production teams, you will learn more about how games are made better then most people in the industry first hand.

In my opinion, every single person working on a game project should actively be a part of a QA team for at least 90 days before ever making or doing anything on their first game. Straight out of college? Good, have some QA. Interning as an artist? Great, have some more QA. Coming from being a producer or marketer from a totally different industry and product line? Excellent! Have a seat right here, I have some QA for you.

It is hard to respect what you don’t know, or haven’t experienced. How do you expect to work on something or represent it properly when you have no idea of how it is made, or what game development entails?

You have a greater sense of accomplishment when you complete work on a game - It is a great feeling to know that thousands, if not millions of people have played a game you worked so hard on. Working on a game in QA is a different feeling from developing it, but it feels just as good.

Hours and hours of enjoyment were had by people playing a game that you helped get to market. To me, it is one of the best feelings in the world creatively.

You get a free copy of the game you worked on - Sometimes this is true, other times it is not. It should be a standard industry practice. This is itself a nice perk of the job, although if the game really sucks, they make for great stocking stuffers for someone else to suffer with

You CAN move up and out of QA to a better position that fits you - Like anything in life, it is what you make it. It is a good foot in the door, however it can be a brief moment of time inside. You can get promoted and move out of QA if you desire, but it takes some work.

Network with everyone and be friendly with everyone, no matter how much of a total jerk they may be. This is a small industry, and burning as few bridges as possible is highly recommended.

Learn what everyone does, find out what kinds of games they like or dislike. Whether you are an artist, programmer, composer, whatever, promote your skills to the appropriate people at the company you work for. Bring your demo reel or files, and let others know in development and production that you are interested in one positions that you feel you can fill.

You will encounter some jealous and negative people along the way who may try to stop you or slow you down, but hopefully they eventually realize it is about the game project, and the players who will play it, not about egos and who gets promoted from where. Just ignore them and keep on learning and trying to make great and fun games.

You can meet some truly talented, smart and nice people - Working beside and with the same people for 2-9 months day in and day out, if you haven’t made friends with most of them by then, you’re doing it wrong. I’m not saying you should try to be Paris Hilton popular, but being nice to everyone and helpful can go a long way.

Those relationships can be helpful to you or them down the road years later when people have switched companies, been promoted, lost their jobs, started a new company, etc.

Someone you help out today, could be your boss offering you a job in the future. Trading “war” stories about being in QA at such and such company with someone could turn out to be the best influential conversation of your life.

Are you still with me? Good. Hopefully I’ve helped some of you see a bigger picture about QA Testing in the game industry. It isn’t all fun and games like some commercials for universities, or one really bad movie made it out to be.

But being a QA Tester is a rewarding job if you know what to watch out for, and how to do things the best you can with the environment given to you.

Still interested in being a QA Tester, or working in the game industry?

Make sure that you can read and write concisely, learn fast, have tact, and don’t give up your dreams for anyone who tells you you can’t. Here are two books I recommend that you read: The Game Production Handbook by Heather Chandler and Game Testing All-In-One - by Charles P. Schultz, Robert Bryant, and Tim Langdell.

And good luck getting to your dream!

Are you insane?

I’m going to rain on your parade a little bit, but there is sunshine at the end, I promise.

Many schools don’t cover one of the more important jobs in the game industry. If you are in QA Testing (Quality Assurance), odds are, most of development and production hate you, but for some strange reason know deep down they need you. It is a weird love/hate relationship that is way too disposable.

From outside the industry, QA Testing is viewed as a hallowed, sacred job that people would do for free, lick the developers’ shoes, wash their cars, whatever. They think it would just be “so totally awesome” to be a game
tester.

Once you’ve been in QA a few years or so, your view heavily changes to slightly jaded, if not totally bitter. This can happen when you have devs and too many (or cocky, know nothing but take all the credit) producers/management constantly making your job a living hell by managing managers and other musical chair games, when all you’re trying to do is ship a bug free (as much as possible) and fun game.

There are some harsh realities to being a game tester for any type of QA Testing job, like standards, TRCs, TCRs, ESRB/ratings pre-checks, etc. What is often perceived as a “dream job” is often a terrible, life-sucking grind if the whole team and company doesn’t really care about their people and/or shipping a quality game.

It would be great if some changes were made in the way QA is handled in the industry. Quality Assurance. The two words are very ironic with what actual QA Testing jobs are at many companies, and the way they are run.

There are good and bad sides to everything, with exceptions here and there. I’ll try to give you a little perspective from both sides drawn from my experiences and from those I’ve heard from people working at various companies in the industry. It would be great if some changes were made in the way QA is handled in the industry.

The Bad

Long hours - Your weeks will often consist of 50-80+ hours a week in a pointless multi-month grind because the project wasn’t scheduled well. Many companies look down on you if you opt out of overtime, and your co-workers may try to give you peer pressure social jabs, like being in high school again, because you want to have a life outside of work.

Little to no respect - Don’t expect any respect from anyone outside of your QA group and QA Lead(s). The developers won’t give you any, and neither will production. You’d be surprised how naive and ignorant some devs and production team members are that don’t even play games, or have only played them for the last 4 years or less.

Regardless of the long hours that you put in, your determination to find those evil bugs, the ambition and drive you take to do extra things to help the devs and production, you will get minimal to no appreciation to show for it. Many times, production will take credit for what QA team members suggested, created, or found to help the project stay on track.

You are treated as a lower-class being for working in QA. I know many in QA (and interns, but that’s another story) who do some of dev’s and production’s jobs for them.

Low pay - Depending on where you are in the United States, or the world, QA Testing is a low paying gig. You will be above minimum wage, but you can’t really make a career out of it long term. Going rates in the U.S.  are around $8.50-15.00+ an hour.

You can work multiple years in QA, and still not make over $40,000 a year, even with moving up in the chain of command multiple times.

Your employer does not try to make your job easier - There are many ways that your QA job could be improved for efficiency, sanity, and to potentially make the game more stable or fun for players. Do not assume common sense exists.

To report bugs properly, and to get them to the devs immediately so that they can be fixed or assessed quickly, the company must have a solid system in place. This is often not the case.

Don’t be surprised if the multi-million dollar company you work for has you writing your bug report on paper, then researching the DB (database) machine to see if they have been entered already, and followed by entering them on ONE DB kiosk machine for the team. When your team consists of 20+ people all ready to enter and/or research their bugs, this is a terrible and time consuming way to do it.

A better way that some companies do this right is they have a DB machine for each tester, or at least every 3-4 testers, so that the process runs better and faster.

Overtime is called volunteer, but it is implied that it is mandatory. Sometimes people get laid off because of misunderstanding this.

You are a disposable contractor - Many game companies hire QA Testers on cycle with the game project to save costs. That means after the game has shipped, that most times, your contract then ends. From a business standpoint I can understand this.

From a developer standpoint, I think it is very stupid. I would rather have a dedicated full time QA team that knows how to write concise and accurate bug reports, works efficiently and well together, work well with the devs/production, are reliable and get the job done from day one. Instead of having morale crushing disposable members of the team re-invent the wheel every few projects.

Bring the QA Team in as early as possible, and have open communication for everyone involved with the project. People that care about the project and company they work for, it shows in the end product. They won’t care if you don’t care about them.

Don’t ever expect management’s decisions to make sense - That way, when they do make sense, you’ll be surprised!

You may experience some things like:

1)  “A” and “B” (major, important) level bugs being shipped with the game, even though you KNOW players are going to be pissed off and you feel that the quality of the game is poor. Then you hear: “We’ll fix it in a patch later”.

2) The release schedule being pushed up (sooner), even though the QA Team was brought onto the project late and there isn’t enough time to clean up all the bugs.

3) Major gameplay problems not being addressed, just ignored, and then corporate wonders why the game did so badly when it had so much potential.

4) New features being pushed into the game that break other parts of the game, which creates more bugs then expected too late in the dev cycle to get fixed in time.

5) There are so many middle managers between the QA Team and the devs, that resolving some simple bug issues takes days, if not weeks, to get looked at, much less fixed.

Getting your name in the credits may not happen - Even though you have spent months of long hours working on a title, and helped find many gameplay and crash bugs to improve the player’s experience of the game, your name may not make the credits.

Not only does this make it difficult to prove on your resume, it also hurts your morale deeply. Movies list half of a city on their credits covering a huge variety of skills from people who may have only worked 1 day on it. Video games should have the same respect for everyone involved in the creation of the game.

QA is looked down upon by many in the industry - Think of QA Testers as Janitors or Marines. They have to go in to unknown hostile territory to do a job no one else will do and clean up other peoples messes.

Once you are in QA for awhile, and get known as a “QA Guy/Girl”, it is like being a type cast celebrity because of their role on a long-running TV show or hit movie.

It is a dirty job dealing with the egos of production or devs and pointing out their mistakes. Many people don’t like being told they are wrong or have made a mistake. People should get over it. The project is bigger then someone’s ego, so they need to grow up, or leave the company. The team is there to make a fun game for players—many lose sight of that.

There are many in QA Testing that have talents equal to, or surpassing devs and production. The sad thing is, this talent is often overlooked because you, as a tester, are viewed as disposable and/or lower class.

No one bothers checking out the experienced and talented people right under their nose. Then you see non-talented, just-barely-made-it-out-of-school interns getting production or marketing jobs that have absolutely no idea how games are developed, much less play them or have any real development skills.

You will be on the same game for months - Try testing, or playing, the same game 8-16 hours a day for 2-9 months per project and see how much you still like the game. When you have devs and production members of the team being uncooperative and/or negative with the QA Team during the whole project, it can be very disheartening.

It can stress you out beyond belief - This is especially true if you have total dirt-bags for immediate Leads or upper management who yell at you for their bad mistakes when production or executives comes down on them. Add to that production yelling at, or sternly telling you, that you’re doing a bad job because they have to delay the game because they have to fix more bugs (when in fact production decided some bugs wouldn’t be fixed at all until they built up near the end of the project and someone finally  DID decide maybe those bugs really should be fixed after all.) due to procrastinating issues instead of resolving them.

So the circle continues. I better end this part of the list now, to make sure I balance out the good list, heh.

Despite the bad things list, there are good things about QA Testing, even though you may think I have nothing nice to write about it so far. Check in next week to see what I mean in the second part of this series.

There was a day, four years ago, when I was not a media whore.

I’ve been indie for almost four years now.  As the sole full-time member of Pocketwatch Games, I tend to do a little bit of everything.  I regularly have to code in C++, PHP, HTML, TorqueScript, Javascript, and Actionscript.  I build games and social media with the Torque Game Engine, Flash, the Wordpress platform, and a PHPBB forum.  I am an Executive Producer, Lead Programmer, Art Director, Customer Support Specialist, Community Manager, Marketer, and Media Whore.

Four years ago, I was an AI Programmer.  That’s it.  I coded in C++.

There’s a whole ‘nother side to selling games beyond development that I wish I could have zapped into my brain before I went indie (bzzzt… I know Kung Fu).  Here’s what I wish I understood when I was just starting out.
The Landscape

When I got started at the end of 2004, the casual games industry was just starting to heat up.  I designed my first game, Wildlife Tycoon: Venture Africa, around a popular niche (Tycoon games) and prevailing trends in digital distribution (small download size, low barrier-to-entry gameplay).  In this way I wanted to satisfy an underserved niche while building my own place in the gaming world with “Discovery Channel” style games.

These days, the landscape for indie game developers is a bit broader.  Small indie teams can make a living – even a fortune – through these distribution channels:
•    Downloadable Console Games
•    Casual Portals
•    Hardcore Portals (Steam, Greenhouse)
•    Direct Sales (Your own website)
•    Flash games (Revenue from Mochi ads, sponsorship by portals like FlashGameLicense)
•    Community-based games (MMOs, virtual worlds)

I believe that it’s important to have an idea of your distribution platform before you begin to design your game.  It will define your limitations, help you to describe your audience, and most importantly, help you to nail down your marketing strategy.

Marketing – The Demo

Ahh, the all-important demo.  For any digitally-distributed game, the demo is the core of the marketing strategy.  More than that, it’s also a way for people to test out system requirements, thereby reducing the number of support requests you’ll get.

The design of the demo should be core to the design of the game.  If you expect that you can get away with simply limiting content and play time, your game will sell a tenth of what it should.  Instead, if you focus on what the customer actually gets to touch before they buy the game, you will be more likely to get them to pull out their credit card.  This means scaling that tutorial WAAAYYY back and focusing on the first 30 minutes to provide quick progression, fun gameplay, and flashy graphics.  I made the “explain everything in the tutorial up front” mistake on my second game, Venture Arctic, and it really hurt sales.  People lost interest before they got to the fun parts.

I have not found that you need to promise a huge amount of gameplay AFTER the demo in order to sell games.  Consider World of Goo, which only takes about 5 hours to finish and features something like a fifth of their gameplay in the demo itself.

It should be noted that some distribution channels don’t use demos, WiiWare being the obvious example.  WiiWare sales depend entirely on word-of-mouth.  Studies have also been done to show that in some circumstances, a gameplay video is more effective than a demo at converting customers, though I suspect this only applies to games with big traditional marketing budgets.

Retail also doesn’t rely on demos.  People buy games in retail for one of two reasons – they’ve heard of it and want to buy it, or the box looks great.  Make sure your box looks like the type of game your typical ignoramus customer would be willing to shell out cash for.  It should be obvious what type of game it is – that’s why my first game had the unwieldy moniker, Wildlife Tycoon: Venture Africa.

Schedule

I like to make a strict schedule for development because it forces me to make decisions and I need to be able to pipeline my contractors.

Like most developers, my instinct was to schedule aggressively because as an employee I always liked to over-perform.  When I began running the business, I had to change gears and act in the role of producer.  I had to learn an entirely different, more conservative way to think about how long tasks would take.  Not only do I schedule all tasks in terms of worst-case-scenario, but I only schedule 4 days of coding/development per week.  Since I generally work a 6 day week, this leaves me two days a week for customer support on my previous games, developing my web presence, doing marketing, and managing contractors.

Also, I believe it’s a good idea to schedule 6 months at the end of a project to take time off, patch any bugs, deal with support requests, build a community, build alternate SKUs for retail or portals, and do your marketing.

In some cases, all this time away from development isn’t feasible –– if you are making casual games your business plan may revolve around frequent releases of small games.  Consider how this limits your ability to market your games and take that into account in your planning.

Employees

When my dad started his geophysical consulting business 20 years ago, he retained his former employer as a client.  He didn’t have to build his business “from the ground up” because he started with the foundation already in place.  This is also the best strategy for building a game development team.

If you don’t know anyone that can help you make your game, you probably will struggle to get it done at the quality you want.  Go get a job where you can meet like-minded fellows.  You can’t do this on your own.

If you build your team remotely, which is perfectly feasible and possibly the easiest way to go, you need to make sure your life is set up such that you’ve got plenty of personal connection to REAL PEOPLE.  Maybe rent out some cheap office space with another small business.  Game development requires long hours and you will be driven crazy if your only human contact for six days a week is via AIM.  A couple years in, I hired a full-time employee perhaps a bit impulsively because I was desperate for human contact.  In the end, it didn’t work out, which cost me the significant investment I made in that employee.

That said, I highly recommend having a core team of 2 and then contracting out the rest of the work.  I wish I had a full-time Art Director but it just hasn’t been in the cards yet.  I contract out Modeling, Animation, Sound/Music, Writing, and Graphic Design, all to separate people.  I knew some of them from previous jobs, and some I met through internet communities like GarageGames.com and indiegamer.com.

Community Relations

This leads me to your relationship to the game development community.  The indie community, centered around such sites as TigSource.com and indiegamer.com, can be incredibly helpful in getting the word out about your game, providing feedback, acting as a talent pool for potential contractors, and giving advice and connections that you can’t get on your own.  Develop a respectable presence amongst your peers and you will gain rewards that are otherwise unattainable.

Of course a smile, a handshake, and the traditional exchange of business cards can add an element to your business relationships that you can’t get online.  Go to GDC and attend any local indie events.  If there aren’t any, organize them yourself.  Before I had anything resembling a positive reputation, I started organizing an indie dinner in San Diego because the previous organizer ran out of time to do it himself.

Lastly, if there are any game-related colleges in your area, volunteer to work with them.  Game colleges are always eager to have contacts in professional game development and can hand you interns from their most choice candidates.  Interns are cheap and fun!

Buy vs. Build

If you come from the game development world, your instinct is probably to always build everything yourself.  Even though you aren’t paying yourself anything, as an indie, your time is actually MORE valuable than it was as an employee.  Think about it.  If you plan to build a successful business, you will eventually make more money than you did as an employee.  The question is, how fast can you get there?

Even if you are capable of building something yourself, you have more work on your plat than you can handle.  Contract the work out, leverage open source systems, or buy royalty-free media.

Music is a great example.  Maybe you can compose some music.  But you are probably best off finding one of the myriad audio guys out there that’s desperate for work.  You also might be able to find some royalty free music from one of these sites for EXTREMELY cheap:
•    http://www.sounddogs.com/
•    http://soundrangers.com/
•    http://audiojungle.net/
•    http://www.opuzz.com/
•    http://www.shockwave-sound.com/

But maybe you can save even more time having your audio guy dig through those sites it and pick your music out for you.  How do you maximize your dollars and minimize your involvement?  The answer of the Buy vs. Build question is almost always “Buy”.

Building a Website

Your primary sales for your first game will likely not come from your own website.  But eventually you should aim to own your customers instead of handing them over to Yahoo or Microsoft or Valve.  Direct sales are the holy grail of indie games because that direct conduit you have to paying customers is worth a lot more than the twenty dollars they shell out for an individual game.  Owning the email addresses of these paying customers is how you build long-term value in your company.

I’m not going to get into “How to Build a Successful Website” – I’m not qualified and there are tons of resources out there on the subject.  But in terms of game specific stuff, here are some numbers I have learned that might be useful:
•    On a decent game website, 25-40% of visitors will download your demo.
•    For a decent game, 1-5% of demo users will convert to paying customers.
•    5-30% of newsletter recipients will buy a new game.
•    20-50% of paying customers will buy more than one game.

What does this mean?  Allow people to sign up for newsletters – they are basically telling you they want to buy your games when new ones come out.  Do everything you can to increase your download rate (build gigantic download buttons that funnel your customers to your demo).  And try to sell more than one game from your site – every paying customer is worth more than the revenue from one game, you just need to get them to realize their buying potential.

Doing Business with Publishers/Distributors

The first thing to understand here is what the different business entities are:
•    Retail Publisher – Creates the packaging for you game deals with the stores directly.  The quality of the publisher is directly related to their clout with the retailers.  Your publisher may help with localization and Q&A, but don’t expect them to do any marketing for you, even if they promise.
•    Distributor – Someone who aggregates a bunch of games into a catalog, which can be sold by affiliates
•    Portal/Affiliate – An individual site, often pulling games from a distributor.  In a few cases, you may want to deal directly with the portal so you can cut out the middle man, but sales will only be significant from the top ten portals.  Don’t do individual deals with small portals, it’s a waste of time.

With publishers, ask for an advance.  If they aren’t willing to give it to you, ask someone else.  The only thing worth trusting from a publisher is the number they write on a check made out to you.  If you can’t find anyone willing to give you an advance, get a sales guarantee.  Don’t give up your distribution rights if you can help it, and make sure you have a way to get your retail rights back if they are no longer selling the game.

While it’s good to develop friendly, personal relationships with publishers, distributors, and portals (we’re all sleeping in the same bed), in the back of your mind you should expect them to act like vending machines for your games.  If you expect them to attract potential customers rather than simply dispense games, you’re likely to be disappointed.

That said, wider distribution is better.  The more eyeballs that see your game, the more units you will sell.  Distribute as widely as you can, and don’t get greedy about royalty rates.  Moving 50% more units matters much more than squeaking out an extra 2% of revenue.  And the more people that see your game, the more people that will search for your game on the web, thereby landing on your website and generating direct sales.  Think of the cut of revenue you give up to portals as your advertising budget.  And that is advertising  that will ALWAYS turn a profit.

Develop Press Contacts

Lastly, Kelly Heckman, the editor of GamersInfo.net, once gave a talk where she encouraged indie developers to send physical copies of their games to press contacts.  This is 100% true.  A link to your game in an email or press release can be easily ignored at best, or even seem shady at worst.  After hearing that talk, I sent Kelly a copy of my first game burned onto a CD with a cheap pack of plastic animals from a 99 cent store.  I’ve received positive and prompt coverage on GamersInfo.net ever since.

There are three things an indie developer can do to advertise his game: use Google Adwords (only worth it if your game converts well or you sell more than one game), distribute your demo far and wide, and get press coverage in the form of previews and reviews.  Treat the press like the girl you really want to go to the prom with.  Be bold.  Be confident.  Be sexy.  But be honest, genuine, and personal.  To all of them.  Be a media whore.

I’ve started a lot of game development “companies” in my life, starting when I was 7.  I’ve finally found a way to make a living with this one at 30.  The difference between then and now is not that my game ideas are better.  I’m not even that much better of a programmer.  I just spent the intervening years developing a broad set of skills to successfully handle the diverse chores of running a small company.

Besides, my 7 year old self would have been far too embarrassed to ask Kelly Heckman to the proverbial prom.

And since then, they’ve spawned large collections both public and corporate, books, newsgroups, anti-patterns, and even a variety of names—interaction design patterns, user experience patterns, usability patterns, user interface patterns, web design patterns, and probably more. I’ll be calling the lot of them UI patterns, for simplicity.

Despite their popularity, UI patterns have received relatively little attention toward how they are or should be used. How often do designers and others actually use patterns, and why do they do so? What kinds of designers use them most, and how big a role do patterns play in their work? Perhaps more importantly, are patterns structured in a way that optimizes their both their usability and reusability? For example, the concept originated in architecture as a means of capturing and reusing the best practices that had developed within the field, and it serves the same purpose in interaction design. However, compared to other methods of knowledge compilation, patterns have a particular challenge: They must be structured generally enough to apply to most instances of a certain class of design issue, but concretely enough to provide specific guidance for handling any one of those instances.

To answer some of those questions, I sent a questionnaire around to several newsgroups likely to be inhabited by various types of designers. I’m still sifting through the results, but I can share some initial findings on who tends to use patterns and why.

First, of the people responding, a little over half had at least tried to use UI design patterns in the past couple of years. They did so most commonly for designing web and web app UIs, and occasionally but much less frequently for desktop software; mobile UIs were a rare target of pattern usage. The most common and, by far, primary reason they used patterns was for design inspiration, followed distantly by the need to address a use case. Communicating with development and design teams was also a common use, but not a primary one.

People seem to be generally positive toward patterns, considering them both useful and efficient. The survey participants said that they find it easy to locate libraries and browse them for patterns, although searching libraries is a bit more difficult. And when they have an appropriate pattern in hand, they seem to have little trouble in applying it to a specific design problem. The challenge is in locating an appropriate pattern: Although people can easily find what they need in libraries to help with a general design issue, they consider it relatively difficult to locate patterns that they can successfully apply to a specific problem.

That finding likely explains the use of patterns as being primarily inspirational. However, it also suggests that patterns may not be achieving an ideal balance between generic and specific: Though they are broad enough to address general types of issues, they are perhaps too broad to help with specific instances of those issues. On the other hand, the otherwise positive opinion of UI design patterns suggests that designers are ok with all that. Unfortunately, I neglected to ask in the survey whether designers actually want patterns that can address specific problems, so I can’t say for sure which is the case.

Modified World of Warcraft Interface

On the gaming front, just under a fifth of people who took the survey said that their main application interest is in games. Of those people, the ones who had used patterns in the past two years were likely to have gotten them from a friend, and they were less likely to be using them to comply with corporate standards. Those two findings suggest perhaps a more informal use of patterns in game development than in other environments. However, because of the relatively small numbers of people responding to the survey items in question, the statistics here are pretty fuzzy.

The results didn’t highlight any other pattern-related preferences that game developers have. On the other hand, they did show that people with a background in graphic design or aesthetics were likely to use patterns for reasons beyond just inspiration –– for example, for communications or to address a use case. Those with interaction and UI design experience showed the same tendency, but to a lesser extent. Interestingly, a background in mobile UI design, which was associated with an interest in gaming apps, also led to a wider range of uses for design patterns. Finally, greater coding experience led to more-negative views of pattern usability, the basic grievances being with the searchability of pattern libraries, and the findability of patterns that can help with the specifics of a problem.

Summing up, the survey paints a picture of a popular tool that is good for generating design ideas, particularly with regard to web-based UIs. The tool may be a bit too general to help with specific design problems, but that issue is perhaps a concern mainly for designers who deal with code.

I’m hoping that those findings and others can point the way toward better methods of structuring and organizing patterns. Library search functionality, for example,  seems a good first candidate for improvement.

Can you tell us a little bit about your interest in game development and where it all started?

When I was 10 years old, my Dad, who worked in the software industry, took me to a special Computer Programming school for kids hoping I’d become Bill Gate’s one day. However, I had no interest in learning programming; instead I got to play my very first computer game at the school. And from that point on, video games were pretty much my obsession. My first attempt in making video games happened when I was 12, and my enthusiasm quickly faded due to a bad 5 inch floppy disk which carried a week’s worth of my work.

When I went to college around 1999, I was pretty much bored with the math and programming, and I started to put all my spare time on digital animation and 3D graphics. At the time, there were no domestic video game development studios in China and video game education was also a vacuum. And by accident, I met some very enthusiastic students in the college who wanted to make video games. It seemed like a good place where I could put my digital art skill to use. Once the training started, the adventure and joy from game development has never stopped.

Speaking of college… What was your role in Cloud and how did it come to be?

My first big student team project in the grad school at USC Interactive Media Division was not Cloud but Dyadin (IGF 2005), where my role was lead artist. It was the first video game made by student team in our division. The big success brought a lot of attention to the school, therefore the school started a grant to encourage students to team up and make more innovative games. The grant was open to the entire university. As one of the applicants I came up the rough idea of making a game about clouds and rallied around students and faculties. Once the cloud game idea won the grant and got funded by the school, we put a team together. My role was team lead. As a result I worked with the team on many aspects of the game: gameplay prototyping, game design, story and all the visual arts.

What do you think made Cloud the 2006 IGF Student Showcase Winner?

Being one of a kind—a fresh emotional experience that’s different from anything on the mainstream market.

Following Cloud, you went right on to working on flOw. How did Cloud’s success influence you?

It’s not the success part of Cloud influenced me but the failure of Cloud. So many people downloaded our game, including people who never played games. I guess they were lured to the childhood fantasy. As a result, their lack of game knowledge prevented them from enjoying the relaxing experience—instead, their frustration of learning how to control the game ruined the experience. I learned from Cloud that there is a huge market for games that evoke a different emotional experience. However, new markets mean new audience. In order to search for a design methodology that enables a game to satisfy both experienced gamers and not so experienced ones, I started the flOw project.

Interesting concept to work with! How was flOw conceptualized and developed?

As part of my master degree thesis at USC, flOw, the original web game, was made for the sole purpose of testing whether the design methodology I developed based on Flow theory works.

In the academia, there was a lot of many research about how to use an A.I. to read player’s performance and alter the gaming experience. However, through playing those games myself, I feel there are so many cases where the A.I. can’t assess player’s true feeling based on rigid formulas. As a side effect, the false reaction of the A.I. broke my “sense of control”, a key condition to enter the Flow state. Therefore, through learning successful video games with mass appeal, I came up a different approach to adjust the difficulties of the game. I call it Active Dynamic Difficulty Adjustment, which uses player’s choice to change the difficulty of the gaming experience. The trick is to embed the difficulty adjustment choices in the core gameplay mechanics so that when player makes those choices, he won’t feel interrupted from the core gameplay. In flOw, player’s only action is swimming and eating, and the way the player engages different content with different difficulties is also through swimming and eating. And the result of the testing was amazing!

flOw is now available on PS3, something that indie developers aspire to. How did you make the leap to console?

My business partner Kellee Santiago and I were very lucky to have studied at the USC Interactive Media Division where we took a class called business of interactive entertainment. It’s that class that opened our eyes that starting up a company and chasing your dream is not a fairy tale; instead it’s something totally possible for normal people like us who had no money, but a passion.

We had a sneak peek at the great potential and promising future of video games through Cloud. And we really hope the maturing of video games as an interactive medium could happen faster. We want to push the boundary of video games and allow more people around the world to see games like Cloud, to awaken the dormant market so that more people can join us to further expand video games’ emotional range and meet various needs from the public. Not just things made for excitement and leisure but also things that are thought evoking and deeply emotional.

With that goal, we started to pitch the grand idea of Cloud, the commercial version to almost all the publishers in North America. Quickly, we realized that based on the experience we had fresh out of school and the ridiculous budget we asked, there was simply no one who would take the risk with us.

It had to be the timing and pure luck that we encountered the opportunity of making games for the digital distribution platform for next generation console like Wii and PS3. Both of Sony and Nintendo were going to launch their new gaming consoles, and they were both dying for new content on their digital distribution channel. The fact that flOw was a rather complete game concept made with two students in three months helped us to convince Sony that they could trust us for a much smaller game than Cloud. And then the leap was made.

Well that’s great! What are you working on now?

We are finishing up our second title for Sony’s Playstation Network, Flower. A game that is a sister piece after Cloud and flOw. Our version of a video game poem dealing with our inner desires towards the wild nature and urban life.

What would you say is the biggest challenge you’ve faced so far as an indie?

The biggest challenge is to grow up, to become experienced from inexperience. We made so many mistakes in running a startup company and in game development. Though we’ve overcome all the challenges, the taste is still yummy pain.

Heh heh. What about your biggest triumph then?

Thatgamecompany is still up and running. And we are making games that we believe will push the boundary of what video games can communicate.

What advice do you have out there for those aspiring to join game industry as an indie?

Really consider indie game developer within our industry. Just look around at what’s happened in the past two years. How many of your favorite indie games have shown up on the commercial platforms? How many highly reviewed video games are from independent studios? This is the golden time of independent video games. We see so many talented new faces coming out of school and even veterans who left the big studios to form their company and chase their dreams.  The renaissance of video games is already happening.