Sunday, 17 August 2014

My games - Ali Baba And The 40 Thieves

Note: In this post, I want mostly to describe motivations, the game itself, the creative process, and rant a little about problems I had, discussion on technical issues will take place in a future post about Game Boy development.

The first week of august in #ludumdare @ AfterNET saw a few of the usual frequenters making efforts at some jam other than the eponymous Ludum Dare 48h game development competition. This was GBJam3, a game development jam focused in Game Boy-ish games. Since there were lots of related talking, I was quickly convinced to also engage in this experience, since the jam coincided with my last week of mid-year med school vacations.

GBJam's rules are the following:

  • You must make a Game Boy-themed game
  • All content must be made during the 10 days of the jam
  • The resolution of the game must be 160x144
  • You cannot use more than 4 colours
As you can see, they are pretty relaxed. But I decided to do the ultimate challenge, the highest form of tribute to the Game Boy, a Game Boy game in it's very truth, a ROM that one can play in an emulator or even write to a cartridge. Since I do not have any experience with GBZ80's Assembly language, I instead opted for GBDK, a set of tools and libraries that enables one to write a Game Boy game in the C language (this latter turned out to be a bad decision, read on to see how exactly).

I was for long cooking an idea in my mind, after rewatching AVGN's Little Red Hood video. You see, a realization that can be made about 8-bit era games, that is very true, was that one of the most challenging aspects at the time was game design. While we grew playing games with established game design practices, the developers of the day were venturing into a new media, so they made many mistakes. Also we must not exclude the laziness factor, in a time in which internet game reviews were distant.

Thus, true 8-bitness is a state that can only be achieved by a game developer if he takes bad game design into consideration. I figured, from Little Red Hood, a list of factors, or rather, a process, that leads to such typical game design.
  1. Chose one relatively well-know canonical material, in special, a well-known story or folk tale.
  2. Design the game not on the actual story, but rather, design it as if you didn't really knew the story too well and didn't bother to look it up.
  3. Base gameplay in repetition and randomness.
  4. Do not tell the player how to play the game or what is the objective and winning conditions, instead he must figure everything on his own.

In those screenshots you can see the playing area. If you want to know what the actual gameplay is actually like, I strongly recommend (rather, beg) you to download the ROM and an emulator and play it. It will be much more fun figuring in your own. However, if you want to skip that, or you played the game and couldn't figure it out anyway, you can select the text below, that has been spoiler-protected, to read what you have to do to win the game.

You must avoid the enemies, which walk around the level in a quite stupid pattern. By pressing the A button, you can shoot rocks, that can use to break vases. When a vase is broken, a snake will appear from the vase for a brief period of time, running around frantically, killing the enemies that are found in its path. Those enemies will drop daggers, which you can pickup. As the story is about 40 thieves, you must collect 40 daggers to go to the treasure room. Then you collect the treasure to win the game. The enemies will also drop crescents, which are the game's extra lives.

Also in these screenshots you can see pixel art made by yours truly. I usually despise pixel art as being too inefficient i.e. too much work compared to other ways of making art. However, low resolution and 4 colors is enough to outweigh those preoccupations. It becomes manageable. In fact, I must say it was quite fun doing the graphics. And as you can see they actually look quite good. Even the very exigent Jiggawatt said that it was quite decent for GB art. The other folks at #ludumdare also helped me a lot, IIRC voxel, awsumpwner27 and vede gave their valorous opinion on the vases, over those many iterations, until it looked right. And hdon warned me, that the light in the interior of the water well was wrong, so that too I could correct.

In the image above you can see a comparison between some art I found on the internet, to the left, and my own, to the right. I made my own versions for two reasons, I could not use content that was made outside of GBJam, and there was a great divergence between the art I found and the rest of my art for the game (mostly in size, look how the cow skeleton is much bigger, and the cactus looks fatter). Nonetheless, this art I found was a great source of inspiration, specially for someone who does not usually practice pixel art.

Note the spinning scimitar on the start screen. That actually takes a lot of the ROM, because it has 10 different frames. That is not pixel art. I used the image above as a reference to make a model in Wings 3D. I then animated this model to rotate in Misfit Model 3D. Here's a high resolution version of the spinning model animation.

Another thing I had the opportunity to use in this jam and that I don't usually use besides pixel art was bad programming practices. The really bad ones, like keeping everything in globals, abusing the goto statement, putting lots of code in main() and avoiding too many functions, putting function definitions in header files... I believe this was all justified, due to the limitations of the platform, there is a performance advantage from restricting yourself to globals, and using less developed forms of flow control. Also a size advantage. In fact, even with my minimalist coding practices the code barely fits into the ROM.

