Uh… I think I am tired.

These days, I had a gradually increasing resistance to working on Re-Hoard. Today, I did not do that much compared to the previous days.

I plan on taking a break, but I am worried that I would procrastinate again.


The value of Clean Code

Today, because I kind of forgot how everything in Re-Hoard worked so far, I decided to read my code.

Not only was the code digestible, but I also found some errors that slipped! I could fix them just fine!

I thank you so much, Clean Code!!

No longer fearing the low level

Going through Jasper Vijn’s tutorial on making games that target the Game Boy Advance was honestly eye-opening. I mean, this tutorial convinced me of the virtues of coding in C. Compilation became approachable. Makefiles became my friends. I no longer fear pointers or raw memory-addresses. My knowledge of low-level graphics programming got such a big boost; Libretro’s software-rendering example made a lot more (though not yet absolute) sense! I mean, I actually know what a pitch is! (Low-level sound still freaks me out a little, though that may be because I did not get to that part of the tutorial yet.)

The biggest part was that I was worried that my Master’s Degree in Software Engineering was pointless because I had little practical knowledge (think makefiles and that stuff), while I had trouble picking apart rather advanced C++ code. I am not sure if that was due to the simplicity of Mr. Vijn’s tutorial, but I could not only actually understand the stuff (if I take things piecemeal), but a few things went without saying! (Of course I would abstract away stuff that I would otherwise repeat in my code!)

Whether I target the Game Boy Advance or not when programming games, I thank Mr. Vijn so much!

ChaiLove or Game Boy Advance

Summarizing part of my pathway in game development, I was initially excited in developing games in LÖVE and the pico-8. However, I hit into the deficiencies of Lua… mainly how Lua does not have support of classes. Because of this, I spent my time searching for alternatives. Two platforms ended up fitting my needs: ChaiLove and the Nintendo Game Boy Advance.

To me, ChaiLove is LÖVE without the problems. More specifically, ChaiLove retains LÖVE’s ease of programming (and, in fact, is modeled after LÖVE’s API), flexibility in programming, abstraction of lower-level requirements (rendering graphics being the big one), and freedom from compilation while adding the benefits of C++/ChaiScript (actual classes!), taking advantage of Libretro, and meaningful active development. In fact, the Libretro blog post explicitly mentions potential portability to other consoles because ChaiLove targets Libretro!

Before ChaiLove appeared, though, I seriously considered using a more indirect approach in trying to write a “universal” game. In this case, instead of trying to code from scratch a game that works in every platform that RetroArch supports, I could simply look for a game system that every version of RetroArch can emulate, then write a game that targets that system. This approach also provides (theoretically) infinite forward-compatibility. Though I initially considered this approach because ChaiLove did not yet exist, the fact that ChaiLove depends on ChaiScript, which depends on C++14, motivated me towards considering the indirect approach again. After all, Visual Studio 2003, which is the latest compiler that can generate binaries that work with Windows 95 and the original Xbox OG console (the one before the XBOX 360), does not support even C++11… or C11, in that matter.

After currently comparing the systems that Windows 95, the Nintendo 3DS, and the PlayStation Portable can play, I decided that the best system was the Game Boy Advance. My reasoning was that:

  • I should avoid any emulators that prohibit commercial use (an issue that plagues Libretro and its contributors to no end)…
  • …or anything that requires an official BIOS.
  • My theoretical game Wuu Shyng is based on the mainline Pokémon series, which is played in the handheld GameBoy and DS product lines. A result of these game being played on handheld systems is that the contents of two different save files interact with each other; home systems that use save files usually rely on the contents of only one save file, instead.
  • My games are based on a maximum of 3 action buttons and 1 menu button. A lot of the systems that Windows 95, the Nintendo 3DS, and the PlayStation Portable can play use 2 action buttons and 2 menu buttons, instead.
  • While I could target the original Game Boy or the Game Boy Color systems, I read, repeatedly, that games that target those systems needs to be written in Z80 Assembly language, even when C compilers exist.
  • The Game Boy Advance has a lot of strength. Mario Pinball Land used 3D graphics. The Game Boy Advance Video series used full-motion videos.
  • The games I want to make are essentially Super Nintendo/Game Boy Advance games, anyways.

