USA Games News
March 18, 2009
Greetings gamers, and welcome to another edition of the USA Games News.
As you know there is a lot of exciting news of late. Work on Mysteries
of the Ancients is going well, and as the release date draws nearer we
are excited to see this title finally get released to the public.
Fortunately, we have had a lot more free time of late, and as a result
we have been putting in many ours on our titles. While most of that free
time has been spent on developing Tomb Hunter Mysteries of the Ancients
it isn’t the only project we have been working on. We have some other
projects in the works, and some plans which will improve both old and
As most of you know we have been developing a rather sophisticated audio
game engine called Genesis 3D. Up until now most of the development has
been done in C-Sharp, with the Microsoft .NET Framework and Managed
DirectX 9.0C. At the time we began the project it seamed like an ideal
solution for us. However, a combination of time, changes in Windows
based technologies, as well as general tech support issues we’ve decided
to rewrite the engine in C++. Why C++?
First, a bit of history. Back in 2007 Microsoft announced that they were
dropping support for Managed DirectX in favor of the XNA Framework. At
the time the Xact tool was completely inaccessible, and even now Xact 3
still has some accessibility issues to contend with. This lead me to
spend nearly two years researching alternatives for Managed DirectX and
XNA. The only one I’ve found is SDLDotNet, but it is not a perfect solution.
Second, over the course of time I’ve tried several different programming
languages and APIs including: Java, Python, and C++. After months of
rigorous research, testing, and experimentation C++ has been the most
stable solution. Plus C++ seams to have the widest possible options when
it comes to input and audio support. This is important to a developer
who doesn’t necessarily want to depend on Windows only technologies such
as DirectX, XNA, etc.
Third, perhaps the greatest advantage to using C++ over Java, Python, or
C-Sharp is that C++ is typically compiled into a native Windows, Linux,
or Mac OS application. There are several advantages for the end user
when an application is natively compiled for Windows, Linux, or Mac OS
rather than being compiled as a runtime application. Bottom line native
C++ applications are generally faster, more secure, and don’t require a
third-party set of runtime libraries such as Python, Java runtime
environment, or the .NET Framework to run. This is, in my personal
opinion, well worth porting the Genesis Engine to C++.
Forth, I’ve essentially written three games using C-Sharp, the .NET
Framework, and Managed DirectX. In each and every case it has turned out
to be a rather complicated process getting my games installed and
operating properly on end users’ computers. I’ve spent many hours
helping customers by phone, e-mail, etc trying to track down if the .NET
Framework is installed, if it is the right version, if the person has
Managed DirectX, if the person has installed them in the proper order,
does the person have an x86 processor or an x64 processor, and so on.
Basically, lots of headaches for customer and developer alike. By
switching to C++ and using the Windows Win32 API directly I can
dramatically simplify the installation process for everyone involved. At
most the customer might have to upgrade DirectX to get the latest
versions of X3D, XAudio2, and Xinput, but this is a fairly straight
Fifth, if that wasn’t enough, C++ has always been the most preferred
programming language used by amateur and professional game developers.
As a result I can always get more documentation, talk shop with
mainstream game developers, and there is more cross platform APIs for
C++. What I am saying is no matter how good Java is, how many people use
Python, how popular the .NET programming standards are now, etc C++
seams to still be at the top of the developers choices when it comes to
programming anything for Windows, Mac, or Linux. Basically, most
programmers regard it as the best all purpose programming language, and
it has a lot of support.
Finally, over the passed year-and-a-half Microsoft has been developing a
brand new audio API for DirectX called XAudio2. When used with the X3D
API it is clear XAudio2 is by far and away the best audio API for
Windows game developers. I’ve built a few test applications using
XAudio2 and X3D and the 3d surround sound support is simply awesome. Not
to mention that it has most of the same features of DirectSound. From a
Windows programming standpoint it is definitely what I’ve been looking
for. I’ve basically held every alternative API to the DirectSound
standard, and that is fairly hard to come by if I don’t want to pay to
license the API for my game projects. With that said I am pretty sure
Xaudio2 and X3D are two very important Windows technologies I need to
make Genesis 3D as good as if not better than the current version that
Mysteries of the Ancients uses.
With all the reasons above it is fairly clear to me that a Genesis 3D
engine written in C++ is the best thing to do all things considered.
Once we finish with Mysteries of the Ancients, and get that project out
of the way, we will probably take several months off of game development
and rebuild Genesis 3D from the ground up. The end result should be a
very stable, very powerful, game engine for creating top-of-the-line
Mysteries of the Ancients
At the time of this article we have released three public betas and
several test builds to our private testers. Even as I write this we are
working on what will be public beta 4. We want to take our time with
beta 4 as we really want to make sure the game is really stable, fix as
many bugs as we can in this release, and just tidy up the source code
some. There is nothing worse for a software developer then messy,
sloppy, or untidy source code. In short, it makes the source code hard
to read when a developer comes back to it weeks, months, or even years
later down the line. So it helps to clean up the code so it is easier to
read later on.
As far as bug fixes goes that is going really well. Just this morning I
have finally found out why you couldn’t grab the rope when you tried to
catch it when using the jump up command, and I have finally fixed that
little bug. In addition, I have fixed some miscellaneous bugs when you
try to jump left or right using a game pad or joystick. As it happens
the fix also applies to the keyboard so jumping works slightly different
in beta 4. These are only a handful of things we have worked on so far.
As far as a release schedule for beta 4 we don’t have a specific date or
time in mind. As mentioned above we want to focus on stability issues as
well as complete everything in our to-do list. It has grown quite large
over the passed three betas, and we need to sit down for a couple of
weeks and work on that, nothing but that, and hopefully get to the point
were we can start adding the rest of the game levels, complete the end
user documentation, etc. In other words get the game ready for a 1.0
release with in the next two or three months, or sooner depending on how
long all this takes.
Another important reason we want to hold back on releasing the next beta
is we have lost time by releasing the previous three betas. We have
spent several hours answering basic questions, helping user’s get the
game installed, fulfilling end user requests, etc. The net result of
this has caused us to slow down on actual game production and take time
to answer questions, fix bugs that popped up unexpectedly, and so on. If
we hold back we can pretty much get the game near complete and then just
work out any last minute bugs, requests, etc at the end. This makes more
sense than letting it all pile up at once. So it could be some time
before beta 4 is ready for release.
Next to Tomb Hunter Mysteries of the Ancients this is undoubtedly the
most anticipated USA Games title currently in development. We often get
requests for updates, news, and more information about the game. It is
true that Mysteries of the Ancients takes up a good majority of our
development time, but that doesn’t mean development has completely
stopped on Raceway, or we don’t have any news to report. In fact, there
is some news on that front.
Recently, with our decision to move to C++ we have started the tedious
process of converting USA Raceway to C++. Given our current speed it is
going to take a while to get Raceway completely converted, get it
stable, and have anything like a playable test release let alone a
public beta. Still, it is really going to be worth it, and not just
because I’ll be using C++.
One of the cooler features of using something like C++ with XInput for
handling game input devices is it natively supports Xbox-360
controllers. Assuming, of course, you install the Windows drivers for
the Xbox controllers. I am a big fan of playing games using joysticks,
game pads, etc and I rather like the idea of turning my home PC into a
Xbox clone. I’m sure those who like the Xbox-360 will enjoy the support
for Xbox-360 controllers as well as I do.
As mentioned earlier in this news letter we will be using XAudio2 and
X3D for handling audio on the Windows side. The end result is a richer,
more realistic, and much more powerful audio experience. Yes, it isn’t
that much different from using DirectSound with 3d audio support, but I
am personally impressed with the new DirectX audio APIs that ship with
the newer releases of the DirectX SDK.
Besides it seams to me to be a smarter move on my part to begin phasing
out DirectInput, DirectSound, etc and begin converting my games over to
the new libraries. It took me a while to become won over by them, but
fact is DirectInput, DirectSound, DirectPlay, and so on are older
technologies no longer receiving updates, support, etc from Microsoft.
It makes sense since Raceway is more or less a new game to go with what
is current rather than falling back on older technologies that could be
dropped at any time by Microsoft. I am all too aware of the kind of
havoc Microsoft caused when they began dropping Visual Basic 6 support
under Windows Vista. Especially, since DX7VB.dll and DX8VB.dll were
completely removed from the DirectX installation as well as Windows
Vista. For our own sake as well as yours we don’t want to fall victim to
that kind of change in Microsoft support policy. The best way to avoid
such a fiasco is to see the change is coming and begin planning for that
eventuality. That’s exactly what we are doing with Raceway.
Finally, everyone on this list knows I am personally interested in
seeing our games run on Windows, Mac, as well as Linux. I think that by
using C++, if I design the game right, I should be able to eventually
port Raceway to whatever operating system I want. SDL is no DirectX,
but I have seen Audio Quake under Linux, using SDL, and it isn’t bad.
Point being the option is open, and I’ve seen games like Quake do well
on Mac and Linux using that combination so it is at least feasible. Plus
if the Windows release sells well I can license something better for the
Mac and Linux side if I really want to. All and all I’m happy with what
we are doing with USA Raceway. I can’t ask for much more than that.
USA Games Sales:
USA Games Support:
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.