Identical Games

Name:	Color Monster
Version:	0.0.0
Author:	Dennis Payne
License:	GPLv3
Operating System:	Linux and TinyArcade
Website:	http://identicalsoftware.com/colormonster/

False Start

Color Monster was a game idea I had back in 2006. The concept was a monster collecting game like Pokemon or Digimon but allowing you to color the creatures. I began prototyping the design as a Java applet with the plan of building an Android game.

Unfortunately I never had a good solution to the resolution problem. The screen sizes on Android devices are not the same for every device. The simple solution would be to pick a size the majority of screens could support and scale up when needed.

I also made the poor decision of grabbing images off the internet for the game. All the images would need to be redone since I didn't make sure I had permission to use the images. At the time of creation opengameart.org didn't exist.

New Beginning

After porting Viobyte to the TinyArcade, I wanted to create a game which took advantage of the capabilities of the system. With the micro SD card I could save and load data. I started thinking of how to implement Color Monster on the TinyArcade.

After the original Color Monster attempt, I did some work on Tuxemon. The monsters used in that game are 64x64 pixels. Assuming two color monsters are on screen at a time, the TinyArcade could have 48x64 per monster. I grabbed a copy of Cateye, removed all color from image, and added a black outline as needed.

For drawing tools, I planned on including a pencil and flood fill. A flood fill algorithm could use a lot of memory. To prevent that I predetermined all the flood fills. The Cateye image used in the game is a patchwork of colors. During initialization, the black pixels were copied and everything else left white. If you tried to flood fill a section, it found what color pixel that was in the original image. It iterated over the original image looking for that color and filled in that spot on the user's image with the current color. In addition to being simple, sections didn't need to be contiguous. For example the Cateye's ears were linked so filling one filled in the other one too.

The pointer movement was initially too fast for fine detail. The buttons also had problems. One click of the button would cause the code to execute multiple times. Since the first version had the tool choice toggle by the second button, this meant you didn't know what tool you would get after pressing the button. A cooldown was added to the joystick and buttons. After registering input from the joystick and buttons, it would ignore all input until the cooldown period passed.

This was great for making pixel changes with the pencil but was annoying for selecting colors and tool as the pointer was much slower. To fix that I made the cooldown for the joystick decrease with continuous movement. If you push the joystick in a direction and then stop, it moves just a pixel. If you hold the joystick, the pointer starts moving faster.

Playing it on the TinyArcade showed that pixel level work is really hard on the small screen. Instead of using the second button to toggle tools which wasn't that useful, I switched it to zoom in and out. I debated adding multiple zooms but settled on just one. There was no scrolling while zoomed in. To get to a different section, you needed to zoom out, move to the appropriate location and zoom in again.

SdFat

With the painting part working, it was time to save the data to the micro SD card. I downloaded the SdFat library and failed to write the save file. I determined that writing only worked in the root directory. I wanted to save the files in the subdirectory for the program.

Some of the other games on the TinyArcade read and wrote files. KemonoRogue had a save file but the source code is not available. SuperOteme did include the source. I tried it and could create a file in the subdirectory. I don't won't to include the SdFat library in my code as then I'll need to maintain it. Initially it looked I would have to but then I discovered the file was zero bytes.

The author of SuperOteme suggested I try the latest code. The TinyCurcuit's site linked to 1.02. The latest version was 1.03. That code did work.

I still didn't want to ship an old version of SdFat with my code. The two code bases were significantly different. Since the library could write to a file in the directory, I thought the problem must be in handling subdirectories. I diffed several files until I noticed a slightly different check in the two code bases.

The working version checked "(m_vol->cacheBlockNumber() <= block && block < (m_vol->cacheBlockNumber() + nb))". This determined if the block was within the cache. The SdFat library had a check of "(block <= m_vol->cacheBlockNumber() && block < (m_vol->cacheBlockNumber() + nb))" which didn't seem correct. The library wrote to a file in the subdirectory after the code was fixed. Thankfully the library author quickly released a new version with the fix.

SdFat library support was added to the tinyscreensim so that the code could be tested without the TinyArcade. Much of the library is not supported. Only the minimal needed for Color Monster was added.

The World

It was time to bring the world to life. The world of Color Monster was black and white. The infusion of color empowered the monsters. Clint Bellanger created the excellent Tileset 1bit Color on opengameart.org. When I tried to use it, I discovered it was 16x16 pixel tileset. Using that size on the TinyArcade would only allow you six tiles across and four tiles down.

Scaling down the tileset didn't work. With a one-bit palette, a hand crafted tileset was necessary. I created a new tileset using Clint Bellanger's for inspiration. Not all of the tiles from the original were recreated. Some I haven't tried. Others I haven't been able to get right.

Scrolling around the world worked well. Older games tried to keep you on the tile spaces. If you moved up a little, you wouldn't move left or right until you had travel up one tile. I allowed free movement in Color Monster. It made collision detection slightly more difficult. Additionally logic moved the character left or right if something was only partially in the way. Without that entering a door could be annoying as you have to be perfectly underneath it.

A black and white world did mean that I'm not using the TinyArcade to it's fullest. The device included a great color screen. I have considered slowly adding color as the game progressed. The black and white world gave it an interesting look so I'm undecided if I will explore that possibility.

Battle Joined

Prototyping the battle system required displaying text. I initially planned to use the same 8x8 font I've used on other projects. The Bard's Tale Construction Set used that size font and could display a maximum of 16 characters in a row of text. At 96 pixels across, the TinyArcade would be reduced to only 12 characters. I knew 16 characters was hard so 12 would be even worse.

The user domsson on opengameart.org created a 5x7 font which looked promising. While the characters were 5x7 that didn't include any space between the characters. Adding a pixel of empty space between the characters increased the size per character to 6x8. It was not as big a difference as I hoped but I accepted the font for now. I believe it may be possible to reduce the characters one pixel in width without adversely affecting readability later.

The initial implementation of choosing your action in combat was tied to the combat interface. Choosing between various options will be needed outside of combat. I refactored the selection code to be independent of the combat.

The first iteration to choose an option made the area black and placed a white square around the current selection. This was not particularly easy to notice. Instead I thought about how console rpgs display choice. Usually they have a little window with the choices and an arrow pointing to the current item. Switching to that design made the screen much easy to understand.

While selecting actions was implemented, combat resolution remains unfinished. Completing the battle system is the top priority for future development.