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!

 

Advertisements

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.

Recklessly Stuck

I am surprised and embarrassed on being stuck in this game. The coding itself did not give me problems this time, but the content did. Worse, I thought that I had developed the idea thoroughly, but I have problems finding out how I should do the exhibits. I got a general idea, but I got trouble turning that idea into specific exhibits.

…I do not like stopping here, especially since I want to have both games done by Comi-Con, but I feel that I need to do more research beforehand. Besides, this is just a temporary detour.

…at least I hope that this is just a temporary detour…

72 hours…

I earlier mentioned that, because both Re-Hoard and Reckless Abandon are half-developed, I can follow eevee’s lead on developing these Pico-8 games in 72 hours.

The issue is that eevee developed her game in 72 dedicated hours (save necessities, of course).

…I can dedicate myself that much, though, to some extent, but this is a flash of perspective that I missed when I wrote my last post.

I should get to playing around with the demos today.

I should start over.

Not long after I posted my last post, I fully realized that, when I was making my first game, I actually did very little preparatory work before just diving into the editor. Despite how fun that would sound, I was clueless all this time at how stuff worked in the Pico-8! Most relevantly, how could I learn how the opponents were to move if I had trouble with the physics!

That was stupid of me.

I decided to take my time exploring the Pico-8 more thoroughly before I go back to the game. I would still work on the assets, but the actual coding would have to wait until I get used to things more.

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.

However…

ReHoardLogic

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.

Uploaded my re-hoarded notes

I just uploaded my notes on the development of Re-Hoard. Hopefully, the help I would get would have the necessary information.

What’s weird is that, though I expected to go to writing the code after I wrote my notes, I found out that I also needed to organize my notes into actual algorithms instead of thinking that the notes are already algorithms in themselves. I realise that I would need actual flowcharts out of this, too.

A weirder thing is that, even though all I did was clean up and clarify my notes, I was no longer willing to work until tomorrow. I thought that this was a trait that only came up during my final project in college.

Then again, these days, I have been adjusting to a life where I essentially have control of all my time. I already developed a surprisingly high amount of self-discipline back at my final year in college, but this transition from following instructions to doing your own work just began. I mean, even when I had a lot of free reign on the things I could do in my final project, I still had to answer to the school staff. Here, I have to do everything and respond to myself. This level of responsibility, while lower-pressure in a way, is something to what I have to get used gradually. I am only getting the hang of these things around this week.

I hope that I would develop more regularly, now.