Ludum Dare 36
The Theme is:
Ancient Technology

Feedback Friends
Give and receive feedback on your game

LD36 has ended!
Well done to everyone who took part.
1910 Amazing Games!

Posts Tagged ‘post-mortem’

“CRTs are Ancient, right?” post-mortem-y thing

Posted by (twitter: @CliffracerX)
Tuesday, August 30th, 2016 3:18 pm

I’m both proud of, and really disappointed with my entry, “CRTs are Ancient, right?“.  Gameplay-wise, I think it’s probably the most polished, and with the most potential for continuation.  Content-wise, I’m really disappointed.  There’s a lot I wanted to do, and a lot of potential, but I was too focused on all the mechanics to be able to get any of it implemented.

All of my other entries usually take at least 10-15 minutes to play through and get a good idea of, whereas this can probably be done in five or less.  There’s one proper level in the game.  One.  That’s the shortest of any Ludum Dare entry I’ve ever made.  Considering how much effort I put into making the mechanics, I’m really sad there’s only one puzzle to use them with.

I think the biggest mistake was trying to make so many features; it’s a stealth game, a hacking game, and a first-person shooter all rolled into one.  You use the computer terminals to achieve your objectives, doing things like printing important documents, toggling lights, or working with elevators.  You can hide in the shadows and move swiftly, like a ninja, and never have to kill a single guard.  You can rambo through and shoot all who stand to oppose you.  All these mechanics are pretty decently polished, but I spent so long making them all that there wasn’t any time left to build a game around them.

Level creation for puzzley games is always a pain, there’s no denying that.  I was lucky to get four made for Shift back in LD35, and it was a real struggle to get them all working; and the number of mechanics to juggle was *way* smaller.  I wanted this to have lots of interesting puzzles built around timing, working with lights, shadows, etc; true light-n-dark stealth is hard to come by these days.  I wanted the computers to feel like an important part of the game; out of everything, they’re still the most clearly ancient.  But instead, they’re more of these simplistic things that you type away at for a couple of seconds, do whatever it is you need to do on them, and then go back to running/gunning/doing whatever it is you do.

I had these grand dreams of putting some social commentary on them; if you stopped and used “viewData” on some, you’d get these little insights in SCI-style files, where someone at the coropration (aka: me) would have written some info on something or another.  An entry on Tulpas, or psychology, social studies, even OS security holes.  Social commentary and story building.  It was going to be awesome.  But when it came time to write them, I realized there wasn’t any time to spend sitting around writing walls of text; not many people would end up reading them, and I needed to focus on level-design or gameplay mechanics.


In the end, I’m happy-ish with what’s out, but disappointed by all the lost potential.  Now, if you’ll excuse me, I’m going to go relax in No Man’s sky for a few hours before going back to playing and rating some of your games.

Post-mortem of “The Language of the Gods”

Posted by (twitter: @ladybenko)
Tuesday, August 30th, 2016 10:41 am

Hi all!

I wrote a post-mortem for my game The Language of the Gods, and I’m publishing it here as well. I hope you like it, and please play my game and tell me what you think! :)

> Play The Language of the Gods <



I woke up at 7AM to see the jam’s theme, “Ancient tech”, and went outside for a long walk to feel refreshed and let my mind wander a bit. Then I headed to a café to have breakfast and do some brainstorming. I really love doing mind maps for jams, it really helps me in finding out ramifications of the theme.

Photo of mind map

And then I had an idea I really, really loved. It was a story-driven game with the plot involving an explorer in an deserted alien planet trying to figure out how to get back home and discover the secrets of the now long lost alien civilization. Topics would include Good & Evil, the nature of reality, personhood, etc.

And to deliver all of this, I envisioned a kind of atmospheric game, with lots of exploring, some puzzles and opportunities to chill out while you go unfolding the story.

Still at the café, I doodled some concept art:

Concept art

Problem with this idea? Way huge for the scope of a game jam. But I wanted to make something with this idea, so I considered two choices:

  • Make a Twine game and focus on the story.
  • Make a vignette that captures the atmosphere I wanted.

I was reluctant to opt for Twine because I had never used it before. So I chose to make a vignette as a proof of concept and see whether people would like that kind of game or not.

As you know from previous post-mortems, I like to spend the first day of Ludum Dare coding, and leave art for Sunday. However, when I opened Pyxel Edit to draw some placeholder art, I couldn’t stop myself and I ended up drawing a pixel art version of the sketch I made at the café.

Pyxel Edit in action

For the curious, I used the Dawnbringer’s 32 colour palette, that comes as a preset for Pyxel Edit –having a reduced colour palette helps me a lot in drawing pixel art. And then I found out this app could export a PNG with all the tiles (a tilesheet), as well as a tile map in JSON.

So, TL;DR: no placeholder art this time.

There was a problem, though: Pyxel Edit tile map’s exported files were huge. Even after minifying, they were still heavy. So I added a task to my Gulpfile to manipulate this JSON and only include the information that I needed. The result? Going from more than 500KB to 8KB, something more reasonable for a map!

After lunch I resumed programming and had a bit of trouble trying to import the data. My first strategy was to mimic Tiled’s file format, since Phaser could directly import that. However, the map was not being loaded properly, so I gave up and imported the data into a Phaser.Tilemap myself. Once I had the map rendering, I included the main character and some passing clouds as decoration.

Since story was important, I decided that the next thing I should do were to display text. I drew a tiny font, using PICO-8 font measurements (3×5 pixels per character). And then implemented rendering of text of up to three lines.

Now that I think of it, I did quite a lot of stuff on Saturday, but at that time I went to bed with the feeling that it was not much, since there were many more things I would have wanted to do.

Progress before bed time


I woke up on Sunday and did the same as the day before: going out for a walk to get fresh air and clear my mind.

I was worried about gameplay. “Will my game be fun if it’s just an story?”, “If so, should have just made a Twine game?”, “Maybe I should make big levels and allow for exploration”, “Maybe I could add some puzzles to it”.

