NES Character Sets

A character set, also known as a tile set or pattern table, is simply a collection of 256 8x8 tiles which are used to build the display. There is no built-in character set for the NES so at least one needs to be provided. Without using any memory managers (a complex subject that will be covered when developing the map games) the NES supports 2 character sets. One for building the game screen with and optionally a second set for sprites.

There are a number of tools available for the creation of NES character sets, with YY-Chr being the tool that I currently am using. There are others available and the format for character sets is simple enough that it would be fairly easy to create your own tool for editing or converting images into character sets. As some of the tools I am creating for editing map data is similar to what would be needed, I may develop a very simple character set editor myself. It is also possible that the cartridge contains RAM for the character set in which case you can manipulate the character set in code.

Each character is 16 bytes with with the 256 characters in consecutive order. In other words, the first 16 bytes are for the first character (index 0), the next 16 bytes are for the second character (index 1), and so on. As characters make use of a 4-color palette, two bits are needed for each pixel. This is where things can be confusing as instead of putting the bits together, they are stored as separate bit-planes. Bit-planes store color information by combining separate proper bitmaps to form the color as shown in the following image.

The image shows the high bit first followed by the low bit, which is the opposite order that the NES expects the planes to be stored. The first 8 bytes represent the low-order bits with the next 8 bytes being the high-order bits.

Now that we know how graphics are stored, we need to create a character set for use in the trivia game that we are ultimately going to make. That will be covered next.

Spikey Bird Postmortem

This post is slightly late as I wanted to create a game for Flappy Jam. I was going to do this last weekend but as is too often the case, things came up so my plans got postponed.

What Went Right

When I am coding a game, I tend to use the approach of just using placeholder artwork (generally coloured blocks and spheres) replacing it with art once the game is functional. Unity isn’t really a programming-based platform so this approach just didn’t feel right. Instead, the artwork was created first and plugged into the Unity project. This approach really worked well which probably isn’t too surprising as Unity is aimed at designers. The nice thing about this approach is you get something closer to the final product right away.

Mixed Blessings

Writing a script to generate the level on the fly is something that is right up my alley. Procedurally generated content in theory offers unlimited replay as no two games will be alike. In reality, the content always seems to be similar enough that the replay value is never as great as it should be. Controlling the difficulty is also not as easy as it would be with hand-built levels. When it comes to a graphical design tool you also have the disadvantage of not having the level visible until you are running the game.

What Went Wrong

One of the cardinal rules of Game Jams is “be familiar with your tools/language before starting.” I am not familiar with either Unity or with C# so developing a game using Unity with C# for the scripting language was probably not a wise decision. Of the 20 hours I spent creating this game, over half of the time was spent searching documentation and the internet for information. Minor things, such as finding the length of a list (C# Lists use Count instead of the length that I am use to) had to be figured out each time eating up not only the time spent in finding the answer but the extra cost of being knocked out of flow. That said, when you think about how quickly I could have created this game had I already been familiar with Unity/C# I can see why the platform is so popular. But if you are not familiar with the platform you are using, the short timespan that a game jam gives you is not the place to be learning a tool/language if you actually want to get something released.

My overall impressions of Unity are mixed. Lets face it. Unity is very much design driven while I am more programming driven. A lot of the way to do things in Unity are not the way I would do things but the power you are getting out of the tool makes it worth using. I can see how using Unity would make sense for a number of the projects that I want to do so I expect more of my games to be created with it in the future. That said, I am still at the very early stages of learning Unity with a huge amount still to learn.

In Memory of Flappy Bird

I interrupt my NES coverage to bring you a rant. Most of you are already sick to death about Flappy Bird but the issues around the game are important and a badly worded Kotaku article really pissed me off so I simply had to rant. It is understandable if you skip this week’s post though there are some valid points made so at least try to skim through it.

Flappy Bird was created by Vietnamese developer Dong Nguyen. It is a Helicopter style game with graphics reminiscent of Super Mario Bros. You simply dodge pipes by flapping, with the score based on how many pipes you dodge. It is essentially the type of game that I would create in a game jam but would not release on other sites because I wouldn’t feel the quality was high enough. Perhaps if my standards were looser developing games would be a job and not a hobby? A simple game that was kind of fun but nothing special. Still, for some reason or another the game took off in popularity and became one of those surprising mobile-device success stories. Then the controversy started happening.

