Tải bản đầy đủ - 0 (trang)
High-Level Concepts: Static vs. Dynamic Gaming

High-Level Concepts: Static vs. Dynamic Gaming

Tải bản đầy đủ - 0trang

Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

Game Optimization: Balancing Static Elements with the 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’s not really needed, can make your gameplay jerky or stilted. This is why game programming is an art form;

it requires “balance,” as well as great characters, a storyline, creativity, illusions, anticipation, accuracy, and,

finally, optimization.

For instance, Table 4-1 describes some of the different game component considerations for

optimization in a dynamic game. As you can see, there are a lot of areas of gameplay 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,” it can greatly affect the user

experience for your game. We will be getting into game terminology (sprites, collision detection, physics

simulation, etc.) in the next section of the chapter.

Table 4-1.  Some Aspects of Gameplay That Can Be Optimized

Gameplay Aspect

Basic Optimization Principle

Sprite Position (Move)

Move sprite as many pixels as possible while still achieving a smooth

movement appearance

Sprite Animation

Minimize the number of frames needing to be cycled to create illusion of

smooth animation

Collision Detection

Check for collision between objects on the screen only when necessary (in

close proximity)

Physics Simulation

Minimize number of objects in a scene that require physics calculations to be


Flock/Crowd Simulation

Minimize number of members that need to be cycled to create an illusion of

crowd or flock

Particle Systems

Minimize particle complexity and number of particles needed to create

intended illusion

Camera Animation (3D)

Minimize camera animation unless it’s an integral part of (absolutely required

for) gameplay

Background Animation

Minimize animated background regions so entire background looks animated

but is not

Digital Video Decoding

Minimize digital video use, unless it’s an integral part of (absolutely required

for) gameplay

Gameplay (or AI) Logic

Design/code gameplay logic, simulated, or artificial intelligence to be efficient

as possible

Scoreboard Updates

Update scoreboard via binding and minimize display updates to once per

second maximum

User Interface Design

Use static user interface design so that pulse events aren’t used for UI element


Considering all these gameplay memory and CPU processing optimization issues will make your

Pro Java 9 games design, and Java coding, quite a tricky endeavor indeed. Needless to say, a lot goes into

professional Java 9 games.



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


Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

nature of 3D new media assets is an order of magnitude more complex than 2D new media assets, the same

thing applies to 3D games versus 2D games. 2D games do have an element of “rendering” called double

buffering where the next frame is composited in memory, before it is displayed on the screen. 3D rendering,

however, is actually creating the pixel color and alpha values, not simply organizing them in an X,Y

location. 3D rendering creates the pixel color values and X,Y locations from scratch, based on 3D geometry,

transformations, materials, shaders, mapping coordinates, light position, and camera position.

Next let’s take a look at the pro Java game design aspects and considerations for some of these core

gaming concepts in greater detail and look at some of the core optimization principles that apply across all

genres of games.

Game Components: 2D, 3D, Collision, Physics, and AI

Let’s take a look at the various game design concepts, aspects, and components that you will need to

understand in order to be able to build a game, as well as what Java (or JavaFX) packages and classes we

can use to implement these aspects of gameplay, which I like to term components of gameplay design and

development. These could include the gameplay elements themselves, commonly referred to in the game

industry as sprites for a 2D game or models for a 3D game, as well as the processing engines, which we will

either code ourselves or import preexisting Java code libraries for, such as artificial intelligence, physics

simulations, particle systems, inverse kinematics, or collision detection. I will spend some time covering

each of these and why they would be applicable to a pro Java game and some optimization considerations

that you should keep in mind if you decide to use any of these game components.

2D Sprites: The Foundation of Arcade-Style Gaming

Let’s start with the foundation of one of the oldest forms of electronic gameplay, the arcade game. The 2D

assets, called sprites, define our main character, projectiles used to damage the main character, treasures

collected by the main character, and the enemies that are firing these projectiles. Sprites are 2D graphics

elements and can be either static (fixed, a single image) or dynamic (animated, a seamless loop of several

images). Sprites can be either vector (shapes) or raster (image-based) assets. If they are image based, they

will usually be PNG32 and carry an alpha channel so that they can be composited over the rest of the game

design in real time and have the result look like it is digital video, that is, like it is being shot with a camera

