Chapter 22 ■ SCoring engine: Creating the SCore Ui LayoUt and SCoring the ContentI would add (am going to add after I turn in this chapter) the answers and scoring for one game board
square at a time, until all 20 game board squares are in place. Adding future game board square options can
be easily done. You just increment the pickS1 through pickS20 variables by 1 using the random.nextInt(n)
variable to add four through however many different random image subjects you want to add to each game
board square. Adding an additional round of random content would amount to adding 20 new Button
answer rounds (80 answer options) and scoring those 80 new answers in your scoring logic, which would
amount to 160 lines of code, or about 240 lines of code per game board content depth addition. Adding more
depth to game board content means players will see duplicate content less as they play the game over longer
periods of time. You could also add code to track used content, if you wanted.
Once you proliferate the rest of the content into answers and scoring logic, you will have finished the
bulk of the game design and development work process. In the chapters that remain, we will look at error-
proofing the UI design so users are forced to use it correctly in the course of playing the game, as well as
things such as optimization and code profiling using the new Java 9 NetBeans IDE.
Summary
In this twenty-second chapter, we learned about how to implement a Score UI panel on the lower-right
side of our i3D board game design. We also learned how to change the score in the numeric portion of this
scoreboard using ActionEvent handling on the Button UI elements that live in the Q&A panel, which we
created in the previous Chapter 21. This essentially puts us into a position where we can finish both coding
and scoring the individual square (and quadrant, once the square is selected) gameplay, where a visual
question regarding the content is answered and scored. (I have to do this before I start writing Chapter 23 .)
This means that this was another of your heavy coding chapters as you constructed 20 custom methods,
setupQ1S1gameplay() through setupQ4S5gameplay(). You also placed conditional if() structures for each of
your Button elements scoring these in your createQAprocessing() event handling infrastructure. You’ll still
need to be sure to cross-check the image assets between all of your board game methods, and finally, you
will need to test all of this code together to make sure it works properly for each game board square.
In Chapter 23 , as part of gameplay protection, we’ll of course reverse the camera animation after the
answering and scoring have been completed and animate back to the more oblique view that is needed to
review the game board spin optimally. We will also prevent clicking any UI element that can be clicked so
that users can select only one topic and can spin the board once, for instance. We are by no means finished
with the game design work process!