I finished translating Re-Hoard’s code from Lua to Chaiscript.

I am surprised at how few days I took after my vacation.

Then again, I was riding the additional hard work I did before the vacation.

Honestly, I still need to write a function that sets the language variable (which would decide whether the game would be in English, Spanish, or Esperanto). While I had the idea of a language-select screen, I also wonder if I could simply have the game read the language setting from Libretro. (After all, does no ChaiLove explicitly target Libretro?) After that, I need to actually draw the Spanish and Esperanto version of the title logo. Then there is the implementation of the priority queue and, subsequently, replacement of the Breadth-First search with the A* algorithm.

However, I would rather debug the game, first. At the current state, the game should run normally. If I debug now, I would have to worry about less possible places where something went wrong.

I am going to ask Mr. Loach again…


My hoard is nil.

if ecs_single_entity["actor"] == "fireball" or "arrow" and ecs_single_entity["location"] ~= nil then
    if ecs_single_entity["location"][1] > 1 and ecs_single_entity["location"][2] > 1 then
        if ecs_single_entity["sprite"] == sprite_fireball_up or sprite_arrow_up then
            if {ecs_single_entity["location"][1], ecs_single_entity["location"][2] - 1} == value then --the location is nil
                ecs_single_entity[key] = nil
            elseif ecs_single_entity["sprite"] == sprite_fireball_down or sprite_arrow_down then
                if {ecs_single_entity["location"][1], ecs_single_entity["location"][2] + 1} == value then
                    ecs_single_entity[key] = nil
            elseif ecs_single_entity["sprite"] == sprite_fireball_left or sprite_arrow_left then
                if {ecs_single_entity["location"][1] - 1, ecs_single_entity["location"][2]} == value then
                    ecs_single_entity[key] = nil
            elseif ecs_single_entity["sprite"] == sprite_fireball_right or sprite_arrow_right then
                if {ecs_single_entity["location"][1] + 1, ecs_single_entity["location"][2]} == value then
                    ecs_single_entity[key] = nil


Even after I explicitly checked if the location is nil, I get this error.

In fact, my main issues are how Lua and pico-8 deal with nil values. They always seem to come up and cause big problems every step of my way, no matter how close I get.

I think that my game cannot handle Lua.

I was prepared in case this happened. I am aware that C, being a lower-level language, invites more problems, but I do not think that I can profitably go farther using Lua at this point.

I am not quitting Re-Hoard. However, right now, I shall search for a different game engine. Meanwhile, I shall take a look at the underlying algorithms that run Re-Hoard. Even if this issue is just another algorithm problem, I still plan on switching languages because Lua is just giving me too much grief.

Re-Hoarding discarded algorithms

After I got the title screen working properly, I found that the Lua used in pico-8 does not support metatables, thus messing with the queue code, which used plain Lua.

I ended up analyzing more closely the queue code used in the Pico Zine.*

At the same time, a bit of looking into the Lexaloffle Forums said that I should review the collision demonstration that pico-8 has because of how robust the collision system is there. I already picked apart the game code there one time, but, given that the alternative that went into the game is not working, I should look into the demonstration again.

On the other hand, there is nothing stopping me from switching to LÖVE again, which uses plain Lua… The way code is structured in the pico-8 is similar to the way code is structured in LÖVE…


  • = I wish the Pico Zine continued…

My Backup Plans

If everything goes all right, then my code at Re-Hoard should be done in 5 days of work.

Whether the code would work is another matter.

At this point, my idea is writing all of the code I can, revising the code, get my code verified, then pick between:

  • staying with Lua in the pico-8
  • switching to ChaiScript in ChaiLove
  • switching to C in the Game Boy Advance

The reasoning behind writing all of the code first then revising the code is not just because of the possibility that my problem is solvable within the pico-8 ecosystem, but also finishing the code would give me a reasonably complete framework from where I can do a translation if I do switch. Yesterday, while coding, I found that I needed to do a few new sound effects, that is, a gap that would have been more difficult in being fixed had I switched immediately to a different ecosystem.

I normally do not learn one language while using another because I want to avoid mixing up the two languages, but I let this because I plan on moving away from Lua. However, this possible mixup is the reason why I did not learn both C and ChaiScript at the same time.