and played on the screen rather than being composited in real time based on the game player’s input, which

is usually a game controller, keyboard keys, or iTV set remote control.

A sprite will be moved around on the screen based on programming logic that dictates how the game

is to function. Sprites need to be composited with background imagery and other gameplay elements in the

Scene Graph as well as with other players’ sprites, so the PNG32 graphics that are used to create the sprites

will need to support transparent backgrounds. This is also why I covered the topic of masking 2D objects—

to use as sprites for your games.

This is also why I introduced you to the concept of alpha channel transparency, in Chapter 2, as we

will need to achieve this same end result with our sprites so that we achieve a seamless visual experience

with our game. We’ll be covering how to use GIMP to create graphics that use alpha channels later during

this book so you can create professional-level sprites that composite seamlessly with the rest of your game


Since 3D models are all in the same rendered space together, the 3D rendering engine will take care of

this transparency factor for you, and you do not have to worry about having an alpha channel for each 3D

component of your game if you use 3D models instead of 2D sprites. Let’s take a look at 3D models next as a

follow-up to this point.



Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

3D Models: The Foundation of the Role-Playing Style of Gaming

One of the newer forms of electronic gameplay involves real-time rendered virtual worlds, thanks to the

advent of real-time rendering platforms such as OpenGL ES 3 and Vulkan, which are used in Android,

HTML5, JavaFX, and DirectX (DirectX is used in Microsoft products such as Xbox and Windows). 3D models

provide far more flexible, advanced, and photorealistic gameplay because they combine all of the other

new media types (except for digital audio) into one; because textures, materials, and shaders can use digital

imagery and digital video; and because 3D geometry mesh objects can use their actual geometry to calculate

collisions with the actual object, and in three dimensions instead of two on top of that. Add in the fact that

3D assets can react in real time to multiple lights and cameras, and you have a far more powerful game

design environment with i3D, albeit more complex from a mathematics and a Java coding standpoint.

Since 3D and i3D are so complex, there are a plethora of optimization considerations, such as

optimizing the mesh (geometry), a process called low-poly modeling that involves using points, edges, and

faces sparingly and then using smoothing groups to provide a smooth curvature that could also be achieved

simply by adding more geometry. I also covered some of the optimization principles of using fewer pixels,

lower color depth, and fewer channels that would be used for texture maps, which are images, in Chapter 2.

Similarly, for 3D animation, in Chapter 2 I covered some of the optimization principles that would be used

for animation data, which is similar to digital video, such as using fewer pixels, fewer frames, lower color

depth, and fewer channels, along with simpler interpolation algorithms.

Another optimization for 3D and i3D games has to do with the number of lights that are utilized to

light a virtual world. Light calculations tend to be expensive, so much so that most game engines, including

JavaFX, limit the number of allowed lights to eight or fewer. The fewer light objects you can use, the fewer

calculations the rendering engine will have to do and the higher frame rate (faster) your game will run at.

The same consideration would apply to cameras in 3D animation software. When you’re rendering out

to film, for instance, you can render out as many camera views of the scene as you need with no (real-time)

processor penalty. When a consumer electronics device is processing that 3D (versus a massive render

farm of workstations), it becomes important to minimize the number of cameras as each one is outputting

the equivalent of an uncompressed raw digital video data stream. In this situation you have a 3D rendering

engine generating another uncompressed 2D animation (video) asset in real time, which again takes up a

lot of your processing power, so use this only if your game absolutely requires a real-time Head’s Up Display

(HUD), for instance, for a real-time second gameplay perspective.

Collision Detection: The Foundation of Game Asset Interaction

Another important component, or aspect, of gameplay for some types of games is collision detection

because if your game elements simply flew right past each other on the screen and never did anything

cool when they touch, or “intersect” each other, then you really would not have much of a game! Imagine

a pinball game or billiards without any collision detection! Once you add a collision detection engine

comprised of intersection logic processing routines, your game will be able to ascertain when any 2D vector

sprites or 3D models are touching or overlapping each other by processing intersections of their component

geometry, usually edges, lines, curves, or their bounds (BoundingBox).

A collision detection will call (that is, trigger) related game logic processing routines that will ascertain

what happens when any given 2D sprites or 3D models, such as a projectile and the main character,

intersect. For instance, when a projectile intersects the main character, damage points might accrue, a life

