USA Games News May 1, 2008
Introduction Greetings gamers, I know it has been a long time since USA Games has said anything official about our products and services, but I personally felt that a news release was well over do. We have a lot going on, and USA Games for the most part has spent the last three months in a period of research and testing. We have experimented with a wide range of technologies, looked into several operating systems, researched several devices, and now have concluded our research. All of it was time well spent. One of the major points of our research was the feasibility and the practicality of creating accessible games for Windows, Mac, Linux, and cell phones. While our researched results showed it was certainly possible using Java, Python, etc it quickly became apparent that creating accessible games on non-Windows platforms and devices is not very practical. The game development tools are less advanced on Mac and Linux, and we would not be able to deliver a game such as USA Raceway to those platforms without dropping some of its selling features such as support for force feedback racing wheels, virtual 3D audio support, built in MS Sapi 5 support, etc. We felt the loss of these features were simply an unacceptable compromise. Besides the technical aspects of targeting non-Windows platforms and devices we needed to look at the non-Windows user base. What we found in looking at the Orca mailing list for Linux and the Mac Visionaries list is that there are very few exclusive Mac or Linux users out there. The majority of Mac and Linux users out there still use Windows as well as Mac OS or Linux. I myself choose to use Linux for my home business needs using apps like Open Office rather than MS Office, Evolution for appointments rather than MS Outlook, etc. When I want to play games, manage family photos, edit sound effects, watch dvds I turn to my laptop which is running Vista. Bottom line a lot of blind users out there are doing the same kind of thing. Which forced me to conclude that from a strictly financial view there isn't much money to be gained by targeting Mac and Linux directly since most users still have access to Windows for this or that application anyway. Yeah, I can understand the Mac and Linux users desire to have Mac and Linux games, but it isn't currently financially or technically appealing to a game company such as USA Games at this time. During our research we did examine some cell phones owned by friends and family members doing some initial testing for accessible games. The main problem we discovered was memory. The cell phones we looked at didn't have large amounts of memory so whatever we made would have to take that into consideration. Since we are mainly going to break into the First Person Action games with our Genesis 3D engine we want to be able to have realistic virtual 3D audio support. With the Windows DirectSound and XAudio2 libraries that isn't a problem. The cell phones we looked at didn't have anything remotely like that which wouldn't do for our current game projects. Then, the cell phones we looked at had very small buttons. Different button layouts aside the cell phones I personally examined had extremely small buttons and touch pads. I'm not an expert on cell phones, but I felt from an accessibility standpoint if cell phones buttons are going to be so small and difficult to feel there is a lot of room for error and difficulty in playing games with complex button layouts. Perhaps there are other cell phones with better buttons, but the ones I examined I didn't like. In conclusion I felt simple games like Monopoly, Checkers, Text Adventures, card games, and so on would work fine on a cell phone. If the game was going to be a USA Raceway, Shades of Doom, or something like that the cell phone is impractical for that kind of game. Since USA games doesn't have an interest in writing text adventures, card games, and board games we won't be targeting cell phones at this time. Finally, one of the major reasons we started our research in the first place is back in November 2007 Microsoft announced they were dropping development support for Managed DirectX 9.0C. As all of our games are based on that very technology we needed to know what alternatives were out there for us. We also wanted to know, do to major changes in DirectX, where the mainstream gaming market is heading. While we currently are focused on delivering support for Windows XP and Vista we would also like to think a little ahead and make sure we can support the next Windows operating system, code named Windows 7, when it is released sometime in 2010. Seeing what changes are currently going on in DirectX it is pretty clear that a C++ developer supporting XAudio2 etc will stand a better chance of long term support than anything else out there at this time. Another reason we were doing this research is when James North originally announced Raceway he promised to deliver force feedback support to raceway customers. He wrote an engine initially in Visual Basic 6. He later upgraded it to Visual Basic .Net 2003 and discovered that Managed DirectX has problems with force feedback devices. I wrote a new engine in C# .Net and also had problems with force feedback devices. As a result I was basically going to just tell the Raceway customers the truth, I was having technical problems with force feedback wheels, and was going to drop it. However, now that Managed DirectX itself is being fazed out by Microsoft I decided switching to C++ and DirectInput for Raceway will fix both problems at once. You will be able to get good force feedback support, and I don't have to worry about Managed DirectX being dropped any longer. In the end after all my time, research, and hours of testing I have finally came up with a really good design strategy for all of our future games and projects. First, all of our new titles will be written in C++ based on the standard Win32 API. There are many reasons why we picked C++, but needless to say I am convinced it is the best long term for everybody. Second, we will use the standard C++ DirectX 9.0C SDK as that seams to be the best option for game development currently. Third, we will be including Sapi 5 in all of our games as that has worked pretty well for us. Despite some issues on end user systems Sapi 5 all and all is a great gaming technology. As a well educated software developer I feel I should have probably looked into using C++ sooner, but like a lot of game developers who does it for a hobby I wanted to take advantage of the simplicity, rapid design, and deployment features of the .Net Framework. It only proves once again slow and steady always wins the race. Which is a lesson I will not soon forget. As they say, "live a little learn a little." Genesis 3D As most of you are ware by now for the passed few months we have been working on a revolutionary new audio game engine named Genesis 3D. As I have described it in greater detail in passed news releases I won't repete that information here. You should be able to find more about it in back issues of the Audyssey magazine or list archives. At this point we have began the process of converting everything from C# .Net to C++. Many of the course classes for creating characters, weapons, math classes, etc have already been converted over to C++ with little difficulty. We have also got Sapi 5 working in Genesis 3D though we still need to expand the speech system to support all of the features of the .Net version. All and all work is progressing pretty well. Right now the only difficulty is getting DirectSound support working in Genesis 3D. As we quickly discovered DirectSound support in C++ is quite a bit more involved than doing in VB .Net or C# .Net. Microsoft has DirectX utility classes that does most of the grunt work, but I'm not all that happy with their utility classes so I am writing my own which will take a while. Besides I think their utility classes were only sample classes rather than meant for for real production use. Once I get my classes for encapsulating DirectSound 9's core features I should be ready to get started on porting STFC, Raceway, etc to C++. Initially when I created Genesis 3D I only had FPS style games in mind. Over the passed few months I have seen a need to be able to share and tap into those core Genesis 3D classes for games like Raceway, STFC, etc. So in the rewrite I am streamlining the engine support somewhat to allow for side-scrollers, racing games, etc so they can all can be based on a common and uniform gaming engine. After all Sapi support, keyboard support, joystick support, Audio support, etc all is basically the same for every game anyway. All that needs to be different is various classes for characters, weapons, cars, jets, etc. Even those can be inherited from higher level super classes in the engine. The engine just needs a more pure oop design to be more flexible, and have the classes broken down and arranged better. USA Raceway I really don't think there is much to report about Raceway as I have basically mentioned the important news already. As stated earlier Raceway, the .net version, is getting canned. I am starting over with C++, and while Raceway fans might find that disappointing and down right upsetting you will be getting a much better product for it. Especially, when it comes to supporting racing wheels, joysticks, and other specialized game devices. C++ just has the best support for those kinds of devices currently. Also as mentioned earlier Raceway is going to be one of the games based off of the new Genesis 3D engine. Raceway, like a lot of my game projects, were started long before Genesis 3D was started. So I was constantly trying to integrate this or that feature from Genesis 3D into the game after the fact. All That did was cause me to constantly spin my wheels getting nowhere. Which probably makes me look like an idiot. However, this time round I plan to get it right. I will write the engine first, plan ahead for everything I need, and then quickly put the game together. This way the majority of support will come strait out of the core engine rather than the game itself. Assuming Sapi, joystick support, keyboard support, etc is working in the engine it will already be there natively in the game from day one. if there is any errors in those features fixing the engine will fix all of my games at one time which saves time and energy. Here is how it works when you have a good engine ready to go. I open Visual C++ 2008, and create a USA Raceway project. First thing I am going to do is add the *.lib files needed to build the project, and then tell it to import some source files such as Calculate.cpp, Calculate.h, Options.cpp, Options.h, Track.cpp, Trac.h, Audio.cpp, Audio.h, etc from the Genesis 3D engine. All of those components are written so calculation, options, Audio, joystick support, etc suddenly is ready to go with in five minutes of starting the project. it is a massive time saver. Since they are imported from the Genesis 3D directory any changes to those files, bug fixes, etc automatically get put into the latest build without having to do anything more than do alt+b and press enter on rebuilt project. So while Raceway is a long ways from a final product I think what I am doing now will make Raceway much easier to update, maintain, and of course add features you were going to lose otherwise. USA Games Side-Scroller Over the passed month or so I been getting the occasional email about our side-scroller project that once was Montezuma's Revenge, Montezuma's Return, and Mysteries Of the Aztecs. To tell the truth we are still considering ideas, story lines, and trying to balance what you paid for with the need to release something in a timely manner. Michael Feir has correctly pointed out that we can't just write something totally different from the intended game, but on the other hand we can't write the game you paid for do to copyright issues. So we are literally back to square one with lots of ideas, but nothing to show for it yet. Fortunately, as it will take us well into summer to get the Genesis 3D engine working using C++ it will give us plenty of time to think about what we will be doing for the side-scroller project. Perhaps by the time the engine is ready for production use we will have a good story, design, and some documentation ready to go for the new side-scroller. One thing I have recently discovered is by writing the manual before writing the game it helps fix the games features, commands, and story line in your mind before even typing up any code. The object here is to try and make the game match the documentation rather than make the documentation match the game. So for this side-scroller by writing the manual first I will have a pretty good idea of the game I am creating before hand. So that is what is happening with us. We are not going to offer dates, announce schedules, etc until we have something nailed down. We are going to work on the games in our free time, and when the games are ready they are ready. Other than that if you don't hear from us I am either too busy to work on them, or I am working on them but don't have anything to report publicly. --- Gamers mailing list __ [email protected] 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]
