martes, 30 de diciembre de 2014

Game Testing 101: Reports and Methods



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:
    • Gameplay and Mechanics: The rules of the game.
    • Art: All visual-related items.
    • Interface: all first plane user communication items.
    • Music and Sound Effects: All sound-related items.
  • The complete article can be read here

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

Confessions of a Nintendo Fangirl



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

The Desk Jumping Parable: Narrative Lessons from The Stanley Parable



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. 

miércoles, 3 de diciembre de 2014

The Walking Dead gave me Goosebumps: A study of narrative in simple gameplay


Have you ever played a game that was so engaging that you forgot you even existed and drooled over it, not even noticing that they were telling you a story? Have you watched a movie, or read a book, so appealing that the hours passed by without you even noticing? 

Telltale's The Walking Dead is nothing like that. It is a futile attempt of both. I believe that The Walking Dead is an interesting experience that provides extensive evidence of everything that is wrong with narrative in videogames.

Mechanics

In The Walking Dead the player has a limited range of exploration, giving the character the power to choose between specific pre-set dialogs with characters, this will make the player feel like he has a control of the outcome of the game, when in reality all that the player can control is the character's emotions toward other characters and minor story twists, leaving the stoty linear with the begging, climax and closure of each chapter the same no matter what choices were made by the player.



Playing this game, for me, felt much like watching a very good episode of The Walking Dead, having annoying pauses where I was supposed to press buttons for the story to go on. 

When I was a child, I loved R.L. Stine's Goosebumps book series and my parents would go to any extent in buying me whatever special, weird collection there was of Goosebumps. There was one of these Special collections that I particularly loved which was called Give yourself Goosebumps.

In Give Yourself Goosebumps, the reader would read a few chapters and then be faced with a choice that would affect the story. If, for instance the character (which was intended to be the reader himself) was locked in a medieval castle with a madman who had an axe (Return to Terror Tower), the reader could choose if he wanted to go through a door or pick up a sword, the story and outcome would change with each reader choice, and there was one (or a few) combination(s) that could save the reader's character and get him out of the tower. The rest would end up killing him, slaving him, transforming him, turning him into a living dead, in other words: Game Over.



In many ways, the Give Yourself Goosebumps series is more than a game to me than The Walking Dead Game Series will ever hope to be. And I will explain why.

Narrative Structure

Even though games are considered to have non-linear stories (meaning that the events will not happen at the exact same time, the exact same way every time the player plays), the narrative itself can be linear. A game that has a story that never changes, no matter how many times we play it, has a linear narrative. The Last of Us, Super Mario Bros, Dead Space are examples of games that have linear narrative, no matter what the player does or how he does it, every time that the player talks about the story of the game he will do it in exactly the same way, because it remains exactly the same.

For games with linear narrative to be succesful they need to have a compelling gameplay. Monkey Island is a narrative based point and click adventure game with a linear narrative but an enganginly challenging gameplay. 



If the gameplay is not as interesting and the Game Designer feels the need to add a compelling story, it would be best is the narrative is non linear, meaning that no matters how the game can be played, it can be "won" or "lost" by having different endings, even having a few fun or crazy ones would be cool. The Stanley Parable explores this concept marvelously, having so many different endings (and only one that can be considered as a win for the character) makes the player forget the dullness hidden behind the game mechanics and creates a completely engaging experience (more on The Stanley Parable in an upcoming post).


In The Walking Dead game, the gameplay is mindless and dull, and the narrative is enjoyable, but slow and linear, the choices of the player don't seem to matter much when looking at the main narrative, so the player has a narrow control over every aspect of the game, including the fate of his character.

In Give Yourself Goosebumps, the gameplay is also mindless and dull (challenge-wise speaking of course, I love reading) the reader / player just has to read and make choices, however the narrative is interesting and completely engaging, taking the reader's choice into account in the story's events and having only one "winning" ending. The player is in complete control over what happens to his character.

Technically Speaking...

According to Raph Koster in his book A theory of fun for game design: "Playing a game is the act of solving statistically varied challenge situations presented by an opponent who may or may not be algorithmic within a framework that is a defined systemic model" This not only means that there are seemingly un-gamey things that aren't games, it also means that there are seemingly gamey things that aren't!


In The Walking Dead the Player:

Solves statistically challenge situations: however they aren't really varied, all important game challenges are moral ones, the player gets used to this and dismisses the "challenge-factor" quickly without a goal that can change depending on his challenge solving abilities. This means that it is fairly obvious to the player that whichever events he thinks that he can change when making decisions won't change, so that the player has no control over the main events of the game, which are narrative driven,

The challenges are presented by an opponent: The opponents are the story enhanced moral values (of the kind: Will you save a child or your grandfather? Will you shoot your loved friend or will you let her kill you all with her decisions?) and this is done wonderfully.

Is playing in a semi-systemic model: Let's understand first what a Systemic Model is. A Systemic Model is a fictional universe in which upon affecting its main components, the rest of the components are also affected, as a goup, as opposed to individually affecting each element without relating to the others. Considering that in The Walking Dead the main feature is the story, and considering that the choices the player makes won't affect the story outcome at all, but they will affect minor narratives inside the main storyline, it can be interpreted as if The Walking Dead is a semi-systemic model.



In Give Yourself Goosebumps, the reader:

Solves statistically varied challenge situatons: In this case the challenges affect the outcome of the story and the winning condition (non existent in The Walking Dead), and the reader has to analyze what possible outcomes may his decisions trigger.

The challenges are presented by an opponent: The opponent being the adverse environment in which the reader's character lives. 

Plays a systemic model: Being the character's fate the main element of the book, the character has complete control over said fate. The choices that the reader makes are completely related to the story's consequences. The complete story reacts as a group when each choice is made.