I started to code events –so I could implement a story– and refine the text display.

A more advanced display

After that, I needed to include some puzzles. I knew that in the grand scheme of the game the game’s beginning mistery would have to do with music, so the simplest puzzle I could come with was Simon.

Once the mini-game was created, I implemented the artifacts that would launch the puzzle when being interacted with.

Artifact animation

And then this made the first playable version of the game! I uploaded it and added a message once the puzzle was solved asking for encouragement and feedback! I really needed some cheering up –and it worked, by the way!

First playable version

It was already the evening, and I still had a lot to do. It reminded me a lot of once of my previous Ludums, where I overscoped and I submitted a really rough entry. But somehow I managed to keep my cool and not panic much. It was obvious that I wouldn’t have time to do a lot (or big) levels, so I decided to cut that part without too much drama from my part.

I went to draw some simple animations for the main character and got hooked into Pyxel Edit again, and ended up doing more frames that I wanted to!

Idle animation

Walking animation

Animations in game

It was getting late and I still hadn’t a story in place, so I coded bits of the story in that single level. I made a mistake and I should have hardcoded the whole thing, but I wrote some kind of semi-generic system instead.

Lastly, I drew another level, this one featuring another type of object that was not an artifact: a crashed spaceship, that will add a bit of info to the story. This level also acts a bit like a tutorial, showing the player tooltips about how to move and how to interact with objects. This has been the first time I included an in-game tutorial in a Ludum Dare and I think it worked wonders: nobody asked me how to play the game.

Tutorial level

After that it was about 11PM and I still needed to compose some background music! The game already had some sound effects, so gameplay-wise it was OK, but music adds a lot to the atmosphere and mood and that was one of the aspects I wanted to try out and get feedback about!

I used Audiotool for music. I’m still not proficient with it, but I had learned enough so I could comfortable remix some samples and even play a melody with a custom-made sound from a synth.

After integrating the music into the game, I just needed to create a title screen and run a few walk-troughs to make sure everything was OK. I ended up submitting my entry at 1AM, despite I was aiming for midnight, as usual. However, it felt amazing to finish and have something playable!

Title screen

What went wrong

  • I chose to do the maps (not the actual drawing of art, but the building of the levels) with Pyxel Edit, instead of Tiled. This caused a delay because I then needed to minify them and write custom import code for Phaser, instead of relying of Tiled, which is the preferred format for Phaser and just works out of the box.
  • Overscope. I knew from the beginning that my game was too big and that I would have to settle for a tiny fraction of it, but I was having some bad feelings on Saturday night about me not having made enough progress (this is The Wall, and I have talked about it before).
  • I was not strict in terms of meal times –I was so in the zone that I would forget to eat–, and it made my stomach quite upset.
  • I ended the jam after midnight, and then I was so alert that I had a rough night afterwards. Other jams that I finished before midnight I was able to sleep as usual.

What went well

  • I did not give up! And I think this is my best entry for a jam ever. Although I will always have a soft spot for Metal vs Hipsters, I think that this entry is more solid and polished.
  • Pyxel Edit was easy to use and a bargain for its price and features. I will keep this app as my go-to pixel art software. Bye, bye, Asesprite and Pixen!
  • I was able to manage overscope. I think the resulting game is extremely short, but it definitely can be considered a proof of concept. I think that the game captures the atmosphere that I had in my mind and the mood I wanted to convey.
  • I got a lot of good feedback and encouragement on Twitter! This helped me to overcome The Wall on Saturday night and not give up.



  • JavaScript as a language.
  • Phaser as a game framework/library.
  • Atom with vim key bindings as text editor.
  • My gamejam generator to create the initial project template and automation tasks.
  • Gulp as a build/tasks system.
  • Github and Git for version control and online backup.

Audio and graphics:

  • Pyxel Edit for pixel art and level building.
  • Bxfr to generate sound effects.
  • Audiotool to arrange the background music.


  • A sketchbook for brainstorming and concept art.
  • Twitter to post WIP screenshots / GIF’s and get feedback.

Crossbow Assassin Post-Mortem

Posted by
Tuesday, August 30th, 2016 8:35 am

This post is my Ludum Dare 36 post-mortem and will be mostly about the development process I went through when making Crossbow Assassin. I’m going to be honest here, I had no clue what I was doing for this Ludum Dare. I totally screwed up my submission. I had submitted 6 hours ahead of schedule but absent-mindedly went back to edit the description after the submission deadline. This changed my submission from a “Compo” entry to a “Jam” entry. Thankfully, one of the Ludum Dare admins, sorceress (thanks!), changed it back to a “Compo” entry for me. I’m not even sure if I’m doing this post-mortem right.

Oh well.

Anyway, it was my first time taking part in Ludum Dare and my goals were reasonably modest. I wanted to prototype something simple and fun and most importantly, to finish a game. There would be no fancy art or audio, just finish making a game with interesting mechanics. I was psyched and raring to go. Since the jam was taking place in a different timezone (UTC-07:00), I had to plan ahead and rest up. I would be waking at 9am on Saturday, 26 August 2016 and my submission deadline would be 9am on Monday, 29 August 2016. I took leave for Monday so that I could have a day of rest before going back to work on Tuesday.


Second chance post-mortem

Posted by
Tuesday, August 30th, 2016 3:41 am

I guess it’s time to write a couple lines about creation of my game before i forget everything while my memories are still fresh.



POST: TBFTWOR_Ludum_Dare36

Posted by
Tuesday, August 30th, 2016 12:28 am

Well, I got something done at least, and uploaded.

Originally, I intended to take it easy, start from scratch and go for the Compo- try to use Visionaire Studio’s new WebGL biz, then the theme hit and I couldn’t resist.  I hit this LD’s theme better in 35, but Ee-yore.

What I got has some bugs, absolutely no point, and you can do some things- not many, but some.  The Mac version is RIGHT HERE.


