Game Standards | Game Testing All in One (Game Development Series)

Among its many responsibilities, the QA team should establish that the project work products follow the right formats. This includes assuring that the game complies with any standards that apply. User interface standards and coding standards are two kinds of standards applicable to game software.

User Interface Standards

User interface (UI) standards help players identify with your game title.

Following are some examples of user interface standards, which are derived from Rob Caminos' 2004 GDC presentation "Cross-Platform User Interface Development." As part of your Quality Assurance function you would examine relevant screens to confirm they had the properties and characteristics called for in the standards.

Text should be large and thick, even at the expense of creating an extra page of text.
Make all letter characters the same size .
Avoid using lowercase letters. Instead, user smaller versions of uppercase letters .
Use an outline for the font where possible.
On-screen keyboards should resemble the look of an actual keyboard.
On-screen keyboards should have the letters arranged alphabetically . Do not use the QWERTY arrangement.
Split alphabet, symbol, and accent characters into three separate on-screen keyboards.
Common functions such as Done, Space, Backspace, Caps Lock, and switching between character sets should be mapped to available buttons on the game controller.
Assign Space and Backspace keyboard functions to the left and right shoulder buttons.
Each menu should fit on one screen.
The cursor should blatantly draw attention to the currently selected menu item.
Avoid horizontal menus .
Vertical menus should consist of no more than 6 ‚ 8 items, each with its own button.
Menus should by cyclic, allowing the player to loop through the menu choices.
Leave breathing room for text localization. (Some languages, such as German, may require more letters per word than your game's native language.)
Place button icons next to their functions instead of using lines to connect the functions to the buttons.
Point button icons to their location on the controller.
Separate thumb-stick movement functions from button functions.

Additional standards could apply to consistent keyboard assignments ("F1 should always be the Help button") or the flexibility of game controller options ("There shall always be an option to enable or disable vibration ").

Your list of standards can be used as a checklist that gets filled out for each screen. The checklist should include other information such as the QA person's name, the date of the appraisal, the name of the software build and/or identifier being checked, and the name of the screen. Don't wait until the UI is coded and put into a release before you check it. Work with developers to verify that the standard is being followed in their UI design. Some checking should also take place after code is released to verify that the implementation matches the intent. This may include a suite of tests that specifically check that each UI standard is met.

You may find that some of these items above make perfect sense for your game, while some don't. Use what's right for you and your customers. The important thing is to have some standards, have a reason for including each item in the standard, and have a way to periodically check that the team uses the standard.

Coding Standards

Coding standards can prevent the introduction of defects when the game code is written. Some of the topics typically addressed by coding standards include

File naming conventions
Header files
Comment and indentation styles
Use of macros and constants
Use of global variables

To many critics , coding standards pay too much attention to the format of the code rather than its substance. On the other hand, there must be some reason why development tool companies continue to provide more and more coding assistance using visual means such as colors and graphs. Both have the same goal in mind: to help the developer get the code right the first time.

Even so, coding standards aren't just about formatting. Many of the rules are designed to address important issues such as portability, clarity, modularity, and reusability. The importance of these standards is magnified in a project that is distributed across different teams , sites, and countries . There are few things less fun than tracking down a defect caused by one team defining SUCCESS as 0 and another team defining SUCCESS as 1.

Here are some excerpts from the C Coding Standards for the Computer Associates Ingres ‚ project:

Do not use constants to check for machine dependent ranges or values. Use the symbolics instead (For example: UINT_MAX not 4294967295 ).
Constants must be properly typed to match their usage. For example, a constant 1 that will be passed to a procedure expecting a long must be defined as ((long)1) .
Do not use the literal zero as a NULL pointer value.
Use TYPEDEF , not #define , to declare new types.

As a tester, you should be aware that these standards also give clues as to how code will fail under certain situations. For example, if machine-dependent ranges are hardcoded, you will see the resulting failure on one type of machine but not on another. So, features that depend on values that could be machine dependent should be tested on different machines.

In a QA role, your responsibility is to check that the programmers have coding standards which they apply to their code. This is typically done by sampling files from the game code and doing a manual or automated check against the appropriate standards. If you are doing QA on behalf of a publisher or third-party QA group , you can still do this by gaining access to the programmer's standards, tools, and files. Alternatively, you could require the programming team to submit evidence, such as printouts, that they did this checking themselves .