force index might be decreased, or a death throes animation might be started. If a treasure item intersects

with (that is, is picked up by) a main character, on the other hand, power or capability points might accrue,

the life force index might be increased, or an “I found it” jubilation animation might be started.

As you can see, depending on the type of game you are creating, the collision detection engine for

the game could well be one of the foundational design elements behind your gameplay, besides your i2D

sprites or i3D models, which represent your characters, projectiles, treasures, enemies, obstacles, and props

themselves, which is why I’ve covered these in this order. Once a collision is detected, often your physics


Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

simulation code will be triggered to show the game player how the objects need to react to each other after

that collision. So, let’s take a look at that next.

Physics Simulation: The Foundation of Gameplay Realism

Another important component, or attribute, to add to your gameplay is real-world physics simulation. The

addition of things like gravity, friction, bounce, drag, wind, acceleration, deceleration, and motion curves,

like the JavaFX Interpolator class provides, and similar forces, will each add an additional level of realism

on top of the already photorealistic sprites, your synchronized animation sequences, scenic backgrounds,

and highly accurate collision detection.

Gravity, friction, drag, and wind are the easiest factors to either simulate or adjust a 2D sprite or 3D model

movement for in your Java code. I touch on this near the end of my book Beginning Java 8 Games Development

(Apress, 2014). Bounce is similar to the mathematics done for acceleration and deceleration in motion curves,

which could be used to simulate a single bounce, but not the decay of a bounce that a physics simulation will.

You can code your own Java methods to apply physics to your pro Java game or you can use the thirdparty Java libraries, which are available on sites like SourceForge, GitHub, or code.google.com. I will cover

some of the libraries that are out there for 2D and 3D game engines, 2D and 3D physics simulation engines,

2D and 3D collision detection engines, forward and inverse kinematics engines, and the like. I will cover this

in the next major section for this chapter, just in case you want to use these in your pro Java games or IoT

applications instead of writing your own.

It is interesting to note that most of the open source third-party physics engines, which I’m going

to cover in the “Java Engines: Game, Physics, and Inverse Kinematic” section of this chapter, not only

implement physics simulation but also implement collision detection. This is because these two things are

closely tied together in real life. To do collisions really well, the physics simulation needs to be a seamless

integration in that code. There are physics involved both before and after a collision in real life, and these

engines seek to re-create real-life (completely believable) implementation results. Be advised that as of Java

9 these offerings will need to be “modularized” for use with the new Java 9 module system in order to be

used properly within that system.

Artificial Intelligence: The Foundation of Your Gameplay Logic

Finally, the most proprietary attribute or logic constructs (Java code) that you can add to add to your

gameplay is the custom gameplay logic, which makes your game truly unique in the marketplace. This

artificial intelligence (AI) programming logic should be kept in its own Java class and methods, separate

from physics simulation or collision detection code. After all, Java makes modularization easy, and this

gameplay intelligence is like the referee for your pro Java game. It oversees the player, opponents, obstacles,

treasure, scoring, penalties, and similar, making sure the game experience is the same every time and for

everyone! This is the same function that a referee performs at a sporting event or competition.

There are third-party AI engines for Java; however, I suggest this is an area where you may want to write

your gameplay logic code from scratch so that it integrates with your user interface (UI) code, your scoring

engine code, your animation engine code, your actor (sprites or models) movement code, and your collision

processing code in a much more seamless fashion than any third-party AI rules engine ever could.

When you start to add all these game components together, it starts to make the game more believable,

as well as more professional. One of the key objectives for a great game is “suspension of belief,” which

simply means that your player is “buying into” the premise, characters, objectives, and gameplay 100 percent

completely. This is the same objective that any content producer, whether it be a filmmaker, television series

producer, author, songwriter, game programmer, or application developer, is going for. Games these days

have the same revenue generation capability as any of the other content distribution genres, if not more, and

you can distribute them directly to the public without a middleman such as a movie studio, record producer,

or television network. That’s the most significant part, as you will get a “70 percent you, 30 percent store”

split, rather than a “70 percent distributor, 30 percent you” split!



Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

Java Engines: Game, Physics, and Inverse Kinematic

There are a number of open source third-party game engines, physics and collision engines, AI engines, and