Post Jam will bring an update and a Windows version.

Thanks all- have played some cool games already!  Grand LD- I was on the fence, but was in the moment I watched the Keynote.  That will stay with me…

Thanks for playing!


Sepulcrum is now released!

Posted by (twitter: @kacperski1)
Monday, August 29th, 2016 8:34 pm


Sepulcrum by BlackCode

It’s been hard, but we’ve finally managed to finish our little game and, well, I’d recommend you check it out!

Two adventurers come into an abandoned temple with a quest to find a legendary gem.
Unfortunately, they turn on an ancient security system that will kill them in 60 seconds.

There’s only way to get out of this situation – our heroes have to hack the security system and open the doors before they die. Fortunately, one of them specializes in ancient operating systems and knows perfectly what to do.

The game features never before heard voice acting with a Slavic accent, astonishing graphics, breathtaking animations and okay gameplay!

What went good?

  • The idea is pretty cool I guess,
  • Muh wonderful vector graphics (Inkscape ftw!),
  • We’ve finished it! Yay!

What went bad?

  • Could have more puzzles,
  • Could have more story in it’s story mode,
  • Could be Half-Life 3.

Post-Mortem updates.

Posted by (twitter: @@TheFish523)
Monday, August 29th, 2016 8:29 pm

I’ve been doing a lot of taking feed back. So, some improvements:

Faster game-play. (Opposite of what people recommended , it’s actually better)

Fixed Camera.

New animation before enemies spawn (So you can tell where enemies will spawn).

My LD36 entry is here

If you liked the original, slower version you can get it here


Turned my Ludum Dare game into full game launched on Steam! :)

Posted by (twitter: @BPOutlaws)
Saturday, July 23rd, 2016 10:54 am

Hey everyone! If you played my dragon game back in Ludum Dare 33:

I kept working on it and turned it into a full game, and just launched it on Steam! Figured it could be good inspiration for people participating in LDJAMs to keep working on their entry if they come up with a cool mechanic/idea…who knows, you might be able to to turn it into a full game!

Here’s the trailer:

Grab it on Steam here:

My next game is ALSO going to be based of my LDJAM entry from Ludum Dare 35:

Hope this inspires some people to take their games beyond their Game Jam entries if they think they’ve stumbled across something fun! With a few more months of work you might be able to turn it into an awesome game you might be able to pay your rent with! 😉

Follow me on Twitter at @BPOutlaws, I use it as a devBlog lol

– Jeff


So I made this game, ShmupShifter.

It was really complicated compared to what I’ve done for the compo in the past, so there were a few odd choices, and in addition to that some elements of the game are only useful very late in the game.

Consider this a postmortem. Maybe.

The Inspiration

I was inspired to make this mechanic by Radiant Silvergun.  I, lacking an Xbox 360 or Sega Saturn (and 700 bucks), have never played the game, but it seems awesome so whatever. Have some gameplay:

You have access to seven weapons which you can change to at any time. I thought the gameplay possibilities from this would be excellent, and in addition it fit the theme well.

The Main Mechanic

The shape-shifting in the game isn’t necessary in many situations until the second stage, which many players never got too. That’s kind of an issue. In the late game it is essential to use all ships in order to avoid the need to dodge patterns altogether. The ability to move around enemies means that in some cases you never need to come close to bullets, as you can herd them in any direction you want.

A lot of people did not seem to notice the importance of the speed differences of the ships, but when you get better at the game you start thinking about using ships that may not have the best fire for the situation, but that you need to move as accurately or as quickly as you need to.

Play the video to see what I mean with the stage 2-1 boss, which you can dodge above with the fast green ship.

The Purple Ship

One of the three usable ships seemed to be pretty useless to, well, everybody. This ship had:

  • Slow movement
  • Hard to use, weak weapon.

Because people do not see the later moments of the game, both of these traits seem a detriment. The slow movement is actually an essential part of the gameplay later on. When fire become dense, especially in the second loop of the game’s stages, it is almost impossible to weave through with the red or green, fast ships.

The weak fire is designed to prevent players from staying in the purple mode for a long time, as the combination of fine control and normal fire would make it far too powerful in later stages.

Here is an example of using the purple ship to dodge a dense pattern. The second use in the clip is what I’m talking about, when the spread firing enemy comes in from the right. You’ll notice that I die soon after I, in panic of being stuck,  switch to the red ship.

Impossible Patterns

Some people complained about some patterns being impossible. This was, believe it or not, by design. It is always (or at least, 99% of the time) possible to get the upperhand in the situation by exploiting the games mechanics, such as the ability to harmlessly go through enemies, move quickly with the green ship, and fire from all angles. The patterns which may be impossible if you approach them like a typical shmup become easily beatable if you utilize the mechanics.

The Root Cause of the Issues

The biggest issue I had with this game was that I made it for people who were into shmups, not for an average Ludum Dare player. This led me to go way overboard with the difficulty, and make stages ludicrously difficult if you don’t think them through and play repeatedly, which many people wouldn’t. Next time I’ll include a normal mode, which would be easier than this game, and an arcade mode, which would be like this game is.

Here’s just some gameplay starting from the second loop to demonstrate how insane the difficulty can get in this game. (of few of the early deaths are intentional to reduce the difficulty. Or at least that’s what I tell myself :P)

Thanks for reading my needlessly defensive explanations of all of my game’s issues! Remember to try ShmupShifter!

A Challenge:

Beat ShmupShifter and be awarded with the TerraCottaFrog’s ld35 True Shmupper Trophy!


Post Mortem: A Mazeshift Title

Posted by
Friday, May 6th, 2016 9:57 am

Hi everyone,

This was my second Ludum Dare. Once again I had a fantastic time participating, and playing the other entries is a great source of pleasure and inspiration. I wrote a post mortem for my game A Mazeshift Title, which you can play here (Unity WebGL version available).


Screenshot1A Mazeshift Title

The Game