Targeting the Game Boy Advance is a very different paradigm, though. I have to code the game in C instead of C++, which uses structures instead of proper classes. The Game Boy Advance does not play actual audio files, but, rather, MIDI-style files that say what sound samples should be played. (I am not good at making full songs, plus there seems to be a lack of freely-licensed music that can be played in the Game Boy Advance.) Sprites have to be converted to bits (which was a big problem when I looking into coding a game from scratch). Homebrew information on the Game Link Cable (a big thing, given Wuu Shyng and its influence from Pokémon) is rare; homebrew information regarding the Wireless Adapter (something that would be very beneficial) is even worse. Of course, I would have to compile, though I would also have to use a toolkit (in this case, devkitARM, a part of devkitPro). Finally, the Game Boy Advance, being a dedicated handheld device, has more programming restrictions… a lot of them.

However, from what I see, targeting the Game Boy Advance is within my skill set. I mean, the Tonc guide and devkitARM’s libgba libraries seem to make the Game Boy Advance accessible. I have the 1st edition of The C Programming Language, a book that is not only enjoyable and digestible but also would definitely produce C that is compatible with Windows 95. Use of C also means that I, in theory, could use plenty of the C libraries out there that would help my game development. I would not have to worry about different display resolutions because I would only have to focus on keeping things 240 * 160. Implementing multiplayer through either the Game Link Cable or the Wireless Adapter bypasses Libretro’s current netplay system which is opposed to the way I want to make multiplayer, which is based on handheld game systems, anyways. (I would still have to do something about programming a server because I want to implement a type of Pokémon Communication Center in Wuu Shyng.) Game Boy Advance games (excluding a couple of Game Boy Advance Video cartridges) go up to 32 Megabytes, that is, significantly small by current standards. (Thought the main influence on file size comes from the programmer, getting a maximum file size, especially one that small, is comforting to the downloader.)  There are also more platforms that can play Game Boy Advance games… including the Game Boy Advance SP that I currently have.

Honestly, I am actually getting excited from the possibilities. I am eager in getting Re-Hoard and Reckless Abandon done!

Hoarding sounds and sprites

Yesterday, I did something that I thought that would not happen any time soon.

I did all of the sounds and sprites that the game needed.

I think that part of the problem was that the amount of sounds and sprites needed was large. There was also difficulty in making a title screen and the music.

I already mentioned how I managed to solve the music problem. The title screen was a form of roundabout ingenuity. I wanted a title screen that has a font in this style, but I was willing to just take a bold font then “hollow out” the font. The font I ended up picking was Paytone One. I then wrote the title in GIMP (using a black-colored aliased font) then used the Perspective Tool in getting the title to look close to the perspective I wanted. I then resized the title in Paint.Net without using anti-aliasing. However, the Perspective Tool seemed to have anti-aliased the title already. I ended up manually filtering the pixels; any pixel that had at least 128 opacity was colored pure black while the lighter pixels were colored black.* I then copied the title to the Pico-8 pixel-by-pixel.

Getting the colors of the title working was difficult. I quickly realized that the text did not have the thickness that would have let me make the outlines of the font that I wanted to simulate. I ended up not drawing outlines that surrounded the inner “holes” of the title’s letters. After I made minor pixel-level adjustments in the title’s formation, I searched for the right colors. I had in mind a color scheme that used a yellow fill but suggested a castle (which is also the reason behind the high perspective), but I had to approximate, given the palette that the Pico-8 used.

After that, the whole thing was easy. After the experience in remixing the music, I made all of the sound effects in the Pico-8 tracker. I also noticed what a difference different octaves made in the Pico-8, I adjusting an earlier song that did not sound right because of the wrong octaves.

All that is left is the code. I am actually more worried that the code would actually work.


  • = Only later did I realize that I could have looked for a way that transformed the title’s perspective without anti-aliasing. A bit of searching said that I could have set the Interpolation of the Perspective Tool to “None.”


