I was thrilled that two of my greatest passions in life (video games and Disney Parks) have so much more in common than meets the eye. After all, Disney Parks aren't magical, even though they may feel magical, they are a result of hard work, attention to detail, strategic planning...

So, happily, Disney Parks aren't that full of magic after all.

Factories of Experience

Disney Parks, much similar to video games, are built to craft experiences. As game designers, we create systems that enable experiences. Disney Parks are all the same at its very core, they are factories that create experiences.

It seems cold and emotionally empty, but if one were to look at a Disney Park from an objective perspective, it's no more than a carefully designed system that enables people to have meaningful experiences.

Crafting these systems is not easy at all, one must not only have attention to detail, one must obsess over it, everything counts, everything builds up to an experience, of course, sometimes one needs to learn how to let things go.

Trash Bin Fantasyland - Magic Kingdom

Trash Bin Tomorrowland - Magic Kingdom

One of the things I've always loved the most about Disney Parks are the trash cans. I was the type of child who would go marvel at the beautifully incorporated trash cans in Magic Kingdom, as an adult I could clearly see why, I mean, the trash cans in Tomorrowland are completely robotic... and they even talk! They definitely are masters of putting attention to every detail in their parks!

The following is a video of a talking trashcan in Tomorrowland:

Disney himself was a heavy smoker, but he never smoke in front of children because he didn't want to set a bad example. Attention to detail doesn't mean not being human or being perfect, it means knowing what to show to the public, how to show it and when to show it.

In game design, attention to detail is a must. In a game, everything must fit withing the system, everything must be placed in the right place to enable the players' experience. In almost every great game the attention to detail is part of the development process, it's not just about observing the game in its final stage, it's about observing what needs to be observed in every step of the way.

Let's say that we are making a game from scratch and we begin the process of laying out the mechanics, or grayboxing, no art, not sound, just mechanics. Obsessing over missing art or sounds details does not make sense at this stage of development, so the designers must focus in the naked mechanics. They need to tweak and iterate so that they are ready to enable the experience they want to provide and so on.

Disney Parks have underground tunnels which enable employers to move between sections without being seen if the visitors aren't meant to see them, so you wouldn't see a Fantasyland employee walking in Tomorrowland, thus not dressed accordingly to the customers' experience, these tunnels are part of the complex system of mechanics that enable a clean and magical user experience in Disney Parks.

Playtesting

There is a key process in Game Design called Playtesting, playtesting is the process in which players play the game and the designers observe. It is a difficult process because in most cases the Game Designer needs to sit quietly and watch the gamers tear apart the game. Either by winning to easily or not winning at all, by missing doors that should have been obvious or not knowing what to do. It's agony.

As designers, we know our games by heart. I can play almost every game that we are doing while looking somewhere else most of the time. I know what every sound means, and when to watch, I know where the buttons are, I know what's supposed to happen every second of gameplay. Which is why I would be a terrible game tester. Playtesting works because playtesters don't know the game, thus they are experiencing what a player should experience.

The other big challenge of the playtesting process is know which data is disposable and which signs should we listen to. Correcting something in a game has an associated cost, and depending on the advanced of the game development process, the cost may be very low, or very high. Understanding that there are some aspects of our game that need to change due to playtesting results is not easy, because it means throwing away our hard work to be replaced by down to earth mechanics.

Halo would be a top down strategy game if it weren't for playtesting

If it weren't for playtesting, many great games wouldn't even exist. For instance Halo, the popular First Person Shooter, was initially conceived as a top down strategy game. It was after playtesting that the designers understood the true potential of their game and it turned slowly and through many iterations, into the FPS that we all know today.

Some Designers say that they are discovering their game, I truly believe this to mean that they are observing what players find engaging and what they don't, having the flexibility to change what needs to be changed, the speed to iterate as fast as possible and the bravery that involves throwing away their work when it needs to be thrown away.

This is another great thing that Walt Disney's design process of Disney Parks and Game Design have in common, quoting Be our Guest:

Walt would wear old clothes and a straw farmer’s hat and tour the park incognito. Dick Nunis, who was at the time a supervisor in Frontierland, remembers being tracked down by Walt during one of these visits.

Walt had ridden the Jungle Boat attraction and had timed the cruise. The boat’s operator had rushed the ride, which had ended in four and a half minutes instead of the full seven it should have taken.

Dick and Walt took the ride together and discussed the proper timing. The boat pilots used stopwatches to learn the perfect speed. Weeks went by until one day Walt returned. He road the Jungle Boats four times with different pilots.

In the end, he said nothing, just gave Dick a “Good show!” thumbs-up and continued on his way

Sounds familiar? Walt Disney used to playtest his rides! It's what must be done in Game Design, observing incognito while our players play and understanding what needs to be changed to enhance experience.

