Designing NES Trivia

As I have said before, and have heard other people say as well, trivia is a trivial game to create. It consists of a set number of rounds. Each round has a question presented to the player with the player choosing the answer from one of a set number of answers. Once the player selects his or her choice, they are told if they are correct and an explanation of the correct answer is given.

This can be represented by a fairly simple data structure:
0..1 Pointer to label for the question string
2..3 Pointer to question string
4..5 Pointer to first (0) answer
6..7 Pointer to second (1) answer
8..9 Pointer to third (2) answer
10..11 Pointer to fourth (3) answer
12..13 Pointer to explanation
14..15 Correct answer number

The correct answer number only needs a single byte but uses a pair of bytes for the simple reason that this makes the structure 16 bytes. Powers of 2 are always nice to have as that allows you to take advantage of the bit-shifting operations instead of using more costly multiplication. When you consider that the 6502 does not have multiplication instructions, meaning that software multiplication needs to be done, this is a very important consideration. The actual implementation of a question looks like this:

questionInfo:
.dw q1_label, q1_question
.dw q1_answer0, q1_answer1, q1_answer2, q1_answer3
.dw q1_explanation, 2
; additional question info structures follow this...
; then we have the actual string data
q1_label: .db "One",0
q1_question: .db "The original Japanese version "
.db "of the NES was called?",0
q1_answer0: .db "Nintendo Entertainment System",0
q1_answer1: .db "Adam",0
q1_answer2: .db "Nintendo Family Computer",0
q1_answer3: .db "Nintendo Advanced Video System",0
q1_explanation: .db "The Nintendo Family Computer "
.db "became better known by the short"
.db "name: Famicom.",0

You will notice that strings are specially formatted to take advantage of the fact that the lines are 32 characters long. Extra space characters are added to fill out lines when necessary. While it would certainly be possible to write code to do the formatting for us, for this first version it is not necessary. The decision to write formatting code will depend on how much storage space is wasted by extra characters for formatting. When we get to the point where code to format text will take significantly less memory than will be saved by embedding formatting into the strings then it will be worth writing the code.

The game itself consists of three separate screens. The title screen and results screen are simple text displays with nothing special about them. The main game screen is fairly simple as well but has three separate phases of operation. The first phase displays the question and answers. The second phase has the user moving a pointer between the four different answers and determining which answer the user has selected. The final phase is determining the results of the user selection and displaying them as well as the explanation. Development starts with getting the game screen to work. Once it is working the game can be completed by adding the title and results screens. That is what we will be focusing on after next month's postmortem.