{"assets":[{"original":"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/06\/nes_game-550x371.png","local":"\/data\/posts\/2014\/06\/d2eea27eb34420e21631f718787beeda.png"}],"author_link":"author\/gatechgrad\/","author_name":"Levi D. Smith","cat":"MiniLD","categories":["MiniLD"],"comments":[],"epoch":1403541480,"event":"","likes":16,"metadata":{"p_key":"80584","p_author":"Levi D. Smith","p_authorkey":"0","p_urlkey":"289702","p_title":"Creating My First NES Game","p_cat":"MiniLD","p_event":"LD29","p_time":"1403541480","p_likes":"16","p_comments":"0","p_status":"WAYBACK","us_key":null,"us_name":null,"us_username":null,"event_start":"1398384000","event_key":"22","event_name":"LD29"},"source_url":"2014\/06\/23\/creating-my-first-nes-game\/","text":"

For this mini-LD challenge, I decided to try to create a game for the original 8-bit Nintendo Entertainment System (NES).\u00a0 This was the first game console that I ever owned as a kid, so creating a game for it was something that I had always wanted to do.<\/p>\n

Unfortunately, to create an NES game, everything has to be written in assembly.\u00a0 When I was at Georgia Tech working on my computer science undergraduate degree, I did have one project where I had to write assembly code for an emulated MIPS system.\u00a0 The emulator was called SPIM (MIPS spelled backwards), and it looks like it is still available for download<\/a> today.\u00a0 While writing assembly is not completely foreign to me, it definitely is not one of my favorite things to do.\u00a0 However, it was my only option for creating an NES game, and it was a nice refresher since I had not written any assembly code in years.<\/p>\n

\"Getting<\/a>

Running NES assembler to get a sprite to move on the screen in the NES emulator<\/p><\/div>\n

The good news is that I found a great series of tutorials on the basics of creating a NES game<\/a> written by bunnyboy<\/a> at NintendoAge.\u00a0 He also has a wide variety of NES homebrew games available on his site<\/a>, and an adapter for sale which allows compiled NES games to be played on actual NES hardware<\/a> using a flash drive.<\/p>\n

I started by working through weeks 1 to 5 of the \u201cNerdy Nights\u201d tutorials.\u00a0 The first tutorial<\/a> is the basics of binary and hexadecimal number systems.\u00a0 The second tutorial<\/a> goes over the architecture of the NES, and provides a barebones example of an NES game with assembly code and example CHR ROM dump.\u00a0 I liked this incremental example approach, which allowed me to just to get something to compile and run, before tackling things like sprites and sounds.\u00a0 I tried a few different NES emulators, but FCEUX<\/a> seemed to be the one that most people recommended these days.\u00a0 It was also available for download from the Ubuntu software center, so the installation was simple.\u00a0 However, the program that is used to compile the NES assembly code called NESASM3 is only offered as a Windows executable, so I had to install Wine to run it.\u00a0 After the setup was complete, I was successfully able to generate a .NES file, which ran in my NES emulator.\u00a0 However, it only displayed a blank screen, but it didn\u2019t crash which was a start.<\/p>\n

In the third tutorial<\/a>, it goes into the details of the 6502 assembly code, which is the instruction set used by the NES assembler.\u00a0 It has all of the standard operators that you would expect, like \u201cload\u201d and \u201cstore\u201d for writing to registers and memory.\u00a0 The NES is a fairly simplistic system, which only has three registers which are the Accumulator, Register X, and Register Y.\u00a0 The instruction set also has simple math functions like \u201cadd\u201d and \u201csubtract\u201d, and control operators like \u201cjump\u201d and \u201cbranch\u201d.\u00a0 The example of this lesson gave enough to get started to change the color of the screen based on the selected palette value.\u00a0 I tested by changing the screen color to different combinations of red, green, and blue by modifying the binary code of the byte which controls the screen color.<\/p>\n

The fourth tutorial<\/a> made things a little more interesting, as it taught me how to display a sprite to the screen and change its colors by modifying the color palette values.\u00a0 The color code chart at the top of the page was a very helpful reference.\u00a0 The fifth tutorial<\/a> shows how to display even more sprites, and how to move them around on the screen using the controller.\u00a0 The example code just shows how to detect input from the A and B buttons, so I extended that code to detect all buttons on the NES controller.\u00a0 The test for the other buttons are just detected by additional \u201cloads\u201d from the from the address of the controller port ($4016).\u00a0 It also only moved the sprite in the left and right direction, so by writing to the sprite\u2019s Y memory location, I was able to make the sprite move vertically when the up and down buttons are pressed on the virtual D-pad.\u00a0 The example only moved one \u201ctile\u201d of the sprite, so I extended the assembly code so that it moved all four tiles together.<\/p>\n

In order to make the sprites for my game, I used a program called YY-CHR.\u00a0 It is another Windows executable, but it also runs well under Ubuntu using Wine.\u00a0 The only issue that I encountered was that I was not able to create a bitmap in Gimp, and then copy and paste it into YY-CHR.\u00a0 Therefore, I created my own \u201chand drawn\u201d smiley face sprite, which is made up of four 8\u00d78 pixel tiles.<\/p>\n

I quickly discovered that writing everything in assembly was going to be a real pain.\u00a0 Therefore, I started writing a simple script that would read some parameters out of a file.\u00a0 Since this is going to be simple, I decided to write the script in Ruby.\u00a0 First, I took the 6502 assembly that I wrote and broke it into five pieces: the header (which doesn\u2019t change), controls (player input), palette, sprites, and footer (also doesn\u2019t change).\u00a0 I put each section of assembly into its own text file, and the main nesc.rb script just reads the contents of those files, and then calls NESASM3.exe at the end.\u00a0 I tested my script, and it successfully compiled an .NES image which I could play in my FCEUX emulator.<\/p>\n

However, that isn\u2019t very interesting since it always just compiles into the same game.\u00a0 As a starting point, I created a game.xml file, and defined four colors which define the four colors of the current palette.\u00a0 In the included nes_palette.rb file, I started defining colors based on the tutorial table, and stored those color constants and the corresponding hex values into a Hash.\u00a0 Then, in another script which reads the game.xml file using REXML and XPath, I stored the user\u2019s defined palette colors in array.\u00a0 Then the palette code just looks up those values in the Hash to get the correct hex values to write palette data using the .db directive.\u00a0 Finally, I added a <palette> tag to contain these <color> elements.<\/p>\n

\u00a0<\/p>\n

\"Changing<\/a>

Changing the palette colors of a sprite using user defined values in an XML file<\/p><\/div>\n

\u00a0<\/p>\n

I expanded my XML file specification format by adding a <player> tag for player attributes.\u00a0 The first player attribute I added was <speed>, which controls how fast the player moves around on the screen.\u00a0 This is currently a hexadecimal value, which is either added or subtracted (ADC \/ SBC) from from the x and y memory locations of the player\u2019s tiles.\u00a0 In my original code, it only moved one of the player\u2019s tiles, however with my Ruby compiler script I was able to create a simple loop to apply the add or subtract to each tile in the player sprite.\u00a0 In my user input code, I made a hash table of the user defined values so that it can be passed around to each of the functions.\u00a0 One issue I had was sometimes the tiles would not move at the correct speed.\u00a0 I found that this was because\u00a0 I was not clearing the carry flag.\u00a0 CLC must be called before every ADC, and SEC must be called before every SBC.<\/p>\n

\"Creating<\/a>

Creating a simple sprite in YY-CHR<\/p><\/div>\n

Now that I had a way to display a sprite to the screen, I needed a way to change the sprite displayed on the screen.\u00a0 I created a simple rocketship sprite which is four tiles in YY-CHR and saved it to gatechgrad.chr.\u00a0 In my game.xml file, I created a new tag element called <spritesheet>, which holds the name of the CHR file containing the sprites to use for the game.\u00a0 I updated my nesc_userinput.rb script to store this value into the userOptions hash table, which is passed to the new nesc_footer.rb which generates the 6502 assembly to read the data from that CHR file.\u00a0 The NESASM3 assembler will throw a compile time error if the CHR file name is invalid.<\/p>\n

While making these updates, I created a Makefile which simply recompiles everything (ruby nesc.rb; wine NESASM3 temp.asm) whenever the game.xml file is updated.<\/p>\n

\"\"<\/a>

game.xml which defines various properties of the NES game<\/p><\/div>\n

In the game.xml file, I added a new <sprite> tag inside of the <player> tags, and the <sprite> tag contains multiple <tile> tags which have \u201crow\u201d and \u201ccol\u201d as attributes and the tile number (in hexadecimal) as text.\u00a0 I updated the nesc_userinput.rb again to load all of these values into the user option hash table.\u00a0 That data then gets used by the nesc_sprites.rb file to write the assembly for the sprite data.\u00a0 After this was completed, I was successfully able to change which tiles composed the player sprite through the game.xml file.\u00a0 It is interesting that most sprites for NES games use sequential tiles, where the head may be tiles 0 and 1, body 2 and 3, and feet 4 and 5.\u00a0 This makes the reads sequential, but it is more difficult to edit a sprite sheet that way since the head, body, and feet are all of the same tile row.\u00a0 For my game, I just specified 0 and 1 ($00 and $01) as the top part of my ship and 16 and 17 ($10 and $11) as the bottom, that way the sprite is easily editable in the sprite sheet.<\/p>\n

The next step is to get the ship shooting.\u00a0 I added a new bullet tile to the spritesheet using YY-CHR.\u00a0 In the nes_sprites.rb script, I added a new line to load the bullet sprite.\u00a0 Then I increased the loop counter in the header to read the new sprite by increasing the CPX value to #$30.\u00a0 This should actually load 12 tiles, since each tile is defined by 4 bytes (x, attributes, tile index, y).\u00a0 In the controller code, under the ReadA: label, which is executed when the A button is pressed, I set bullet\u2019s x and y location values to the position of the spaceship.\u00a0 I used the values of the first spaceship tile, to make things simple for now.\u00a0 After the control handling code, I added a section to add (CLC\/ADC) the bullet speed to the x position of the bullet.\u00a0 Now, the bullet\u2019s position will fly from left to right on the screen.\u00a0 In the game.xml file, I added a <bullet> tag which contains <speed> containing the speed of the bullet in hexadecimal, just like the player speed.\u00a0 This value is read and used to determine the bullet speed in the game.<\/p>\n

Unfortunately, when the bullet reaches the right edge of the screen, it will loop back to the left side.\u00a0 Also, if the A button is repeatedly pressed, the one bullet will reset back to the location of the spaceship.\u00a0 I created a variable in the assembly code to hold the \u201calive\u201d flag.\u00a0 When the A button is pressed, I load a 1 (LDA #$01) and store it in the alive flag.\u00a0 In the UpdateBullets section, I load the bullet alive flag and compare it with 1 (CMP #$01) and jump to the end of the section if it is not equal (BNE).\u00a0 This will make the bullet stop if it is not alive.\u00a0 Using this reference<\/a> I learned how to check if a value is greater than or less than a number by using the BCC and BCS (\u201cbranch carry clear\u201d and \u201cbranch carry set\u201d) instructions.\u00a0 Using BCC, if the bullet\u2019s x location is less than 240 (#$F0) then it will jump to the end of the section, otherwise it will set the alive flag to zero.\u00a0 I used 240 instead of 255, due to the values looping back around to zero when value exceeds the 255 limit for a byte.\u00a0 As long as the bullet speed is less than 15 there should be no problems.\u00a0 There are techniques for checking if the summed value exceeds 255, which is used for 16-bit numbers, so I will investigate that later.\u00a0 To fix the other bullet position reset problem when A is repeatedly pressed, after the A button is read I simply loaded the bullet alive flag, compared it with one and jumped to the end if it is equal.<\/p>\n

\"\"<\/a>

Displaying player ship, missile, enemy ship, and score on the game screen.<\/p><\/div>\n

The next step was to get an enemy on the screen.\u00a0 I used YY-CHR to create a new enemy ship sprite on my spritesheet, which is another four tile sprite.\u00a0 I added a new <enemy> tag to my XML file, which contains all of the properties of the enemy.\u00a0 In the Ruby code, I added an array to hold all of the enemies, and an Enemy class which contains the memory locations of the X and Y position of the enemy.\u00a0 I also defined an \u201calive\u201d flag variable for the enemy, so that I can set it to dead when it is destroyed.\u00a0 In the future, I could also add a life value, if the enemy takes multiple hits to be killed.\u00a0 To get the enemy moving, I just simply keep subtracting the ship\u2019s speed value to the x location variable, so the enemy will continually keep moving toward the left side of the screen.\u00a0 This isn\u2019t really impressive, but at least it\u2019s moving which gives the game a bit of a challenge.\u00a0 When the ship\u2019s \u201calive\u201d flag is set to zero (#$00), then the enemy ship stops moving.<\/p>\n

Displaying text in the game is done by writing the text tiles to background name table.\u00a0 For my spritesheet, \u201c0\u201d starts at tile $00 and goes up to \u201c9\u201d at tile $09.\u00a0 The letter \u201cA\u201d starts at tile $0A and goes up to \u201cZ\u201d at $23.\u00a0 The letter mappings can be seen in the PPU viewer of FCEUX.\u00a0 Using the technique explained in the tutorial<\/a>, I was able to display the score up to six digits at the top of the screen.\u00a0 I created a Hash in the script to map all of the letters to the equivalent tile numbers.\u00a0 It may be possible to write a function to do this conversion, but I will leave that to do later.<\/p>\n

I separated all of the object code into its own Ruby script, which held the memory locations of all of the tiles for each of the objects.\u00a0 The update code for each of the objects was also moved to another script containing update subroutines.\u00a0 In the update script, the locations of the tiles are set based on the location of the object, plus an offset which is added based on the tile\u2019s row and column in the sprite.<\/p>\n

Next, I added collision detection between the bullet and the enemy ship.\u00a0 This was accomplished through a series of CMP, BCS, and BCC statements which check to see if the bullet\u2019s x and y position are within the enemy sprite.\u00a0 I subtracted 4 from the left and top bounds of the enemy ship, so that a collision is detected when the bullet\u2019s x or y is equal to the enemy ship\u2019s x or y, since there is no \u201cgreater than or equal to\u201d operator.\u00a0 When the bullet collides with the enemy ship, the bullet alive variable is set to #$00.\u00a0 Then JSR is called to execute the code to increment the player\u2019s score.\u00a0 This collision code just checks to see if the bullet\u2019s x, y location is inside the enemy ship rectangle to make things simple.\u00a0 Modifying the code to do rectangle\/rectangle would complicate things too much for this simple game.<\/p>\n

The next step was to get a simple sound to play when a bullet is shot, which I got working by following this tutorial<\/a>.\u00a0 This just plays a simple beep, and I modified it so that it doesn\u2019t continually play by enabling the length counter and setting it to 0001.<\/p>\n

\"Two<\/a>

Two enemies on screen with six digit score<\/p><\/div>\n

I added a second enemy by adding to the enemy array defined in the object script, and set the appropriate address values for the x, y, and tile index values.\u00a0 For now, I just duplicated all of the bullet collision and enemy movement code for the second enemy.\u00a0 I added a new \u201cgametime\u201d varaible that gets incremented on every NMI interrupt break.\u00a0 When the gametime variable is equal to #$FF, then both enemies are set to alive and their y position are set back to a position on screen.\u00a0 This gives the appearance of new enemy ships spawning.<\/p>\n

In order to have a game over state, I added a new variable to track the player\u2019s lives.\u00a0 Whenever the player\u2019s ship collides with an enemy ship, a new subroutine is called which subtracts one from the player\u2019s lives, and set the game state to \u201cGAME OVER\u201d if the number of lives are equal to zero.<\/p>\n

Using my sprite editor, I created a title graphic for the game.\u00a0 However, I quickly found that it isn\u2019t so easy to change all of the background tiles on the screen at once.\u00a0 I tried a few things, but I had little luck.\u00a0 After digging around on some forums, I found that it really isn\u2019t possible to update the entire background in one update, like updating the screen in modern game programming environments.\u00a0 One poster said that it\u2019s only possible to update 3 rows or columns in one update, or the game will start to slow down.\u00a0 For now I\u2019m leaving the title screen out, but I\u2019m hoping to eventually get it working in the game.<\/p>\n