A Mazeshift Title is a 2D puzzle game where the player must construct a route between two endpoints using a collection of shapes organised in a grid. These shapes are manipulated by shifting entire rows horizontally, or columns vertically. It could easily be compared with a 2D version of a Rubik’s cube, with a pattern that must be completed. The game contains 7 individual levels, and each one is procedurally generated to provide a degree of replayability.


The idea for the game was originally conceived from thinking about shifting bits in computer registers, but using shapes instead. A good three hours on the Saturday morning were spent settling on a design. I felt it was important to take the extra time at this stage to ensure the concept was both interesting and achievable. By the time I had stopped on the Saturday night, the game consisted of a single feature-complete level.

The focus of Sunday was polish: after creating some menus and finishing the transitions between different levels, I moved onto audio. I ended up spending many hours fighting with multiple software packages, and eventually only managed to produce three sound effects. I had initially anticipated having enough time to produce a simple ambient background music track, but this no longer seemed feasible. Some visual polish feature had also been planned, such as sliding the grid tiles when they are shifted, but sadly these also had to be cut.

The Good

  • Procedurally generated puzzles.
  • The mechanics are explained non-verbally using a trivial first level.
  • I followed my plan: the core mechanics were implemented by Saturday night, Sunday was spent polishing the game.

The Bad

  • No music.
  • Tiles don’t slide when shifted.

Thanks for reading, see you all next time!

ShipShift PostMortem

Posted by (twitter: @DeadBodyOutline)
Thursday, May 5th, 2016 11:12 am

A little late, but here is it!

go play


What is the game about

This game is about a spaceship that can change its shape. Each one has unique abilities, and you must use them to save the universe in the year of 2344.

It’s a endless bullet-hell like game, where you confront increasing waves of enemies. Btw, what is your score??

Ideas and process

We had just some ideas until we get this one. One of them was a puzzle game where you had to move as quick as possible onto some cell next to you that has the same shape of the player’s current shape (the red rectangle from the image below). We discarded this, as we do not find so much fun on it :p



So we got the idea of a bullet-hell game, using only geometrical forms (as it can be easily generated using SFML lol), so we started the development and we get…. Some shapes on screen


it’s… something

Of course, this was one of the first steps on having a game. A little more effort we got some enemies on screen and started testing the ship movements, including awsd controls, asteroid-like moving through the edges of the screen and, finally, a follow the mouse approach.

asteroid uh?


Long story short, we had some nice ideas for different abilities for each shape, but as the deadline was coming, we just simplified them to get a minimum viable product. See the abilities breakdown:

Triangle (weak, quick)

Attack: quick laser shot

Alt attack: nova (was guided missile)

Rectangle (strong, slow)

Attack: nope (was melee)

Alt attack: melee (was timed invincibility/time warp)

Circle (normal, medium)

Attack: nothing (was mine deployment)

Alt attack: absorbs enemy shots with its shield (was reflective shield)

Also, we did not make any sound for the game. Sorry


not today!

What Went Well

  • We did a game!
  • Learnt some new cool things on SFML
  • Valuable feedback from the community (yay, you!)
  • A more finished game the our last entry
  • Linux, OSX and Windows builds
  • A really cool HUD 😉

What Went Wrong

  • No music
  • No joystick support
  • No shaders :/


Now we will try to finish the game, add some missing features, improve the code quality (generic classes will belong to our “bootstrap” code, helping on future projects), a better collision detection, evaluate game balancing, create some badass audio, all of this considering all your advices <3


ffmpeg FTW!

So go play our game (the jam version, we didn’t worked on improvements yet, but take a look on the code on our github page), follow us on twitter/facebook and have lots of fun!

Cat Tidying: the post-mortem

Posted by (twitter: @mahalis)
Thursday, May 5th, 2016 8:03 am

Neko Katadzukeru is a puzzle game where you take delivery of an endless assortment of contortionist cats and must package them neatly to send them on their way. It’s my fourth compo entry (see the previous ones here), and the first one where I actually had the whole weekend to work on it; here are some tales of its development and bits of advice.

Screen Shot 2016-04-17 at 6.14 p

Things what went good

  • Sleep. Seriously, I know the jam tradition is to grind late into the night and hypercaffeinate and so on, but in my experience that results in making sillier and sillier mistakes as the weekend goes on, and being totally burned out in the last couple of hours which are the most critical for finishing things up. I aimed for ~7 hours a night, and while I did have to keep working down to the last few minutes of the deadline, I spent way less time staring blankly at weird bugs and wondering where my life’d gone wrong than I would have otherwise.
  • Early ideas. It’s really important not to spend too much time agonizing over finding the Perfect Idea that is Definitely Better Than All The Other Ideas. Think of as much as you can as quickly as you can, pick one, and go. I typically look over the list of theme finalists on Friday and try to brainstorm at least one or two possibilities for each one. Another thing that’s helpful for this: not just staring at your computer trying to think of something. Go outside; take half an hour to wander around and mull things over. Brains are really good at taking random stimuli and building ideas out of them; the more stimuli you’re exposed to, the better your chances of finding a good idea.
  • Hand-drawn art. A lot of people go for a pixel-art style in the compo. When that’s done well, it can look really cool, but it’s hard to stand out unless you are a pixel wizard (in which case I hope you are enjoying Pixel Hogwarts—bet it’s rad). Somewhat less common is a hand-drawn look, which, even if you’re not great at drawing, instantly gives your game a unique character. You don’t need a scanner—take as straight-on a photo with your phone as you can, then use Photoshop or similar to make the image grayscale and adjust the levels so you have a pure-black-and-white image, as in the image below. This time, I made most of the art using a Pencil, but the principle is the same if you’re working with a pencil of the lowercase variety.
    • levels example
  • Mouth sounds. Again, lots of games use tools like sfxr to generate old-school beeps and boops, and that’s fine, but you very likely have a way more flexible sound-effect generator at your disposal. Every sound effect in Neko came from me standing in my closet with a towel over the door (to muffle outside sound and echoes) making noises into the Voice Memos app in my phone. Record a bunch of variants on the same sound in a row, then get the file onto your computer, chop it up in something like Audacity, and you’re good to go. It’s quick, efficient, and it makes your game stand out; the only downside is feeling kinda silly standing in your closet trying to do cat noises.

