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.

Friday, July 25, 2014

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:

.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.

Friday, July 18, 2014

RPG Maker VX Ace Review

Sorry for not posting last week. Here is my review of RPG Maker VX Ace. It is a fairly long review which is broken into good, bad and ugly sections.

The Good

I actually consider this to be a really good program that I would gladly use to develop games in if it were not for the items in the ugly section. Before I get to the ugly points, lets first look at where the program excels.

Map Editor

When you consider that RPGs consist of multiple maps it is important that you have a decent map editor. Thankfully the map editor is very nice. It is tile based with each map having a tile-set that the map is made of. Tile-sets are made up of one or more image files. It is possible to share images between tile-sets which can reduce the number of necessary image files.

My favorite feature of the map editor is smart tiles. These tiles work by looking at the surrounding tiles and choosing the appropriate tile. For example, let's say you were adding a 4x4 tile rug to a room. The corners and edges would become the appropriate border pattern while the centre four tiles are the mid-carpet image.

The map supports multiple layers. Essentially you have your floor/wall layer which various decoration tiles can be placed over top of. This allows you to have things such as walls that have pictures on them or tables and chairs in the middle of the room. Tiles have three states of enterability. They can be solid, appear over the player or appear under the player. Each tile can also have an event placed on it. Events can have their own sprite and have scripts attached to them. I will cover events in more detail in the scripting section.


The database holds all the actors, classes, skills, weapons, armours, enemies, troops, states, tile sets, common events, system, and terms that the game uses. Editing these is what makes your game unique. There is a default starting database that is set up for your typical fantasy game. If you are not developing a fantasy game or want to create an original game then you will pretty much want to get rid of most of the stuff in the database and start from scratch.

Database pages generally give you a list of all the items in that category. The number of items in a category is set to a certain number of entries, but those can be changed to however many items you need. Each item then has a simple to fill out form making creating and editing items very simple.


The power of any game engine is largely dependent on how good the scripting system is. There are two parts to this factor. The actual language(s) the engine supports and how much the API for the game lets the player control the engine.

Language-wise RPG Maker VX Ace uses the Ruby language. This is a very flexible and powerful language but not something easy for a first-time programmer to grasp. To allow non-programmers the ability to create scripts, the program also offers a menu-based scripting language. This is a fairly easy to use language where you assemble commands based on typical RPG actions and fill out dialog boxes with the details of what you want to do. There is enough actions that you can accomplish most game tasks.

For those going with Ruby, which I never did for First, you have access to an API that gives you access to pretty much everything you would want to do with the engine and even gives you access to the windows API giving you a lot of power if you absolutely need it.

The Bad

While this is a great tool, there are some rough edges.

Database dependencies

While the database is nice to use, there is one really annoying thing about it. Many categories of items depend on items in other categories. If you are creating an encounter in the troops tab, you need to make sure the monsters have already been created. The monsters need to have skills and items set, and so on. What I would have liked to have seen is the option to create a new required skill or item on the fly so that when creating something you are not jumping back and forth between tabs.


I covered the packaging issue in my postmortem of my first RPG Maker game. The tool for creating a distributable package does not analyze your game for the assets that are actually used but instead includes all the files in the resource manager. This means you need to manually remove any items your game does not need otherwise it will be included in the distribution. If you are doing a total conversion, this may not be that bad as you can start by removing everything and only adding back what items you need but this is still a lot of work that could have easily been automated.


The documentation that comes with the package is kind of sparse. It covers the basics of the tool and has an API reference for Ruby programmers. It has no tutorials on how to use the game nor any explanation of how the stats in the default database work. To find answers to these questions requires searching forums or delving into the ruby code and spending hours looking through the database to piece how things work. There are some really good RPG Maker VX Ace tutorials on the internet, which you really should go through before using the tool for the first time, but nothing with the package.

The Ugly

None of the bad items above are enough to deter most people from using the tool. I would too, but there are three issues that prevent me from doing so.


The game resolution is really ancient. Anybody who has played a RPG Maker game probably has noticed the small window that the game is played in. While it is possible to get past this limitation by liberal use of Ruby scripting and Windows API calls, this would be a huge amount of work. I am hoping that if there is another version of RPG Maker released that it will at a minimum address this issue. Possibly by supporting different resolutions of tile-images though even the simple solution of scaling tiles would be sufficient for many people. If RPG Maker VX Ace had proper support for HD resolutions then I would probably be developing a commercial game in it right now despite the other two ugly items.

Windows only

Having used cross-platform languages for over a decade, I really don’t understand why developers still release tools that only create stuff that will run on Windows. Windows is such a large base that this is not an outright killer, but when combined with the resolution limitations makes it so for me. Minimally I would like to have the ability to export games to OSX and Linux. Ideally support for tables as well. Even if you had to pay extra for the ability to port to different platforms, this would be a great feature to have.

DLC Licensing

One thought that I had was to simply use RPG Maker as a prototyping tool and then find a way of exporting everything to another engine that overcame the resolution and platform limitations of the tool. Making this much more complicated is the fact that all the built-in graphics as well as most of the DLC theme packs are licensed only for use if the game is published as an RPG Maker game. As most of the DLC packs that have this limitation don’t explicitly mention this until after you have bought/downloaded them, this is exceedingly annoying. While this deters people from jumping ship to a different tool, it also prevents people from using the tool. This is unfortunate as it would be a great prototyping tool even without proper export commands.


While I would not rule out using RPG Maker VX Pro as a prototyping tool, I would make sure I did so by making sure all the music and artwork used was my own (or licensed for use outside of RPG Maker). It is a really good tool but the resolution and lack of cross-platform capabilities makes it unsuitable for my needs. I am really hoping that a new version that addresses at least one of the above issues is released soon as I would quickly grab that tool.