Video game is such a new field that even though there are some standarized and recommended practices, they don't work for every company, and each company works different and implements different processes. Sometimes we even take concepts from other industries, such as the film industry, and incorporate them without a second glance to the design process, whether they work or not.

I believe that we have a lot to learn from Disney's vision of his business, of finding economic success through high quality products resulting from processes that always have the customer in mind. That, at its core, smells of success.

miércoles, 25 de febrero de 2015

I have to be honest, this was supposed to be an article continuing the Game Testing 101 series. But there was so much that I wanted to write about that I just couldn't complete it. I wrote and re-wrote, heck I even tried writing in rhymes (don't believe me? Wait for next Tuesday, the Testing Tuesday post might be a bit cheesy)

I settled for separting my giant post into several not-so-giant posts, and this is the first one of those.

Game Bonding

When I was 8 years old a firend of my mom gave me 6 Goosebumps books. They changed my life. I was impressed after reading each and every one of them, they were my first deeply inmersive experience, for real. I hadn't even connected with videogames as much. It was so personal, so meaningful, that it opened up my eyes to the world of story telling. I would make up stories of everything, I would read stories of everything, and I would soon connect to videogames at a deeper level.

I guess that most of us can pinpoint the most life-changing events we had in our childhood. This was one of my top 5.

I could see myself in the characters, I would get scared at the most ridiculous things because I was so deep into the story, that I was living the story. Eventually I grew up to be an avid reader and an avid gamer, and it wasn't until I started studying Game Design that I could understand why noone could have ever explained what a Goosebumps book was really about.

If you look up the the definition of a game in Wikipedia, you will find not one, but many definitinos that have been "perfected" over the years, out of which my favorite is Eric Zimmerman's and Katie Salen's "A game is a system in which players engage in an artificial conflict, defined by rules, that results in a quantifiable outcome."

It is one of my favorite definitions because it has the following key elements:

System: A set of interacting or interdependent components forming an integrated whole, that has structure, behavior, and relationships between the elements.

Conflict: It can be an obstacle, an enemy, a puzzle that the player as to solve. I like to replace this word with "challenge"

Rules: Also called mechanics, they give the structure to the system, this is implied by saying that games are systems but sometimes it's good to be redundant.

Outcome: The result of the game, I don't know if Eric Zimmerman and Katie Salen meant it this way, but it's not always winning or losing, it's more about what the player learned from the game, how the game changed the player's life.

And, most importantly, I like their definition becuase it has:

Players' engagement: Exactly, there is no game without player, the game means something because of what happens in the player's mind.

However, like all Game Definitions that I have read so far, this one leaves me unsatisfied, empty. How can anyone define such a complex thing in just one or two paragraphs. Even if I were to tweak their definition with my conception of a game to something like this: "A game is a system with rules in which players face challenges, and that results in the shifting of human values meaningful to the player." It seems like a futile attempt of compressing all that a game is into very few words, it just doesn't feel right.

After thinking it through, I realized that the reason that I'm not satisfied with any Game definition is because I've been asking the wrong question all along (Douglas Adams' Hitchhiker's Guide to the Galaxy Reference and Spoiler alert coming up).

In The Hitchhiker's Guide to the Galaxy, a super computer called Deep Thought is built with the purpose of answering the Ultimate Question of Life, the Universe and Everything. Deep Thought started working and after 7 and a half million years, the answer was ready. Everyone gathered around this super computer and waited to hear the Answer to the Ultimate Question of Life, the Universe and Everything, which turned out to be... 42!!. After a conversation with Deep Thought and general disappointment, it was revealed that the answer seemed so meaningless because the people who asked the question were asking the wrong question all along.

Ultimately they asked the computer to generate the proper question, so that it could afterwards compute the answer, but the computer was not powerful enough to do so and it created a much more powerful computer with living beings incorporated into its processing systems, which would turn out to be the Earth.

See? This is precisely how I feel with every Game Definition I have ever read, it is as though I needed to know the Answer to Life, the Universe and Everything (and Games), and all I get is 42!. After all, games are complex systems with humans thrown into them, so surely it's not that simple. The implications of making a game are so deep and have so many variables that it is jut not right to mix it all together in one paragraph definitions.

So I realized that I had been posing myself the wrong question all along, I didn't want to know what games were, I play games everyday, I have quite a good grasp of what they are, as does everyone who has played a game at least once in his life. No, the real, more meaningful question is why do we play games?

So, why do humans play games?

Ah, that's a different and refreshing point of view.

The most important word on that sentece is humans. If we couldn't speak or write at all, what would a language really be about? If we couldn't speak or write, we can define a language as a set of characters that can be put together using predefined rules... again, empty, it's missing the main objective: Communication. You can see where I'm headed, the definition of Games is also missing the main point: Communication!