Things what didn’t go so good

  • Difficulty. This has been a perennial problem for me, and I’ve seen it in a number of other games too: when you’ve spent all weekend playing and replaying the same game, it becomes much easier for you than for someone approaching it for the first time. Neko is really hard; a number of people have told me they couldn’t even finish a single box. It’s critical to have other people play your game while you’re building it, or at least early enough that you can tweak it before you submit it—if the game’s too hard, people miss out on the fun of succeeding at it.
  • Tutorials. Think you’ve taught players your mechanics? You probably haven’t. People will misunderstand things you tell them, or forget about them, or not even notice your instructions at all. Games I’ve seen that do this well will show you prompts that don’t go away, or don’t get out of your way, until you’ve successfully done the thing they’re trying to teach you—there’s a reason basically every AAA game makes you go through a “press X to jump over this thing, press Y to crouch under that” section at the beginning. In Neko, I put instructions on the title screen, which is an incredibly easy place to not see them. Don’t do that, and really don’t put the instructions on the download page (at least not as the only place they’re available). Make sure your players always know what they’re doing.

This has run on longer than it was meant to, so I guess I’ll wrap it up here—I hope some of this proves useful for your next jam. If you haven’t played Neko Katadzukeru yet, please do; I think it turned out pretty well. Thanks for reading!

Nyamo’s Adventure In-Depth Post-Mortem

Posted by (twitter: @ddrkirbyisq)
Thursday, May 5th, 2016 1:31 am

There’s still time!  Play and rate Nyamo’s Adventure now!


Nyamo’s Adventure is our Jam entry for LD35 — made by yours truly in association with my trusty artist Kat.  It’s a 2D “Metroidvania”-style platformer game with shapeshifting abilities, multiple worlds to explore, and collectibles scattered about!  We’re releasing it as part of our “Cocoa Moss” collection of games.

Overall, Nyamo’s Adventure was a blast to make!  This is perhaps our most solid LD showing to date as a team, and it’s really awesome thinking about how far we’ve come since we made Match Girl way back in LD28.  Match Girl was a solid game itself, and was very well-received (2nd place overall!), but just the sheer amount of content and different things that we were able to create this time around for Nyamo’s Adventure is really impressive in comparison.

I had 4 “goals” (ish) this time around for LD, and they were:

  1. Successfully use Unity
  2. Have fun
  3. Finish on time
  4. Make some awesome music :)

I’m happy to report that we managed to hit all four of those pretty well!  #2 was a little rough at times (more on that later) but overall things were great!


As always, let’s go over what went well and what didn’t go so well.

What went well:


Wow!  Color me impressed — Unity really overperformed as a dev environment and editor tool.  Now, I’ve used Unity in the past, so I’m well-familiar with both what it’s capable of as well as the little tricks of the trade that you pick up along the way as you work with the quirks of the engine, but I think I still underestimated just how much it allowed me to do when compared with my standard suite of tools (HaxePunk).  As much as I’d like to be a hipster and jump on the bandwagon, I can’t really argue with what it allowed me to achieve this LD.  Having the visual editor around for both editing and debugging was truly invaluable and saved precious precious iteration cycle time when I was trying to design levels, get mechanics working, etc.  Here’s the entirety of world 3 in Unity’s scene view, for instance:

Screenshot 2016-05-04 21.37.02

Being able to put the levels, UI, etc. together like this made things so much easier!


Level design and Tiled2Unity

Nyamo’s Adventure is a huuuge game compared to some of my other ones.  5 different worlds, each with a bunch of different screens, and the different rooms all fit together in a cohesive way.  I spent a LOT of time on level design — easily more than I actually spent on coding, which was quite surprising at first.  Although I’ve had some experience with platformer level design from the work I did for Match Girl, I had never quite exercised my designer mind like this before.  I made sure to read up on some Metroidvania design articles as I was first starting out (which proved helpful), and made sure to really plan out the first few screens of the game in a specific way to introduce the different concepts (moving, jumping, collectibles, the final temple door).  I’m actually really happy with how the level design ended up panning out, and how I was able to properly execute the Metroidvania feel.  Of course, it’s very simplistic and if you really look at it the different worlds are very similar in terms of how they lead you down a linear path to an ability and then use that ability to shortcut back to the beginning.  But I think it still works just fine, and designing the rooms themselves was also great thanks to Tiled being a wonderful tool:

Screenshot 2016-05-04 21.38.05

One of the first things I did after we decided on our game concept was to figure out how to integrate Tiled with Unity (something I hadn’t done before).  Luckily, Tiled2Unity exists, and was very straightforward to set up.  Besides a few snafus with our tilesets changing mid-design (was annoying to resolve but was certainly doable), it was pretty straightfoward and just worked pretty much the way I needed it to.  Awesome!


Animations, tilesets, and world design

Can we take a moment to appreciate how beautiful the art is in this game?

Screenshot 2016-04-18 19.06.17

Would you believe me if I told you that this is the first time Kat has worked on tilesets? (besides the single set from Match Girl, which doesn’t even count)  She really did an amazing job with everything, and it was awesome getting to pull the tiles that she drew into Tiled and using them to build out the different worlds, each with their own palette and feel.



The soundtrack took around ~5 hours in total to write.  It was a blast!  Nothing really new here — just standard jamming out like usual.  Everything was pretty straightforward, with the notable exception of the Temple theme which was basically my attempt to make something ambient and atmospheric in as little time as possible (11 minutes).  It’s kind of uninspired, BUT at the same time, I think it’s nice that it sounds totally different than the rest of the soundtrack because it helps to communicate the fact that it’s a special area.

