Introduction
It’s time for a new post-mortem! Today I’ll talk about the game I made for the Ludum Dare 36, G.L.I.T.Ch. Yes, it’s an acronym and stands for “Game that Learns Information Technology to Children”. I must be honest, I got the gameplay idea long before the LD, mostly when I saw the Cubetto project on kickstarter. I told myself “Cubetto is fun in the base concept, but you could extend it a lot more if your robot was virtual”. I left this project/idea on a sheet of paper, extending with new features for weeks. I even talked about it on a forum like four months ago ( in french ).
GLITCh – A ludum dare 36 game
The ludum dare was the opportunity to materialize the concept in a proof of concept. For the theme, I immediately thought about Wall-E, an old robot forsaken on earth (that’s your ancient technology) but the only one “alive” as other, more advanced robots suffered from a glitch. As the player, you would have to program your robot by placing instructions on the level. In it’s core concept, the game is reminiscent from the old Amiga game “Brat” ( gameplay video ).
Saturday
Due to the heat at this end of the month, I woke up at 5 am. As I live in France, the LD theme is announced at 4 am, so it was almost a perfect match. I just checked the theme of the LD and got back to sleep.
At 8 am, I fired up my IDE with MonoGame, a open-source XNA replacement, and with my MonoGame extension libs. Having done mostly platformers with the previous ludum dare, I knew that my lib didn’t have such features as controls (in the Windows sense); I would have to implement draggable items, buttons, control panels, and so on. Also, my lib supports sprite animation but it is very experimental, and I never tested it in a game (only functional and unit testing where done in a previous project, but I didn’t know if the framework put in place to handle the animations was easy to use or not).
I basically started by copy / pasting the initialization code from the LD35, and replaced menu and title images from the previous game with new images. I choose to use pixel-art (upscaled 4 times, that means that each sprite pixels use 16 pixels on screen) because it’s an art style that I’m at ease with, but also because it’s fast to produce.
The day was taken mostly to add basic features and to test the core concept, aka “put arrows in place, make the robot follow the arrows to the exit”. Around midnight, I had my first level working, but very rough controls and input (mostly due to bugs in the draggable code).
Sunday
I had to get back my daughter who was on holidays for a week with my girlfriend’s parents. I only had the time to code/draw late at night (starting from 9 pm to 12pm). I already knew that I could not make it to the compo, and that I’ll have to use the Jam extended time period to finish my game.
However, as the base was working, I could code new tile behaviors (the no command tile). I also had the idea of a switch that can control a distant gate, but my level editor ( which is a simple HTML page where you can drag and drop items on it, generating the XML for the level ) didn’t support editing of properties that aren’t positioning properties (i.e. top left width left and tile type). While for other games, I could dodge this missing feature by using tricks, I had to implement it for the LD 36, as I needed to tell the switch which gate it could open.
The new, improved, level editor with property edition
I also had another problem; in the first design, I thought I could make the robot “fall” from the level if an arrow was misplaced; however this proved difficult to implement as you may run in drawing order changes ( currently, the level is splitted in layers, a bit like photoshop: the background with the tiles, the one where the commands are added, and then the layer containing the robot ). This layering system is a legacy from the previous ludum dare ( it’s nice for a platformer, as you can put items behind or before the player sprite ) but is not so clever for a top down game. So, when falling, my robot should have been occluded by tiles that are at the same ground, but lower from a screen perspective. Due to the false 3D perspective, I would have to encode some kind of Z component on each tile to tell if the robot was occluded by the tile when falling.
That was really too complicated, especially due to the time frame left. It was simplier to stop the robot in a fail-safe mode (OK, it is ancient technology, but even the Roomba has sensors to prevent to fall from stairs :D) and indicate the player that he was stuck. And that was doing the trick!
Monday
Again, as I was working, I did know that I only would have 3 or 4 hours more to work on the game on Monday. I usually spend Mondays on polishing the game: adding transitions, tests, timers, fading screens and so on. Usually, the game without these things shows a gameplay concept, but taking time to adding non critical things like this gives your game a polished look. I prefer, in general, have less features but a well finished game than putting a lot of untested / badly tested features in a game. And most of the time, some last added features proves to be bad features. Keep It Simple and Stupid (KISS) principle prevails in all of my games :D.
Unfortunately, there are some things that I could not finish in time:
- The robot animations (move left and right were made, but I also wanted to include rotations and move up / down animations). Drawing the robot rotation in pixel-art proved to be a real challenge.
- More levels. Like said, the ideas are not missing for this game. The robot already includes a battery (it’ll fail if you start an loop ingame due to battery depletion), but there is no representation of it in game. The robot could also use tiles that replenishes it’s batteries (induction anyone? :D). Threading could be represented through multiple robots doing tasks concurrently. Robots could pick up items (in a stack), so you could technically make a level that would allow a Tower of Hanoi kind of problem to be solved. Pressures plates could be a thing to (similar to a dead-man switch where you have to stay on the switch to allow it to function). Logical gates (Switch A and B must be activated to open a gate). Arithmetics counters tiles. There are really a lot of things doable for such a game…
Conclusion
This game was made essentially to teach the basics of computer science to my daughter; It was time for her to test the game. After explaining her the base concepts of the game, she was able to play through level 1 to 4, but the fifth level proved to be a bit difficult for her, and I had to accompany her and explain her some tricks to finish the level.
Now, I have a question for you all. The game was intended to be played on a mobile device (tablet, or smartphone), and some testers asked me for more levels (and I didn’t forgot you at all, I was working on code upgrades/clean up required for these new levels). Should I really continue this game? I have lots of features ideas (that could teach the principles of threading, stacks and so on) that I could put in it, but only if more people are interested in this game. If you say yes, I could maybe work more on the game, and release it, but I’m unsure about it as it wasn’t my original plan at all…
Link to the game’s entry: GLITCh
Tags: final post mortem
Civilization Builder is ready for the first test: http://www.airapport.com/p/civilizations-builder-first-testing.html 
