Now:
October Challenge 2014
Ends in:

Coming Soon:
Ludum Dare 31
December 5th-8th, 2014

PST: 6 PM
*EST: 9 PM
UTC: 02:00

ConstructionPlease excuse the site weirdness. Mike is making and fixing things. Clocks are probably wrong. Colors are place-holder.

Ludum Dare 31:
Ludum Deals
???
 
Recent:
MiniLD #XX

Shit! It’s evolving Post-Mortem

Posted by (twitter: @38leinaD)
September 1st, 2012 3:18 am

Try the Web-Version!

This was the first time ever for me to successfully complete a Ludum Dare. I have tried 4 times before, but never was able to finish. The reasons varied from other real-life distractions and no good ideas to simple exhaustion. And also this time it felt the whole time like I will not be able to finish it or submit something really bad not even close to the theme. But with a week now to look back, I have to say that I am pretty happy with the result. The story and the feel to the game is more then I could have expected to develop in about 35 hours (including breaks but not the sleep).

Already a few days before the LD I decided to go with a ray-casting-based 3D game in a Wolfenstein-like fashion if I would somehow get the game to match the theme in some way. So, I briefly read an article on ray-casting to get the idea and the math straight …at least in theory. Also, I wanted to do 3D but the problem is that you can easily get caught in the art-trap: doing highly polished graphics that take up a lot of time. That’s why I love pixel-art: It has a great visual style but (depending on the resolution) requires not so much effort. Well, that sounds wrong; great pixel art takes a lot of time but you know what I mean: You can have a visually pleasant game with rather simple and fast pixel art. Would I have used OpenGL, you often get lost in detail because you can display a lot of detail (one of the previous failed attempts made me realize this).

Result of day one: basics renderer including texturing are working.

Come the announcement of the theme, I was sure that I made the wrong bet because I could not immediatly think of a good gameplay idea. I decided to proceed with implementing the raycasting-based renderer and postpone this problem to a later point in time. This lead to me spending basically 1.5 days of the time on implementing  the renderer; i.e. rendering perspectively correct walls and sprites, getting the math straight and implementing all edge-cases. I was sure that I would not be able to finish this time. Espacially because thinking straight and doing the math got hard after one day and I struggled a long time to get the textureing and sprite-rendering right. And I also discovered a bugs that got my rendering spiral out of control once I went out of the defined bounds of the world. But I learned a lot from these two things:

Result of day 1.5: Everything is almost finished (main-menu, story, weapon animation, level, sound) except the sprite-rendering

  1. Having to tackle a “hard” problem (it was hard for me at that point) actually made me get frustrated and push the problem aside a lot of times. I did not get the sprite rendering done before 4-5 hours in to the end of the compo. This lead to the situation that I was doing everything game-related that I usually have the least fun with: doing menus, sound, story, optimizing the mechanics, nice graphical gimmicks. In the end: improving the overall atmosphere of the game. I did all of this in quiet fast succession. In between I always tried to tackle the hard problem but failed or was not motivated to do it. So, 4 hours to the deadline I have a “polished” game that was only missing one core element: the enemies; because I had trouble getting the sprite rendering right. Then I got back to the problem and was so motivated to get this finally done because it was the only thing left for me to release an actually pleasant game for a 48h compo. And I finally cracked it.
  2. I realized that you sometimes get blinded by problems that are no actual problems you need to care about. As said, the rendering went haywire once I exited the bounds of the game world. Some trigonometry where I though there is a symmetry or math itself takes care of it but actually wasn’t. After struggling with it for an hour I came to the realization that the player will never be exiting the game world. Why would he? Per definition he keeps in the game world. So, I just implemented the checking that the player cannot run past the bounds of the world and everything was fine. This is not the solution that makes the math-addict in me happy because I know there is some wrong thinking in my calculations but for all practical purposes it does not matter.

Game development is almost over; the sprites animations of the blobs are finally rendered correctly.

So, actually everything went good in the end. Also the story was ok and somewhat in line with the theme. I guess you can always push a shooter in  the direction of a theme if you want but I was not happy at first with going this easy road. But as I did not have any good gameplay ideas, I got pragmatic and am quiet happy now that I did. Otherwise, it would have been another failed LD with the excuse of having no good ideas.

Once the sprite-rendering was working, the low-resolution art style again came to my rescue: the blob with it’s two animation frames was done in zero time and I could focus on improving the feel of the gameplay. What sounds are played when the blob get’s hit? How many times do I have to hit the blob? When is it getting to hard/easy? How many blobs and where are they located in the level?

I actually did not spend too much time on this questions because there was still one final thing that I never did before (due to always dropping out)  but actually turned out easy: Actually releasing the game. A quick question in the IRC revealed that most people use dropbox to host the download, so I went with that too. Especially because you can also host a static website (which I did not know). So, packaging the game as a Java applet to run in the browser should be an easy task in theory… Also in practice: I never before developed a Java Applet (maybe once in a Java course at university) but was hoping that it would be easy as my game was based on AWT as the window system.  And I was not going to be disappointed: Embedding the game-frame within a JApplet and done. It was so easy, I was impressed. While doing this I actually lost track of time and noticed while writing my final progress post that I was minutes away from the deadline. I guess it was because I really wanted to package the game as a web-version to make it as easy as possible for everyone to try it. No download and bad feeling to start some random executable on your local system. (Side note: I still don’t understand why not more people make this a higher priority in the choice of their dev tools/language. The exposure of the game gets so much better.)

Looking back, I am happy to have finished the compo with a game I feel is not too bad for 48 hours and me knowing that I can do this; there is no excuse anymore to drop out of future LDs.

If you are interested, I also made a timelapse:

Leave a Reply

You must be logged in to post a comment.


[cache: storing page]