USA Games News

Aug. 20, 2008


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 for C-sharp, 
and decided it wasn't good enough for our needs. While 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.


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 
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 __
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
All messages are archived and can be searched and read at[EMAIL PROTECTED]
If you have any questions or concerns regarding the management of the list,
please send E-mail to [EMAIL PROTECTED]

Reply via email to