It’s worth noting that I didn’t put much focus this time on reusing a shared motif throughout the entire soundtrack — there’s hints of it, but nothing you would really notice unless you’re really looking out for it.

Something I realized as I was making this soundtrack was that giving yourself a jumping off point in terms of atmosphere, tempo, or feel really helps in getting things started.  I think I started each composition with a very small idea of how I wanted to differentiate it from the others and that helped me get things started.  For example, for Autumn Colors I knew that the first world was going to be the “hub” of the adventure and was also going to be an outdoor world, so I wanted something that felt more “open” as well as relaxed.  Musically, that translated to a slower tempo, with a laid-back drum beat, and using chords similar to major 7ths.  For Take to the Skies, the spring world, I knew it was going to be the first “stage” that you explored after the hub, so I wanted it to contrast with the outdoor hub music, and also wanted it to be more upbeat and driving as you’re now getting into the “meat” of the game.  Musically, this meant a faster tempo, with more complex breakbeat-type drums.  I also knew that the world was going to have an “underwater” palette, so I used some specific instruments to evoke that feeling.  (Compare it to Song of the Sea from Melody Muncher to see what I mean)  Anyways, the point is that having that starting point allowed me to lay out the tempo and maybe even a drum loop right away, which really worked to get things started (often the hardest part about writing a song).

Soundtrack can be downloaded at



Spikes, knives, and other level elements

I almost feel like this one was luck because of how well it ended up coming together…

So, when I was first thinking of the design of the different worlds, I knew I wanted them to look different, and each feature a slightly different focus on the different abilities that you unlock as you go through the game.  For example, the puddle world (the dark one with spiders) was specifically constructed to be more closed-off and cave-like because there would be many places to make use of the puddle ability and it made sense to have tighter corridors.

However, there were no plans initially to have a different “gimmick” in each level.  That one just sort of happened through development, and I’m glad it did!  The disappearing megaman-style blocks (the first thing that I came up with), the spiders, and the knives really did well to differentiate each area and made the level design more interesting than just having different tilesets that were functionally equivalent.  I’m especially happy with how the spiders and the knives ended up interacting with the abilities that you find in the respective worlds — in world 3 you’re forced to use the puddle ability to avoid spiders that you can’t get past otherwise, and in world 4 you have to use the balloon ability to get past these long rows of knives shown in the screenshot below:

Screenshot 2016-05-04 22.21.15

Funny story about the spikes at the bottom of the pits you have to jump over — for a long time through development I was planning for them to be water or some kind of liquid, as you can see in A Kitty Dream and The Valley Rule (both wonderful references for this type of game, by the way).  But throughout development we never got around to putting in the graphics for the water (I had already coded an element that triggers death and a respawn when you touch it), and more importantly, I had no idea how we were going to animate it.  In the end we ended up coming up with the idea of using spikes instead and it was a simple, elegant, clearcut solution to the problem that I’m glad we stumbled upon.


What didn’t go so well:

2D platformer collision detection

Ugh.  I had done a warmup project with Unity to play around with their new 2D features (much improved since the last time I had used them) and to write myself some starter code (for doing basic things like playing sounds, fading the screen, etc.).  During that I had done some extremely basic testing to make sure that I could test “collision” (as in, detect when two objects touch/collide and do something), but for some reason I didn’t actually bother checking to see whether I could easily implement actual 2D platformer physics.  You know, moving and stopping flush to obstacles, jumping and landing on the ground, etc.  I have my own set of functions that I used to do all of this in HaxePunk (they are very scrappy but WORK very well at what they need to do), but I didn’t have any of that set up in Unity.

So, for the first couple of hours of development I was busy trying to wrestle Unity’s engine to get it to do what I wanted it to do…I already knew coming in that the Character Controller / etc stuff was probably NOT what I wanted, yet I also wanted to be able to hook into the built-in collision detection / etc. and leverage that.  I did NOT want to have to implement all this stuff from scratch, as that would just be ridiculous.  Fortunately I was able to jury-rig together something which worked very nicely, essentially just doing a handful of raycasts on a rectangle as described here.  That was pretty much the only major technical hurdle I ran into over the course of the project, but I wish that I had prepared for it earlier.  On the plus side, I now get to start building out my set of utility scripts, functions, and prefabs for Unity games, just as I did for HaxePunk, so hopefully this won’t be a problem in the future.



Ugh!  I was not in great mental or emotional shape through the weekend and there were some points when I was really not feeling too positive about the project, and in general worried that it just wouldn’t come together.  This wasn’t necessarily due to us being in bad shape, and more just due to me being tired and stressed out due to other RL things (was trying to pack for moving out of my apartment, not enough sleep, etc.)  Sometimes this just happens — unlucky that LD happened to coincide with a weekend when I wasn’t fully up to snuff mentally.  I also had some congestion in the eustachian tube of my left ear which can be really aggravating when it comes to mixing music.  Luckily it all ended up being fine in the en and we made it okay…phew!  Was really glad when we finally hit the submit button (and went out for a nice hearty dinner).


Sound design

Kind of a minor point here, but this project taught me that although my music skills are really on point, my sound design skills are not.  It was actually pretty difficult for me to come up with good sounds for Nyamo’s movement/etc. and I ended up having to redo some of them.  The collectible sound also ended up getting changed in the post-compo version to something that didn’t clash as much with the background music.  Labchirp is nice but sometimes you have sounds that are just tricky to figure out.  It’s something I need to be conscious of and try to research a bit more.

Unused graphical elements

Kat had some other graphics (like additional background and foreground elements) that she drew up that never ended up making it into the final product.  I really didn’t have any time to put them in at the time because I was busy scrambling to finish all of the different rooms, but even afterwards for the post-compo version they ended up not really fitting in and looking a bit out of place.  You can see in the post-compo version that there are more leaf decorations in the puddle world, but that’s the extent of how they worked out.  So, not the end of the world, but we probably could have designed some other way of adding some graphical accents to the levels.  I think we wouldn’t have had this issue so much if we had been working more slowly (i.e. not in a 72-hour game jam) and had time to step back and see what the overall look and feel was going to be like.