I decided on learning C first. While the main motivation was simply big interest in the Game Boy Advance at the time, I found that there were more practical reasons why C would get priority over ChaiScript.

  • C is widespread. From what I have seen, C is the most widely-used language in all electronics, beating out even C++ and every dialect of BASIC together! This would make my games written in C very portable.
  • C is marketable. Because of that wide spread, a knowledge of C would be very useful in a lot of business and industrial contexts.
  • C lets me understand the hardware at a lower level. From what I had seen, C is essentially cross-platform assembly language. One of the main benefits of C is its ability of manipulating stuff at the bit level. A knowledge of C would deepen that knowledge of bit manipulation. (Once again, this deep knowledge would help me in an industrial context.) This is important because I finally would get to understand pointers, that is, a common theme in programming.
  • C helps me understand Libretro more. Libretro is a C library first of all.
  • C is reverse-compatible. My main trouble with ChaiScript is that ChaiScript ultimately relies on C++14, which would make things difficult when porting stuff to earlier hardware. This fact became more relevant here when Libretro supporting an old compiler let Libretro resume development that targets Microsoft’s first game console, the XBOX. That means that, even if targeting the Game Boy Advance does not work out, I can still code “from scratch” using an older version of C. Because I am using a book from 40 years ago even before C was standardized into C89, my code would definitely be reverse-compatible.
  • C is mature. ChaiScript is still being developed. While I am fine with waiting until ChaiScript finishes development or at least progresses to a form of maturity, C is already time-tested and, therefore, more reliable. I can write things in C while I wait until ChaiScript matures.

From another perspective, though, ChaiScript may have fit my current priorities more. The development time of Re-Hoard is easily approaching a year. Spending so much time on a simple game is ugly, even though I do not exactly have an audience. ChaiLove not only is deliberately similar to LÖVE (another framework I used) but also abstracts away a lot of close-to-hardware features. Adding assets in ChaiLove is also drag-and-drop, whereas writing a Game Boy Advance program would require conversion and appending the assets. Therefore, using ChaiScript would make a sooner release. There is also the fact that ChaiLove is tied to the Libretro ecosystem whereas making a Game Boy Advance game is not. (I could make a game “from scratch” that implements the Libretro library, but that would be too much work when the goal is getting my games released.)

Maybe I should have started with ChaiScript? I am too deep in C, but I might learn ChaiScript after I finish with the basics of C.


Hoarding Problems on Lua

I need a way of checking whether every entity does not have a value. That way, I can find out whether every opponent is not hunting. That way, I can check if the game can play the normal theme again.

I now also need a way of making either a system or a plain function that accepts two entities. This would work with the collision system.

This is hurting me.

My current plans are putting in “boilerplate” functionality that might work, writing the rest of the game while pretending that the functionality definitely works, then requesting the help from the people at Lexaloffle, but I am leaning ever more towards changing the platform to ChaiLove or even the Game Boy Advance, even though the game is about done and has assets that specifically target the pico-8.


Earlier, I mentioned that Lua’s lack of an object-oriented system was restricting me.

These days, I learned that the alternative, the entity-component system, may be itself restricting. One thing is that I do not know whether I can check if every entity that has a component does not have a component set to a certain value. Another is functions (or, rather, “subfunctions,” because they are parts of systems); some functionality some systems have can be abstracted away into subfunctions, but I am not sure if the subfunctions would work with the entire entity-component system in general or that I need to give the components’ values before the subfunctions would work first.

This has me worry if I could actually do the game in the pico-8 at all.

This is obviously very bad because I am so close. All of the art assets, which specifically target the pico-8 are there. I planned everything I could thoroughly then added stuff that I needed to plan once I went along programming. I worked a lot of the game; the end appears to be in sight. The worst part is that I had been working on the game since the latter half of 2016. Development just picked up when I decided to knuckle down and actually plan the thing thoroughly, but I am taking too much time with this game.

I am still working on the game, regardless, but a change of platform is not out of the question.


(Despite the above, this has nothing to do with my decision to look at Red or ChaiScript. These problems were forming over the days.)

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

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.