Lua to the End?

From the beginning of my game career, I intended to make games that use Libretro, a C/C++ library that can be used in writing emulators and standalone games. The reason why I learned Lua in the first place was because, compared to using straight C or C++, writing games in Lua and relying on the Lutro core seemed to be the more comfortable option. Indeed, because Lua programs do not need to be compiled, I ended up saving myself plenty of precious time in my last two college projects back when I took my Master’s Degree. Developing my final project using LÖVE instead of trying to understand the Libretro library, especially given the one-trimester deadline, spared me from a lot of grief. That knowledge of Lua also helped me develop games for the PICO-8, an all-in-one platform that not only helped me get used to normal game development but also has several channels of delivery, my favourite one being uploading the game itself in image format. You can even play these games in your browser with little fuss!

However, I am starting to feel the limitations Lua has. While Reckless Abandon has simple code, Re-Hoard has a game plan that needs object-oriented programming when generating random anti-hoarders, each with their own patrolling and hunting styles, per stage. Lua does not have any object-oriented functionality; other people fake that functionality using metatables. Even with that fake functionality, I fear that I would be better off relying on the real thing. Besides, if Lua lacked true object-oriented functionality, then what else would Lua lack? Other consideration include less layers of abstraction that might interfere with my wanting to interact with Libretro itself, the bigger maturity of C++ tools and libraries, and practice in a language that is still in high demand in the workplace. In fact, the more advanced aspects of Lua actually use a C library!

On the other hand, the gains from the lack of a compilation time proved to be an assets when I debugged my college projects. Also, LÖVE games store their assets as-is instead of they being baked directly in the program; I can edit a sprite or switch around a song and see the effects when running the game anew.

Despite these benefits, I am seriously considering working on my new games with C++ from now on. In fact, though Reckless Abandon would stay a PICO-8 game, I might move Re-Hoard to C++.

I just need to figure out how to display and move .png sprites and implement collision detection while I use Libretro.


Reckful Spriting

I managed to do almost all of the graphics of Reckless Abandon. I was actually out of ideas by the time I stopped, but I thankfully got almost everything done there. Other than that, I still have to do the bonus exhibit and a secret or so.

I stopped temporarily because I both wanted to rest and celebrate. I wanted the ideas to come, but that needed me stepping away from the game. Even coding would not give the rest my mind needed in gathering ideas.

I think I got almost all the ideas I needed since then now.

I feel accomplished that I did so much. I hope that I can release both Reckless Abandon and Re-Hoard by the end of this month.


No help yet…

I posted in the Lexaloffle Forums, but I did not get a response even after about a week. I wonder what I did wrong in writing my post… I modified my post by making my request more specific, but I just do not know what else to write. I am so blocked; I don’t even know how to properly articulate what I need.

Maybe I can use this opportunity to “refresh” the code. I should branch the code, first, in case someone from the forums notices my edited post. Thankfully for me, posts that are edited also get “bumped” to the top of the BBS list, making unnecessary the need of “bump” posts and all that.


Delays and Re-Hoard

One of the most iconic quotes from Shigeru Miyamoto: “A delayed game is eventually good, but a rushed game is forever bad.” However, in the Internet, a couple of interesting rebuttals to this quote is Duke Nukem: Forever and The Mighty No. 9, that is, games that had a large development time but ended up underperforming terribly. The problem with that rebuttal is that both of them had undergone gross mismanagement during their long development times. Duke Nukem: Forever kept changing companies. The Mighty No. 9 was Keiji Inafune’s first time managing a game by himself, which involved him making horrible mistakes with his backer’s money among other things.

My time with Re-Hoard gave me an idea of the trouble Mr. Inafune had to stand. The only reason why I am not undergoing the same controversy is because, while Mr. Inafune as running on the money of a huge number of fans who wanted him to revive the same iconic MegaMan franchise that made Mr. Inafune historic in the first place, I am an unknown person who is making something entirely new on my own resources. Also, while The Mighty No. 9 had its development known far and wide, I made public only the source code of my game Re-Hoard because I do not want to cause such a fuss over any problems from my failing to deliver.

Of course, because this is my first game that I am fully developing and releasing, I have gone against a lot of mistakes on the overall development procedure, the most important being my own responsibility on development. More specifically, while I wanted to develop daily, I spent weeks without touching the game. Eventually, I did get around to work.



This is the farthest I could go in developing how the opponents were supposed to act in my game. I stopped in March 3rd.

…I soon remembered why I stopped in the first place. I was not just procrastinating; I was frustrated at not being able to plan how my game is supposed to run! This was the farthest I could do when planning the behavior of the opponents in the game. After that, I would still have to deal with the behavior of the player dragon, the switching between stages, the title screen, and the music, let alone the debugging! At least I managed to find good visual designs of the opponents and the treasure.

I feel stupid and useless over this inability. I spent 5 years in my Bachelor’s Degree and 3 years in my Master’s Degree; shouldn’t I be able to do this stuff by now?


I should not be so hard on myself here; this is actually the first time I coded around the Pico-8 API. A lot of things are still new to me. Writing this, I wonder if I went too fast before starting to code my game, even if my game is relatively simple.

I think this would be the best time that I would request help in the forums. I did not want to do so because that might leave a bad impression on others, that is, one where I would promise without delivering a game, but, because I want to actually deliver my game, I willingly put away what is, in the end, just an assumption.


Why write in Pico-8?

When I develop Re-Hoard, I target the the Pico-8, a “fantasy game console” from Lexaloffle. The Pico-8 had some features that I found enticing:

  • The Pico-8 is deliberately designed with a “retro” quality that I like. I do not simply like this “retroness” aesthetically; Lexaloffle seems to actually understand just why the games of yesteryear were actually fun, not simply mindlessly apply a “retro finish”.
  • I enjoy the entire process. I like writing games in the simple and familiar Lua programming language, even though I use Notepad++ instead of the Pico-8 itself. I like working with the graphics. I like the quick turnaround between editing and playing. I like the ingenious distribution format which puts the entire game in an actual .png image file.
  • I like the fact that there are others who seriously like the games of yesterday. I also like that they take their seriousness into actually making games that are skilled and actually fun.
  • Pico-8 games are easily distributable; other than sharing the game in either its native format or in an image cartridge, you can embed the game in an HTML5 page where anyone that has a contemporary bowser and keyboard controls can play the game. In other words, games from the Pico-8 have a very low barrier to entry.
  • The console itself had a low barrier of entry to development: other than said easy-to-use Lua language, the console has tools that assist in making audial and visual assets, then packs up your game in easy-to-distribute packages. The Pico-8 enforces resstrictons in development to rather simple games, thus taking off some pressure or making something “big”. In fact…
  • …part of the reason why the Pico-8 was made was having fun in game development!