Also about programming, I discovered that the compiler that ships by default with GBDK is utter crap. It's sdcc, but from 2000. There are a multitude of bugs. for's and if's that don't work, mathematical expressions that evaluate wrong, and random compiler crashes that force you to move code around until you solve them. Unhelpful error messages. Weird messages about a modified DOG called EVELYN that has something to do with the optimizer. A real pain in the ass. I advise anyone wanting to do C development for Game Boy to use the newest sdcc for GB version available. Perhaps you can even use GBDK's libs, with some messing around.

The game seems to have been averagely received by those few who played it. A problem is, GBJam does not have a voting system like Ludum Dare, that forces you to vote so you receive votes yourself, and you need a minimal number of votes to appear in the final listing. This is quite stupid. Also about the organization of the jam, Gamejolt is a terrible place to host a jam. It forces you to use 16:9 thumbnails, larger than a certain size, for some reason. It does not let you specify custom platforms for your game. It's voting system is not very good either. I suggest future GBJams should happen in jams instead.

Now for the most waited moment, the links. Click on the image below to download the ROM, also, please leave a comment if you play the game:
Alternatively, click on the image below to see the game's source code in github:

Saturday, 2 August 2014

My code - AABB vs. triangle collision with least translation vector

Recently, I did one SM64-esque demo while working on some collision code. This in all in preparation to the upcoming development of 3D games. I have now completed my quest into the world of collision detection, and I shall narrate it.

While I previously had working triangle vs. AABB collision, that implementation was of little use to game development due to the lack of a "least translation vector", that is, the minimum displacement that makes two objects to stop overlapping each other.

That implementation was based on this code, by Tomas Akenine Moller. I merely translated his code to Javascript, without understanding it. His code is pretty bad, I must say. It has horrible macros, including defining "X", "Y" and "Z" as "0", "1" and "2" (obviously for accessing elements of vectors). Any decent programmer knows why calling a macro by a single, uppercase letter is very stupid, namely, because then you can never use that letter in your code, ever, without replacing it with the macro. I also looked at some code at this site called Geometric Tools. It is also horrible. The collision functions try to be very good for performance and everything, but then the guy writes a class to do collision detection. For every single different type of collision. Now that's some stupid C++. I, however, am pretty sure of the root of such computer science horror. That is academic code. Written by academics. Who don't know how to write code that is meant to be actually used for doing something actually interesting. Precisely the same reason why they don't care to provide the least translation vector, because they don't know the real needs of game developers. They only care about publishing their clever papers about how smart they are and how much optimization they can fit into their little math puzzles.

However, since collision detection involves quite an amount of mathematics, and we humble non-academic mortals have no time to deal with those, we have no choice but to succumb to those academics. I was advised to look for a certain book, "Real time collision detection", by Christer Ericson. Of course it doesn't tell you about the least translation vector, because Mr. Ericson is an academic and did not research what game developers actually need for collision detection. I then could actually understand what Mr. Moller's horrible code was doing. And then I could make my own implementation of triangle vs. AABB collision detection, without as much bullshit and including the least translation vector (that was actually quite trivial to include, once I understood the vector operations between the separating axis theorem, it was only a matter of normalizing some vectors and including a few dot products).

I then had an almost 500 lines of code long function that of course I had to debug. Now, this kind of thing is horrible to debug, because any silly math mistake like a 0 instead of a 1 or a - instead of a + goes unseen but makes the result completely wrong. And in my case both things happened. I had to add some quick & dirty  debugging to show which axis was claiming to separate to solve the false negatives, and then to correct the errors in the least translation vector. Those last actually required checking the entire function anyway, because one of the possible candidates to least translation vector was longer than it should be and therefore would not appear in the debugging, instead a longer vector would be selected causing the box to jump around due to unnecessarily high displacement.

In the process of debugging, I made this little demonstration of the collision detection. It has a randomly positioned box and triangle, you can move the box around, and it makes the box change colors if it collides against the triangle and also shows the least translation vector as a 3D arrow. You can even move the box around.

But now I am over this horrible episode. Hopefully I will actually be able to create something with this. Except my vacations are almost over and then I won't have time. Oh well.

Check out the github repository of my triangle vs. AABB collision code by clicking the Octocat below:

P.S.: someone that has been asking me about collision detection asked me why I think this is one of the most useful forms of collision detection and why it's more useful than box vs. box collision detection. The trivial answer is that you can make a level with arbitrary geometry in any 3D modelling program and load it and collide the bounding box of your character against it.