To me games are a form of communication between the player(s) and the system. The system speaks and listens to the player(s), and the player(s) speaks and listens to the system. That's it. There is no game without player, and no player without game.

Think about Minecraft for a second, it is a system, it has rules, but the conflict and the outcome are not as visible. It's the communication that makes the game a game, the player wants to build something, the game displays the tool it has avaiable for that, the player chooses it and puts it wherever he needs, the game displays said piece in the desired location, and so on. The game eventually tells the player "Here's what you built" and the player is either satisfied or keeps building.

We play games because we want to communicate, learn, achieve, even show off. Humans play games because they are expecting to retrieve a meaningful experience out of them. Much like the experiences that I retrieved when I read my first 6 Goosebumps books.

We must, then, be guardians of the game experience. The thing is, that it is not that easy. As Sylvester Tynan puts it in his book Designing Games: A Guide to Engineering Experiences, this communication between player and game creates events, which are the responses of the game during each particular gameplay session, these events trigger an experience, which is a set of emotions, thoughts and decisions inside the player's mind.

But beware, as Jesse Schell says in The Art of Game Design: A Book of Lenses the game is not the experience, the game enables the experience. So don't get confused, remember that we are not trying to answer what a game is, but why we play them.

How can we possibly ensure that the experience that each and every player has is the one that we want them to have? We can't, because we don't live inside the players' minds, and that is a sad truth that we must deal with as designers. We can, however, make our games adequate for a target audience and manipulate their experience by understanding how people react. We can make our games similar to the most manipulative girlfriend or boyfriend that anyone could ever have, anticipating the players' emotions and giving them tools (visual tools, musical tools, tools with rules) to experience what we want them to experience, and then step back and see them experience their own unique experience, and hope that it is as close as what we designed.

And we can only do that by asking the right question. If we are designing, for example, a Survival Horror game, would we be interested to know what a Survival Horror Game is, or Why would a player play our Survival Horror Game? If you guessed the second one, you were right. There are many additional questions, don't get me wrong, one key question would be: What kind of player will play my game?, but by asking Why would a player play our Survival Horror Game we will get answers such as: To feel scared, To live in an extreme world low on resources, To kill monsters. To save others from extreme, unknown danger.

And things like these are the real clues which will get us in the path of finding and molding the right game for our players.

domingo, 1 de febrero de 2015

Some games, some books, some movies, give each one of us experiences so deep that we feel change stirring deep inside us. For me, Valiant Hearts The Great War was a life-changing game.

We see war games all the time, the shooting, the missions, the rescuing, I like to call them games about the machanics of war. But, what if there was a more human game of war? What if there was a game that was not about the shooting, but about the dead, and the feelings? Valiant Hearts is such a game.

What is behind Valiant Hearts?

Valiant Hearts is brought to us by Ubisoft Montpellier, the responsibles for titles such as Rayman, ZombiU and Assassin's Creed Unity. The game is an attempt of making an indie game culture-wise that is not indie game by definition.

The game goes back to 1914, when the paths of Karl, deported to Germany and separated from her wife and son, Emile, Karl's father-in-law, Freddie, an American seeking revenge on the infamous Baron Von Dorf, Anna, a Belgian student looking for the kidnapped father, and Walt, a military Dog Medic, cross by fate in the hardships of war.

Having such a wide range of characters gives the designers the options to cover a wide variety of feelings, each of these characters represents a standard soldier with its virtues and flaws. Emile is the one at the service of the rest, giving everything up so that his companions may live and return home; Karl is deseperately trying to return home to his wife and child, apparently not really caring about the greater conflict of war in order to go home; Freddie is angry and wants revenge, having lost everything to war, his goal is to wipe the people reponsible for his disgraces from the face of the earth regardless of his safety; Anna is not trying to escape war, but joining it to protect her father, who was abducted by the German military; and Walt is the depiction of innocence, taking care of everyone no matter their aliegeance.

Valiant Hearts The Great War also relies on solid, historical facts, and goes as far as teaching the player about them all and showing true history lessons in the pause menu as the game progresses, the player can choose to read these or not, but they truly put the player in context.

The mechanics and ambient of feelings

Playing Valiant Hearts is a very insightful experience that, like all experiences, happens in the player's mind. The art is reminiscent of a gray, far-away time, the music and sound effects are all deeply melancholic, from the general's screams to Walt's barking, it completely surrounds the player in a deeply human, sad situation.

It is, all in all, an ambient game, ambient games are those who design the envoronment to generate particular feelings in a player, in Valiant Hearts, the feelings were of loss, sacrifice, horror, hope and melancholy.