First people started accusing Dong of gaming the system. Claiming that the download numbers and 5 star ratings were artificially inflated by using bot nets or large numbers of paid-off people. If you had looked at the review pages for this game you would have noticed a lot of 1 star ratings mixed in with 5 star ratings. This may seem suspect but when you think about human nature it is quite conceivable. When many people go to rate a product that they like and notice a bunch of undeserved 1 star ratings, the score that was going to be given immediately changes to a 4 or 5 star rating to compensate for the “idiots” (and if they don’t like a game but see a bunch of undeserved 5 star ratings they will lower their rating to 1 or 2 to compensate for the “idiots” with anybody that has a different opinion from your own being a idiot). For those of you who are curious, I wouldn’t have bothered to rate the game because it is too simple to deserve the effort required to give it a rating but if compelled to rate the game it would get a 2 due to the annoying difficulty since overly difficult games aren’t my forte.

Next were claims that the art was “ripped” from Super Mario Bros. While the art style is very similar, it is clear that the artwork was created by Dong. The Kotaku article claiming the art was “ripped” was poorly researched as ripping art means you take the actual art from another game. Creating your own similar artwork is perfectly legal. The pipes, in particular, can be created by anybody in under a minute by using two linear gradient filled rectangles. I’m not saying that the artwork in SMB is bad, in fact with the palette and tile restrictions that the NES had the art is really good.

After that we get to the argument that the game is just a clone of another game. This is actually the case for the vast majority of games. For example, if you are a fan of first-person shooters, you are playing a clone of Battlezone which itself is a clone of 2D shooters but extended to the third dimension. If you think a game is too much like another game then play and promote the other game.

It is doubtful that the above items are the real reason for the hatred that Dong is receiving, however. The real reason is that the game made a lot of money. Seeing a weekend project make someone lots of money is annoying. Especially when a great game like Kingdoms of Amalur fails in the market. This doesn’t give you the right to harass the person but far too often on the internet people forget that they are talking to other humans.

Interesting enough there is a Flappy Jam going on at http://itch.io/jam/flappyjam . I will probably be doing something for this jam. Will be starting out in Unity and see if I can figure enough out to finish a simple game in it.

NES Palette

Traditionally, one writes a hello world program when they first start learning a new language or platform. Unfortunately, there is a lot of graphics related material that one must understand before they can write Hello World for the NES, so the next few NES articles will cover the PPU. I will start in higher level concepts then finish by writing a hello world program in 6502 Assembly Language.

Before I begin, I should point out that today the term bitmap is incorrectly used to indicate a raster graphics image. Technically speaking a bitmap is a two-color image with each pixel of the image being a bit. I am using the term to represent a grid of pixels that form an image. This is the common usage of the word, even if it technically is not the correct usage.

Today it is fairly simple to create and manipulate images.  When writing code to manipulate bitmaps most the time you are dealing with pixels in the RGBA (Red Green Blue Alpha) format. This means that each color component is a byte an each pixel requires 32 bits. As today memory is so much cheaper than it was a couple of decades ago, this is not that big of issue. This is a fairly inefficient way of storing graphics as not every color available is used. Older graphic cards/chips reduced the total number of colors available to a small number of colors. Instead of specifying the color in RGBA format, bitmaps would just hold a number indicating what palette index to use. The NES has a 64 color palette as shown below. As you can see, 8 colors are not actually available and there are a couple of colors that are almost identical, so the palette is not really64 colors.

Using only 6 bits per pixel is certainly a drastic reduction from using 32 bits per pixel, but this can be taken even further. If we make the image a grid of 8x8 pixels and give each tile in this grid it's own 4-color palette taken from the 64 color palette.  To reduce things even further, we don't really need a palette per tile, instead lets have four palettes that the tiles can use. Sprites can also have their own separate set of palettes for a total of 8 possible palettes.

This is very simple. Simply to set the palette you simply send 32 bytes to the PPU, with each byte being what color from the 64-color palette to use. Of course, things are not quite that easy. The first color in the first palette represents the background color. This will be the same color for the other 7 palettes so the first of the four colors is always the background color. Due to the way the PPU is set up, writing a color into the first sprite-palettes first color will also set the background color so when putting together the palettes you need to keep the background color in mind.

This now leads to the tiles. Having every tile uniquely programmable would take a lot of memory. Instead, lets limit the tiles to 256 different tiles and call this a character set. Character Sets will be discussed next.