Game Development Reference
In-Depth Information
795 wl_act3.h
1401 wl_def.h
212 wl_menu.h
4494 total
Listing 6-1 shows the total number of lines of code (
.c
files plus
.h
header files) of Wolf 3D for the
Gamepark32. It's close to 30,000 lines of code. It doesn't seem that much for today's standards, but
consider this: when I was in school, one of my computer ethics professors said that, statistically, a
software developer can deliver ten lines of production-quality code per day. If you do the math, 3,000
days is the time that a single person would take to deliver a high-quality product. Compound this with
the fact that that the work must be done pro bono. Wolf 3D falls under the GNU Public License (GPL),
which would allow you to sell your Java version; however, the GPL also requires for you to give up the
source, which will prevent you from reaping the product of your hard work.
In my quest to bring this game to Android, I even played with the idea of rewriting this code in Java.
I found people who attempted a Java and JavaScript port of the game, but I was quickly discouraged after
looking at the complexity and size of the source. These are the reasons why a pure Java port of this game
is not feasible:
•
Size
: The code base is too big and complex (even for such an old game).
•
Licensing
: All work must be done for free, which is not good for business.
•
Time
: Writing the game will take too long even for a small team of developers.
The only solution with potential time and cost savings is to create a dynamic shared library of the
game and cascade messages back and forth between Java and C using JNI. This is what you will learn in
this chapter. Let's get started by looking at the game architecture from a high level perspective.
Understanding the Game Architecture
Figure 6-2 5.250shows the workflow of the application. When you start the game the main activity
(
WolfLauncher
) will start. After some preliminary sanity checks,
WolfLauncher
will start a thread which
loads the main subroutine from the dynamic shared object (DSO)—the native library). All interactions
with the native library go thru the native interface class (
Natives
). The DSO loads all game data and runs
the main game loop. In each iteration of this loop, two basic pieces of information are sent back to Java
thru JNI:
•
An array of integers representing the video buffer for each frame of the game
: This
array is encoded in Android's format, as a 32 bit integers with ARGB values.
•
An integer representing the index of a sound to be played by the Java audio API
:
This value gets sent every time there is a sound event, such as firing the gun or
opening a door.