The mechanics are also deeply inmersive, consisting of puzzles that the player has to think and solve, taking the time to check the scenary to look for clues to solve puzzles is exactly what is needed in terms of integrating mechanics to ambient scenarios.

Not everything in Valiant Hearts is perfect, some animations are untimed, or they overlap existing assets, for instance when Emile kneeled down to pat Walt, he would always stand in front of Walt when the patting animation kciked in even if he was previously standing behind it. In an asset intensive game where the players attention is completely absorbed into the environment and characters, this is an experience-breaking mistake.

Even more, there are a few experience-breaking C:\Users\mariateresa\Pictures\Uplay\Valiant Heartsugs easy to reproduce, Anna's parts are cloned and she gives medical aid to thin air, all in all it is a very unstable game in terms of bugs. But even so, it is still a wonderfully amazing game that I recommend to every fan of indie game and of meaningful experiences through games. It is also an example to follow in the matter of story telling, but that is content of another post.

A sad goodbye

It was one of those games that you both want and don't want to finish, I couldn't wipe off the feeling that I was slowly dying and being dragged into war if I kept playing, yet I couldn't not continue playing.

I stopped being myself, and I started being a desperate husband, a helpful father, a revengeful widow and a worried daughter, I cried and laughed and felt hopeless and hopeful.

jueves, 15 de enero de 2015

Today is Throwback Thursday and, like every Throwback Thursday from now on, it's Retrogaming Lesson day, because we must understand our past to better understand our future. Now I'm not saying that Retrogames are perfect, in fact, there are also tons of lessons that we can learn from past mistakes.

This is the first of a series of posts in which I'll be analyzing the lessons learned about First Time User Experience through level desgin in Megaman's levels. I have played almost every Megaman there is to play. They have a something, it's like a hook, a magnet. I love how difficult they are, I love how they make me feel, and I love it when I succeed in any task the game throws in my path.

It was only logical to start the Retrogaming lessons with good old Megaman and guess what: Megaman doesn't think you're stupid. Megaman challenges you every step of the way.

I believe that one of the problems of today's games are how they underestimate the player's brains and abilities. Think about it, any of those games feels the incoherent but very real need to tell you everything, and I mean everything. If they want you to press A to jump, they'll tell you at least the first 5 times, with pop ups, voice overs, images, diagrams, or, even worse, all of them.

It is also true that the gaming community has drastically grown to involve less experienced players, and that not all game are arcade platformers now a days, and each category has its own standards. So this should be taken with a grain of salt, but still, I believe that there is much to learn in the way the level teaches the user through the complete Megamanic experience.

What Cut-Man has to teach

This is an image of the Cut-Man level in Megaman. I will be analyzing this level exclusively through First Time User Experience, let's see how the steps, ladders, bumps and even enemies are teaching the player how to play.

When Megaman spawns the player can't advance any further if he doesn't, at least, climb the ladder on his left. This means that the player needs to:

Move Left

Fall off the platform that he's standing on

Move Up

These 3 simple actions are not casual, Megaman is trapped in there for a reason, Cut-Man is teaching the player how to move without actually saying it, it is instinct that tells the player that he should use the D-Pad for simple movement (this includes climbing ladders) and he learns it in the first second of gameplay or so, and it's internally rewarding and gratifying because there is a small sense of discovery and self accomplishment attached to all this.

In his book Designing Games: A Guide to Engineering Experiences, Sylvester Tynan depicts games as sparks of sensations in players, he says that each game will cause emotion if it changes a human value in the player. A human value is a condition that can change between states, and for it to be significant it has to mean something to the player. There is a brief talk about human values in my article: Distilling Game Design, you can check it for further enlightment, although I really recommend reading Sylvester Tynan's book. The human values that constantly shift through this stage are the ones related to learning instructions and abilities. The player goes from ignorance to knowledge to ignorance again, and from unskilled to skilled to unskilled again. Taking a closer look:

The player is both unskilled and ignorant when Megaman spawns in the level, as soon as he moves left, Megaman falls of the patform, here both values have shifted to knowledge and skilled again, only to go back to ignorance and unskilled when Megaman faces the ladder again. This process happens with every game we play, the thing is, that some games just ruin the discovery and surprise factor attached to it, it is not the same discovering a combo for a fighting game and doing it, than doing it because you've read it somewhere. The first one is much more challenging, thus much more rewarding.

There is one additional thing that these few seconds of gameplay have to teach Mr. Player: Megaman won't be hurt when he falls (at least from such a short distance, and the player can deduct that it applies to all heights), this is obvious right? Wrong!

The players are not only players, they are humans who live in this world, and are ruled by the laws of physics, every game has to teach the player that it has its own very own, special rules of physics, and this may seem intuitive now, but back when Megaman was published in 1987, many of the players who played it were new to gaming.