even inverse (or forward) kinematics (IK) engines that can easily be found on the Internet. Most of these are

on SourceForge or GitHub or on code.google.com and can be found using a basic Google search. Most of

these come in JAR format.

Game Engines: JMonkey and the Lightweight Java Game Library

LWJGL is an open source, cross-platform Java library that is useful for the development of 3D graphics

(OpenGL), 3D audio (OpenAL), and parallel computing (OpenCL) applications (Figure 4-1). API access is

direct and high-performance yet also wrapped in a type-safe layer appropriate for Java ecosystems. Other

high-level 3D game engines may also make use of LWJGL.

Figure 4-1.  The Lightweight Java Game Library 3 is an open source Java game library compatible with Java

and JavaFX


Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

JMonkey is also a free, open source game engine targeted at Java game developers who want to create

i3D games (Figure 4-2). This software is programmed entirely in Java and is intended to provide wide

accessibility and rapid deployment.

Figure 4-2.  jMonkeyEngine 3.0 is an open source cross-platform game engine compatible with Java and


It’s important to note that I’m going to show you how to create games using only Java (8 or 9) and

JavaFX 8 or 9 because that is what this book is about: using and learning about the native Java APIs

(of which one is JavaFX) to make games or IoT applications. I just wanted to make you aware of the two

leading Java games platforms before we start.

Physics and Collision Engines: Jbox2D, JBullet, Dyn4j, Jinngine

There are a large number of third-party physics engines that also include support for collision detection, so

you can add collision and physics at the same time to your game using any one of these collision physics

code libraries to your pro Java games or IoT application projects simply by importing a JAR file into your

project and calling the proper APIs.

Jbox2D is a “port” or recoding for use in Java of the Box2D C++ physics engine. Box2D is an open

source, C++-based physics and collision engine for simulating rigid body dynamics in i2D (X,Y) space.

Box2D was developed by Erin Catto and was released under the zlib license, which does not require formal

acknowledgment of usage; however, it is encouraged that you give credit to Box2D in your pro Java game if

you use the Jbox2D API port from C++ Box2D.

JBullet is a partial port of the Bullet 2.7 3D C++ physics engine for use in Java. Bullet 2.87 is an open

source, C++ physics and collision engine for simulating rigid body dynamics in 3D (X,Y,Z) space. The Bullet

collision detection and physics library was developed by Advanced Micro Devices, otherwise known as

AMD. It can be found at http://bulletphysics.org if you want more information. JBullet was released

under the zlib license, which does not require formal acknowledgment of usage. However, it is encouraged

that you to give credit to JBullet in your pro Java game if you use the JBullet API partial port from the Bullet

2.7 C++ physics engine.

The dyn4j engine shown in Figure 4-3 is a 2D collision detection and physics engine compatible with

Java 6 and 7, meaning that it works with the Java 8 and 9 versions we are covering in this book. Dyn4j was

designed to be stable, extensible, optimized (fast), and relatively easy to use. Dyn4j is free for commercial

use, as well as for use in noncommercial applications. It is licensed by its author, William Bittle, under the

BSD licensing model.



Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

Figure 4-3.  Dyn4j is an open source, 2D collision detection and physics engine that is available under the BSD


Jinngine is an open source lightweight 3D physics engine written in Java that gives you real-time

collisions, as well as real-time physics calculation capabilities. A user can set up and simulate physics by

calling API functions to specify geometry, joints, and parameters. Friction is modeled by implementing an

approximation of the Coloumb law of friction. This physics engine focuses on collision and physics only,

has no rendering features, and is built using a velocity-based algorithmic approach that is solved using an

efficient NCP solver. You can use jinngine as your physics engine, and you can also use other components

of this engine as if it were a Java code library, for instance, if you want to only implement collision detection

or if you wanted to only utilize the point-of-contact generation features. Next, let’s take a look at inverse

kinematics, or IK engines, which are used in character animation to define skeletal structures and their joint

movement restrictions.

Inverse Kinematics and Robot Engines: JRoboOp and JavaFX-IK

JRoboOp is an open source Java library (package) designed for IK robotics simulation with visualization

of a 3D robot model. The engine simulates robotic inverse kinematics as well as robot dynamics and is

based upon the C++ library called ROBOOP. This library was developed by Richard Gourdeau of École

