![\"\"](\"http:\/\/libgdx.badlogicgames.com\/yay.png\")
<\/p>\n
I implemented Bob\u2019s movement (acceleration + damping makes for some nice movement) as well as collision detection. The later turned out to be a problem and took me 4 hours. Once Kivan told me an easy way to handle it in my setting i was able to completel scratch and rewrite it in 20 minutes. The more you know.All in all i spent around 6 hours for this first phase.<\/p>\n
In terms of language, tools and so on i settled for the following:<\/p>\n
- \n
- Java plus libgdx<\/a>. I wanted to eat my own dog food<\/li>\n
- Deployment would happen as a single self-contained runnable JAR file. Easy to distribute, no installation required, the closest you can come to an executeable in Java<\/li>\n
- Eclipse, cause it\u2019s what i know best.<\/li>\n
- For graphical asset creation i used Paint.NET. While i really like Gimp, it\u2019s interface still turns me off and i find it a lot easier to work with Paint.NET\u2019s more streamlined (but less capable) interface. Sadly it\u2019s only available for Windows (not a problem for me).<\/li>\n
- For the tile maps and object placement i also turned to Paint.NET. Objects and tiles are color encoded in a bitmap. Objects that span more than a tile are represented by a pixel indicating their starting position only. The rest is constructed during run-time.<\/li>\n<\/ul>\n
Downtime, trying to give up<\/h3>\n
With this prototype i ended the first LD phase. I had a feeling that there was not enough time left for me to fully finish a playable game. I started on sunday, 1:30am GMT-2, so there were only ~27 hours for me to work. My woman and I planned to go to an HR Giger exhibition the same day. Let\u2019s say she was surprised to see me awake at 8am in the morning in front of the netbook. I went to bed at around 8:30am and got up at 1pm. At that point i gave up on LD as i figured i\u2019d only have 8 hours when i come back from Vienna (trip was estimated to take ~6 hours). Some impressions from the exhibition (couldn\u2019t photograph the actual artwork).<\/p>\n
![\"\"](\"http:\/\/www.badlogicgames.com\/wordpress\/wp-content\/uploads\/2011\/05\/IMAG0072-179x300.jpg\")
<\/a><\/p>\n![\"\"](\"http:\/\/www.badlogicgames.com\/wordpress\/wp-content\/uploads\/2011\/05\/IMAG0073-300x179.jpg\")
<\/a><\/p>\nThe toilets in the Hundertwasserhaus are especially artsy fartsy.<\/p>\n
![\"\"](\"http:\/\/www.badlogicgames.com\/wordpress\/wp-content\/uploads\/2011\/05\/IMAG0074-300x179.jpg\")
<\/a><\/p>\nAliens with Penises and Tits, Phase #2<\/h3>\n
On our way to the exhibition we talked about the game in the car. For 2 straight hours. Steffi wrote up all the ideas we talked about. When we arrived in Vienna i had a full fledged game design in my pocket. I was psyched. I knew with this in my hand i could easily finish of a basic version of the game in the remaining 8 hours i had when we came home at 8pm. Here are the notes in German:<\/p>\n
![\"\"](\"http:\/\/www.badlogicgames.com\/wordpress\/wp-content\/uploads\/2011\/05\/IMAG0075-300x179.jpg\")
<\/a><\/p>\nTranslation:<\/p>\n
- \n
- Chambers\n
- \n
- Entry\/Exit, use cube to open the exit.<\/li>\n
- One or more cube dispensers\/respawn points<\/li>\n
- If there\u2019s not cube in the scene, the last touched dispenser generates one<\/li>\n
- Cube follows automatically<\/li>\n<\/ul>\n<\/li>\n
- Controls\n
- \n
- Keypress activates cube control via usual means (w,a,s,d)<\/li>\n
- Pressing the same key while the cube will return control to Bob, the cube freezes for n seconds and is collideable (useable as a platform). Once the time is up the cube follows Bob again.<\/li>\n<\/ul>\n<\/li>\n
- Obstacles\n
- \n
- Bob can die in which case he respawns at the last touched dispenser. Same is true for the cube<\/li>\n
- Spikes \u2013 kill Bob<\/li>\n
- Lasers, vertical and horizontal \u2013 kill Bob, can be blocked by cube<\/li>\n
- Moving Spikes, vertical and horizontal \u2013 kill Bob & Cube<\/li>\n
- Homing Missles \u2013 kill Bob, blocked by cube<\/li>\n
- Robot \u2013 kills Bob on collision, no effect on cube<\/li>\n
- Shooting Robot \u2013 kills Bob on collision, shots blocked by cube<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
A sequence of levels was also losely defined:<\/p>\n
- \n
- Introduce dispenser, cube & exit<\/li>\n
- Introduce jumping and cube following<\/li>\n
- Introduce spikes (no help from the cube needed)<\/li>\n
- Introduce moving spikes<\/li>\n
- Introduce non-shooting enemies<\/li>\n
- Introduce spike pit only traverasble via the use of the cube mechanic<\/li>\n
- Introduce shooting enemies and corresponding cube mechanic<\/li>\n
- Introduce Lasers and corresponding cube mechanic<\/li>\n
- Introduce homing missles and corresponding cube mechanic<\/li>\n
- Be creative with the elements from here on<\/li>\n
- \u2026<\/li>\n
- EOL!<\/li>\n<\/ol>\n
Back home i looked at this and was excited. I had 8 hours left, a very simple prototype and a full-featured plan. I started by prioritizing game elements. The doors went the way of the Dodo, they didn\u2019t add anything to the game play. While they would be a motivator to keep the cube alive they were ultimately point-less: you can always get a new cube from the last dispenser, the only effect would be that you have to replay the level from start without any real benefit. Frustrating!<\/p>\n
The enemies were cancled as well. I thought the other game play elements (spikes, moving spikes, homing missles and lasers) where interesting enough. I was also confident i could implement them all in the remaining time. <\/p>\n
After some reordering of the level sequence i decided to have a single big level with multiple dispensers. Sort of like in VVVVVV. Continuous level for the win. <\/p>\n
The level itself would be tile-based as said earlier. Objects would be encoded as pixels with specific colors, e.g. a dispenser would be red (0xff0000), a laser cyan (0xffff00) and so on. An object\u2019s pixel would only signify it\u2019s position in the world, not it\u2019s extend. Lasers and moving spikes span multiple tiles in-game for example. I could easily derrive all properties during runtime given only their position, e.g. their direction and so on based on their surrounding. <\/p>\n
With all this ready i started hacking again. And hacking i did.<\/p>\n
Hackaton, Phase #3<\/h3>\n
Everything went a lot better then excepted. I added one game element after another. I set a time-frame for each feature and a sequence of implementing them. 7 hours to go!<\/p>\n
- \n
- Cube control & following with Collision detection: 30 minutes, code is basically the same as the one for Bob in the prototype<\/li>\n
- Spikes and collision detection & response: 60 minutes, this included respawn points, animating Bob\u2019s death<\/li>\n
- Homing missles: 45 minutes, this included spriting the rocket and an explosion plus the usual physics\/logic implementation<\/li>\n
- Moving spikes: 60 minutes, a simple afair of figuring out the direction based on the position & surrounding of the spike in the map as well as collision detection with the map and changing direction in that event<\/li>\n
- Lasers: 80 minutes, basic setup as with moving sprites (figure out direction and end position of laser) plus some more involved collision detection with the cube (blocks the laser mid-way) and Bob. I knew this could get hairy but it turned out better than expected<\/li>\n
- Screens: main menu, intro screen, game over screen: 30 minutes. I decided to go with a rather \u201cmake-your-eyes-bleed\u201d single image per screen style which could be implemented quickly. <\/li>\n
- Exit & Gameover state: 30 minutes. Another simple afair, just place the exit somewhere in the level and trigger a screen transition to the game over screen<\/li>\n
- Level Design: 80 minutes. I wanted to have one continuous level. For this i made a special respawn object that let\u2019s me test different chambers immediately on the go. This system let me test a specific chamber immediately. I just moved the object around the map when i created a new room. This way i could generate a level that takes an average player (Steffi) around 6-7 minutes to complete. Not a lot but enough for my needs.<\/li>\n<\/ul>\n
As you can see in the timelapse<\/a> i could stick to that schedule pretty much 100%. The final packaging took about 5 seconds. Export -> Runnable Jar. <\/p>\n
I delivered the submission at pretty much excatly 4am local time, a spot on submission so to speak.<\/p>\n
What went Well<\/h3>\n
- \n
- The decision to use a bitmap to encode the level information was a good one. I did not have to battle any editor i wasn\u2019t familiar with and could make up new encoding rules on the go. Previewing was also painless and always only two keystrokes away.<\/li>\n
- Since i decided to eat my own dog food in form of using libgdx for this i was curious if our design decisions would hold up in an extreme situation like Ludum Dare. Thankfully the framework never got into my way at all. Everything i needed was in place, from input handling to rendering and some math & collision helpers. Of course, the game is pretty simple so i did not have to make use of any of the more advanced facilities in the framework. Never the less it turned out to be extremely simple to work with.<\/li>\n
- Having a full design is something i can\u2019t state the importance of enough. Seriously, if you enter something like Ludum Dare, spent enough time to make everything watertight. It\u2019s so much easier to work from a design then to make up shit on the go. Of course i first prototyped before i went full-design-metal. Once you know your prototype works start designing, not coding!<\/li>\n
- Paint.NET is a joy if you know all the keyboard shortcuts. I was able to pull of all the asset and level creation in no time.<\/li>\n
- Having ~20 people in our IRC chat was valuable as well. I had some test slaves and some of the folks could even give me tips on how to approach the fsm damn initial collision detection problem (never did a platformer before\u2026). Thanks Kivan!<\/li>\n
- The schedule was also very helpful and allowed me to make the deadline. It would have been very easy to get sidetracked with a small detail otherwise. Keeping my eye on the clock was a \u201cgood thing\u201d and mostly responsible for me making the deadline.<\/li>\n<\/ul>\n
What went Wrong<\/h3>\n
- \n
- Having done some rather elaborate math and computational geometry in the past i thought that the collision detection for a simple platfomer would be a piece of cake. Not so. I spent full 4 hours out of the 13 hours total to get Bob to correctly react to his surrounding. That was rather embarassing as i thought i was knowledgeable about most game development stuff. The more you know! A humbling experience.<\/li>\n
- Due to me starting on the second day and spending a good 7 hours on none Ludum Dare related things i was really short on time. I think i could have created something a lot bigger if i\u2019d used the full 48 hours.<\/li>\n
- Sleeping for 4 hours is useless. Sadly there was no other option. I really wanted to see the Giger exhibition and spent quality time with my woman. Note to self: sleep at least ~8 hours before and dacuring Ludum Dare!<\/li>\n
- I did not have time to include sound effects. Which is funny cause i really think sound makes up 30% of a game easily in terms of immersion. I\u2019ll do better next time (sfxr & my own sequencer to the rescue!).<\/li>\n
- The level design is very basic. I underestimated the time needed to come up with something fun and engaging. I think the basic game mechanics and elements would allow for a pretty decent game. 80 minutes are simply not enough to explore the full potential of the game. Spent more time on this item the next time!<\/li>\n
- The game is controlled by w,a,s,d and e. It was my goal to keep the controls as simple and intuitive as possible. To bad i forgot to add an option to \u201cunfix\u201d the cube. At the moment it will stay fixed for 5 seconds which can disturb the overall flow quite heavily. I didn\u2019t think of letting the user press e when the cube is fixed so it starts following again. Oh well
![\":)\"](\"http:\/\/www.ludumdare.com\/compo\/wp-includes\/images\/smilies\/icon_smile.gif\"\/)
<\/li>\n<\/ul>\nConclusion<\/h3>\n
I haven\u2019t written a single \u201creal\u201d game in over a year. The three games i wrote for the book<\/a> felt a lot like work due to the time pressure, so i don\u2019t count them. Hacking away on libgdx, while game development focues, is not the same either. I nearly forgot how enjoyable game development can be. So, thanks Ludum Dare you reminded me why i do this
<\/p>\nMy Ludum Dare 20 Entry<\/a><\/h3>\n
Source Code<\/a><\/h3>\n
Playthrough (Warning, Spoilers. Or so\u2026)<\/h3>\n