USA Games News Aug. 20, 2008
Introduction Greetings gamers, Welcome to another friendly USA Games news letter. This one really is a lot more up beat and positive then the passed two or three news letters. Also we have some good news to release this time so stay tuned. Before I actually get into the topic of our games I'd like to let everyone know that my wife and I are now moved back into our apartment and are finally setup again. I have all of my computers back up and running, and as a result I have a Windows XP, Windows Vista, and Ubuntu Linux 8.04 computer to do development and testing on our products with. This is very good as our new game engine we are working on is now being designed to be multi-platform supporting Mac, Linux, and Windows. It also may eventually be possible to port our games to cell phones and other mobile devices with a compatible Java 6 runtime environment. Yeah, you heard that right. We have finally decided to adopt Java 6 as our new programming language and API for all of our new games. The reason is that we converted one of our games to use SDL.net for C-sharp, and decided it wasn't good enough for our needs. While SDL.net was a fairly decent programming API we wanted all the power of DirectX. We discovered Java's J3D graphics and audio API fit our needs perfectly. It is multi-platform, renders equal 3D audio support on all platforms, and I already know Java fairly well so the switch isn't all that big an issue for me. Obviously, with the change in language and API we will go back to using pre-recorded speech for the majority of our games. While there is a Java sdk for Sapi 5 it is pretty expensive, and of course is not multi-platform. Besides that, while we were supporting Sapi in Montezuma's Revenge we got a lot of technical support issues with Sapi. In many cases the end users Sapi broke for whatever reason, and it had to be fixed to play our games. We feel just dropping Sapi will add greater stability and replayability to our games long term as well as not tie the game to a proprietary Windows technology. With all that said let us get on with the news we have for you today. Tomb Hunter Mysteries of the Ancients We are happy to announce despite the disruptions to our programming schedule our replacement game for Montezuma's Revenge, Mysteries of the Ancients, is back in active development. Over the passed two weeks we have been working hard on translating our C-code from C-Sharp to Java, and that process is going very well. Actually, it is going better than expected. One reason we can account for this very fast translation process is that Java and C-Sharp are very similar in a lot of ways. They both use the same lexical and syntactical structure, use the same variable declarations, and sometimes similar functions and class names. As a result some parts of the game code just need a few changes here and there while others more language specific need to be rewritten. In any case it is going faster than I had first anticipated. The programming language isn't the only thing we have upgraded in this new version. We also have done a massive sound upgrade to the game, and it sounds, well, a lot more realistic than ever. We have updated the background ambiance, character effects, footstep sounds, and several other sound effects. Some sounds we have digitally remastered to sound better. All and all we have done an excellent job on giving the game all new audio effects. In addition we have redesigned the game somewhat, and given it a more Tomb Raider style make over while preserving its original side-scroller format. In addition to swords Angela Carter will be able to pick up various firearms such as a Browning 9MM pistol, 357 Magnum, 12 gage shotgun, and an Uzi. As well as weapons Angela will be able to collect various items such as: diamonds, emeralds, rubies, sapphires, gold coins, ancient scrolls, healing potions, and torches to light her way. The enemies in this new side-scroller have also undergone an upgrade as well. The skulls are now undead skeleton warriors armed with bow and arrows. Some of the skeletons are, however, undead priests that are able to throw fire balls. In addition to the skeletons there will be plenty of rattle snakes and gray wolves inside the ancient ruins to avoid or kill. New and deadlier enemies aren't your only obstacle to face. There are several new traps to avoid such as: poison darts, chasms to jump over, fire pits, spikes, and rolling boulders to name a few deadly traps you will have to avoid a long the way. As far as a schedule we are hoping to have a beta out by Christmas, but we can't promise a December 25 dead line. Obviously this year has proven difficult enough to keep a schedule for our games do to people and events out of our control. Not only that, much of that time was spent on researching and testing alternatives to Microsoft DirectX and the .NET Framework. While both technologies are fairly good for Windows only users I am not, strictly speaking, a Windows only user. Over the passed year I have really began exploring the possibility of using Apple Mac OS or Linux as my primary operating system, and there are elements of both that make them good alternatives to the Windows platform. Not the least is the screen reading technologies for both are cost effective on a small budget, and I don't have to worry about the Vista style product activation that I despised from the beginning. I personally feel it is slightly unfair to tie a product specifically to Windows for those power users, like myself, who are decidedly unhappy with the way Microsoft and other companies are going with all the anti-piracy and security measures to force the average legal Windows user into paying for the same software media multiple times if they have more than one computer in there home or office. In my case I do feel there does need to be a line drawn somewhere that states how far I am personally willing to spend in support of all the digital rights management that is being heavily promoted by the recording industry Association of America, Microsoft, and the film industry that have pushed for tighter control over our personal use of digital media we have legally purchased. I could probably rant for hours on the evils of DRM technology, and why as users we need to be more vocal in trying to protect our fair use rights to the media we have purchased. However, DRM technology is a controversial subject, and one I will not go into at length here. Finally, more and more people are getting into mobile devices such as cell phones, PDAs, and other hand held devices with microcomputers built into them. As a result of the boom in mobile technologies more and more game junkies are becoming interested in taking there favorite games on the road with them on their cell phone, PDA, or laptop. As a result game companies, especially adaptive game companies such as USA Games, has to take such trends somewhat seriously and begin creating games that may eventually be able to be ported to these devices. Even mainstream game companies like Edos Interactive have began seeing this fact and have released Tomb Raider Legend Mobile for mobile devices. A language like Java can do this with only miner changes in some cases. Which is a good reason to walk away from more proprietary Windows only APIs and languages. USA Raceway Another game that has seen much more active development of late is USA Raceway. Like Mysteries of the Ancients it is now being converted over to pure Java. Besides those reasons mentioned earlier in this news letter there are some other good reasons to do this for Raceway. One of the things I have noticed between the time James North originally announced his plans for Raceway, and the time I actually began creating this game two very decent racing games have been released for the accessible games community. Both Topspeed II and Rail Racer are fairly good racing games, and both offers online network play between gamers. I can't count how many times I have personally received requests to add network game play and one on one racing between Raceway players. Well, now it seams you may get your wish. A few years ago when Raceway was initially scheduled for release Microsoft's DirectPlay technology would have certainly been the way to go for online networked games. It was a programmer friendly, fairly straight forward, API for writing networked games that helped make DirectX the defacto game developers API of choice. Then, in 2007 Microsoft officially announced their intention to drop DirectPlay from DirectX leaving developers like myself without a clear API to use for online game play that has the simplicity and functionality of DirectPlay. With a language like Java such concerns is not a problem. When the programming language was first released by Sun Micro Systems they had intended that Java come packaged with a fully functional, well documented, networking API that will work on virtually any operating system. Over the years Sun has continued to design and update the core networking API, and today it really is the leading API for software developers trying to network applications across different operating systems and computer platforms. What this means for you and I is that it shouldn't be all that difficult to use Java's native networking API to build a cross platform independent racing game where two or more gamers can race together online. Obviously, this functionality needs more work, but it is definitely a thought for a future addition to Raceway. With a programming language like Java 6 it is not all that far fetched to imagine a instance where you might be able to fire up your Windows Mobile phone, PDA, etc connect to a wi-fi connection and play against an online player while you are waiting between classes, on your coffee break at work, waiting for a doctors appointment, etc. This is truly the power of walk away content, multi-platform software, and why so many mainstream users are spending so much time on their cell phones, PDAs, and other mobile devices. The power of multi-platform software combined with a universally excepted networking API really is the only way to go if you want to reach the widest number of users, and give them virtually endless choices how to use their software media. It is this kind of freedom that digital rights management attempts to control by restricting software media you buy to one platform, one computer's unique hardware, and forcing you to pay multiple times for the same product for every computer or device you plan to use it on. If you haven't already noticed I am a typical computer geek, and I love to think of stuff like this all the time. As a result it isn't that hard for me to think of a game like Rail Racer, and take that idea to the next level. It already has a great online racing system in place. Why not take that idea and make it so Raceway will work on mobile devices, PCs, Macs, or whatever device will support it? It isn't that difficult an idea to play a game on your mobile device, save the game, copy the save game file to your Windows PC at home, and continue in the race exactly where you left off. Since Raceway is primarily season based, where you play in an actual Nascar-like season, you will want to be able to back up and save your seasons. You may even wish to be able to transfer them between various devices you own such as your mobile phone and your PC. Now, days with the way technology is progressing it is getting easier to do that sort of thing, and it will make Raceway far better than James North's original design by light years. With that said, there are going to be some drawbacks. If I want to do maximum portability over devices it would be better to depend on core Java input methods rather than using OS specific input devices such as joysticks. I'm probably not going to introduce joysticks, steering wheels, initially until the core game is complete and stable. At that point we can explore the option of hooking Raceway up to an API such as JInput for obtaining force feedback racing wheels, joysticks, game pads, and other devices not natively supported by Java. So what I am talking about is a lot of work, and time consuming. On the other hand I think it will be worth it, because there is a lot of power to be had in walk away content you can just drop on a memory card and take it with you on your mobile device, or play it on your desktop PC at home. Summary USA Games has always strived for perfection and software innovations that are rarely seen in the blind gaming community so far. I will admit we have not always been timely in getting our products out, and many of you have been waiting long enough to see our products come to light. However, now that we have selected the technology we plan to use, and once Genesis 3D is ported to Java you should begin seeing faster turn around times on our games. While Genesis 3D will be more difficult to use do to the necessity to self-voice the games without the aid of Sapi it will however offer the ability to create games for virtually any operating system or device that supports Java 6. At the time of this news letter the majority of Mac OS users are currently running Java 5. It is my hope that Apple will be offering a Java 6 upgrade by the time our new Java based games become available. If not it may become necessary on my part to recompile the games for the Mac platform using a compatible JDK for Mac users. I'm hoping this won't be necessary, but time will tell. As for the games running on Linux we are currently tracking down an unusual error where the Linux Java runtime for Ubuntu 8.04 isn't working properly. When we test the MOTA Alpha on Windows everything seams to be working fine. When i install the Alpha on my Linux system half the time the menu keys fail to work. I'm totally clueless as to what is causing this error as the code refering to those keyboard commands is straight out of the core Java API, and is standard on every Java runtime environment out there. I'm currently putting out a report of this problem to some mainstream Java developer forums, and hope they can give me some ideas to why this might be working incorrectly. It may be the version of the JRE I have installed on that system has some bugs in it, and I need to update to a newer Java version such as Java 6 update 7. Also i can try testing it on other Linux distributions such as Fedora and Open Suse for comparison though the Java runtimes should be identical. In any case there are problems getting everything working as it should on Mac, Linux, and Windows, but that is to be expected at this point. The new Java based engine I am working on has only been in active development for about three weeks, and is obviously still buggy anyway. A good portion of the original engine code has been converted to Java, but even as close as C-Sharp and Java are to each other in similarity there are still things that were easy to miss or overlook when doing the conversion process. For example, when declaring a boolean flag in C-Sharp you would declare it like private bool isKilled = false; while in Java it would be declared like private boolean isKilled = false; which are pretty similar but not exactly the same. As a result it is sometimes easy to forget which is which and use a C-Sharp declaration in the Java version of the game resulting in a massive compilation error that has to be edited and repared by hand. Other diferences between the languages can be just as easy to overlook. So I have had to rethink the way a certain block of code was written, or find a better, cleaner, solution to a particular issue. For example, the weird bug where you could walk through walls I had in the C-Sharp version of the game. Well, that bug reappeared in the Java version of MOTA so I took that colision detection code, rewrote that section of code from scratch, redesigned how it worked, and now it appears that bug is well and truly gone. In the end it turned out I just used a poor design to begin with, and I had to tototally rethink the process through before I saw the error in my original design. Programming is like that sometimes. A lot of non-programmers think that programming is all about math, or knowing how to use this or that programming language. That is the easy part. The hard part is actually training yourself to think logically, cover every possible condition a certain state the game can be in at that time, and then programming your game to deal with those different conditions at that current point in time. Often it is the small things we take for granted that get overlooked, and then need to be corrected when our game behaves in a way that is less than satisfactory or does something that is unrealistic. For example, let us assume you found an old sword, and then are forced to climb up a rope to get up to a ledge. Logically speaking, a person is going to want to climb up that rope two handed and isn't going to be hanging on to a huge and heavy sword as he/she does it. In more modern games they offer the ability to ddraw and holster weapons so the main character is free to use his or her hands for other tasks such as climbing, swimming, hand to hand combat, or moving certain items such as a heavy stone door. It is these kinds of logical concidderations a game developer has to seriously think about if we want our games to be at all somewhat realistic. So in the end we are working on an all new engine, improved game play, and rethinking how our games are logically designed. Improving the games internal logic will eventually make a funner and much smoother gaming experience for all involved. --- 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]
