{"assets":[{"original":"http:\/\/ludumdare.com\/compo\/wp-content\/uploads\/2016\/09\/LevelEditor.jpg","local":"\/data\/posts\/2016\/09\/1279aa338ca83621007f9ce1f81c5766.jpg"}],"author_link":"author\/perecil\/","author_name":"Mathieu Muller","cat":"LD #36","categories":["LD #36"],"comments":[],"epoch":1473828180,"event":"LD36","likes":5,"metadata":{"p_key":"84031","p_author":"Mathieu Muller","p_authorkey":"0","p_urlkey":"294771","p_title":"GLITCh \u2013 A ludum dare 36 post mortem.","p_cat":"LD #36","p_event":"LD36","p_time":"1473828180","p_likes":"5","p_comments":"0","p_status":"WAYBACK","us_key":null,"us_name":null,"us_username":null,"event_start":"1472169600","event_key":"35","event_name":"LD36"},"source_url":"2016\/09\/14\/glitch-a-ludum-dare-36-post-mortem\/","text":"

Introduction<\/strong><\/p>\n

It\u2019s time for a new post-mortem! Today I\u2019ll talk about the game I made for the Ludum Dare 36, G.L.I.T.Ch. Yes, it\u2019s an acronym and stands for \u201cGame that Learns Information Technology to Children\u201d. I must be honest, I got the gameplay idea long before the LD, mostly when I saw the Cubetto<\/a> project on kickstarter. I told myself \u201cCubetto is fun in the base concept, but you could extend it a lot more if your robot was virtual\u201d. I left this project\/idea on a sheet of paper, extending with new features for weeks. I even talked about it on a forum<\/a> like four months ago ( in french ).<\/p>\n

\"GLITCh\"<\/a>

GLITCh \u2013 A ludum dare 36 game<\/p><\/div>\n

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\u2019s your ancient technology) but the only one \u201calive\u201d 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\u2019s core concept, the game is reminiscent from the old Amiga game \u201cBrat<\/a>\u201d ( gameplay video<\/a> ).<\/p>\n

Saturday<\/strong><\/p>\n

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.<\/p>\n

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\u2019t 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\u2019t know if the framework put in place to handle the animations was easy to use or not).<\/p>\n

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\u2019s an art style that I\u2019m at ease with, but also because it\u2019s fast to produce.<\/p>\n

The day was taken mostly to add basic features and to test the core concept, aka \u201cput arrows in place, make the robot follow the arrows to the exit\u201d. Around midnight, I had my first level working, but very rough controls and input (mostly due to bugs in the draggable code).<\/p>\n

Sunday<\/strong><\/p>\n

I had to get back my daughter who was on holidays for a week with my girlfriend\u2019s 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\u2019ll have to use the Jam extended time period to finish my game.<\/p>\n

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\u2019t support editing of properties that aren\u2019t 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.<\/p>\n

\"Level<\/a>

The new, improved, level editor with property edition<\/p><\/div>\n

I also had another problem; in the first design, I thought I could make the robot \u201cfall\u201d 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\u2019s 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.<\/p>\n

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!<\/p>\n

Monday<\/strong><\/p>\n

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.<\/p>\n

Unfortunately, there are some things that I could not finish in time:<\/p>\n