USA Games News
http://www.usagames.us 3/3/2008 Introduction Greetings gamers, There is a lot going on here at USA Games Interactive. I can not begin to tell all of you how stressful and busy life has become for my wife and I over the last few weeks. Unfortunately, there have been several disruptions to our current game productions including a vicious hacker break in on the USA Games web server, and a grievous disagreement over the copyright issues over Montezuma's Return. As a result I am attempting to single-handedly get things straitened out. Which isn't an easy job considering both the web site and games need urgent attention as well as my daily duties as a husband, parent, contract developer, etc. Basically, a very busIn addition to the afore mentioned issues I've been strongly looking at taking USA Games in an entirely different direction development wise. There are a lot of different factors I need to look at before I eventually decide one way or the other where to go with our new development projects. One of the biggest questions I am personally dealing with is weather or not to remain with C# and use the XNA Framework, which is not very accessible, or move all our games to Java. Either way I do feel that a change in direction is necessary in order to stay on the cutting edge of software development. One final note before I get down to the real news I'd like to announce USA Games new developers initiative. On Feb. 22, 2008 USA Games officially launched http://developers.usagames.us which is a wiki specially setup and designed for those of you interested in learning how to program your own accessible games. As of the time of this writing there is still a lot of work that needs to be completed such as a frequently asked questions section, Getting Started Guide, and of course adding several tutorials and training materials to the web site to research. Obviously, as strapped as I am with everything else the site isn't going to be completed soon, but I do hope to have some definitive guides, tutorials, and articles for accessible game programming sometime in the future. Changes In Development In January 2007 Microsoft released its latest operating system, Windows Vista, with many new features, technologies, and has transformed the industry standards for how game programmers design games for the new Windows platform. In the past someone with a little C++ or Visual Basic know-how could create Windows games using the Win32 API as well as the DirectX SDK. In 2001 Microsoft introduced the .NET Framework for Windows developers. Sometime after that Microsoft released DirectX 9.0 with a new technology called Managed DirectX. Managed DirectX is an optional DirectX upgrade that allows C++ .NET, C# .NET, and Visual Basic .NET developers to add DirectX to games and other multimedia applications. In 2006 Microsoft announced they were going to release Managed DirectX 2, but later reversed their decision and canceled the release of Managed DirectX 2. Soon after releasing Windows Vista Microsoft announced the release of the XNA Framework. The XNA Framework is a new set of gaming libraries and APIs from Microsoft specially targeting new games for the XBox 360, Windows XP, and Windows Vista. Like managed DirectX XNA is based upon the .NET technology, and is specially designed for C# .NET game developers. That would be fine except for a big problem. I discovered in order to use the XNA technology in my future games I would have to pack my game sound files using a tool named Xact. As luck would have it Xact is very unaccessible with Jaws, Window Eyes, NVDA, or any other screen reader I have tried. To add insult to injury in August 2007 Microsoft announced in their DirectX release notes that Managed DirectX was to be phased out of the following DirectX SDK release. True to form the November DirectX SDK had no official support for .NET developers putting USA Games in a real bind. The situation is simply this. If USA Games is to continue using C# as our development language of choice we will either have to stick with the DirectX August 2007 release, find a way to work with Xact, or find some alternative language and APIs to use. Luckily, we are not without options and choices. Just a very time consuming issue when we are already behind on two games already. At the time being USA Games is looking at the possibility of moving all our source code to Java. While it would be a major undertaking there are several good reasons why USA Games is looking at switching. Those reasons will briefly be discussed below. First, Java is one of the most flexible, highly portable, platform independent languages used by programmers today. Since Java relies on its own libraries, shipped with the Sun Java runtime environment, a Java based game can potentially be created on Windows, but be made to run with very little to no modifications to support Mac, Linux, Sun Solaris, etc. It all depends on how many operating system specific dependencies the developer uses. Second, as of Java 1.4.x Sun has been adding more functionality to Java to handle the demands of commercial games. For example, the javax.sound package has been upgraded to allow for the playback, looping, mixing, panning, etc of game sounds. While not DirectX Sound quality it is a pretty good package if your needs aren't too advanced such as 3D audio. As for USA Games we are currently looking at a Java runtime update called java.media. The java.media package seams to have all the bells and whistles required to produce top-of-the-line 3D FPS shooters, racing games, etc. Another recent discovery is the JInput package. The JInput package is a nice game developers input package which allows a Java game developer to include keyboards, mice, game pads, and force feedback game controllers to any Java game. The advantage of this is that USA games doesn't have to worry about dropping support for racing wheels and other devices in games like Raceway if we decide to go Java. Finally, for years Java has been notorious for having accessibility issues with screen readers. A lot of this is because the swing toolkit requires the presents of an accessibility bridge, and of course the screen reader needs to support it as well. Miss anyone of those requirements and your Java application days are over. However, recently I have discovered an accessible alternative to swing. The Java Eclipse IDE, used for developing Java applications, offers an alternative toolkit called swt. What is nice about swt is that it wraps the native operating systems widget toolkit exposing the window elements in the operating systems native API. What this means in layman's speak is that swt will create a window with buttons, edit fields, check boxes, etc similar to ones created by traditional Windows applications written in Visual Basic or C++. Screen readers like Jaws, Window Eyes, NVDA, Hal, can read swt Java applications without requiring the Java access bridge which is a good thing. In addition, swt isn't limited to Win32 applications. It is also supported on Mac to wrap Mac's Cocoa graphical toolkit and Linux's GTK+2 toolkit. With swt I feel very sure USA Games can begin building Java based applications insuring maximum access out of the box. Another popular advantage of Java over other programming languages is that Java has been designed to prevent certain common programmer errors that all programmers make from time to time. For example, one very common error programmers make is failing to initialize variables as the create them. In many programming languages you can declare a variable like int myVariable; with no default values. As a result when the program is run there is a tendency to crash or run into some sort of runtime error. Java is different at minimum you must do something like int myVariable = 0; which sets the default for myVariable to 0 unless new values have been passed to it. This makes safer, cleaner, and more error free code. Java also includes what is known as the garbage collector. In languages such as Visual Basic 6 and C++ it is pretty much left up to the programmer to use good coding practices and clean up memory leaks, dispose of unwanted objects, and game performance is usually based on how well the game is written. In Java its garbage collector is like a built in vacuum cleaner. The garbage collector keeps track of what is in memory, and as soon as it sees something that is no longer of use to the program it removes it from memory. This is often helpful as it places the responsibility on the Java JRE rather than in the hands of the human programmer. Not to say that the human programmer has no control. There are ways to call the garbage collector manually in Java to clean up a huge section of code you just completed for especially time sensitive or memory critical point in your application. As a result with the garbage collector Java isn't usually prone to such bugs as memory leaks and waisted CPU power as is the case with many games written in C++ or Visual Basic 6. While Microsoft has done its best to mottle C# .NET and Visual Basic .NET after Java there are still a few things Java can do better than any of the .NET programs. One of these areas happens to be networking. Java was designed from the beginning to work as server side and client side applications communicating over large and small scale networks. What this means, surprise, Java is well suited to networked games with multiplayer game play in mind. Which is another advantage to think about when considering Java. With all the advantages and possibilities Java has to offer I am certain Java is where USA Games is heading. There are of course going to be issues getting our new games launched, but in the end it will probably be worth it. Mysteries Of The Aztecs Formerly Montezuma's Return Over the last couple of weeks or so some of you have been emailing our info address asking about Montezuma's Return now known as Mysteries of the Aztecs. Do to recent copyright legal issues USA Games can not and will not offer old downloads of Montezuma's Return Beta 9 and earlier. We formally request that others do not pass around and share old copies of the software either as it would be a violation of our agreement with the copyright holders. As a result USA Games is working on a replacement game with a similar theme called Mysteries Of the Aztecs. Mysteries Of The Aztecs is the first in a new line of games called Tomb Hunter featuring daring adventurer Angela Summers. For a description of the new game visit http://www.usagames.us/mota.php and read the Mysteries Of the Aztecs home page for an overview of the new game. First, many users have asked if their product keys for Montezuma's Return will work with Mysteries Of The Aztecs. Our answer is yes. Weather we stick with C# or move to Java we plan to use the exact same authorization system to make the new game backward compatible with registration keys purchased before the copyright issues came up. The internal way that it works might be different, but your keys should still work. Second, a few have asked about refunds. Unfortunately, once keys have shipped we can no longer offer a refund for the product. However, we have used some of your money to purchase new sounds, music, etc to make Mysteries Of the Aztecs hopefully a better game than Montezuma's Return. Third, many of you have asked when will Mysteries of the Aztecs beta 2 be ready for download. Unfortunately, we can not give any release dates as we don't even know ourselves when it will be ready. We have decided to convert the code from C# to Java, which will take a few months, and will be designing an all new platform independent engine extending Mysteries Of the Aztecs to Mac OS Leopard and Linux operating systems. Finally, some time ago I had polled the community weather or not Mysteries Of the Aztecs should go FPS or remain a side-scroller. The majority of those polled were in favor of a side-scroller format so Mysteries Of The Aztecs will remain a side-scroller. Though, the levels and weapons will be a little different. One of the new changes is the game will definitely have a bit of Tomb Raider and Indiana Jones type elements appearing in the game. As Angela explores the Temple of Death she will be able to pickup lost or dropped items from Romo's failed expedition such as guns, etc. The new game will also feature some new traps such as a spinning blade trap Angela must duck under or jump over. She must also avoid rolling boulders, lava pits, fire pits, and cross underground streams and lakes. All on her way to meat the Aztecs king and queen of death in armed combat. USA Raceway Some of you have asked of late what is the status of Raceway. Unfortunately, there is not a lot to report since our primary focus has been on Mysteries Of the Aztecs, building our developer center, and trying to get the USA Games web site back up and running after a hacker hacked into our web hosting company and completely deleted the USA Games web site as well as everything else on the web server. However, one decision we have made is that USA Raceway is definitely going to be converted from C# to Java. We are still testing and trying to figure out JInput, but once we get racing wheel support figured out there is little reason not to make the switch to Java. We would like to see Raceway, as well as our other games go multiplatform, and we are making breakthroughs everyday to solve issues in making the switch. Though, there is one decision yet to be made. In the current C# .NET version of Raceway we had planned on creating a cfg file you could edit in notepad so you could change such information as driver name, sponsor, car, etc. In addition you could create your own seasons by editing the season.cfg file and putting the tracks in whatever order you wanted to play them. As a result of such editing you would be able to create the exact season races for Nascar 2008, 2007, 2006, or whatever year you wanted. While it is still possible in Java the question is not if it can be done, but how it should be done. When it comes to the matter of making a custom engine, as Raceway currently is, something like Sapi 5 is extremely helpful. It allows new or changed data to be spoken aloud, and it doesn't matter if the driver is your own name or Jeff Gordon, Richard Petty, Mickey Mouse, Donald Duck, Sponge Bob Square Pants, etc. the use of Sapi in a game like Raceway will adapt to new data, and allow the Nascar fan to do whatever with the game. There is a commercial SDK for Java developers for Sapi 5 engines, but then the game would become tied to Windows. Frankly, that bites. The alternative is to find a human to record everything, that would sound more like Nascar Thunder 2006, but you would lose the total customization ability of changing driver names, cars, and sponsors. Though, personally I think the second choice is slightly better than the former. If I go with the second option one way to reach a compromise is to use common everyday first names such as Richard, Jeff, Kyle, John, etc. If you are racing you might be able to pretend that the guy in the car next to you with the name Richard is Richard Petty without having to use the guys full name. You can see how that might work. Anyway, Raceway is for all intents and purposes going through a rethinking process. I have not forgotten about the game, am still working on it, but it isn't my primary focus right now. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to [EMAIL PROTECTED] You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/[EMAIL PROTECTED] If you have any questions or concerns regarding the management of the list, please send E-mail to [EMAIL PROTECTED]