Once the player climbs the ladder he is faced with a step, this is not a coincidence, the 3 basic mechanics in megaman are: moving, jumping and shooting, and in the first 2 seconds of gameplay the level is taking care of teaching the player all of these.

When the player finds out how to jump, it will not be enough, because in order to overcome such a tedious obstacle, he needs to jump and move to the right mid-jump, this is easy enough for almost every human brain and the player should have no trouble overcoming it.

After the player has jumped and if he waits long enough, some Blader will come along ready to kill and the player will have to shoot them, thus learning to shoot, if he doesn't wait long enough, they will appear in the next second of gameplay so he will have to learn this anyways.

Look at everything that Cut-Man has taught us so far, and we're under 5 seconds of gameplay for sure. All of the above is learnt by the player without him even knowing that he is learning it. By Megaman dying once and once again the player is learning how to overcome one specific obstacle or enemy, without the need of an interrumptive tutorial.

The player feels that sense of self accomplishment when he beats this level not only because it is hard, but because deep down he understands that he had to learn all of this to overcome it.

The player also learns about enemies behaviours by observing, for instance a flying shell, which will hide for an instant, and get out of hiding to shoot at the next moment. The first flying shell will appear above a platform, which means that the player will be at a lower level, unharmed, watching the enmy behaviour, inmediately understanding a pattern and getting ready to solve it.

Pattern is also a very important word in this kind of games, every enemy must behave in the same way so that whatever the player learns when encoutering the first enemy can be applied when encountering the second, third, forth and so on enemies of the same type. Imaging how difficult math class would have been in 2+2 always had a different result!

The game is also forgiving when introducing hazards, when the player is facing the first pitch it is very easy to guess that what may happen to Megaman if he falls is no good, this is because the pitch has no floor and this physic law is very similar to our real world's law: if you see no floor, that's no good!

Even more, Megaman doesn't even need to jump to get over this first pitch, all he has to do is keep walking, the level is designed so that the platform on the left side of the pitch is tall enough to make the player fall to safety if he just keeps walking to the right. What a brilliant and simple way to introduce hazards!

Next #ThrowbackThursday

Next #TBT we will continue taking a look at Megaman's First Time User Experience through level design. We have a few more examples to look at with some new mechanics. In our next Megaman's #TBT editions we will also analyze enemy designs and boss design.

martes, 30 de diciembre de 2014

So, you want to be a Game Tester? Or perhaps you are already one, but want to share your experiences and see others'? Game Testing is a perfect way of entering the Game Industry. Being "paid to play games" is every child's dream.

This is my second #TestingTuesday post, a continuation to the guide Game Testing 101. Every #TestingTuesday I will write a Game Testing 101 article to complete the Game Testing 101 series.

A walk in the past

Last Testing Tuesday highlights:

Game Testing is methodical attention to detail applied to finding mistakes and incoherence in a game.

A videogame has many stages, and the testing must correspond to the current stage of the game. In the Pre-Alpha phase the basic game architecture is programmed, not much experience-oriented testing is needed, however technical testing is needed. In the Alpha stage experience-oriented testing is normal in terms of game mechanics and basic game elements. The Beta phase, in which every feature is included in the game, is the most testing-intensive phase, both user-experience oriented testing and technical testing.

While it is true that every game is different, giving some structure to testing maximizes the results, with this purpose we should guide our testing with some specific categories:

How to Report

There are many software in which bugs can be tracked and reported, from a self-made google sheet to most complete software such as Bugzilla or Mantis. The main advantage that I have detected in using these tools is that they ease the communication with the rest of the team by sending emails when an issue is assigned to them and when specific actions are made on that bug issue.

More important than what software to use is what we should say about each bug. While some fields of a report may vary in each company or project, there are some other fields that we should always strive to keep in our reports so that the team for which the report is directed receives as much information as possible without having to write a long text per each issue.

For example purposes we will be reporting a game crash in the pause menu in level 3 o an imaginary game. A game crash means that the game has become unresponsive and has frozen, stopping further gameplay to occur normally.

Summary: this is the news headline, we need to give as much information as possible in just a few words, it is different to say: "There was a baseball game last night" than to say "The Yankees beat Red Sox 4-2" In our game crashing bug, we should report: Game doesn't load in Internet Explorer.

Description: A 1 paragraph description of the bug. We should only describe what is happening. For our game crashing bug: When trying to load game in Internet Explorer 11.0.1 in Windows 8.1 the game is stuck in the loading screen at about 50%. Nothing else happens. Browser doesn't crash.

How to Reproduce: A step-by-step guide about how to reproduce the bug, we should be careful about the level of obviousness that we handle in this piece of information, we don't want to be too obvious or too careless. If the programmers needs to enter the pause screen in level 3 and press 2 simultaneous buttons in the controller to activate the crash, we should make emphasis in the bit corresponding the pause menu in level 3. So for example:

