Well, ten minutes to go, might as well post this now.

I’ll be using javascript (with raphael.js), gimp, inkscape and musescore (maybe I’ll also use audacity).

 

Good luck everyone.

Hey everyone,

I had some interesting anecdotes from my entry this year, so I thought about documenting them somewhere to share in the future. The Ludum Dare blog looked like a nice place to store it. :)

EDIT: Sorry for the long post on the front page, I thought this would be collapsed :x

Initial concept

The initial concept for the game was quite different. I had just recently watched How To Play NiGHTS (And Why You Should), and wanted to implement a similar mechanic, where you have some limited time to finish up a level, but you want to stay in the level for as long as possible.

So, the initial idea was: - You were stranded in an island with a volcano ready to erupt - There would be a timer with how long it would take for the volcano to erupt - You would visit multiple levels with treasure scatered around. - At the end of each level, you would visit the volcano to sing, and increase your timer.

Implementation

Basic code

Git commit

I started with some very rudimentary platforming implementation, just to see if I could get gravity and collisions to work. The jump felt really floaty, but it was enough for a first concept.

I also wanted to see if I could get a basic map file format to work with spritesheets and a background, and it seemed to work fine. By this point, the map format was just a text file with numbers from 0 to 9, where each number represented a tile (with 0 being "no-tile").

Initial sprites

Git commit

The I took a break from programming and worked a bit on the graphics.

At this point, I had only thought of having the volcano level (where you would sing to increase the timer), so I just started with a background and tileset for that. This also made it pretty obvious that just having 10 tiles would not work, so I moved the previous file format to use tiles from 0 to F instead of 0 to 9 (spoiler, this also wasn't enough).

The camera movement didn't work yet, so I was pretty much restricted to one screen, but this was already enough to see something taking shape.

Camera movement and character sprite

Git commit

So, the next logical step was the camera movement (with some background paralax scrolling).

After working that out, I also started to work on the fist character sprite (with no animation), because I was getting quite tired of looking at that green sprite.

I wanted to draw a character with some long hair, because I think all my previous game characters were either bald or had a hat/cap (just so that I didn't have to animate any hair). This was a nice opportunity to try something bolder.

Improved physics

Git commit

Now, the movement was still really clunky at this point, feeling super slow and floaty.

I tweaked the values a bit, added some momentum logic and then added a speedMultiplier value, which worked pretty much as a "every frame simulate the logic N times". This was helpful because then I could control the sped without having to worry about breaking the collision system.

I ended up no tweaking this any further, and the final game still feels a bit floaty as a result.

Game design changes

At this point, I started to question the original design... If you could just go to the volcano and sing to increase your time, the optimal strategy would be to actually finish the levels as fast as possible, go to the volcano and then do the level again (and again, and again...).

This was not my initial idea of having the player try to stay in the level until the last second, so my idea was to add lullabies. Every time you would sing to the volcano, you would waste on lullaby, so you would need to manage that resource.

Tutorial level

Git commit

I added the first tutorial level. This forced me to change the map format once again, to handle tiles from 0 to Z. I also added support for whitespaces in the format, which would be an empty space (same as 0). This allowed me to see the level silluete in a text editor.

I was a bit tired of the orange sunsetty background, so I just changed it to a more morning pallete and added a cute volcano on the background.

I also run into an annoying problem: As the level progressed, I started to run out of brackground, due to the paralax.

The way I handled it was to add support for background tiles (tiles from 0-9 would have no collision). This is why every level pretty much ends in a dark cave. Also, the song at the end of a level is just a background tile (number 9).

Wrapping up Day 1

Git commit

By the end of the first day, I always like to have the Game Over logic and some kind of "Win"/"Next Level" logic implemented. This allows me to be able to stop working at any point, and have a finished game, so that's what I did next.

By this time, I also noticed some very annoying problems:

• My code to pick up the final item was quite hacky, I just checked the collision with a background tile. This was not going to work if my goal was to have the player picking up treasure like coins or diamonds.
• There was a bug in the collision detection. On platforms with just 1 tile, the player could become stuck. I ended up just designing the forest level around it, but this is the reason the level feels so cramped.

Starting Day 2

Git commit

The first thing I did was to clean up the menu and game over backgrounds. As I said, at this point it's really important for me that I can just wrap up the game at any time. I also cleaned up the forest level a bit: no more black background at the bottom, like on the previous images and I made some parts less cramped.

Rest of the levels

Git commit

I then took some time to add more levels and to add make sure that, when the player reached the lullaby, it would transition to the next level. I also balanced the difficulty a bit (I added a bit more time to the timer, as usually my Jam games end on the harder side).

One important thing to note is that when I was working on the temple level, I endedup fixing the collision bug, which was also quite helful for the volcano level.

I never went back to clean up the forest level, though. Actually, at this point it became pretty obvious that I wouldn't have time to tweak the physics, as that would force me to update all levels (I guess I should have polished that first... oh well).

I also decided to add an easter egg in the last level. It does literally nothing (it's just a background tile).

Adding music

Git commit

I always leave the music for last. I don't like to spend the whole Jam listening to the same game song.

I composed the songs in the following order: - Intro - Menu music (actually, in-game music, I'll explain later) - Jump sound effects (which was just me saying "fwoosh" to the microphone and applying compression) - Game Over - Lullaby - I initially planned to split this song in 4 parts, with each one playing at the end of each level (with the full song being played in the end). I gave up on this idea, because some parts would just sound a bit weird in isolation, and I think most players wouldn't notice it. - In-game

In the end, I really didn't like the in-game music that much, and during testing I was already using the menu music, which seemed pretty fitting, so I just swapped them.

While working on this, I also took some breakes and finished the game title, thank you screen and the "GO" and "Finish".

Wrapping up

After that, I just wrapped the project up. I converted all resources to QOI (I used BMP while development because it was faster to export, but QOI files are much smaller), added a loading bar and made sure that the JavaScript build worked).

I ended up delivering the final product quite early (I think there were at least 5 hours left), but I was already quite tired and ready to call it a day.

Final notes

If you were able to read this far, thanks so much for your time. :)

I developed this game not only with the intention of enter the jam, but also to test a new version of my graphics/input library: Minart.

This actually allowed me to find some bugs with loading BMP files and some of the keyboard input handling (you might notice that the jump acts kind of weird if you keep space pressed down, this is a library bug).

Take aways

Now that the results are in, I can take some notes about the performance of this entry.

The good: - I was quite happy with the graphics. I think I'll use Libresprtie on future entries as well. They also got quite a nice score (Q2 - 3.52). - I was able to get a JS build ready with a nice framerate on both Chrome and Firefox. - I think this 720p resolution worked quite well.

The mixed: - I tried musescore instead of tuxGuitar this time. The audio got a nice score (Q1 - 3.475) and it seemed to work better than tuxGuitar, but I'm not 100% sold on it.

The bad:

• This was my worst Ludum Dare entry, placing on Q3 on almost every category.
• Looking at both the ratings and feedback, it's clear that the game was just not fun (and not really innovative).
• I spent too much time working on the polish, when I should have improved the gameplay loop first
• Overall, this type of adventure game seems like a bad idea for a 48 Jam game (at least for me). It required a ton of assets, and I'm quite slow at producing those. Adjusting the original idea to a simpler arcade concept would probably have worked better.

Hope that I actually learn something from this entry :slight_smile: