I guess I answered prematurely…

After I woke up today, I got the urge to work on Re-Hoard again. I did… but got “enough” after a few hours.

I guess I just needed a slower pace.

However…

…I got that same feeling when I was working on my Master’s Project 2 years ago. At that point, not only was I “running on empty,” but, after the trimester was over, I could not do any work until a month later.

Advertisements

libgba is so Advanced…

After I read through the basic of targetting the Game Boy Advance, I decided to take a look at the libgba libraries that devKit Pro, the standard tool of targeting the console, has.

I am surprised that there are two libraries that deal with multiplayer. I am even more surprised that there is support of the Nintendo e-Reader! (Despite what most people say, I actually enjoyed playing with the Nintendo e-Reader.)

That probably explains why devKitPro keeps being developed despite the Game Boy Advance being discontinued in 2010.

I hope that ShinyQuagsire23‘s research on the Wireless Adapter gets in libgba one day…

ChaiLove is a First Choice

I decided that, if I were to make my games, I would make ChaiLove my first priority.

I came along when I looked at Red, a programming language that had a simplified grammar that deploys executables in hard-to-believe small file-sizes to plenty of platforms. After thinking over the potential (if true), I wondered: why target ChaiLove or the Game Boy Advance over Red?

My answer was that I liked Libretro so much that I wanted to specifically take advantage of Libretro. I also realized that, because part of what I liked of Red was the simpler syntax, ChaiLove would be a good fit my preferences opposed to the Game Boy Advance. In fact, the only real advantage I have in targeting the Game Boy Advance, other than being able to play my games in the Game Boy Advance SP I have, would be protection against the possibility that ChaiScript, due to its eventual reliance on C++11, would not make games that would run on old platforms… or the 3DS or PSP.

I would still explore Game Boy Advance development due to the accessible knowledge of low-level programming, the still widely-used C language, and having an available backup if my worries on the portability of ChaiScript come true, but ChaiScript’s mixing strength with ease of use (a big asset to me) had bumped up ChaiLove’s place.

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

A Thanksgiving gift in 2017

I inserted into the Re-Hoard cartridge the algorithms I had adapted and tested. I then pushed those changes into GitHub.

https://www.github.com/tinglar/re-hoard/commit/1f12a29f3512fc131b3504cd5a9501366fd05491

Though there is still a lot of stuff that remains, I feel relieved and accomplished that I managed to leave an experimental phase with something worthy of being put in the develop branch! (In retrospect, I probably should have put those experimental changes into their own branch yet manually add them into the cartridge in the develop branch.)

Happy Thanksgiving!

 

Chai Chai Chai

ChaiScript is a new scripting language more directly based on C++. That means actual classes and stronger overall capabilities.

ChaiLove is essentially LÖVE with ChaiScript. LÖVE has spoiled me with its mature functionality and many user-provided libraries, but ChaiLove actually seems complete.

 

This puts me at a crossroads. In one thing, ChaiLove combines LÖVE’s ease of use and freedom from compilation with C++’s functionality. On the other hand, ChaiScript requires C++14 since version 6.0.0, which was previously C++11 since version 5.3.0, which was Boost up to version 4.3.0. Stone Soup got those problems with C++11 being too new to old compilers, making my “a game that runs in any platform that runs RetroArch or even just Libretro” difficult.

I shall keep an eye on ChaiLove, but I am not permanently switching from my plans of making a game “from scratch”.

Re-Starting Fundamental Algorithms

I have been looking into how to do the fundamental algorithms that run Re-Hoard:

  • Some way of generating a maze
  • Some way of drawing a maze
  • Some way of directing the opponent’s movements whether they be patrolling or hunting while respecting collision
  • Some way of generating fully-functioning opponents

Though I looked for several maze generating modules already written in Lua, especially accounting the tight restrictions the Pico-8 has, I ended up coding the Recursive Backtracker algorithm that Jamis Buck wrote in his presentation on algorithms. (What really confused me way how to iterate over a 2D table in Lua.) However, I still needed some way of implementing queues in Lua. I ended up with the Deque module. I only put the specific functionality the game needed, though. I ran the code, but I ended up stuck today on some odd syntax error when dealing with this line:

 if dungeon[(current_cell.1) - 1][(current_cell.2)] == nil then

current_cell holds a table (a list, actually) that simply holds the “current” coordinates ({x, y}). Out of some reason, though, Pico-8 keeps saying:

‘)’ expected near ‘.1’

…even though I already put a closed parenthesis.

Thankfully, I already made a quick code that draws the map, which is actually a table full of “true”, “false”, or “nil” values.

On the opponent AI, Scathe at the Lexaloffe forums suggested repeatedly directing the opponent to a specific point in the map. His posts use a Pac-Man-style algorithm while the Pico-8 Zine used the A* algorithm, instead. I picked A*. This requires some careful attention from me, though I realized that the pathfinding algorithm also solves the issue with collision: pathfinding algorithms are designed to find the shortest path to a goal while avoiding obstacles, that is, the same obstacles that motivate me putting in collision detection in my game!

I already have the actual collision detection algorithm fully understood and coded, by the way.

On actually generating these opponents, I found Entity-Component Systems which not only promise to be more efficient but also do away with the need of object-oriented programming (in theory), making them a good fit to Lua, which does not have native support of OOP.

I would push these changes to GitHub, but I put all these algorithms on a separate cartridge because I want to focus on understanding and testing those algorithms specifically.

Release goals of Re-Hoard and Reckless Abandon

Please excuse the news blackout. Since July, I needed to rest, first. Afterwards, I got a new computer that replaced my old one which had a malfunctioning keyboard. After that, I spent my time setting up my computer to my liking and getting used to a new keyboard layout based on the 2nd ANSI Keyboard variation of the DH Colemak mod.* I am still yet from fully used to this layout, but I am reasonably competent here. Besides, I should not be putting off development of my games so long.

How does September 10 sound? I am not making any promises, but I should be getting back to work.

Abandoning a Reckless Pace

Neither Re-Hoard nor Reckless Abandon are going to be released by Comi-Con this year.

Ever since my last post, I took my time both recovering and considering my needs. I realized that I would not be able to deliver a good product (or maybe any product) by that deadline. My health and other kinds of energy trump any business opportunities.

That does not mean that I would stop. I just needed to recover from the deadly pace I took. In fact, a couple of days ago, I reoriented myself on listing what both games still needed.

However, I fear that, given that this is my second delay, I am setting up an image of lazy unreliability.