Jakub Rogalski, Msci Creative Computing ma802jr, sourceforge username: cubeen

Nightmare Demo- “Rolling Riot” Project: QA Report.

As a member of the demo team I am in charge of Quality Assurance procedures. By its nature majority of work involved in creating a final quality assurance report takes place at the end of the game development cycle. Final stage of this process involves creating acceptance package for the client to establish whether implemented software meets desired goals ( as specified in the design documentation) as well as feature requests and necessary bug fixes ( as raised earlier in the previous QA testing cycles).

This report has been created in accordance with game design document and includes acceptance package as its integral part.

Acceptance package composes of the document that should act as a legal documentation of receiving/ rejecting implemented software by the client as well as a spreadsheet to be filled in by the client. Spreadsheet helps the client to establish if requested software features (agreed upon at the initial phase of ordering software, or in the previous QA sessions) and previously specified requests are present in the delivered product. Acceptance package is build based on the design documentation which should act as a primary point of reference (any subsequent requests should be reflected in the design document).

Bug Report SummaryAs “Rolling Riot” is a 3D platformer game, there are multiple characteristic feature for this type of games testers should pay attention to. The main issues with 3D platformers are player control, graphics, and camera. Player control is an extremely important feature requiring a lot of attention to detail as even minor bugs can significantly decrease game experience. Moving to 3D for this type of games means more complicated than the 2D background making it prone to many visual bugs such as z- fighting, missing textures, and screen tearing abound. Finally, the camera is also a crucial feature for this genre of games. It can never be allowed to interfere with gameplay. If players needs to constantly worry about this, they might give up playing altogether.

Audio bugs

It is easier to detect visual bugs than audio bugs, because it is easier to see discrepancies than to hear them. Audio bugs can therefore be more challenging to be tracked down.Audio bugs can range from volume differences to complete audio meltdowns. Examples of audio bugs include audio drops, skipping, distortion, missing sound effects, and volume level. Several missing sound effects have been found as well as missing music in the main game loop.

Visual bugs

No physics bug have been found. Game character is always in control, does not freeze. No crashes reported, screen does not go dark. No performance bugs found, frame rate acceptable giving smooth animation. Load time is quick and does not impede the gaming experience.

Main Menu

Sound effect for rolling a ball are present. Music in the background played in loop on the appropriate volume level.

Level Chooser Menu

At the time of testing only two levels have been implemented , therefore presence of remaining level buttons (level 3 – level 10 is somewhat questionable). Options and High Score buttons do not launch any screens and an audio effect for the button click is played in loop.

Main Gameplay

First thing noticeable when accessing gameplay loop is the lack of music. Actually all sound effect seem to be missing.User can navigate the sphere with no problem, as it is highly responsive to the key presses. There is however a problem with jump controls as the sphere would jump on every spacebar press even if already in the air (i.e. detached from the surface). This bug allows for placing game character in significant distance from the surface if spacebar is pressed multiple times in row. This bug is

considered high priority as it significantly impairs the control of the character and significantly decreases overall game experience.

In several locations camera does not cut through walls making it impossible for the player to see the character. This is considered a bug.

desired behaviour

Undesired behaviour- user unable to see what is behind a wall

Bug Categories

Low Priority Bugs

Low priority bugs are considered as almost unimportant. It might make no difference to the developer whether they are fixed or not. Examples of low bugs might be minor graphical glitches, a short intermittent sound distortion, some small error in the user interface or any bug that doesn't impact the flow or the reception of the game. Low bugs abound in every software. It is not uncommon for low bugs to be ignored in favour of more serious bugs as the tight schedule characteristic for computer games development might limit the time allotted to the development.

• Poor track graphics.

Medium Priority Bugs

Medium priority bugs should be fixed. They occur more often than low bugs and they are rather not intermittent. Some frequent low priority visual bugs could be “upgraded” to medium. Examples of medium priority bugs are the ones occurring on the title screen or bugs that would annoy a player, but not affect gameplay.

• walls blocking the view making it impossible to see a character in particular locations,• no music in the main gameplay loop ,• missing Options and High Score screens.

High Priority Bugs

High priority bugs require a necessary fix. A game that ships with high bugs is either a bad game or it has been rushed to market. High bugs seriously affect gameplay, making them annoying for a player and are therefore very noticeable (e.g. dropping frame rate, inability to complete the level etc.)

• missing power collectables,• ability for the character to bounce in the air.

Critical Bugs

Critical bugs, such as crashes, freezes, and data corruption demands immediate attention from the developers.

• after collecting all available collectables game does not proceed to the next level.

Group CollaborationAs “Rolling Riot” is a group project, it required a lot of communication between group members. My limited availability did not allow me to attend every meeting that took place, but efficient communication through Google Groups and Google Docs and Sourceforge repositories allowed for efficient communication between group members without being physically present at every meeting. I fairly enjoyed helping attitude of my group members, taking responsibility for the whole project as opposed to particular task assigned to themselves. Perhaps our meeting could have been more efficient, involving more practical activities to be performed (especially at the beginning of the development). Considering however the challenging task, lack of experience and expertise in the field as well as the fact that our work was dependant in a large scale on Engine team I feel like we did a good job.

BibliographyL. Nevy, J. Novak, Game Development Essentials. Game QA & Testing. Delmar Cengage Learning , New York 2010