Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!

Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created.You NEED ratings to get a score at the end. Play and Rate games to help others find your game.We’ll be announcing Ludum Dare 36’s August date alongside the results.

New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.

Joe Williamson's Archive

This was my seventh Ludum Dare. I always aim for the compo, though for my last couple of entries I ended up overflowing into the Jam. I’d only failed to finish once before (Ludum Dare 33), and it felt pretty terrible. Not only was it the first time I had failed to finish, but I also felt like what I had produced was not worth using.

Once again–Ludum Dare 35–I did not finish, but this time I feel quite differently about it. I could have gone into the Jam, but realistically I know that would not have helped. I still had some fundamental issues to fix and was far behind where I needed to be.

In the first morning I produced a rough mockup. My thinking was that if I kept to low resolution silhouettes, I could save some time on art compared to my usual style. It didn’t really work out. It didn’t do any art beyond this, but it’s pretty clear is wasn’t going to be a simpler task than usual to complete.

Following that, I produced some music. It’s very rough but I was pretty pleased with it for how quickly I put it together.

Finally I came to implementing my shapeshifting mechanic idea, which is perhaps the most ambitious I have attempted in a Ludum Dare. Having not completed any new level design or art for this jam, here is a demonstration of the machanic in my LD32 game, Fathom, alongside a gif showing the original LD32 mechanic.

One issue I have with Ludum Dare is that it often leaves me with an idea I really want to work into a full game, and finding the time for that is very hard. Each Ludum Dare seems to add another game to my todo list, and Fathom is already on that list! However, I feel this new warping mechanic suits my plans for Fathom very well, both in terms of story and gameplay. I have many ideas for variations on this mechanic, and many ideas for puzzles.

Unlike in LD33, then, I feel I have actually spent my time in a useful way. Furthermore, I am newly inspired to do more work on Fathom!

I was absolutely sure I had missed my chance at getting anything in. It’s a tad truncated, and you’ll likely run into a bug or two, but it feels good to have actually got something in after having actually given up and gone to do something else for a bit. xD

Fathom in a platform game in which you play a robot trying to escape from the organisation that created you. Machine gun turrets block your exit, but fortunately you have the ability to slow time and redirect their bullets with your mind.

I had clear objectives for this LD. In my previous two entries I had put great emphasis on creating experiences based around a single moment, with attention to narrative and cinematography. In Sinister, this moment was the creation of the world around you, culminating the stars and moon exploding over the horizon in time with the music. In Spiral Wings, this moment was when the dragon breaks free from the prison and spreads it’s wings, silhouetted against the sun.

Ultimately I hope to create games built out of many impactful moments, and so I took these previous entries to be practice. This time, however, I decided to make my focus more about the gameplay, which in my previous entries had ended up being an afterthought and implemented in the final two hours.

My hope was that with more experience, improved skills, and better preparation, I would be able to spend more time on gameplay without the art and sound suffering too much. I would simply avoid spending excessive amounts of time building some cinematic introduction synchronised with the music.

Tools and Preparation

As with previous LDs, Haxe was my language, and HaxeFlixel my engine (which has improved a fair bit since my first LD a year ago). For art I primarily used PyxelEdit, with an occasional dip into Photoshop. For audio I used Reaper, with a selection of free VSTs from VST4Free.com, plus a couple of premium ones such as NI Massive. For level design I used Tiled.

This time I did try to prepare some base code. I intended mainly to fix some things I considered to be issues with flixel. Firstly, Tiled maps could not be loaded with multiple tilesets, nor could they be loaded while maintaining the order of the object layers. Furthermore, tilemaps in flixel are quite restricted if you wish to use them like regular sprites, for example if you wish to treat them as physical objects. Prior to LD, I made some commits to flixel-addons on GitHub to improve the Tiled integration. Flixel developer Beeblerox also implemented a method for loading multiple tilesets into a single tilemap. Lastly, I attempted to write some flexible Tiled loading code, and a set of classes for making tilemap games with Nape physics, including platformer physics.

This last part didn’t go so well (but the abandoned work in progress is still available on GitHub). I didn’t have time to finish the Nape integration, and so the majority of time I spent on the base code was not useful. However, when LD started and I realised I wanted to make a platform game, I was able to salvage a chunk of the base code for Tiled loading. This code made it easy to define different game object types that could appear in a map, and what should happen when they are loaded.

Further to code preparation, I had also created a platform game tileset template for PyxelEdit. This is available at joecreates.co.uk/download/tilesettemplate16x16.pyxel. While I am still working on improving this template, it provides a good base for designing a platform game tileset, and PyxelEdit will allow you to resize the template to any tile size.

Art

