Chapter 4 ■ an IntroduCtIon to Game desIGn: Game desIGn ConCepts, Genres, enGInes, and teChnIques
It is important to note that some of these work together to create a given illusion to the player; for
instance, the sprite animation will create the illusion of a character running, jumping, or flying, but without
combining that code with sprite positioning (movement) code, the reality of the illusion would not be
achieved. To fine-tune an illusion, the speed of the animation (frame rate) and the distance moved (in pixels
moved each frame) may need to be adjusted. I like to call these adjustments tweaking. To tweak means to
interpolate a data value by hand in order to achieve the most realistic end result. Game development is an
iterative process; as much as you might try to sit down and design your game up front and then create the
new media assets and write the Java code, modifications will be inevitable.
We’ll be getting into many of these areas of pro Java game design and development during this book,
but to elucidate on these in a bit more detail here, while we are looking at these considerations, if you can
move gameplay elements (primary player sprites, projectile sprites, enemy sprites, background imagery, 3D
models) a greater number of pixels a fewer number of times, you will save processing cycles. It’s the moving
part that takes processing time, not the distance (how many pixels are moved). Similarly, with animation,
the fewer frames needed to achieve a convincing animation, the less memory will be required to hold the
frames. The same principle applies to the processing of digital video data, whether your digital video asset is
captive (contained inside a JAR file) or streaming from a remote server. Decoding frames of digital video is
processor intensive whether you are streaming the data or not and can take away valuable CPU cycles from
each of the other components of the game, which probably also require a lot of processing.
It’s also important to remember here that we are optimizing memory usage as well as processor cycles,
and the two go hand in hand. The fewer memory locations used, the less effort the processor has to make to
retrieve the data because memory locations are read and processed one memory address at a time; fewer
addresses to process means less processing is going on. Therefore, memory optimization should also be
considered as a processing cycle optimization.
With Flocking, Crowd Dynamics, and Particle Systems effects, fewer elements to process and less
complexity per element will add up quickly when using processing-intensive special effects such as these.
These types of particle-based special effects add a ton of “wow” factor to any game, movie, or television
series but also require huge arrays of data to be processed in real time, which can be processing intensive.
We’ll cover arrays in Chapter 5.
Detecting collisions is another major part of game programming logic for a number of different game
genres such as arcade games, board games, and virtual reality games such as first-person shooters. It is very
important not to blindly check (process) for collisions between game elements. Be sure to exclude game
assets that are not “in play” (on the screen) or are not active, that are not near each other, or that cannot
ever collide with each other (static elements). As you might imagine, collision detection considerations,
optimizations, and programming are art forms in and of themselves, and entire books on this topic alone
have been written, so keep this fascinating topic in perspective and investigate it on your own as well,
especially if you are interested in creating Pro Java 9 Games where lots of collisions could occur.
Calculating forces of nature for physics simulations is the most processor intensive, and like collisions,
many books have been written on each individual area of physics programming, including rigid body or soft
body dynamics, cloth dynamics, rope dynamics, hair and fur (which are actually connected cylinder particle
systems), and fluid dynamics or driving dynamics (which are used in driving games). If any of these types
of physics simulations have not been coded and optimized with great care, then the entire gameplay user
experience may come to a grinding halt, based on how many processor cores the game player has inside the
consumer electronics hardware they are playing the game with.
2D vs. 3D Rendering: Static vs. Dynamic Under the Hood
Static 3D games, such as chess, where the game board is static unless you are moving a game piece to a
new location on the chessboard, may seem to be static; however, since they utilize 3D real-time rendering
to create the virtual reality environment, “under the hood” the system could be busy rendering geometry,
lighting, cameras, and materials in real time, depending on how you have designed all of these elements in
your scene graph and how your Java game processing logic is set up. Just like we saw in Chapter 3 that the