Polytechnique de Montréal, and the library is compatible with Java 5 and later as well as with JavaFX 1.3

and later, meaning that it will work great with the Java 7, Java 8, JavaFX 9, and Java 9 versions that we will be

covering during this book. This package is distributed under the GNU Public License (GPL).

The JavaFX-IK library was created about two years ago specifically for JavaFX and is available on

GitHub at https://github.com/netopyr/javafx-ik. It is licensed under the Apache License, version 2.0.

The IK software, which allows you to create Skeleton object structures in the JavaFX Scene Graph using

Bone objects, was created by senior software engineer Michael Heinrichs, of Freiburg, Germany.

Next, let’s take a look at the different types of games that can be created as well as how these differ

in their application of the core game components of sprites, collision detection, physics simulation, and

gameplay AI logic.


Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

Game Genres: Puzzle, Board, Arcade, Shooter, or VR

Like everything else we have talked about in this chapter, games themselves can be categorized by using

a “static versus dynamic” approach. Static games aren’t “processor bound” because they tend to be “turn

based” and not “hand to eye coordination based” in nature, so in a sense they are easier to get working

smoothly, as only the programming logic for the “rules” of gameplay and the attractive graphics need to be

put into place and debugged. A significant opportunity also exists for developing new types of game genres

that use a hybrid combination of static and dynamic gameplay in creative ways that have never before been

seen. I’m working on a few of these myself!

Static Games: Strategy, Knowledge, Memory, and Board Games

Since this is a pro Java games programming book at its core, I am going to approach everything from this

important (for game development) static versus dynamic standpoint, and it just so happens to be a pretty

slick way to categorize games into three discrete categories (static, dynamic, and hybrid). Let’s cover the

static (fixed graphics), turn-based games first. These would include the “move-based” or “turn-based”

games such as board games, puzzle games, knowledge games, memory games, and strategy games,

all of which should not be underestimated in their popularity and marketability, especially where families

are concerned. Not all of your game customers are going to be teenage males, and this category of games

is also the most likely to be used for edutainment, a popular buzzword these days where education and

entertainment are fused together to further the success of the education part of that equation. There are a

dearth of fun, effective games for educational content, so this is a significant games business opportunity.

The thing that is important to remember regarding static games is that they have the capability of being

just as fun to play as dynamic games. Static games by their very nature have significantly less processing

overhead, as they do not have to achieve the 60 FPS real-time processing target in order to achieve smooth,

professional gameplay. This is because the nature of the game is not predicated upon continuous motion

but rather on making the right strategic moves. Moves are made when it is your turn to do so, which is why

these types of static games will often be referred to as move-based games.

There can be some form of basic “collision detection” involved in static games, regarding which game

pieces have been moved and to which location on your game board or playing surface. With a static game,

however, there is no danger of overloading the processor with collision detection because the rest of the

game board is static, with the exception of the one piece that is being strategically moved during that

particular player’s turn. Once that process of ascertaining the collision is completed, there is no (real-time)

collision detection needed until the next turn is taken by either the single player (in a single-player game) or

the opponent (in a multiplayer game).

The processing logic for strategy games is more strategy logic–based programming, geared toward

allowing the players to achieve a given end “win” given the right sequence of moves, whereas the dynamic

game programming logic looks more at what collisions are taking place between game sprites. Dynamic

games are focused on point score, which is generated by dodging projectiles, finding treasures, landing on

targets, killing enemies, and completing those types of level objectives in order to get to the next level, where

players can generate even higher point scores.

Complicated strategy games with lots of interrelated rule sets, such as chess, for instance, are even

likely to have far more complex programming logic routines than dynamic games feature. However, since

the execution of the code is not as time sensitive, the resulting gameplay will be smooth, no matter how

powerful the platform and CPU are, because the player is willing to wait for the game to verify the validity

of the move and score it, if appropriate. Of course, the game ruleset logic must be flawless for this type of

game to be perceived as truly professional. Therefore, in the end, both static as well as dynamic games, the

great ones at least, can be difficult to code, albeit for significantly different reasons. Next let’s take a look at

dynamic games, which tend to have high public profiles, appeal to younger player demographics, and tend

to be played individually, instead of by groups, students, or families.



Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

Dynamic Games: Arcade, Shooter, Platform, and Action Games

