Friday, August 29, 2014

So long, and thanks for all the fish!

For those who haven't seen Blazing Games yet, the final game was posted there today. While Blazing Games Inc. is closing, I do plan on continuing to develop games in my spare time. I do not feel it is appropriate to keep this blog going, as Blazing Games isn't so I have decided to start my own personal blog located at .

I am not going to go into details as to why it is closing down here, though in a few years I might write a post in my new blog about the decisions. I will say that I am going to back to university to complete my Bachelor degree. If any readers know of a Canadian company hiring part-time programmers (doesn't have to be game related) let me know.

I hope anyone reading this will join me on my new blog. If not, then so long...

Friday, August 22, 2014

NES Trivia Title and Results

From a development perspective, the title screen of the game is not that important. From a marketing perspective, it is vital as it is the first impression of the game that a player will receive. My personal opinion is somewhere between the two points of view. You want a title screen to be attractive but you do not want to spend too much time on creating the title screen. Some decent artwork and perhaps some simple animation will probably suffice for smaller projects. For larger projects with big budgets, some type of CGI may be what the project backer insists on.

For trivia, out title screen simply shows a graphical title while waiting for a button to be pressed. More elaborate games may have a menu of options. Different modes of play, options, credits, and instructions are possibilities. Handling a menu would be done similarly to how we handled answer selection in the main game. The different options simply jumping to a separate routine for handling the particular screen.

The only hard part of the title screen is displaying the graphical title. Once you realize that the graphics are just a bunch of tiles, it is not much of a leap before you realize that you can simply print graphics. The only real restrictions being that you are not able to use character 0 as that is the character that is reserved for indicating the end of a string, and that the length of the string be under 256 characters. In our case, most of the title image is empty space so we conserve ROM space by breaking the string into individual lines. It would certainly be possible to take advantage of the consecutive nature of screen memory to have multiple lines of graphical information in a string. Still, here is the code used for printing the N.E.S. part of the title.

CallClearScreen ' ',0,0

CallPrintStringAt titleNES1, 5,2,0
CallPrintStringAt titleNES2, 5,3,0
CallPrintStringAt titleNES3, 5,4,0
CallPrintStringAt titleNES4, 5,5,0
CallPrintStringAt titleNES5, 5,6,0

And here is the data for the print statements.

titleNES1 .db 30,10,32,32,32,30,32,32,32,30,30,30,30,32,32,32, 9,30,30,10,0
titleNES2 .db 30,11,10,32,32,30,32,32,32,30,32,32,32,32,32,32,11,10,32,11,0
titleNES3 .db 30,32,11,10,32,30,32,32,32,30,30,30,32,32,32,32,32,11,10,0
titleNES4 .db 30,32,32,11,10,30,32,32,32,30,32,32,32,32,32,32,10,32,11,10,0
titleNES5 .db 30,32,32,32,11,30,32,30,32,30,30,30,30,32,30,32,11,30,30, 8,32,30,0

The rest of the title screen is pretty much more of the same, though the press start and copyright messages are ASCII strings. Once the display is generated, we simply use the WaitForButtonPress and WaitForButtonPressEnd functions to wait to start the game.

The results screen is rendered pretty much the same way though has the interesting problem of having to display the score. Thankfully the score is a single digit number. This means that to display it, we only need to add 48 to the number to get the proper ASCII value for the number. For numbers greater than 9 we would need multiple digits which adds the problem of no BCD or division functions for the NES. We will be covering software multiplication and division shortly, but it is a complex topic so it is nice that we didn't need to get into it before creating this game. Here is the code for displaying the score.

ADC #48
; the cursor is already at the appropriate position in the PPU so
; simply need to send the character index to the PPU
STA $2007

And that is all there is to trivia. Of course, having randomly selected questions and mixing up the answers so they were not always in the same order would be nice. This requires quite a bit of work as we need to delve into the topics of entropy, pseudo-random numbers, and software multiplication. Software division will be covered as well as we will need it for displaying multi-digit numbers which is something the target RPG will need for sure. There is a lot to cover before we can do the full version of trivia, though I may have a couple of other simple games before we get to trivia 2. But…that will not be done on this blog as the Blazing Games Development blog is being shut down. More on that, and where future home-brew articles will appear will be covered next.

Friday, August 15, 2014

NES Trivia Gameplay

As covered in the NES Trivia Screen article, the code for this game is at . We are only covering the most relevant snippets of code. If you wish to look at the main game loop in its entirety search the code for the MainGameLoop label.

With the Questions displayed we now need to monitor the user input. To allow for the player to hold the up or down buttons down there is a delay between reads of the joystick that is initiated when the player performs an action. This works well for holding down the directions but rapidly clicking on a button doesn't work as well as it should as some of the clicks can happen between the delay. This will be fixed in the second version of trivia.

BNE MainGameLoop_adjustScroll
INC INPUT_DELAY ; Make sure if no input we update next frame
JSR ReadController1

Moving up or down is simply a matter of adjusting the CURRENT_ANSWER variable. Because there are only 4 possible answers (0..3) we can simplify the range checking logic by simply using the AND operation to force the value of the adjusted CURRENT_ANSWER to within the acceptable range. This technique saves us from having to have a conditional branch which, at least in my opinion, makes for more readable code. While people who are not familiar with boolean operations may disagree with this, if you are programming in assembly language a lot you will quickly get use to working with boolean operations.

BEQ MainLoop_checkButtonA
AND #3
JMP MainGameLoop_adjustScroll

The heart of the trivia game logic comes when the A button is pressed. The handling code waits for the button to be released and then calls DisplayQuestionResults. This function potentially prints a lot to the screen so we temporarily turn off the display so we can write to the PPU without any issues. It then sets up the print location before checking to see if the answer the player selected is the correct answer. The appropriate result string is printed, and if the answer is correct the score is increased. Finally, this function prints the explanation before returning to the main game loop.

LDA #$00
STA $2001 ; disable rendering

; set up print coordinates
TAX ; accumulator already 0
JSR SetScreenXY

; See if selected answer is correct
LDY #14 ; Offset to correct answer
BEQ DisplayQuestionResults_correct
CallPrintString incorrectText
JMP DisplayQuestionResults_explain

CallPrintString correctText

; set up coordinates for explanation text
LDA #0
JSR SetScreenXY
; print explanation
LDY #12
JSR PrintQuestionInfoString
LDA #011110 ; enable background + sprites
STA $2001

When we return to the main loop we wait for the press and then the release of a button so that the player has time to acknowledge the explanation. After this, we need to know if the question is the last question or not. If it is the last question, we jump to the summary screen loop. If it is not the last question, the pointer to the current question info structure is incremented by 16 (the length of the structure) and we call DisplayQuestion to get the next question displayed.

CPX #9
BEQ SummaryScreen
ADC #16
BCC MainLoop_showNextQuestion

JSR DisplayQuestion

We are now finished with the game's core logic. Essentially we have a game. The only thing missing from having a complete game at this point is the title and summary screens. Normally, these are not things that I would bother to cover as they are very straightforward, but as this is our first NES game, it is probably a good idea to cover them. This is what we will be doing next.

Friday, August 8, 2014

NES Trivia Screen

As usual I am only going to cover the snippets of code I consider most relevant for the discussion. For those of you who want to see all the code, it is located at @link to source code here@.

The core of the game is fairly simple. We start by clearing the screen and displaying the label for the current question. As the label always takes the form of “Question ???” we save a bit of memory by having the label string only create the ??? part of the string generating the full string on the fly. The label is underlined. This is done by taking advantage of the fact that the PrintString function returns the length of the printed string in the Y register. Notice that the use of macros makes the code quite a bit more human-readable.

CallClearScreen ' ',0,0
CallStrNCpy baseLabel, SCRATCH_PAGE, 0
LDY #0
JSR AppendString

; once created we print it
CallSetScreenXY 2,1,0
CallPrintString SCRATCH_PAGE
; underline Title
PHA ; save length of string to underline
CallSetScreenXY 2,2,0
PLA ; retrieve length of label string
TAX ; transfer to appropriate parameter for call
LDA #'='
JSR PrintRepeatedChar

Printing the question, answers, and later the explanation is all pretty much the same code but with different pointers being used, this is ideal code for a function. The desired string to be printed is part of the question info structure. We set Y to the offset within this structure to the pointer for the string we want printed. In case you are wondering, the term for a pointer to a pointer is called a handle. We copy this pointer to the zero-page SOURCE_PTR variable then call the PrintString function.

JSR PrintString

Now, as we did for underlining, we take advantage of the returned length value to determine how many rows were used for printing the string. I should point out that this is not always correct as the answers are indented by a couple of characters. This generally is not a problem but is something that has to be kept in mind when creating the data for the game. Divide the length printed by 32 to determine how many lines were printed. It is important to remember that the remainder from the divide is dropped. This means we need to add 1 to the result. As we are adding a blank line between rows this means we need to add 2 to get the appropriate next row.

TYA ; divide printed length by 32
CLC ; add it to current printed row so we know what line we are on
CLC ; add 2 so we know appropriate row for next print
ADC #2

While tracking the row for printing is important, we also need this information for handling the player choice. After calling the above function to print the question, we store the returned row number which will be the location of the first answer. We then call the function again for each of the answers storing the rows in subsequent memory locations. This is the equivalent of creating an array of rows. You may have noticed that there is an extra row stored. This will be used to display the results and explanation.

The players choice is represented by a right arrow sprite. The column the sprite appears on is set to 4 when the sprite is set up and never changes. The vertical placement of this sprite is based on the current choice that is selected which is stored in the CURRENT_ANSWER variable. The value in this variable is used to index the rows table we stored the row in above to determine the Y coordinate of the sprite.


At this point we have the question displayed with an arrow to the currently selected answer. Getting player input and determining if the selected question is our next task.

Friday, August 1, 2014

Drone Defence Postmortem

It is a new month so time for my postmortem of my Blazing Games release for this month. The game is my first game created with OpenFl which is the flash-like library for Haxe. I am not sure why I decided to try doing a similar game to what I did as my Game Maker test game, but I did. The game needs a lot of polish yet, but for the limited time I put into it worked out great.

What Went Right

OpenFL is a flash-like library for Haxe. While Haxe already supports the Flash API for projects exporting to Flash, OpenFL expands this to all the other platforms that programs can be exported to. At least in theory. As I have done a lot of work using the Flash API, this is a great feature for me as it makes getting up to speed with Haxe much easier. If you are not familiar with Flash, this is probably not that big of a deal but it is still a decent library. I have tried a number of different Flash-like libraries for a variety of languages to various results. This library, from what I did with it, worked exactly like I expected (at least until I exported for HTML5) which was nice considering the learning curve that Haxe gave me.

Mixed Blessings

Haxe is a rather interesting language as instead of compiling to machine-language (or a virtual machine-language) it compiles to a number of different programming languages for a variety of different platforms. The idea here is that different platforms have different key languages for development. Windows is C++, IOS/OSX was Objective-C, Android is Java, the internet is HTML5 or Flash. The idea here is that you code in Haxe then fine-tune for each platform in it’s preferred language. It is, however, it’s own language with it’s own way of doing things. While similar to ActionScript, it is different enough to occasionally throw a wrench in the works. One of the nice things it does, which I wish C and all its decedents did, is automatically break switch statements unless you explicitly tell it not to. One thing I didn’t like is the requirement of iterators in for loops.

What Went Wrong

Unfortunately, as is often the case with projects still in development, there are issues with OpenFL. In my case, the HitTestObject method did not work in the HTML5 export. As this is essentially just a bounding box test, I replaced my hit test code with calls to check for rectangle intersections between the bounding boxes for the objects. The problem here then became there always being a collision. After checking the results of the getBounds function, I discovered to my dismay that the width and height of the object were the canvas size and not the size of the sprites. Worse, requesting the width and height of the sprite also returned the canvas width and height. These bugs don’t exist in the other export formats I tried so I ended up releasing the Flash build of the game instead of a HTML5 build like I was originally planning to. I will have to look into this issue a bit more as I really liked OpenFL and think if issues like this can be fixed this would be a great platform to develop for.