Step 1: Open the game normally.

Step 2: Play normally until level 3 is reached.

Step 3: Midway through level 3, press Pause to Pause the Game.

Step 4: Press buttons X and A at the same time and observe. Game crashes.

Additional Information: Any additional information should be given at this point, browsers, controllers, specific characters that trigger the bugs, and so on. For our game crashing bug, we could, for example, write: See references (2 attached images of the state before and after the crash), happens with both Xbox One and PS4 controllers in both Xbox One and PS4.

Expected Behavior: When a bug happens is because something is not behaving as it should, and if the tester detects it is because he has, consciously or not, compared the game against an improved version of the game that exists in the tester head. This field is to be filled with the behavior of this improved version. In our pause crashing bug, the expected behavior is: Game should not crash in pause.

Platform: This field should be filled with all the information of the platforms in which the bug happens, browser versions, operating systems, consoles, mobile devices, browsers in mobile devices, specific controls, specific brand of keyboard and devices, and so on.

Assignee: This field should be filled with the name of the team member who is responsible of the solution of this bug at the moment, for example if it is an art related bug, the immediate assignee is the artist, but when the artist has done his job as expected, the assignee should change to the programmer who will implement this change.

ID: A unique identification number.

Attachments: All the images, videos, screenshots, sounds or any other related media files that support the bug description and that are mentioned in the "Additional Information" field. The naming of all these should be obvious.

Frequency: This refers to the reproducibility of the bug, a crash may happen all the times, some times, 50% of the time, only once or the tester can simply not know. Either way, this field should be filled with the frequency of the reproducibility. For small games, it is ok to test 10 times to measure this frequency. For bigger games, 100 times is recommended.

Severity: This field refers to the importance that this bug represents to the end user, for instance a crash that is reproduced 50% of the times or more has a very high severity, but a small pixelation in a button has a low severity.

Priority: The priority represents the immediate importance of the bug fix. It is important not to confuse it with severity, a grammar bug has a high severity always, but it doesn't have a high priority in the pre-Alpha and Alpha phases, in which final text are yet to be defined and most of the game functionality is being implemented.

Testing Methods

We now know about what to test and how to report, it is time to learn a bit about how to test. A clean testing method will give us more results in less time. It is very easy to lose sight of bugs in big games, or when testing for hours in one sitting, and one person can only see so much. The following methods serve as guidelines to test each of the categories.

Smoke Testing

It is the first test that should be done and it is the first test that is usually done, consciously or not. Smoke testing is in many cases automatized, but some manual smoke testing is always needed.

When smoke testing, the tester needs to verify that the game is not crashing, the screen flow is correct and that no crashes occur. Smoke testing can block the rest of the testing, and this is why it must be done first, even if it is a fast run of the game, if smoke testing is not properly done we can encounter, for instance, a crash in level 1 will logically bock the testing of further level.

Even if we have tested the game 100 times and it is ready to deliver, we should always smoke test to make sure that everything is running as it should be.

Soak Testing

Soak Testing is very simple to do and it can detect problems in saving data and memory leak. In order to soak test, we should leave the game running in a specific device, platform or console for long periods of time in a critical screen, for instance in the pause screen for 8 hours, and go back to it to observe the game behavior, if the game performance is slow, if the level continues where it has left off, with the same amount of coins, lives, ammo, if the enemies are spawning correctly and so on.

Specifically, if the game performance as been affected, it could be a sign of memory leak, this means that some trash data is not being properly destroyed and it is being constantly stored in the device, the longer the game is running, the more amount of data that it is stored in the device.

Play it Right

This means to play the game as the game developers intend the players to play, if the game is a platformer scrolling from right to left (meaning that the player moves left to right), then we move left to right. If the player is supposed to press only one button at a time, then the tester presses only one button at a time.

Play it Wrong

In Play it Wrong, the tester job is to play the game in a completely opposite way to what was designed, if it was designed so that the character moves from left to right, we should move from right to left, we should press all the buttons at the same time, try to go through walls or jump a hundred times in a row.

Sometimes I like to pretend that I'm a hyperactive toddler fiddling with controller to Play the Game Wrong, this has given me amazing results in finding bugs that are difficult to find but common to reproduce in gameplay.

Upcoming in the Next #TestingTuesday

Now that we know how to report and how to test, we will go deeper into each of the testing categories.

In the next #TestdayTuesday we will be seeing what does gameplay mean, what does it mean to test gameplay and how it is related to the player's psychology.

domingo, 14 de diciembre de 2014

I've been a Nintendo
Fangirl since birth... Not a Nintendo Gamer, a Nintendo Fangirl. The obnoxious
brat type who would say that Nintendo would top at gaming because they focus in
experiences rather than graphics, technology, and the sorts.