Dynamic games could be termed Action Games or Arcade Games and include a lot of movement on

the display screen. These highly dynamic games almost always involve shooting things, such as in firstperson shooters (Doom and Half-Life, for instance) as well as in third-person shooters (Resident Evil and

Grand Theft Auto) genres, or stealing things or evading scary things. Action sports games, such as football,

soccer, baseball, basketball, golf, and lacrosse, are also very popular in the dynamic games genre, and

they are almost always created using a photorealistic, i3D virtual world or virtual reality game simulation

environment. Driving games are another incarnation of this genre and also tend to use real-time i3D game

rendering technologies to provide the driver with an ultrarealistic driving simulation.

There is also the obstacle course navigation paradigm, such as commonly seen in platformer games

such as Donkey Kong, Pac-Man, or Super Mario Brothers. Platformer games are often arcade games, which

are typically 2D or 2.5D, which is called isometric. The arcade game ZAXXON was a great example of an

isometric game that was 2D, and looked 3D, or Tempest, where geometric shapes climbed up a geometric

well where the player shot down the side to prevent the climbing shapes from reaching the top.

It’s important to note that any genre of game can be produced using 2D or 3D graphic assets or can even

be produced using a combination of 2D and 3D assets, which is allowed by JavaFX 9.0 and which I would

term a hybrid.

Hybrid Games: An Opportunity to Leverage JavaFX Creatively

From a JavaFX Scene Graph assets perspective, a hybrid game would be one that used both 2D and 3D

assets, most of which we covered in Chapters 2 and 3. There is another type of hybrid, which could span

different game genres, which we just covered some of in the previous section. There are so many popular

game types that there is always a fantastic opportunity to create an entirely new genre of game by using a

hybrid gameplay approach. For instance, imagine taking some of the characteristics from a static (strategic)

game type, such as a board game, and adding elements of a dynamic (action) game type. A good example of

this would be Battle Chess, where chess pieces do battle to the death when they come into each other’s chess

board square.

In my Beginning Java 8 Games Development (Apress, 2014), I used JavaFX 8.0 to create a hybrid game

engine that has support for attributes of a platformer game, a shooter game, and a treasure hunting game. As

you can see in Figure 4-4, the BagelToons InvinciBagel game engine created in that book, where I cover i2D

games development, has elements normally found in different types of 2D games, including superheroes,

enemies, shooting, treasures, obstacles, hiding places, buildings, cars, landscaping, magic carpet cats, safe

cracking, food, and the like.


Chapter 4 ■ An Introduction to Game Design: Game Design Concepts, Genres, Engines, and Techniques

Figure 4-4.  My i2D game development book called Beginning Java 8 Games Development covers using sprites

to develop games

In summary, Java is positioned to allow game developers to deliver vanguard, hybrid games, containing

both 2D and 3D assets, as well as high-quality 16-bit 48 kHz and 24-bit 48 kHz digital audio. With a little bit

of creativity and the knowledge you are garnering during the course of this book, you should be able to pull

off what’s never been done before. This is especially true for areas that hybrid gaming will be beneficial for,

such as the areas of education (edutainment) and the workplace (business process gamification). This is

because Java is widely used in OSs and browsers, as well as in 64-bit platforms such as Android 5 - 8, which

have a majority market share and manufacturer following in consumer electronics. That said, it is important

to point out that JavaFX is not (yet) suited for i3D VR real-time 3D-rendered games with an HD or UHD high

frame rate, like those created using C++ for customized game consoles such as PlayStation or Xbox.


In this fourth chapter, we took a closer look at some of the more important game design concepts that we

will be using in our pro Java game development work process so that you have the foundational knowledge

for these things taken care of in advance, in the first section of the book.

I started out covering the key concept of static versus dynamic and how these are important for both

game design and game optimization, as too many dynamics can overload older single-core and even dualcore CPUs if game optimization is not an ongoing consideration throughout the game design, development,

and optimization process.

Next, you looked at some of the key components of game design and development, such as sprite

position, sprite animation, collision detection, physics simulation, flocking, or crowd dynamics, particle

systems, background animation, camera animation, digital video streaming, user interface design,

scoring engines, and gameplay AI logic.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

High-Level Concepts: Static vs. Dynamic Gaming

Tải bản đầy đủ ngay(0 tr)