Chapter 23 ■ Completing the gameplay Code and player proofing your event handling
Use a Run ➤ Project work process, shown in Figure 23-30, to test an entire cycle (or two rounds of
gameplay).
Notice in Figure 23-30 that our testing process has revealed another problem! It turns out that testing
for square clicking is not “deep” enough to guarantee flawless gameplay! You can click another quadrant’s
squares when a certain quadrant has “landed” or been randomly selected for gameplay. This requires that
we add another level of protection to the game and that we must actually create four squareClick variables
(one for each quadrant) to really thoroughly protect our gameplay completely. Let’s modify our code in the
next section of the chapter to accomplish this using squareClick1 through squareClick4 boolean variables
and testing on a per-quadrant basis.
Quadrant-Level Protection: squareClick per Quadrant
Let’s change our squareClick code thus far to accommodate per-quadrant square checking. The first thing
that we will want to do is to change squareClick at the top of the class to be squareClick1 to squareClick4
(to match up with your quadrants). We also need to change the testing in the createSceneProcessing()
method to match the squareClickN variables with each of the four quadrants, so if(picked == Q1S1 &&
squareClick1) would be the modification, for instance, and if(picked == Q2S1 && squareClick2), and so
on, as shown highlighted (for quadrant 4) in Figure 23-31. The Java code for this change is fairly subtle, and
the amount of code is large and somewhat repetitive, so I’m not going to list it here. Figure 23-32 shows the
slight (but significant) modification I’m referencing.
Figure 23-30. Use Run ➤ Project to test code; notice that clicking another quadrant square sets that quadrant
image