Designed for Windows Logo Program


"Designed for Windows" Logo Program

The logo program is an optional certification that allows you to affix the "Designed for Windows" logo on your box. This is much more important for kid's titles or other mass market games than hard core titles. The reason being that if my Mom were shopping for games and she had two essentially identical candidates in front of her, she'd probably choose the game that was designed for Windows.

There is an extensive feature checklist that your game must pass to be eligible for the logo program. While most of the list is a no-brainer, there are a few line items that will make you go "You're kidding, right?" The entire testing document with details of all the test cases is up on MSDN (www.microsoft.com/winlogo/). It's a whopping 105 pages long. I briefly thought about including it in this book in the hopes my editor wouldn't notice the extra pages, but in the end a summary of the checklist and a discussion of the tricky items seemed more appropriate.

The numbers designation "T#.#" is Microsoft's code for tests related to a general test requirement, and "TC#.#.#" denotes a specific test case.

There are tests for general compliancy as well as tests specific to games. We'll cover the tests for all Windows applications first:

T1.1

Perform primary functionality and maintain stability

TC1.1.1

Does the application perform its primary functions and maintain stability during functionality testing?

  • Pass The application performed all its primary functions and did not crash, stop responding, or lose data.

  • Fail The application failed to perform one or more primary functions, or it crashed, stopped responding, or lost data.

TC1.1.2

Does the application remain stable when a mouse with more than three buttons was used?

  • Pass The application did not crash, stop responding, or lose data.

  • Fail The application crashed, stopped responding, or lost data as a result of executing the test for at least one mouse button.

TC1.1.3

Does the application use the user's temporary folder for temporary files?

TC1.1.3.1

Does the application store its temporary files only in the user's temporary folder during installation?

  • Pass No temporary folder was created and no temporary files were stored in the wrong places.

  • Fail One or more new temporary folders were created or one or more temporary files were stored in the wrong places. Record the full paths for the folders and files.

TC1.1.3.2

Does the application store its temporary files only in the user's temporary folder during functionality testing?

  • Pass No temporary folder was created and no temporary files were stored in the wrong places.

  • Fail One or more new temporary folders were created or one or more temporary files were stored in the wrong places. Record the full paths for the folders and files.

TC1.1.4

Does the application not crash or lose data when presented with long path, file and printer names?

TC1.1.4.1

Does the application maintain stability when a file is saved by drilling down through the "User1 LFNPath1" path in User1's "My Documents" folder?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

TC1.1.4.2

Does the application maintain stability when a file is saved by entering the full "User1 LFNPath2" path?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

TC1.1.4.3

Does the application maintain stability when a file is saved using a long file name?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

TC1.1.4.4

Does the application maintain stability when a file is opened by drilling down through the "User1 LFNPath1" path in User1's "My Documents" folder?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

TC1.1.4.5

Does the application maintain stability when a file is opened by entering the full "User1 LFNPath2" path?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

TC1.1.4.6

Does the application maintain stability when a file is opened using a long file name?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

TC1.1.4.7

Does the application maintain stability when printing to a printer with a long name?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

  • The application does not have a "print hard copy" feature. This is not a failure, but it is also very unusual. Make sure there is no printing functionality in any part of your application before you check this option.

TC1.1.5

Does the application perform primary functionality and maintain stability on a dual-processor computer?

TC1.1.6

Does the application not crash when devices it uses are not installed?

TC1.1.6.1

Does the application maintain stability when printing if no printer is installed?

  • Pass The application did not crash or lose the test document data.

  • Fail The application crashed or lost the test document data.

  • The application does not have a "print hard copy" feature. This is not a failure, but it is also very unusual. Make sure there is no printing functionality in any part of your application before you check this option.

TC1.1.6.2

Does the application maintain stability when attempting to use devices that are not installed?

  • Pass The application did not crash.

  • Fail The application crashed upon attempting to use one or more devices that were not installed. Record the names of the devices.

TC1.1.7

Does the application switch the system's display mode back to the previous color mode, if application automatically changes to 256-color mode when it runs?

  • Pass The system color quality setting was the same after the application closed as it was before the application was started.

  • Fail The system color quality setting was "256 colors" after the application was closed.

One of the first tests to raise your eyebrows is TC1.1.3, where your game should locate temporary files. This is where your registry key, discussed a few pages back, comes in handy. Use the Win32 GetTempPath() API to get the root of the temporary directory, and add your registry key to create a unique space within the temporary directory to create your files.