I'm not quite that
Fangirl anymore, as it pains to admit it, I feel that Nintendo has disappointed
me more times than rewarded me, and that has began to take its toll on me.

I hadn't even confessed
it to myself, deep down I have a love for Nintendo that I believe it will be
difficult to beat, but there are at least 5 things that I have to admit are
going against Nintendo and are opening my mind to other alternatives:

No
Space for Competition

If a third party
developer, big or small, ventures to develop in Nintendo waters, they are faced
with a brutal and unfair competition against... Nintendo... And I mean, who can
compete against that? It sure leaves the rest in a disadvantage.

The strategy that most
of the Third Party developers and publishers have armed themselves with is to
try and not compete directly with Nintendo, by publishing titles of genres that
Nintendo has no plans to develop in the foreseeable future, and even so, they lose
in sales. For instance Ubisoft's ZombiU, widely advertised and only sold
740.000 physical copies, while New Super Mario Bors. U, released almost
simultaneously, sold 4.320.000 physical copies. I know that ZombiU is not the
best game ever and marketing can only do so much, but everything worsens when
you take a look at who you are competing with, even if it is in a totally
different genre. A game that can be considered direct competition, or almost
direct, is Epic Mickey 2: The Power of 2, who sold 160.000 physical copies, vs
Super Mario 3D World, which sold 2.390.000 physical copies.

Even more, what space do
Indie developers have, compared to other friendlier platforms such as Steam or Sony?

It's
always the same game, over and over again

Yes, I know, Mario is
Nintendo's iconic character and the games are tons of fun and yes, I can't wait
to get my hands on the new Zelda Game for Wii U. But it's always the same
games, with the same IP's, over and over again.

The Latest published new
IP that Nintendo presented us with is The Wonderful 101, and it didn't receive
as much attention from the people of Nintendo as, say, The Legend of Zelda:
Ocarina of Time for 3DS (a porting of an old game!!) So, even if there are new
IPs out there, Nintendo doesn't want to share the spotlight of their previous
classics.

Even more, in one of the
latest Nintendo Direct, the biggest news was: The Legend of Zelda: Majora's
Mask for 3DS, another port! I mean, it is a great game and all that, but they
should share the spotlight with new content instead of focusing on remakes of
old games, no matter how great they were.

The
Best-Sellers cost almost the same 2 years later

There are no significant
sales for Nintendo. New Super Mario Bros. U, who saw the light 2 years ago, cost
60 USD back then, now it can be bought in the Nintendo eshop for 60 USD! And in
Amazon for 47 USD,,, To make a comparison, Biosohck Infnite was released late
March 2013 and back then it cost 60 USD in Steam, right now it costs 22.5 USD,
this makes it very easy for non-early adopters to play a wide variety of games.

...And
they have paid DLCs

Paid DLCs are not new
and not Nintendo exclusive, but they make sense when the game price drops
quickly and the player can afford to buy both the game and the DLC, they also
make sense when a reasonably long period of time has passed since the game was
released, so the early adopter player can complete the game before the DLC
coming out, normally this time is enough for the original price to drop.

6 months after Mario
Kart 8 was released, 2 DLCs came out simultaneously, each one of them costing 8
USD, this doesn't make any sense to me for a 60 USD game, who still cost 60 USD
6 months after its release (even so, I still bought the 2 packs... shame on me)

They
seem to take advantage of their fans

All in all, they play
with the loyalty and nostalgia of their fans, knowing that they will buy the
Wii U even though it doesn't have enough games for a release (and it didn't
have enough games 6 months after the release), who will buy the same games over
and over again with hope in their eyes, who will buy the DLCs in pre sales,
just because it is Nintendo and boy, they do produce good games.

So everyday I'm less of a Nintendo
Fangirl, I bought everything over an over again, early adopter and all, but I'm
not so proud of it.

domingo, 7 de diciembre de 2014

As I was reading Designing Games: A Guide to Engineering Experiencees by Sylvester Tynan I came across an interesting concept in the chapter of Narrative in games. The term that Sylvester Tynan used to name this concept was Desk Jumping and it basically means interrupting the game's narrative with gameplay.

Understanding Agency as the player's power of choice in the game world, the Game Designer faces the challenge of telling a story with a breathing, thinking, decision making agent (a.k.a. player) willing to interrupt his every move if the story and / or gameplay allows it.

It is categorized as a potential hazard for game narrative if not treated right, for instance, in The Last of Us one plays Sarah, Joel's daughter, in the prologue of the game. After a series of happenings, Sarah is in a pick-up truck with her father and uncle while they are trying to run away from the city. In this ride, several events happen in the streets and the player can control the camera by pointing at the direction in which Sarah is looking at. One could choose not to look at anything, so the Game Designer needs to make sure that the events that are transpiring in the background while Sarah is in the pick-up truck are not crucial to the story, knowing that the player can simply choose to not look at it and spoil the whole thing.