Games will be games

After this analysis and according to my perception of gaming, there is a jaw dropping conclusion:

Players who play The Walking Dead are not really playing a game, they are witnessing a story (like what we do when we watch a movie), and they aren't players, they are witnesses. 

Readers who read Give Yourself Goosebumps are also players who play a game. 


martes, 2 de diciembre de 2014

Game Testing 101: The Basics



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. 

Celebrating #TestingTuesday I will post, each Tuesday, a guide toTest Games, with the hopes that I can help others like me get in this beatuiful business and expand their careers towards the path of their choice.

Why me?

Who am I and why should you be taking advice from a random girl with a blog? I currently work at a growing videogame studio called TeravisionGames as QA Lead, I've been in this role for most part of the past 2 years.

During my adventures in the videogame industry I've been a programmer, an associate producer, a tester and a QA Lead. I've tried to find information everywhere about Game Testing but it has been either too advanced or too specific, so I have come to develop a guide for our testers which has worked very well and has given them fairly quickly a critical-testing eye.

So stick with me and I'll open your eyes to the wonders of game testing.

What's Testing?

Videogame testing is a very important part of the game development process, it is the component that analyzes whether the game is ready to be shipped or not. It provides the development process with a critical eye in constant search of mistakes, incosistencies, gameplay coherence and feature completness. Game Testing is methodical attention to detail applied to finding mistakes and incoherences in a game.

Without game testers, there would be a high probability that the end user (a.k.a. Mr. Player) would find himself buying a copy of Shadow of Mordor with a crash starting the game which would make the game close and stop working before the player's very eyes.


Preliminaries

The process of videogame production can be compared to the process of construction of a building. 

First, we have the blueprints which are designed by architects and supevised by engineers, this first constuction phase can be compared to the pre-Alpha, where the Game Designers build a Game Design Document (the blueprints of the game). Then everyone starts building the foundation, so that you can se the complete structure of the building, you know how tall is each floor, but you don't know what colors will the wall be, this is similar to the Alpha phase of the Game development process, in which you have a vertical slice of the game with the basic game mechanics, but you don't have every level of the game, or every character. After this the building may be completely built, appartments and all, but the final installations will surely be missing, there will be no doors, the kitchen may be halfway and everything is dirty, this is a Beta, a Beta is basically the most heavily testable game phase, in which all the features are in and some final polishing and debugging is in order. When the game is done and ready to be published it is called a Gold build.

As a tester, you need to know how to set up your testing environment to test the game in each of its stages, don't get ready to test final art in an Alpha release, instead focus on the mechanics (the rules of the game). You also need to set up your target platform(s): PS4, PS3, Nintendo, PC, Mac, Xbox, iPad, Samsung Galaxy S5, the list goes on and on. If a multiplayer testing is needed, you need to have the right amount of people, if a resolution testing is needed, you may need available resolution displays, and so on.

What should I Test?

Considering that each game is unique and its testing phases may vary, the testing reports can be enclosed in four big categories (we will be talking about each one of these categories in an upcoming post):

Gameplay and Mechanics: In this category, we basically need to test that every game rule (mechanic) is correctly implemented, every enemy, every level, every control movement or the difficulty (balancing).This includes every game behavior. 

If Mario should jumo when the user presses A (a game mechanic for Super Mario Bros), does it jump when I press A? What if I press B? What if I press A and B at the same time? Are the rules well implementes? Does it have the correct amount of levels? Are the enemies well balanced? This is such a broad category that it naturally splits into several subcategories, we will be looking at this in much more detail in an upcoming #TestingTuesday

Art: Basically in this category we need to test every art-related item. Whether if it is Visual FX, 3D models, environment, 2D art, everything needs to be in the game, with the correct resolution, in the correct place, and everything must maintain a similar art style.

 Are all the animations OK (not jumpy but fluid)? Is something or someone missing an animation? Are we having an excess of animations? Is the art coherent? Does it match the game IP? Are the 3D models within the correct triangle count? Are all the art assets in the correct resolution(s)? 

Interface: Game systems are a constant communication between Game and Player, if player does one thing, game reacts in such way. Without tis feedback, there would be no game at all, think of how unsatisfying it would be to kill an enemy and hit it multiple times and just watch him take the hits with no reaction, how would you know that you hurt him? The game is basically in need of an initerface. Interface is the language that we give to our game to talk with the player. Specially in consideration when testing Interface is the Heads-up display (HUD), all the elements that we need our game to show our player in a first plane (score, buttons, health...)

Are the buttons in the right size? Are the elements following the right hierarchy? Is the information show enough? Is the information showed too much? Do we need to add a pop up (for instance: No internet conection pop up).

Music and Sound FX: This category specifically relates to all in game music (such as environment music, songs that the character plays, character themes, and so on) and the SFX: Footsteps, explosions, gunshots, landing sound, wind sound, and so on.

Is all the music needed ingame? Are all the SFX needed implemented? Are there some SFX too much? Do the music and SFX have the correct level? Is the music and SFX consistent with the IP?

Upcoming in the Next #TestingTuesday

We learned the basics about a Game Development Porcess and saw an overview of the Game Testing categories. 

In the next #TestdayTuesday we will be seeing how we should test and report, different methods and process that will adapt to all games out there in any of their development phases and that will make our testing more efficient and our results more relevant.


lunes, 1 de diciembre de 2014

#Random Madness steam codes giveaway

This December brings laughter, joy, GamerGate debates and Madness.


Starting today and in random days of December I will be giving away 7 steam codes, just because. Buckle up!

The first Steam Code gift for Pixeljunk Shooter:



Enjoy! And Stay tuned for the next #RandomMadness giveaway within this week!

Follow me @The9BitGame