Since your registry key is probably a few slashes deep, you'll need a function to parse through the path name and make sure the directory tree exists. Here's a function that starts at the temporary directory and creates the directory tree:

 void MakeTempDirectory(CString &tempDirectory) {   TCHAR buffer[MAX_PATH];   GetTempPath(MAX_PATH, buffer);   CString tempDirectory = buffer;   tempDirectory += "\\";   tempDirectory += GAME_APP_DIRECTORY;   if (0xffffffff == GetFileAttributes(tempDirectory))   {     // Ok - we have to go make a new directory to store temporary data.     CString current = buffer;     CString myAppData = GAME_APP_DIRECTORY;     CString token;     do {       int left = myAppData.Find('\\');       if (left==-1)       {         token = myAppData;         myAppData = _T("");       }       else          {            assert(myAppData.GetLength()>=left);            token = myAppData.Left(left);            myAppData = myAppData.Right(myAppData.GetLength()-(left+1));          }          if (token.GetLength())          {            current += "\\";            current += token;            if (false == CreateDirectory(current, NULL))            {              int error = GetLastError();              if (error != ERROR_ALREADY_EXISTS)              {                      return false;              }            }          }       } while (myAppData.GetLength());   }   tempDirectory += _T("\\"); } 

The next set of tests, TC1.1.4 concern long file and printer names. Don't let this test fool you into thinking that you can get rid of 8.3 filenames in your application. It turns out that there are some older CD-ROM drivers that still cannot handle long files names on the CD. This is likely going to go away in 2003 or 2004 completely, and is probably already such a small percentage you don't have to be overly concerned. Still, it's a good thing to know.

Best Practice

If you're curious about long file name compatibility and you don't have a huge budget for doing hardware surveys, take a look at CD's coming out of Microsoft. When they start using long filenames on their CDs and DVDs it's probably safe for you to do so.

Test TC1.1.5 is a serious concern for games, since games are usually multithreaded applications. If you ever thought that debugging multithreaded apps on a single processor computer was tough, try it on a multi-processor box. Check the Debugging chapter for more tips on finding nasty bugs like that.

Test TC1.1.6 is also a concern for games. Your game must fail elegantly if it doesn't find the joystick, mouse, or sound card that it needs. Users can easily disable hardware with the device settings dialog box, which is effectively the same thing as physically removing the hardware.

TC1.1.7 is handled by DirectX if you use it. If you use another graphics API you should always restore the player's display to the setting your game detected when it started.

T1.2

Any kernel-mode drivers that the application installs must pass verification testing on Windows†XP

TC1.2.1

Do all related kernel-mode drivers pass testing as Windows†XP loaded them?

  • Pass All kernel-mode drivers passed initial load tests.

  • Fail At least one kernel-mode driver failed initial load tests.

  • The application does not install kernel-mode drivers. This is not a failure.

TC1.2.2

Do all related kernel-mode drivers pass functionality testing with standard kernel testing enabled?

  • Pass All kernel-mode drivers passed verifications during functionality testing.

  • Fail At least one kernel-mode driver failed verifications during functionality testing.

  • The application does not install kernel-mode drivers. This is not a failure.

TC1.2.3

Do all related kernel-mode drivers pass low-resources simulation testing?

  • Pass All kernel-mode drivers passed verifications during low-resources testing.

  • Fail At least one kernel-mode driver failed verifications during low-resources testing.

  • The application does not install kernel mode drivers. This is not a failure.

T1.3

Any device or filter drivers included with the application must pass Windows HCT testing

TC1.3.1

Are proofs of WHQL testing attached to the submission for all required drivers?

  • Pass All device and filter drivers have been tested by WHQL.

  • Fail At least one device and filter driver has been tested by WHQL

  • The application does not install drivers that require WHQL testing. This is not a failure.

TC1.3.2

Do no warnings appear about unsigned drivers during testing?

  • Pass No unsigned driver warnings appeared during any testing.

  • Fail At least one unsigned driver warning appeared during any testing. Record the name of the driver.

I don't know about you, but I've never written a kernel-mode driver or device driver and don't intend to. Most, if not all, games fall in this category so we don't have to worry about T1.2 and T1.3.

T1.4

Perform Windows version checking correctly

TC1.4.1

Does the application install correctly under current and future versions of Windows?

  • Pass The application successfully installed on the future version of Windows, or it appropriately blocked the installation without hanging, crashing or losing data.

  • Fail The application displayed an inappropriate version error message, hung, crashed or lost data during the installation.

TC1.4.2

Does the application perform all functionality tests correctly under current and future versions of Windows?

  • Pass The application passed all functionality tests on the future version of Windows, or it appropriately blocked some or all tests without hanging, crashing or losing data.

  • Fail The application displayed an inappropriate version error message, hung, crashed or lost data during functionality testing.

  • The application blocks functionality for future versions as documented. This is not a failure.

Test T1.4 is absolutely hilarious. How in the name of Albert Einstein can I know if my game will properly install and function under all future versions of Windows? Actually, this is probably concerning any Windows operating system currently in beta test, and has little or nothing to do with Windows 3000.

T1.5

Support Fast User Switching

TC1.5.1

Does the application properly support Fast User Switching?

  • Pass The application passed all CVTs as User2; or the application blocked User2 from starting the application; or the application blocked User2 from executing specific functionality.

  • Fail The application failed some functionality testing, or incorrectly blocked User2 from starting the application.

TC1.5.2

Does the application properly support Remote Desktop?

  • Pass The application passes all CVTs as the remote desktop user, or the application blocked the remote desktop user from starting the application; or the application blocked the remote desktop user from executing specific functionality

  • Fail The application failed some functionality testing, or incorrectly blocked the remote desktop user from starting the application

TC1.5.3

If the application installs a replacement GINA, does the GINA propely support Remote Desktop?

  • Pass The replacement GINA adheres to the current Winlogon APIs and functions properly.

  • Fail The replacement GINA does not adhere to the current Winlogon APIs or does not function properly.

Fast user task switching is a serious concern for games. There are two things your game should be able to do to support fast user task switching: run minimized and run multiple copies of itself. The last one might seem weird, since most games detect their own window and simply bring themselves to the front. I'm talking about opening game files in a read-only sharable mode so that two users on the same box can open your game without a weird file sharing failure.

If your game stores user save game files in the users Application Data directory, required by test T3.1, you should be fine.

T1.6

Support new visual styles

TC1.6

Does the application pass all functionality tests with a Windows†XP theme applied?

  • Pass The application did not lose functionality or usability when one of the new visual styles was selected.

  • Fail The application lost some functionality or usability when one of the new visual styles was selected.

This is one place games get special dispensation from adhering with logo compliance: Games write their own interface that has nothing to do with Windows styles or themes. You can ignore this rule to the extent that you don't provide Windows-looking components that are deceiving, such as an "X" button in the upper right hand corner of your game that brings up a help window instead of closing your game.

T1.7

Support switching between tasks

TC1.7.1

Does the application display normally and not lose data when focus is switched among other applications with Alt+Tab?

  • Pass No data was lost when switching among applications and all applications displayed normally.

  • Fail Data was lost data switching among applications or some display irregularities appeared.

TC1.7.2

Does the application display normally and not lose data when Windows logo key and the taskbar are used to switch among applications?

  • Pass No data was lost when switching among applications and all applications displayed normally.

  • Fail Data was lost data switching among applications or some display irregularities appeared.

TC1.7.3

Does the Windows Security dialog box or the Task Manager display normally and can the application be cancelled or closed without losing data?

  • Pass Everything displayed normally and the application did not lose data when canceling the Windows Security dialog box or closing the Task Manager.

  • Fail Something displayed abnormally, or a dialog could not be closed, or the application could not be restored or lost data when canceling the Windows Security dialog box or closing the Task Manager.

This is where most games fall flat on their face, if they run in full-screen and windowed modes. It's critical to handle WM_ACTIVATE and check your DirectX surfaces for loss. If you do that correctly, your game will pass these tests.

T2.1

Do not attempt to replace files protected by Windows File Protection

TC2.1

Does the installation finish without any Windows File Protection messages appearing?

  • Pass The installation completed and no WFP dialogs appeared.

  • Fail At least one WFP dialog appeared during the installation. Write down the name of each file WFP had to replace. You may need to look in the System and Application logs using the Event Viewer to find the names of the files.

This install requirement is pretty easy to pass, just make sure that any special game DLLs don't collide with other DLLs in the Windows System32 directory.

T2.2

Migrate from earlier versions of Windows

TC2.2.1

Does the application successfully migrate from Windows†98 to Windows†XP Home Edition?

  • Pass The application migrated successfully.

  • Fail Migration was unsuccessful. Describe what went wrong.

TC2.2.2

Does the application successfully migrate from Windows†Me to Windows†XP Home Edition?

  • Pass The application migrated successfully.

  • Fail Migration was unsuccessful. Describe what went wrong.

TC2.2.3

Does the application successfully migrate from Windows†98 to Windows†XP Professional?

  • Pass The application migrated successfully.

  • Fail Migration was unsuccessful. Describe what went wrong.

TC2.2.4

Does the application successfully migrate from Windows†Me to Windows†XP Professional?

  • Pass The application migrated successfully.

  • Fail Migration was unsuccessful. Describe what went wrong.

TC2.2.5

Does the application successfully migrate from Windows†NT†4.0 Workstation to Windows†XP Professional?

  • Pass The application migrated successfully.

  • Fail Migration was unsuccessful. Describe what went wrong.

TC2.2.6

Does the application successfully migrate from Windows†2000 Professional to Windows†XP Professional?

  • Pass The application migrated successfully.

  • Fail Migration was unsuccessful. Describe what went wrong.

I don't know of any games that support migration. In fact there are plenty of legacy games that failed after Windows XP was installed due to the security measures on the Program Files directory.

T2.3

Do not overwrite non-proprietary files with older versions

TC2.3.1

Does the application not overwrite non-proprietary files with older versions?

  • Pass The application did not overwrite any non-proprietary files with older versions.

  • Fail At least one non-proprietary was overwritten with an older version. Record the file name and versions for each file.

TC2.3.2

Do all application executable files have file version, product name and company name information?

  • Pass All executable files the application installs have version number, product name and company name information.

  • Fail At least one executable file the application installs is missing version number, product name, or company name information. Record the names of the files that are missing information.

The take-away from this test is make sure all your game files have embedded version information. This is trivial for game EXEs and DLLs—just insert a version resource, and make sure your install program respects the old version by installing the new one in a parallel directory. It shouldn't just whack the old files. This is also handled if you use the registry key to locate your game in the Program Files directory. The two versions can safely coexist because they'll be installed in two different directories.

T2.4

Do not require a reboot inappropriately

TC2.4.1

Does the installation finish without requiring a reboot?

  • Pass During installation, the application did not require or suggest a reboot, or it prompted for a reboot and one or more reasons detailed in the Specification requirement 2.4 are documented.

  • Fail During installation, the application prompted for a reboot and no reasons are documented; or the reasons documented are not allowed by the Specification; or the application rebooted without giving the user the option to postpone the reboot (even if the documented reasons are allowed by the Specification).

TC2.4.2

Can all Test Framework testing be completed without application requiring a reboot?

  • Pass During functionality testing, the application did not require or suggest a reboot, or it prompted for a reboot and one or more reasons detailed in the Specification requirement 2.4 are documented.

  • Fail During functionality testing, the application prompted for a reboot and no reasons are documented; or the reasons documented are not allowed by the Specification; or the application rebooted without giving the user the option to postpone the reboot (even if the documented reasons are allowed by the Specification).

I know install programs love rebooting the machine, especially older install programs. If you use the most recent version of your installer, you should be fine.

T2.5

Install to Program Files by default

TC2.5

Does the application offer a default installation folder under "E:\ProgramFiles?"

  • Pass Both "E:" and "Program Files" appeared in the default installation path.

  • Fail "E:" and/or "Program Files" was missing from the default installation path. Write down the actual default path the application used or offered you.

Duh. That's pretty easy.

T2.6

Install any shared files that are not side-by-side to the correct locations

TC2.6

Does the application install shared files only to correct locations?

  • Pass Either all shared files are installed in the correct locations, or there are no shared files.

  • Fail At least one shared file was not stored in the correct location. Record the full path and name of each incorrectly installed file.

That test seems a little cryptic. Here are more details from the logo compliancy document, describing the location of shared files:

  • The file is located in "E:\Program Files\Common Files\<company name>"

  • The file is located in "E:\Program Files\<company name>\Shared Files"

  • The file is located in the system folder E:\Windows, or a subfolder of the system folder, and the file is documented as a service or driver. For example, a file with the extension SYS that is installed to the system32\drivers folder is clearly a driver and would need no other documentation.

  • The file is located in the system folder E:\Windows, or a subfolder of the system folder, and the file is documented as a DLL or OCX required for legacy software support or documented as shared with applications from other vendors.

  • The file is not a shared file.

The docs make it clear that shared files are files common to more than one application your company makes. This would be true for a common game engine DLL.

T2.7

Support Add or Remove Programs properly

TC2.7.1

Does installation add an uninstall to the Add or Remove Programs utility?

  • Pass The application added all the required information to the registry.

  • Fail Some required information is missing or appears to be incorrect.

TC2.7.2

Does uninstalling application as Owner remove and leave all the correct files and registry settings?

  • Pass The application removed and left all the correct files and registry settings.

  • Fail The application did not remove everything it should have (and there are no exemptions for the data), or the application removed user-created data without prompting the user for permission, or the application left user settings and preferences data without providing an option to completely remove them.

TC2.7.3

Does uninstalling application as User1 either degrade gracefully or both remove and leave all the correct files and registry settings?

  • Pass Either the application degraded gracefully (and did not allow User1 to uninstall it), or it both removed and left all the correct files and registry settings.

  • Fail The application failed to completely uninstall because User1 is a Limited User and the application did not degrade gracefully, or it did not remove everything it should have, or the application removed user-created data without prompting the user for permission, or the application left user settings and preferences data without providing an option to completely remove them.

TC2.7.4

Can the application be reinstalled after uninstalling it?

  • Pass The application can be installed without problems.

  • Fail The application could not be fully reinstalled, or Owner's preferences and settings were not fully retained.

T2.8

Support "All Users" installations

TC2.8.1

Does the application default to an "all users" installation or provide an "all users" installation as an option when installed by Owner?

  • Pass The application successfully installed using one of the accepted "all users" installation options.

  • Fail The application either could not be installed for all users, or it did not offer "all users" as the default option.

TC2.8.2

Does the application default to an "all users" installation or provide an "all users" installation as an option when installed by User1?

  • Pass Either User1 installed the application successfully for "all users" or the installer degraded gracefully and did not install any files on the system.

  • Fail Either User1 was able to install the application for User1 only, or the installation failed and did not degrade gracefully and/or installed some files on the system.

If you use the latest install programs you'll be automatically covered for T2.7 and T2.8.

T2.9

Support Autorun for CDs and DVDs

TC2.9.1

Does the application's installer start by way of Autorun?

  • Pass The application's installation started using Autorun.

  • Fail The application's installation did not start automatically.

  • The application is not installed from CD/DVD.

TC2.9.2

Does the application's installer correctly detect that application is already installed and avoid restarting the installation?

  • Pass The application's installer did not try to reinstall the application

  • Fail The application's installer restarted the installation process as if the application was not already installed.

  • The application is not installed from CD/DVD.

Autorun has been part of the operating system since Windows 95. If you're unsure about how to make this work, you can find it on MSDN. It's a relatively trivial matter to get autorun to work, but there is a nice trick you can employ: The Autorun should launch a program that detects if your game has already been installed. If it has, it should launch your game. Otherwise, it should launch your install program.

T3.1

Default to the correct location for storing user-created data

TC3.1.1

Does the application offer a correct location for opening User1's user-created data?

  • Pass The application uses a correct default location.

  • Fail The application used an incorrect default location. Record the full path the application used.

TC3.1.2

Does the application offer a correct location for saving User1's user-created data?

q

Pass The application uses a correct default location.

q

Fail The application used an incorrect default location. Record the full path the application used.

TC3.1.3

Does the application offer a correct location for opening User2's user-created data?

  • Pass The application uses a correct default location.

  • Fail The application used an incorrect default location. Record the full path the application used.

TC3.1.4

Does the application offer a correct location for saving User2's user-created data?

  • Pass The application uses a correct default location.

  • Fail The application used an incorrect default location. Record the full path the application used.

This is without a doubt the most significant change for Windows XP, because if your game ignores this requirement it will likely fail under Windows XP Home. There's a Win32 API that finds this directory for you:

 // set the players data directory TCHAR playerDataPath[MAX_PATH]; if (SHGetSpecialFolderPath(m_hWnd,playerDataPath,CSIDL_APPDATA, true))) {   // you've found the players data directory! } 

This call should be placed in your game initialization code after the main window has been created but before your first player data files are opened. These files aren't your game maps or sound files, rather they are your save game files or user options settings.

T3.2

Classify and store application data correctly

TC3.2.1

Does the application store less than 128K of application data in the registry for User1?

  • Pass The application saved less than 128K of application data in the registry.

  • Fail The application saved more than 128K of application data in the registry.

TC3.2.2

Does the application store configuration data for User1 only in acceptable folders?

  • Pass The application stored configuration data for User1 in acceptable folders (or stored no configuration data in folders).

  • Fail The application stored User1 configuration data in unacceptable locations. List the locations and file names.

That test seems pretty obvious. Clearly large save game files belong in the user's application data directory, not the registry.

T3.3

Deal gracefully with access-denied scenarios

TC3.3.1

Does the application prevent User1 from saving to the Windows system folder, E:\Windows?

  • Pass The application prevented User1 from saving the file with a meaningful message and did not hang, crash or lose the test document.

  • Fail The application allowed User1 to save the file, or it prevented the save but did not display meaningful message, or it hung, crashed or lost the test document.

TC3.3.2

Does the application prevent User1 from modifying documents owned by User2?

  • Pass The application prevented User1 from saving the file with a meaningful message and did not hang, crash or lose the test document.

  • Fail The application allowed User1 to save the file, or it prevented the save but did not display meaningful message, or it hung, crashed or lost the test document.

TC3.3.3

Does the application prevent User1 from modifying system-wide settings?

  • Pass The application prevented User1 from making system-wide changes.

  • Fail The application allowed User1 to system settings changes that User1 was blocked from making from outside the application.

  • Does not apply. The application has no functionality that allows users to make system settings changes.

TC3.3.4

Does the application's installer either allow User1 to install application or degrade gracefully if the installation fails?

  • Pass Either User1 was able to install the application, or the application gave User1 an appropriate dialog and degraded gracefully.

  • Fail The application either failed to install so CVTs failed, or the application did not degrade gracefully.

T3.4

Support running as a Limited User

TC3.4

Does the application support running as User1, a Limited User?

  • Pass All primary function tests succeeded with User1 running the application.

  • Fail One or more primary functions failed with User1 running the application, and the failure was caused by insufficient privileges.

Tests T3.3 and T3.4 are all related to access-denied situations where your install program or your game is attempting to do something it shouldn't. An interesting "ahh-ha" in T3.4 is found when you recall that most programmers run their computers as an administrator or debugger user, which has much broader access rights as other users. When your game has one of those, "It crashes in QA but is completely "unreproducable" on the programmer's machine." For problems like this, you should look closely at the user access rights.

"Optimized for Games"

The tests for games cover additional install criteria as well as tests for audio, video and network support. If you look on MSDN, you'll find a vague reference to the tests that Microsoft will expect your game to pass, but absolutely no details. Since I worked with Microsoft, I had an early version of the test details, which I'll present here. Most of the tests are pretty self-explanatory, so if I have nothing to say about them I'll simply move on to something worth discussing. I hate it when books simply restate something to restate it. Again, I won't bother telling you something you already know.

S1.1

General Game Playing Experience

S1.1.1

The application should make sensible default choices for three-dimensional (3-D) device, resolution, and color depth without asking the user.

S1.1.2

The game should use LoadLibrary or CoCreateInstance to give itself the option of failing more gracefully instead of displaying the system "missing DLL" dialog box.

S1.1.3

If the game uses the LoadLibrary function to load any system components (that is, Microsoft Direct3D , Microsoft DirectInput , and so forth), do not hard-code paths.

S1.1.4

The game should perform its basic operational functions over at least four hours without any problems. The game must still function after crossing the date change barrier.

S1.1.5

If any system components that the game relies upon change then another first-run analysis of the computer should be performed. For example, when a new input device or display adapter is installed another analysis should be executed.

Test S1.1.1 deals with selecting the default game options based on the players computer and installed hardware. You would pass this test if you detected a multiple monitor setup and picked the best display for your game without asking the player. The last test, S1.1.5 is somewhat related: If the hardware configuration changes, your game should detect it, and fix the settings to make the best user experience possible. This means a player can go out and upgrade their box, maybe installing the latest video card from NVidia or something, and your game should notice the difference.

S1.1.2 and S1.1.3 are just common sense, really. I wonder why these tests are included in the games specific section and not included for the nominal logo tests ?

The test for stability over four hours, and over the date change is a good one, although I wonder if Sony and Nintendo have such lax requirements. Four hours isn't that long. I'd hate to buy a hard drive with a mean time between failure measured in the single digits, wouldn't you? If I were you, I'd take stability tests a lot longer than four hours.

S1.2

Do Not Install or Depend on 16-bit Files: The application should not crash or fail to execute on 32-bit edition Windows XP because of a dependency on 16-bit code. The application must not read install or depend on 16-bit files.

S1.3

Do not write to Config,sys, Autoexec.bat, Win.ini, or System.ini files: The application must not read from or write to Win.ini, System.ini, Autoexec.bat, or Config.sys on any Windows operating system.

Tests S1.2 and S1.3 make sure you've moved your game into the modern age. Back in the day game programmers had no problem putting crazy stuff into autoexec.bat, config.sys, and Windows INI files. If you are reading this and you have no idea what these files are, good for you. You're already ahead of the game. If your curious about them, find a computer museum and boot up a Windows 3.1 box.

S1.4

Provide both manual and automatic install options: Near the start of installation (after any option license agreement), provide the user with the option of selecting either Automatic or Manual installation. The Automatic installation will make as many logical choices as possible for the user. The Manual installation may take the user to another dialog box where the user can choose any number of installation types: custom, typical, minimal, and so on.

This is a really good idea, since many games have the possibility of installing different levels of game data on the player's hard drive, trading hard drive space for performance or level of detail in the game.

S1.5

Allow installation termination: The user should be able to cancel out of an installation at any time before the installation completes. For each dialog box of this install process, make sure that your application can stop the installation.

Again, another test that should probably be in the general tests for all applications, and not games. Still, this feature is a good common sense item to put in your install program.

S1.6

Running from CD or DVD

S1.6.1

If the game requires a CD or DVD for game play even with the game fully installed on the hard drive, launching the game from the Start menu\Games folder should display an "Insert CD or DVD" message if the CD or DVD is not in the drive. When the CD or DVD is inserted, then the game should continue to run without requiring the user to restart the game.

S1.6.2

The game must be able to be played on a different CD or DVD drive than the one from which it was installed.

S1.6.3

The game must work even in situations where Red Book audio is not available for a particular drive (for example, external drives).

Test S1.6.1 is satisfied by the code discussed in the WM_DEVICECHANGE section earlier in this chapter. S1.6.2 needs a little more work. Here's how to search the computer for the marker file:

 enum CDPOLL_ENUM {    POLL_SUCCESSFUL,    NO_CD_ROM_FOUND,    NO_CD_DRIVE_FOUND }; CDPOLL_ENUM PollForCD(const _TCHAR *markerFilePath) {   CDPOLL_ENUM       result = NO_CD_DRIVE_FOUND;   /* Assume failure. */   unsigned int      drive_type = DRIVE_UNKNOWN;   int               drive;   _TCHAR            path[_MAX_PATH];   _TCHAR            current_directory[_MAX_PATH];   FILE              *test_file = NULL;   int               Current_Drive_Index = 0;   /* Save current drive. */   GetCurrentDirectory( _MAX_PATH, current_directory );   Current_Drive_Index = _getdrive();   /* Set this to -1 for easy error checking. */   int iCDDriveIndex = -1;   /* If we can switch to the drive, it exists. */   for( drive = 3; drive <= 26; drive++ )   {     if( 0 == _chdrive( drive ) )     {        GetCurrentDirectory( _MAX_PATH, path );        drive_type = GetDriveType( path );        if( (drive_type == DRIVE_CDROM)        #ifdef _DEBUG        || (drive_type == DRIVE_FIXED)        || (drive_type == DRIVE_REMOVABLE)        || (drive_type == DRIVE_REMOTE)        #endif        )        {           iCDDriveIndex = drive;           /* Found the drive, now look for the CD-ROM. */           result = NO_CD_ROM_FOUND;           _TCHAR buffer[_MAX_PATH];           _tcscpy(buffer, path);           _tcscat(buffer, markerFilePath);           if (0 FFFFFFFF == GetFileAttributes(buffer))           {             int a = GetLastError();             result = NO_CD_ROM_FOUND;           }           else           {             result = POLL_SUCCESSFUL;             break;           }         }       }     }     /* Restore original drive.*/     _chdrive( Current_Drive_Index );     SetCurrentDirectory(current_directory);     if (result == POLL_SUCCESSFUL)     {       m_CDPath.Format(_T("%c:\\"), iCDDriveIndex + 'A' - 1);     } #ifdef _DEBUG   return POLL_SUCCESSFUL; #else   return result; #endif } 

You would call this code in a while loop, with a message box or some other game dialog:

 while (PollForCD(searchFile) != POLL_SUCCESSFUL) {   // Bring up a dialog box and ask the player to find their CD. } 

S1.7

Games must be rated: The game must be rated by and adhere to guidelines specified by the Entertainment Software Ratings Board (ESRB) if the game is to be distributed in North America and by the appropriate ratings for the country in which the game is distributed.

I often wonder what it would be like to play with a copy of Microsoft Word that had an ESRB rating for adults only. I would probably be less productive.

S1.8

3-D and Graphics Support

S1.8.1

If the game uses Direct3D, it should be the default method for displaying graphics.

S1.8.2

If the game employs 3-D graphics and runs in full-screen mode, all screen resolutions enabled in the game should be supported by the computer. If it runs in windowed mode, it should properly handle a range of resolutions. A friendly error dialog box must appear for any resolution that is not supported.

S1.8.3

The game must not rely on the presence of Microsoft DirectX color-keyed textures. Alpha channels and true-color textures are strongly preferred, and products must not crash simply because the hardware does not support the obsolete methods.

S1.8.4

The game must not rely on the presence of DirectX palette textures. Alpha channels and true-color textures are strongly preferred, and products must not crash simply because the hardware does not support the obsolete methods.

S1.8.5

The game must not use retained mode or the ramp-mode rasterizer.

S1.8.6

If the product employs 3-D graphics, it should support hardware acceleration.

S1.8.7

If the game supports 3-D graphics hardware acceleration then it must support cards from at least 2 chipset manufacturers.

S1.8.8

If the game uses Microsoft DirectDraw , it must not use device-independent bitmap (DIB) sections or other legacy methods.

S1.8.9

If the game changes the resolution or colors to play the game in full-screen mode, it must restore the original resolution and color depth when the game exits.

S1.8.10

The game must not rely on Hardware Cursor Support.

The first test in this and the next two test groups cracks me up. In order to get blessing from Microsoft you have to prefer Microsoft's technology. I'm not sure what I think about that exactly, but I'm not the one setting the rules.

Test S1.8.2 is directly related to the full-screen and windowed mode discussion at the beginning of this chapter.

Concerning S1.8.5, These old rasterizers refer to pre-DirectX 8 technologies. If the test was rewritten it would probably refer to the reference rasterizer, which is written to display accuracy instead of speed. This and the remaining tests fall into that "Duh, sure..." category.

S1.9

Audio Support

S1.9.1

If the game uses Microsoft DirectSound , it should be the default method for providing sound.

S1.9.2

The game should use the DirectSound API to handle all calls and not call the cards directly to use specific features of specific cards.

S1.9.3

On systems with more than two audio output channels, audio must emanate from appropriate speakers. For games that use 3-D audio, this means that sounds should pan around the listener using all available speakers. For games that do not use 3-D audio, audio may, but need not, emanate from the rear speakers.

S1.9.4

The game must not disturb volume settings. If the game can adjust its audio volume, settings must be unchanged on exiting the Windows Volume Control.

S1.9.5

If audio is not essential to the operation of the game, it must run on a computer without a sound card installed.

Again, tests S1.9.1 and S1.9.2 show a little chauvinism regarding other technologies, but that doesn't surprise anyone does it?

S1.10

Device Support

S1.10.1

If the game uses Directlnput, it should be the default method for input.

S1.10.2

The game must support game playing devices on more than ID1. Game playing devices on ID2 or higher must be supported.

S1.10.3

A method should be provided for the user to easily select which device he or she wants to use to play a game (that is, switching from one joystick to another or from a joystick to the keyboard and mouse).

S1.10.4

On platforms that support multiple keyboards, the game must work properly when there are two keyboards plugged into the system. Because the limitation on the number of keys pressed simultaneously is normally a hardware limitation, it can be overcome by using multiple keyboards. The game must not crash, stop responding, or lose data when multiple keyboards are used to cause more simultaneously pressed keys to be reported than would be possible with one keyboard.

S1.10.5

The game must not fail when used with mice with more than three-mouse buttons.

Test S1.10.4 implies that a platform with multiple keyboards exists. I haven't seen it, and even if I saw it I'm not sure I'd believe it. Perhaps I can have a different font setting for each keyboard? I guess it would be cool to have a machine with two different language keyboards; but alas I don't speak or read Japanese.

S1.11

Network Support

S1.11.1

If the game has an online component, it should recognize when it is in its offline state. For example, the game must not spend minutes trying to reach an unreachable master server.

S1.11.2

All non-working networking options should be detected and disabled from the list of choices presented to the user.

S1.11.3

During lengthy network transactions, the user should be able to cancel operations at any time.

Do you notice something missing from the network tests? DirectPlay! Again, that cracks me up. This is most likely due to the fact that there are a few networked-enabled Microsoft games that don't use DirectPlay. I won't point them out.




Game Coding Complete
Game Coding Complete
ISBN: 1932111751
EAN: 2147483647
Year: 2003
Pages: 139

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net