Back then, when I way trying to compose the “playing theme” of Re-Hoard, I could not compose anything good beyond one loop. I since decided to go out searching for music, instead. The problem was that, though I needed a Creative-Commons music file that was either already in MIDI format or could be converted to MIDI, I had trouble finding one that had a song that actually fit the game’s mood.

The closest match was “Surreptitious”.

After converting the MIDI file to a Pico-8 format, I went to adapting the song to a version that only used 3 channels maximum. (The Pico-8 has 4 available sound channels, but I want to leave 1 channel free that can play round effects.) However, during the process, I found out that I could replace the rhythm track with the “good loop” I originally composed!

I ended up spending a few days remixing the song. Now, the song not only implements my loop and plays in up to 3 channels but also fits the mood of the game, is grouped in patterns of 4, and just sounds great. That song should be up next commit.

This is embarrassing, though. I have discriminating taste in not only a song’s euphony but also fitting a situation. I can deeply analyze songs and discover how they work. I can remix a song and make slight note adjustments. I can even compose tiny melodies. However, I cannot properly make a full song.

Maybe I have this potential, but my lack of knowledge is preventing me from bringing that potential to fruition? I never did take music theory…

Is ChaiLove a good fit?

Looking at my previous journals, I noticed that LÖVE had a lot of benefits: because of its specific focus towards game programming, the “batteries” are included (especially on video!), yet I can extend the capabilities more (say, if I wanted to add networking or adaptable resolutions), all in a language that has more simplicity over C++ yet does not require building! The disadvantages are that Lua, the language LÖVE uses, loses some important functionality C++ has (most notably classes) while Lutro, the Libretro implementation of LÖVE, seems to have been slowed, plus I can run things out of Libretro, anyway, despite me wanting to make games that take advantage of Libretro.

Though my current plans were to use a custom arrangement of C++ libraries and make an API that connects them all together, ChaiLove seems to be LÖVE, but without the aforementioned negatives. I mean, ChaiLove is not only undergoing active development but is also specific to Libretro. More importantly, ChaiLove uses ChaiScript, which is based on C++ and therefore has its strengths, including classes.

This just makes ChaiLove more attractive. There also seems to be some writing over other possible ports, though I am a bit wary over the possible lack of ability of being able to run ChaiLove in consoles that might not be able to handle C++14.

If I could use my own C++ libraries in my game, this would be excellent.

Re-Hoarding logic

During my time off from here, I took to learning the requirements and subsequently planning the logic of Re-Hoard.

I mean really learning the requirements and planning the logic. Before, I tended to go right to coding once I had even some form of logic in my head. While planning, I was always wary of any feeling I had of things being even close to being done, a wariness that paid off a few times.

I ended up planning:

  • how the opponents would be placed at generation time
  • how would the opponents patrol and hunt
  • how the main song would go (though those plans had changed after implementing that part)
  • what weapon the Joyful opponent would have
  • how weapons would work
  • how the Knight would respond to damage
  • how the Dragon would respond to the Knight logically firepoofing the treasure
  • how the game would display each round and opportunity
  • what would happen during a “Game Over”
  • how the title screen would work

I am still wary on declaring something “finished” here, but this is a very complete planning.

During this time, I also read Rapid Development: Taming Wild Development Schedules. Right now, I am at the 13th Chapter, but…

…oh, my.

I knew that my going into this project without the proper planning was the reason why I spent over a year in making this game, but all the mistakes I made, especially all of the classic mistakes I made… this is unacceptable from me!

Final Fantasy turned 30??

…just after the RockMan anniversary, too!

I was so busy these days; I ended up missing the anniversary!

I still am, which means that this post has to be short.

The games did not have that strong an influence on me; the first Final Fantasy game I have played is actually Kingdom Hearts: Chain of Memories!

Oddly, the first mainline Final Fantasy game I got was Final Fantasy VII.

I like I and II better, myself, though. I studied those games quite deeply, actually.