[JAVA][Beginning Java 8 Games Development]

Chapter 5 ■ An Introduction to Game Design: Concepts, Multimedia, and Using Scene Builder
Game Optimization: Balancing Static Elements with Dynamic
Game optimization comes down to balancing static elements, which do not require processing in real time, with
dynamic elements, which require constant processing. Too much dynamic processing, especially when it is not really
needed, can make your game play jerky, or stilted. This is why game programming is an art form: it requires balance
as well as great characters, a story line, creativity, illusion, anticipation, accuracy, and, finally, optimization.
Some of the different game component considerations for optimization in a dynamic game are listed in Table 5-1.
As you can see, there are a lot of areas of game play that can be optimized to make the processor’s workload
significantly less “busy.” If you have even one of these primary dynamic game processing areas “run away” with the
processor’s precious cycles per frame, this can greatly affect the user experience for your game. I will be getting into
game terminology (sprites, collision detection, physics simulation, and so on) in the next section of the chapter.
Table 5-1. Aspects of Game Play That Can Be Optimized to Minimize System Memory and Processor Cycle Usage
Game Play Aspect
Sprite position (Move)
Collision detection
Physics simulation
Sprite animation
Background animation
Game play logic
Scoreboard updates
UI design
Basic Optimization Principle
Move sprites by as many pixels as possible to achieve smooth movement on the screen.
Check for collisions between objects on the screen only when necessary (in close
proximity).
Minimize the number of objects in a scene that require physics calculations
to be performed.
Minimize the number of frames that need to be cycled to create an illusion of
smooth animation.
Minimize background areas that are animated so that the entire background looks
animated but is not.
Program game play logic (simulated or AI) to be as efficient as possible.
Update scoreboard only when scoring, and minimize score updates to once per
second maximum.
Use a static UI design so that pulse events are not used for UI element
positioning or CSS3.
Considering all these game programming areas makes game programming an extremely tricky endeavor!
It is important to note that some of these aspects work together to create a given illusion for 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 will not be achieved.
To fine-tune an illusion, the speed of the animation (frame rate) and the distance moved (in pixels per frame) may
need to be adjusted (I like to call this tweaked) to get the most realistic result. We will be doing this during Chapter 13.
If you can move game elements (primary player sprite, objectile sprites, enemy sprites, background) a greater
number of pixels a fewer number of times, you will save processing cycles. It is 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 those frames. Remember that you are optimizing
memory usage as well as processing cycles. Detecting collisions is a major part of game programming logic; it is
important not to check for collisions between game elements that are not “in play” (on the screen), or active, and that
are not near each other.
Forces of nature (physics simulations) and game play logic if it is not well coded (optimized), are the most
processor intensive aspects. These are subjects I will cover later in the book, when you are more advanced
(see Chapters 16 and 17).
www.it-ebooks.info
103