Sylvester Tynan calls this concept Desk Jumping because in Deus Ex, where the player is a super spy working in a secret organization, besides doing everything related to his super secret missions, he can jump on the Boss' desk, looking funny and spoiling the atmosphere of the game. The player may find this humorous, and the player's motivation may be to create a comedic scenario, while the character's motivation would be to get information on a mission. Desk jumping happens when the player's motivations are different from the character's motivations.

Some game designers disable desk jumping, which integrated to the context of the game can work but it means giving the player limited control of his character in specific situations. Some game designers ignore it, hoping that by not encouraging it the player would get bored of doing it, and some game designers try to incorporate desk jumping as part of the gameplay and narrative.

Then there is Davey Wreden, developer of The Stanley Parable, who dealt with Desk Jumping integrating it to the gameplay so completely, that he made a whole game out of it. The Stanley Parable is a game about Desk Jumping that treats Agency issues like mechanics and adapts the complete story to these issues.

I've got the power

The Stanley Parable sets up a scenario where the player is completely free to choose whichevere path he wants, and this sense of freedom helps him immerse into the game and feel like his character, poor old Stanley, trapped in a lonely office with no idea of where did everyone go.

The immersion is so dynamic that Stanley's personality is drawn by the player's actions, not by a preset background story and character story. The player can do whatever he wishes, and the game will react to it in hilarious, mad ways.

In this case, Stanley's motivation is to get out of the office and solve the whole mystery of where did everyone go, while the player's motivation may vary from creating humour, to find every possible ending, to just curiosity in trying everything there is to try and seeing how the game reacts, or they can be aligned with Stanley's. Desk jumping is so expected, that there would be no game if it weren't for this.

What if... Scenarios

The way that the Game Designers accomplished a winning Desk Jumping mechanic was by tempting the player to challenge (or, better put, think that he's challenging) the Game Designer and look for alternative "What if" scenarios. The game is set up in an office, with a narrator explaining the context of the game and giving the player instructions. The office is empty and no one knows why, and Stanley needs to discover why and mainly just get out of there, Pretty simple.

The catch is that the narrator narrates everything, I mean EVERYTHING, if the player is faced with two doors, the narrator would say something along the lines of "Stanley went through the door on the right". This is far from innocent, this is said to create a story and at the same time to tempt the player to take the door on the left. Why would a narrator mandate where the player should go?

Even minor details are heavy with story content, I once entered a broom closet and stayed there for about 10 minutes and the results were completely hilarous, the narrator would say that Stanley went into a broom closet for no reason, that there was no Broom Closet ending that the player could tell his friends about, and lastly he was so annoyed that I hadn't left the broom closet that he said that the player must have died on his keyboard, and that this was the only logical explanation about he not getting out of the closet. The 4th wall in storytelling was completely broken and shattered to pieces and the results were amazingly good.

Story Evolution

The story evolves so naturally and organicly that it is next to impossible not to feel overpowered and humbled at the same time. The narrator makes the player understand that he has merely an illusion of control, that he may control the story but that Stanley's fate would only be in the hands of the narrator, he becomes sooner than later an all powerful Game God (pretty close to the definition of Game Designing).

The story is far from linear, it has many endings and some of them are even endings "in development" in which Staley gets to unfinished rooms. The choices that the player makes not only affect the story line, but the narrator's reaction to the story, the endings, and mostly everything that happens in between.

Having a reasonable small game world allowed the developers to record a narrator line and create and environment for every decision. The most curious and exploring player would naturally want to draw a diagram about which doors to go and paths to take to unlock every single ending.

The narrative feels naturally a part of gameplay, the controls are so simple that they enhance the feeling that this game is all about a sotry, or, better, about many stories. Moreover, every restart counts as a part of the same story, and the narrator will just skip parts on purpose with literally "Blah, blah, blah" dialogs because the player has been there in a previous spawn and knows that specific sequence by heart.

Bonus Points

Not only did the Game Designer integrate desk jumping to the narrative, but Steam achievements as well. Brilliantly, when the player tries to get an achievement the narrator (which, as I said before, feels like an overpowerful God) detects it and goes on an on about whether Stanley has done enough to deserve the achivement or not.

It is the cherry of a cocktail of brilliant story telling in games. By nature, games have a big drawback in story telling, which is that they are controlled by people with free will, but if the Game Designers integrate that free will into the main mechanic of the story, thus creating a dynamic narrative with very different conclussions that depend on the player's choice, we can all delight ourselves playing a true narrative masterpiece.