I spent (very) approximately 20 hours on art. For this time, I am very pleased with what I was able to do, even though I still had many assets that were incomplete, or that would have taken too long to get into the game. Whereas I had previously wasted a lot of time on clouds, this time I was able to do them in minutes thanks to PyxelEdit’s scatter setting on the brush (yes, I basically just scribbled scattered circles over the canvas).

I took a lesson from Sinister when animating the character. In Sinister, I animated the tailcoat as a separate object, and then reused this in the standing and running animations, adding a lot of movement for very little effort. In Fathom, I used the same method to animate the scarf.

I was also able to produce a tree fairly quickly, thanks to a strategy that I am increasingly trying to apply to my process. This is to combine the steps of tidying the initially rough sketch with the stage of adding of highlights. Often, these can be two distinct phases, however, they can often be done at the same time. For the tree, I was able to sketch the overall form of the leaves out of small circles. These circles could quickly be turned into leaves by adding a single straight highlight to the side. This highlight added the extra pixel needed to give each circle a point (to give it the shape of a leaf), thus solving two problems at once. Another example of this approach is to remove “jaggies” (making the lines in a piece appear to be cleanly straight or curved) during the phase of antialiasing. Something I feel I still spent too much time on was simply choosing the colors. Perhaps in future I could use prepared palettes?

The above screenshot shows the three frames of a turret, normal, muzzle-flash-lit, and destroyed, along with a mockup I used to experiment with rough assets.

Music and Sound

In previous LDs, I had easily spent over 10 hours on just the music. This time I was hoping to ship with something a little less developed, but still effective. I think I ended up spending about 4 hours on the music. I quite like the theme, but I think there is a lot more that can be done with it, and some bits just sound a bit messy to me. It still does the job, so I am happy with my decision to spend less time on it.

Gameplay

This time I actually managed to have gameplay beyond “collect X -> you win”. Firstly, I implemented a (to my knowledge) fairly original mechanic of allowing you to slow time and redirect enemy projectiles. On top of this, I also implemented collectable upgrades which could enable the player to reach new areas of the map. Enemy bullets can so far be used to destroy other enemies, and also to destroy generators which power obstacles such as an electric gate.

There are a few issues that stand out with the current implementation. Firstly, when you click to slow time, the camera zooms in a little. This looks pretty cool, but is totally annoying when it means you can no longer see the thing you are aiming at. I will experiment with having the camera also move in the direction of the cursor when you slow time.

Secondly, it is currently possible to “brute force” your way past the most difficult turrets. Whereas it was my intention for players to collect the “Penetrate Shields” upgrade before being able to proceed past some shielded turrets, some people were able to pass them simply by keeping time slowed and progressing very slowly. I had originally intended to have a time-out and recharge on the time-slow ability, which would solve this issue, but I didn’t have time to implement it during the jam.

Finally, it is currently beneficial to just sit and wait for bullets with time slowed, seeing as without doing this the bullets are very fast and difficult to pre-empt. This means that a lot of the player’s time is spent sitting and waiting, which I’d like to avoid. Once solution might be to reduce the speed of the bullets, however, I quite like the fact that they appear to slow a lot when you slow time. Reducing the bullet speed might make the time-slow ability seem less powerful, and frankly I want players to feel epic when they slow time. Alternatively, I could add some kind of charge effect on turrets to make it possible to pre-empt a shot.

Moving from Compo to Jam

With the compo deadline closing in, I had the main gameplay implemented, but only about 10% of the level. I had completely underestimated how long it would take to put the level together. This was not helped by the fact that the tilesets were relatively complicated. In order to make them look good, tiles had to be carefully positioned such that they look right next to their adjacent tiles. Furthermore many of the tiles required specific tiles to be placed on layers above or below them, increasing the complexity of the tilemap for purely aesthetic purposes. A simpler tileset that could work on a single layer, made out of more obvious squares that could be placed adjacent to pretty much any other tile, would have been significantly quicker to build a level out of. I do love to be overambitious with the art, though. Can I bring myself to do something simple enough to quickly build levels out of next time? Er . . . I make no promises.

Without a level, I had no choice but to swap to the Jam and take an extra day to complete the game. It turns out that I also needed this time to fix bugs and balance the gameplay.

Future Plans

I have quite a lot of ideas for developing this further. On top of fixing the issues I mentioned above, ideas I have include:

More in depth story

Rocket turrets with curvable rockets

Upgrades for charging the time-slow ability

More clear connections between generators on the things they power

Spinning reflective blade projectiles that can be jumped on

Laser projectiles that cannot be redirected (seeing as they have no mass) but can be reflected by the aforementioned reflective blade projectiles