© Wallace Jackson 2017 575
W. Jackson, Pro Java 9 Games Development, https://doi.org/10.1007/978-1-4842-0973-8_23
CHAPTER 23
Completing the Gameplay
Code and Player Proofing
Your Event Handling
Now that your i3D UI and its event handling, not to mention most of your animation and digital audio, are in
place and working, it’s time to finish loading a basic level of content (60 images, 240 answers, and scoring)
in your code base. We will do this in the first part of this chapter, so I can show you what I did to finish up
the gameplay and there is no loss of coding continuity throughout the book. Most of this coding is copy and
paste, thanks to the way I set up the game design code, and making sure answers match up and work well
when testing the game.
During this chapter, we’ll finish populating the 20 setupQSgameplay() methods with the
text-based answer content that matches up with the visuals (questions). We’ll also be finishing the
createQAprocessing() method, which holds the answer scoring code that updates the Score UI panel. The
players will use these to select the correct answer, revealing what the visual for that square represents and
scoring their answer. This means you’ll be adding several hundred more lines of code during this chapter,
approaching 1,750 lines of code before you are finished.
Once we finish coding the bulk of the gameplay “answer display, selection, and scoring” infrastructure
and test each square to make sure it is working, we can create the error-proofing portion of the Java code.
This results in a professional game that makes sure the players use it properly. This involves using Boolean
variables (called flags) to hold “click” variables; once a player clicks the spinner, game board square, or
answer Button UI element, the elementClick variable is set to false so that your game player cannot click it
again and “game” the gameplay code.
For instance, your player might click your correct answer Button UI element multiple times, which
would run up the “Right:” (answers) portion of the scoreboard! I call this “user proofing” or “error proofing”
the code, and it is a fairly complex process (as you will see in this chapter), which can sometimes go several
levels deep. For instance, we will first protect all game board squares from being clicked twice and then go
down one more level and protect a quadrant’s game board squares so that only the selected quadrant in
each round of play can be selected by a player.
We will also be adding the final animation, which takes the camera back out to the game board spin
view of the game so that a player can invoke a random spin to select the next quadrant (animal, vegetable,
mineral, or place topic). This will be done by adding a bright yellow Let’s Play Again Button element to the
top level of the board game UI design. We have a ton of work to do during this chapter, so let’s get started!