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!

Advertisements

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.

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

What a LÖVEly API!

Ever since I gave up on making my own game engine through C++ and Libretro bindings, I took another thorough look at Lua and LÖVE.

What I found was amazing.

First, I found Moonscript, a language that compiles to and simplifies the already pleasantly simple Lua language. One big benefit is its adding support of classes. I mean, while I am still concerned with how this object-oriented programming is actually a pseudo-functionality, that this feature is built in this simplifying language is just great! Also, because Moonscript compiles to Lua, I can write PICO-8 programming in Moonscript, classes and all, before pasting the code in the cartridge! I do not have to worry about a separate function that simulates object-oriented programming in PICO-8! Indeed, there is already a way of inputting Moonscript in the PICO-8. My only real concern that I would not be able to mix regular Lua with Moonscript or use regular Lua libraries with .moon files.

Going back to the LÖVE forums had me reacquainted with several libraries and introduced to a lot of new ones:

  • bump.lua adds simple collision detection.
  • cargo efficiently loads resources.
  • il8n helps organise localisation.
  • locco generates documentation based on Markdown-formatted comments.
  • lovekit gives a lot of functionality and is based on Moonscript. While I do not know what each sublibrary does, I like tilemap, which draws the game setting from a small pixel image.
  • lyaml parses .yaml files.
  • material-love provides Material Design to GUIs in LÖVE.
  • push manages the different possible solutions a game might have.
  • sodapop is an animation library.
  • SUIT is an immediate GUI.

All this made me actually eager towards game development!

P = NG

After my previous adventures in rendering .png files to a software framebuffer, I realised that I needed to convert between lodepng’s RGBA 4-bits-per-pixel format to Libretro’s RGB565 format. My studies since my last post brought me to pixconv.c which has a function, conv_rgba4444_argb8888, that does just that type of conversion. I need to give the function the following in this order:

  1. the output variable
  2. the input variable
  3. the dimensions of the image file
  4. the output pitch
  5. the input pitch

In theory, all I had to do was add lodepng and pixconv.c to my project, run a test.png file through those two, and put the resulting data in the framebuffer.

The result was a mess. Learning that <iostream>, a stape at my studies of C++, was worthless when working in C, was actually the easy part. Even if I did not exactly know what type of data type were the variables that held the RGBA4444 and RGB565 arrays (I settled on unsigned char when void did not work), the makefile refused to recognize lodepng_decode32_file and logepng_error_text, even after I put those two types in various places (though not at the same time) inside the actual libretro_test.c file. I learned that this issue comes from the linker, which is related to the makefile.

At this point, I decided to give up at least temporarily. I mean, while there is the possibility that this is the last problem and that I actually have everything else right, I decided that this matter requires advanced knowledge that is specialized on C++. I mean, I have a Master’s Degree in Software Engineering, but my actual usage of the fundamentals of C++ and related languages were all in Integrated Development Environments. I barely know anything more than how to run make (not “CMake”, but “make”)!

This lack of specialized knowledge is also the reason why I am no longer pursing either adapting a current C++ engine to Libretro or, per Radius’ suggestion, using OpenGL. I still would have to deal with compiling the C++ code in those situations.

In light of this, I was looking more seriously at Rust, which has bindings to Libretro. While Rust is not object-oriented in the conventional sense, Rust has features that have just about the same functionality anyway. The problem is checking how the current game engines that use Rust render graphics. After all, I want to use software rendering because I want my games to be played at the full range of consoles that run Retroarch, not just the ones that can handle both versions of OpenGL.

I am also seriously considering going back to Lua per my original plans. Not only does LÖVE have no need of a distinct compilation process but also displays graphics through an API that works great and easy. In fact, the ease of use LÖVE provides is the reason why I picked using LÖVE instead of straight C++ in the first place! The main reason why I am not so sure is because that the reason why I wanted to leave Lua in the first place was because Lua did not have any proper support of object-oriented programming. I would much rather use the real deal, especially since Re-Hoard needs object-oriented programming! Even if there is an alternative, this lack of functionality may hamper heavily my plans of future games!

I tried to see how Lutro, Libretro’s interpreter of LÖVE, displays games written in LÖVE. I mean, LÖVE apparently uses SDL, but that does not seem to be a problem to Lutro. However, I got overwhelmed once again.

Eevee is right; if I were to write from scratch, I would be essentially inventing the universe if I needed to get off the ground. Then there is compilation afterwards.

Why write in LÖVE?

While I previously wrote of the benefits of writing through the Pico-8, I would need to write larger games through LÖVE, instead. The reason behind this came from a decision during early planning of my Master’s Project, which I wanted to be a game. I wanted to target Libretro, actually, because of the:

  • free license
  • cross-platform support
  • specific, through game-oriented design

However, games that target Libretro would have to be writen in C or C++, both programming languages that, despite my familiarity, were unpleasantly complex. However, I found out about Lutro, a porting of LÖVE to Libretro, the main benefit being an ability to write games in the far more pleasant-to-use Lua. Another benefit was that, though Lutro was still a work in progress, the original LÖVE had benefits that were similar to Libretro. The original LÖVE also achieved similar maturity, which meant that I could write games through original LÖVE, get similar benefits, and still be ready when the Lutro port matures.