That’s about all I have to say about Nyamo’s Adventure!  It was an awesome experience to make, and I hope you all enjoy it as much as we did! :)

Spelldown Post-Mortem

Posted by
Wednesday, May 4th, 2016 6:58 pm

First of all I have to say, Ludum Dare 35 has been a wonderful experience for Gabriel and me. After a good experience on the last Ludum Dare we decided to team up again for LD35 as team Pixelpotions. We had a lot of fun and (for the most part) made a fairly complete game.

We have been featured in two (to our knowledge) videos!
check them out:
Gaming Faster than Light

Pablo Perez

Please play and rate our game here, we rate and comment everyone who comments on ours.



When the theme was announced I was drawing a blank, it was past 3 and I felt tired. I was on Skype brainstorming with Gabriel and by talking with each other we slowly got the creative juices flowing till we were saying idea after idea. 2 hours after the theme announcement we had decided on an idea and art style. Because of time zone differences Gabriel would be making some mockup art while I slept.

RPG mockup

Mockup for SPELLDOWN


Figment, a post-mortem

Posted by
Tuesday, May 3rd, 2016 5:15 pm

The following is a post-mortem for our entry, Figment. You can find the game here if you would like to play it for yourself. We plan to continue development after Ludum Dare, so if you’d like to learn more, you can also find updates on our website or twitter.

Figment is a dimension-switching puzzler about a little girl and her sentient cube.

Hop between the two realms of this dream world to solve puzzles and find out why you’ve been brought there in the first place.


Whilst we had entered a few other jams before, this was our first Ludum Dare. We spent the run up voting on themes and trying to come up with some good ideas for the themes that we’d selected. As it turned out, ‘Shapeshift’ wasn’t one of them!

We kicked off midday on the Saturday, and started by wracking our brains for an idea that could fit the theme. Rich had been playing with the idea of a masking shader a few days before, so he was really keen to find an excuse to write one (the final effect is shown in the GIF above). This led us to the core concept of switching between dimensions in order to solve puzzles; we thought that this would tie in really neatly with the theme, as all of the objects in the game could change their form whenever you swapped realms.

In hindsight, trying to force a dimension-switching mechanic in to a 72 hour game jam game was probably biting off a little more than we should’ve. This was particularly poignant knowing that two of our three team members actually only had 48 hours to work on the game. Still, Rich was confident that he could get the core mechanics up and running within the first day, so we thought we’d take a crack at it!


Before starting the jam, we’d decided that I would focus on music and sound effects (instead of coding), whilst Ed did artwork and Rich handled the code. So, while Ed started creating concepts for the characters and Rich began on the dimension switching, I took to writing the main musical theme.

Our previous game DiscStorm had all been chiptunes and dance music, so for a change of pace I decided to go for a hybrid orchestral piece. The unique hook was that I would score it twice and then have the game switch between versions as the player swapped dimensions. The idea was to write a melody that felt playful and upbeat in one realm, whilst being haunting or sombre in the other. It took the majority of the first day to get these two pieces finished, along with the code to handle the blending, but I feel it was well worth the effort – as the player is required to constantly switch back and forth between dimensions, it keeps the music feeling fresh, despite each only being three and half minutes long.

Working in the same room meant that every time someone produced something new, it had a direct influence on how the others approached what they were doing. Once Ed had completed the sprites for the little girl and cube, it became pretty clear to all of us that the game was heading towards having a rather “Nintendo” feel to it. That didn’t really come about intentionally, but in the spirit of a jam, as soon as we noticed it we all began to embrace that style.

After we wrapped up at the end of the first day, the game looked pretty similar to how it does in the screenshot above, minus the crate and the incidentals. Rich had the dimension switching code nailed down and you could move around the world, pick up the key and exit through the door, although there was only one level. We were left with a few sorting order issues, as the game is completely 2D, but it wasn’t anything we couldn’t look to iron out the next day. As I was settling down to go to sleep, my need to code got the better of me, so I grabbed a copy and added some screen-space effects to the dimension switch. In case you’re wondering, it’s a mixture of static noise, bloom and chromatic aberration, which all ramp up as the circle expands.


Whilst the game pieces were coming together, we were still unsure at the start of the day whether it was actually any fun. We always aim to have a game that we can play by half way through a jam, so we’d fallen behind a bit with this one. Knowing this we decided to switch Ed off of art and get him designing some puzzles.

It became clear that there was a fair bit of depth in the mechanic relatively soon. I’d love to say that we’d planned this up front, but really it just came about from experimentation. Rich began getting a few of the levels in to the engine so that we could actually start testing if the game was enjoyable to play. Getting the first two levels built took a long time. Every wall, floor piece or object had to be painstakingly aligned in the Unity editor for both dimensions. There were also some very particular settings that needed to be used in order to get them to appear in the correct dimensions. The levels seemed pretty fun, but we couldn’t afford to have our developer creating them, so I finished a few sound effects and then swapped over to making levels during the afternoon.

As the day drifted on, Ed got a title screen together, incidentals for the world (like the shelves and rugs), and dialog designs for conveying the story. I finished off the title screen and got it in, as well as incorporating the rugs and shelves in to the newer levels. In the meantime, Rich endeavored to keep the mechanics one step ahead of the levels that were being made. This actually worked really well, as we like to design levels such that they introduce the mechanics gradually, allowing players to discover how things work for themselves. As a result, I could tell Rich which mechanic we needed next, he could code it up, and Ed could make sure the artwork was ready. For the most part, things worked out really well using that approach.

We closed the first day with three or four levels in the game, a fair few bugs, and the dialog boxes still needing to be implemented. I had planned on taking the Monday off, but if we wanted to get everything done there was no chance of that!


