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.


Now is the Time for 2D

3D is the standard of games these days. I am not talking about pop-up visual effects, but rather assets based on 3D models. This trend was already present in computer games and arcade games. While console games at times flirted with 3D, the Nintendo 64, the Sega Saturn, and the Sony PlayStation introduced a “3D-first” paradigm that is standard in console games today. This history repeats with handheld games, Nintendo 3DS and the Sony PlayStation Vita having a “3D-first” paradigm themselves in their official games. Mobile games, probably due to the still heavily 2D-centric nature of  non-game mobile applications, are still largely 2D, but mobile games seem to be going to that 3D standard.

The games I want to make are 2D.

If I were to be more specific on why I decided on this direction:

  • I want my games to be different from those of the mainstream game industry. Tinglar is radically different from contemporary game companies right down to the core values; I want others to take a look into Tinglar and notice the fundamental differences.
  • This reason being a specific example of the previous reason, I want to protest the contemporary emphasis on production. Food that looks beautiful but tastes disgusting, does not fill you, and is non-nutritious is not really worth being called “food”. Games that push not only graphics but also music and even story, but at the expense of gameplay and content, fail to be games.
  • 2D is less costly. The hardware required to even run 3D models is orders of magnitude higher than that required of running 2D sprites. (I want others to be able to run my games even in low-end devices.) Then there is the complexity in making the assets; whereas 2D sprites simply require drawing straight pixels, 3D models require far more nuanced and layered editing, including rather complex physics. Making, fixing, and modifying 2D sprites, therefore, also takes less time and general emotional fortitude.
  • A corollary to the above reason, the lower costs of 2D makes modification more inviting. I want to encourage people building upon my works. 2D leads to a lower barrier of entry than 3D.