I woke up and got going with the dialog system. We wanted a reasonable level of polish in the game so I took the time to have the dialog transitions fade in and out, rather than just snapping. After this it became a mad rush to get the ten levels that we’d planned implemented. I started getting through them as quickly as I could, but it became clear that we still had a few bugs to quash. As soon as Rich and Ed got in from work they jumped on Slack – Ed had finished all of the art that we needed (and a little more!) so he largely spent his time testing the game whilst Rich ticked off defects.

As the clock counted down, it became clear that we’d have to cut a few things. We’d taken a decision the previous day to cut a mechanic – a little monster that walks around in the ghost realm but turns into a statue in the human realm – but we decided to go a step further and cut level nine too. We had a plan for the game’s story by this point, so we all felt that having the final level would add more weight from a narrative perspective. I won’t spoil why if you’ve not played it, so I encourage you to have a go!

I realise that our post-mortem is a little late, but hopefully it’ll come in useful for those that read it! By far our biggest lesson learnt was that it’s important to create a game in which you can make levels quickly. About half of our development time in the jam was actually spent building the levels, rather than coding the mechanics. If we’d found a way to make that process swifter, we could’ve added more content in the time we had. If you’ve not played or rated the game yet, please take a look, we really appreciate it!

I came to stay

Posted by (twitter: @josemwarrior)
Thursday, April 28th, 2016 11:27 pm


This is what I thought on Monday, right after I finished my first Ludumdare and completed an old task. You can read this post in spanish here.

I’ve finished my first game and I’ve named it “Booba Loomba“. It is a name that I already had in mind for previous game which also had small “balls” but finally I decided to use it for this game. It is true that it was a stressful (really stressful) weekend. There were moments when I didn’t know if I was going to be able to finish it or at least to submit something. I had to figure out the whole game in just one morning – Saturday morning. I’ll explain it below in further details. This is my game:

Click in the following link to play the game.





This is a gameplay by Marta Jones

Another gameplay by Alice “Buttons”, it starts at 1:02:05


Booba Loomba
Booba Loomba




Let’s get started, the theme of the competition that was announced on Friday at 03:00 a.m. (Spain) was “shapeshifting“. At first, I did not like the theme because of the complexity of shifting something’s shape (even though you can do many things including shape shifting, changing something visually is the first thing that comes to your mind). I stayed awake until 03:00 a.m. to see what was it about and then going to sleep in order to be ready for the following day but I couldn’t do it. I was thinking about games that included changing shapes. After thinking about them, I got stuck with two:

  • World of goo (PC): You have to make a structure with the characters to reach a certain point of the map. Sometimes you have to switch your shape to reach the goal.



  • Locoroco (PSP): You have to rotate the screen to move your character and absorb “friends” to reach the goal with them. When you absorb any friend, you will grow physically and sometimes you have to split yourself to get through different parts of the stage.


I really liked Locoroco as a source of inspiration! Now that I finally sorted out some things, I went to sleep. I organized my timeline as it follows:




All right, as planned, on Satudary morning I invented the game’s mechanics:

  • “You are a ball and to move yourself through the stage you have to rotate the screen and play with gravity. You do not move the character neither the stage; you can only control gravity.


  • “To clear every level, you have to reach the goal


  • “To achieve it you have to find all your “friends”. There are two kinds of friends, fruit (they can’t move) and other balls (they can move). Any time you roll over a fruit it turns into a friend, to catch friends you have to press the A button.


  • “You have to reach the goal as big as you can. To achieve it you have to divide yourself to go through narrow spaces and then absorb your friends again. To split yourself you have to press the spacebar.


  • “You cannot lose in the game. There is no “game over”. The only thing you can lose is time.”



I chose Game Maker because it is really fast to start a game with it. However, it was a long time since I last used Game Maker, return to global variables, the style of working with arrays, it seemed a little complicated because I had been working with Libgdx months ago. But don’t misunderstand me, I highly recommend Game Maker to make games.
I started with the default collide system of the software.
It worked, kind of, but it was not what I was looking for. I observed how the ball got stuck sometimes and did not drop as I wanted.
Then I discovered that Game Maker uses a physics engine based on Box2d and “Liquid Fun open source” that I had never worked with.




I hadn’t time enough to learn how to use it but it gave me pretty neat results.




Then I prepared the script that made the ball join other balls and split itself.



The next thing was to include the items, “fruit” and the “goal”.



The “Friends” parameter was named greatness before. I thought that it was a good idea since “You are greater with more friends”. I finished the prototype on Saturday night but…


It isn’t a bug, it is a feature.

… Nothing turned out as I expected. Game maker gave me more than one problem. On Sunday morning I discovered a bug that made me waste all the day trying to solve it. Because of this, I had to upload my game to the jam (72 hours) instead of to the compo (48 hours). This was the bug:




If you grew in narrow spaces you got yourself stuck. I stayed all Sunday trying to find an efficient way of pre-calculating if the space was enough before growing and if it wasn’t enough it won’t let you do it.

need more space to grow

I was trying a lot of possibilities but when I thought I had found it, it completely broke the game (especially in the HTML5 version 😀 ). Sometimes I thought that I couldn’t solve it because this bug had destroyed the gameplay. Later on Sunday, I thought about the same thing applied to an imaginary machine. If it had more gears, it is easier to break it, so I got stuck with the KISS principle and to the “it is not a bug, it is a feature” principle. To solve it I showed a message telling the player that “It is impossible to continue, you have to split yourself.”:


This lead to some changes in my timeline, that resulted into this:



This is what Ludumdare is about. It makes you change and remove things to the maximum; it makes you release a game that in other way you wouldn’t.
On the third day, I made the level design, graphics and music without any major problem. I work hard on the tutorial. I wanted it to explain the game itself and to get the player hooked to the game from the very first moment. People told me that those things were perfect so I felt relieved. The third day was the toughest because I was holding enough stress and I was really tired.
I am very thankful to Erik Sanchez G., who translate this awesome post into English.
Now I would actually like you to play the game and give me an honest opinion 😀



[cache: storing page]