Ludum Dare 35
Coming April 15th-18th Weekend

Ludum Dare 34 Results

Posts Tagged ‘postmortem’

Grow Your Love Postmortem

Posted by (twitter: @ddrkirbyisq)
Thursday, January 14th, 2016 2:00 am

It’s postmortem time!

Grow Your Love

If you haven’t yet played Grow Your Love, you can do so here:

You can also download the official soundtrack here:

This was my first time doing a jam entry with my trusty partner-in-crime Kat Jia since waayyy back in Ludum Dare 28 when we made Match Girl (and took 2nd place!).  That was two years ago, and since then, the number of jam entries has more than doubled, going from 780 to 1,638.  Wow!

This time around, we managed to take 3rd place in Audio, 13th place in Fun, and 13th place Overall.  Not bad at all! 😀

My personal goals going into the project were:

  • Don’t make another rhythm game
  • Work on pixel art together
  • Have fun!
  • (Maybe) treat iOS and Android porting as first-class

Humorously enough, I actually did very poorly on most of these. xD  While I didn’t REALLY make another rhythm game, one of our seven minigames was a simple dance game (haha).  Kat ended up doing 90% of the art as I had no time at all to work on any of the graphics…I drew the shooting stars and some of the UI elements like the arrows in the kniting minigame, but that was it =X.  And iOS and Android porting, pfffttt, come on, we both saw it coming from a mile away that that would get dropped.

Fortunately, the most important goal of having fun was a huge success; this game was definitely very enjoyable to make!

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


What went well

Concept, mood, feel, and overall vision

Probably the most common comment we got about our game was that it was really cute and adorable, which was great!  When we set out to decide what kind of game we were going to make, we weren’t trying to make something that was super innovative or challenging or anything — we really just wanted to make something fun and cute; something that would fit in with our Cocoa Moss label.  We had a really good and light-hearted energy bouncing ideas back and forth for the different parts of the game, and I think it reflects in the overall end product.  Kat did an especially great job with the dancing animations, and I tried to write out the Letter and Texting dialogue in a way to match the same style as well.  It all ended up coming together very well, and I think the game is much more about enjoying a cute story than about the actual scoring of the minigames itself, which is perfect!


Making smart code architecture decisions

Having SEVEN different minigames to make meant that code reuse was at a premium, and I found myself super-grateful to myself that I had enough foresight to plan well for it.  There was no way I would have finished all seven games in time if I had to create entirely separate logic for each of them.  Sharing most of the common logic for the tutorial demos, starting and ending the game, etc. saved me heaps of time and even though there were lots of hacks and messiness throughout the codebase (as always), it ended up working out really well.


Slamming out music faster than ever before

Holy crap.  I know I’m known in some circles for my speed-composing abilities, but I even outdid myself this time by writing the entire 10-song soundtrack in less than 5 hours total. O_O  FL Studio saves your project working times automatically; here was the breakdown of how long I spent on each track:

Lovers’ Rave: 32 minutes
Watch Carefully: 15 minutes
Hope You’re Not Asleep: 34 minutes
Stargazing: 20 minutes
Love Sprout: 3 minutes
Grow Your Love: 1 hour 6 minutes
Wiggly: 31 minutes
Our Love Has Grown: 46 minutes
From Me to You: 17 minutes
Rainbows of Yarn: 20 minutes

Total: 4 hours 44 minutes

Aside from the title theme I basically wrote each song in 20-30 minutes, which was kind of insane.  Of course, these were shorter songs, so it makes sense that I was able to churn them out at a faster pace, but I was surprised at how well I was able to work under pressure here while still remaining creative, especially given that some of the songs are not of my usual style.  I was under MASSIVE time pressure as I started doing the bulk of the soundtrack work, so I really had no choice but to do it quickly.  Ironically, this might have =helped= my creativity by giving me no choice but to go with my first gut instinct.  I’m especially happy with “Wiggly”, which was ridiculously fun to write.

You can read more of my comments on the individual songs in the in-game jukebox if you’d like — there are some interesting notes in there since a lot of the songs were repurposed from what they were originally intended for.  To be honest, neither me nor Kat were planning for the mood of the game to play out exactly how it did; it sort of evolved as things went.  I had to rethink how I was doing the music to reflect the shift in mood that ended up happening, but luckily I didn’t have any wasted work as a result.  I do have to say that the full hour I spent on the main Grow Your Love theme was well worth it; it’s now my favorite track of the entire soundtrack and I think it really gives a lovely first impression.  You’ll notice that I centered all of the songs around a shared motif — it’s a great technique I’ve used over and over again that really brings cohesion to a soundtrack. :)


What didn’t go so well

People not getting the menu controls

Sadness.  Perhaps I was going too deep with the “two button controls” theme, but I thought that in order to really be complete the menu of the game should use two button controls as well.  Of course, it’s hard to make menu controls using only two buttons, so I looked to DiveKick for how they did it and figured that I would do the same thing.  Apparently it wasn’t obvious to most people as they just gave the screen a blank stare and wondered why pressing left or right separately didn’t do anything, so in the post-compo version I made it painfully obvious by putting big flashing indicators on the screen and highlighting the text, press LEFT + RIGHT TOGETHER.  Sigh.  It’s always the little things that you assume that bite you in the foot later on…


Not testing on the release platform until later on

This one was a smaller point, but for most of development I was testing on Haxe’s Neko VM instead of actually testing the Flash compile.  This was fine, except halfway through development when I tried the flash build and ran into a crisis.  You see, most of the graphics in the game are upscaled by 4x, so I had set the camera zoom at 4.  But the text was way too big at 4x, so I had the text sized 50% smaller, so overall the text would be upscaled by 2x.  Setting the text scales to 50% worked fine in neko and everything was perfectly happy.  Well, as it turns out, in Flash with the buffer rendering flow, you actually can’t draw pixels with a size less than the current camera zoom, so instead of the text being nice and crispy at a 50% scale compared to everything else it was actually just unreadable.  Oops.  Luckily I was able to jury-rig a fix by hacking at the haxepunk code, so that was a major crisis averted.  The hack was pretty ugly — I set the camera zoom to 2 instead of 4 and then edited the image class so that every image in the game would be scaled up by 2, etc — but hey, you gotta do what you gotta do.  Managed to dodge the bullet on that one, phew!


Balance and scoring

Ugh, this is probably my number one regret with the game.  The scoring formulas and balancing of the minigames is pretty terrible and I really didn’t test them very much.  In particular the dance game seems to get people a lot — like rhythm tengoku/rhythm heaven, it’s grading you not only on whether you memorize the sequence correctly, but how on-beat you are.  Of course, I had no time to make sure the lag calibration was spot-on, so it’s not perfect at all. =(  In the compo version, some players also misunderstood the goal of the Letter writing game (do it as fast as possible), and players also tried to figure out which word made grammatical sense in the Texting minigame, instead of realizing that you just needed to tap on the YELLOW highlighted word.  In the post-compo version I tried to be much more explicit with the directions for those games, and made the tutorial overlay display across the entire screen because people were probably skipping the text due to being distracted.  Some people also got confused with the Stargazing game in the compo version by pointing to where the star was going rather than which side the star was on.  In the post-compo version I solved this issue by getting rid of the stars that start on one side and travel towards the opposite side, to make it more obvious.  We also made some tweaks to the dance minigame during development to make it more clear.  Clarity in instruction is always super hard to get right, I guess…

Initially I had planned on rebalancing the game and even adding an “Expert Mode” where each minigame gets harder (e.g. harder rhythms for dancing, longer letter and text, more arrows for knitting), but in the end I realized that Grow Your Love really isn’t =about= the challenge and the scoring anyways, so it’s not that important to have Expert Mode or anything like that.

Not enough time (as always)

Some of the issues with balance and scoring were a direct result of me having almost zero time to properly test and play through the game, as I was still working on core features like the main menu.

Several things accounted for the time pressure:

  • Making seven separate minigames just takes a lot of work, period.
  • There was a nontrivial amount of work put into making a horizontally-scrolling menu workable; I couldn’t just copy the vertical menus that I usually put into all of my other games.
  • Certain aspects such as Free Play mode ended up not being that important to the overall experience but still took time to implement and get right.
  • Did I mention making seven different games?

Overall there was just a LOT of stuff to get done; not only did I have the 7 games to program, but there was the menu, jukebox, liner notes in the jukebox, free play mode, scoring algorithms, the intro scene, record saving, tutorials, tutorial skipping, and don’t forget the ending scene!  This was probably the most hours I ever worked for an LD, and I felt =exhausted= afterwards, jeez!  Even after submission, I was still finding stupid bugs that I needed to patch up (at this point I still  hadn’t ever had time to actually play through the entire game).  I don’t know if there was really anything that could have been done about this, aside from maybe not worrying about Free Play mode…perhaps we could have gone down to 5 minigames, but I really think 7 is a good number and that we like all of the ones that managed to make it in.  Honestly I think we just did the best that we could have! =P


All in all, Grow Your Love was great fun to make and I hope you guys enjoyed playing through it as well.  As always, we learned a lot, and in the future we probably won’t try doing a warioware-style collection of minigames again.  I know that it worked well this time around, but it was just too much work!  It also caused an issue in that it took a long while before we had a single one of the minigames completely finished, as we were sort of working towards a lot of them at the same time.  One of these days, I’d like to have a LD where I actually finish the work for the main game EARLY instead of scrambling at the last minute!  (Melody Muncher was sort of close…).


Thanks for playing and reading about our game! :)

A Mobsferatu postmortem

Posted by (twitter: @CremaGames)
Monday, January 11th, 2016 8:52 am


Hey there! Since you liked our game so much in this jam, we wrote a little postmortem about how we worked on it and what mistakes we thought we made during the development. Hope you like it and, once again, thank you so much for voting Mobsferatu.

It’s been a week and we still can’t believe we ranked 5th in the Overall in our first LudumDare.

Dizzy Dazzle – postmortem

Posted by (twitter: @tselmek)
Wednesday, January 6th, 2016 9:03 am

What time is it? It’s postmortem time!
Last LD I set myself the goal of focusing on more complex mechanics and level design, that might wait for LD35 :’D

= What went right =

  • Audio: Really proud of how the audio fit the style of the game. Again, credit goes to the great Ted Wennerström.
  • Programming: Programming went rather smoothly, I’m pretty happy of the way the game is built, it allowed a lot of changes in the same canvas.
  • Style: Regarding the style of the game, we stuck to the original idea and players seemed to like it (pairs with Audio)
  • Juiciness: The constant screen wobble was an experiment, but the feedbacks were pretty easy to make and pretty efficient

= What went (entirely or slightly) wrong =

  • Balance and Design: Oh did I screw up that part. A majority of players made me notice how the game should be more penalizing. I first thought of letting mistakes pass in case people were not good at this kind of game and the Accuracy rating was just a treaky way to reward the accurate player, but it runed out pretty bad. Secondly, the game was way too fast since the beginning but while playtesting got me used to the speed and I realised too late that indeed it was way too difficult.
  • Ideas: We knew in the very beginning what the style of the game would be but had no idea on the precise mechanics so we groped until we stuck to the arrow mechanics.
  • Theme: The tied themes were pretty confusing at first, moreover we started the design around Growing but ended up using the Two Button Controls because I couldn’t get the Growing mechanics to be fun to play.

The final ratings:
Look at 'em ratings

Kicking it with the Audio score. Did better with Theme than I thought. Fun and Mood were the main focus I guess, and I’m actually a little surprised about the Fun score considering the huge penalty flaw of the game.

Thanks everyone for playing Dizzy Dazzle, cheers!

Tselmek out!

Grow Trees… Or Something – Post Mortem

Posted by (twitter: @gamepopper)
Saturday, December 26th, 2015 10:57 am

So this is something I didn’t expect to happen, around two weeks ago was Ludum Dare, where we all had only 48 hours (or 72 for jams) to develop a game, however because I had plans to go to a party that was some distance from home, I had much less time. Despite that I still managed to finish something, although honestly was disappointed I didn’t have much to show, so I could go and vote on other entries.


What surprises me is that I’ve had some nice and positive comments from many people so far, obviously I wasn’t expecting overwhelmingly positive comments of people thinking a game about planting trees, letting them grow and chopping them down with no time and a limited amount of space was the best they’ve ever played, however I was surprised to see many people saying how nice and calming it is, how it’s very peaceful and relaxing it was to play. Among that, most people said they were impressed that I managed to produce this in around six hours.


Originally, I was going to team up with an artist that I work with in my full time job as a programmer. When the themes were announced, we were hoping the winning theme was going to be non-violent combat, and had an idea for combating enemies with dancing. I cannot recall why we didn’t go ahead with that one, but we did also have ideas that involved growing trees, so when growing became one of the themes we ended up agreeing to it.


After recalling the development stages, I’m not entirely sure if I did only work on the game for less than six hours. After the theme was announced at 1:30 am on Saturday, I went to sleep. I didn’t start working until around 10am when I got on the train to London, where I did at most 1 1/2 hours (see above). Because of the party, I didn’t do any work until Sunday afternoon when I got back home (around 4pm), and even then I had stopped to discuss any chance of salvaging what time we had left to work on the project with an artist. Once it got late enough I decided to call it quits and try for Monday.

After getting back from work on the Monday, I quickly finished the last of the art work, added in some audio from and uploaded it, so judging by the timestamps and when I took breaks, it’d be more accurate to say I took around 6-8 hours of the game.

In Conclusion

Regardless of how long I actually took, what’s clear was that I honestly should have planned my time better, either by cancelling my invite to London or not take part in the games jam entirely. By having more time, I could’ve made a more complete and fulfilling game entry, and probably kept both myself and my artist motivated to working together. Instead I went on an assumption that because I managed to create games in shorter times in the past, that it would be fine this time around.

Thank you to all those who have voted, I have been enjoying all the entries that I have seen so far. I’ll be interested in what the final scores will be.

Rolla Grolla Arena Post Mortem

Posted by (twitter: @xanjos)
Saturday, December 26th, 2015 10:21 am

Hey Everyone!!

I hope you all had a nice Christmas. Anyway, I’ve recently written up a post mortem for my LD34 game Rolla Grolla Arena which you can view on my blog.


There’s still time to play/rate my game before judging ends so click here to give it a try. Also, I’m looking for more games to play/rate so click here to submit your entry and I’ll get to it as soon as possible.

Finally I’ve included a video clip taken from a Twitch stream last weekend where a group of people played and rated my game (which appears in the first few seconds).

Happy Holidays!!

Last Chance To Green – Post Mortem.

Posted by
Thursday, December 24th, 2015 7:11 pm

Almost every Ludum Dare we’re spending the first day arguing about the game idea… And this time was not an exception.
First idea was about little toy growing in the water, which you have to observe one hour in real time hoping something will happen (sort of arthouse game), but it seemed a bit unplayable and we’ve put it aside.
Second one was a bit better: nuclear wasteland and little sprout which is taken care of by little clumzy robot on the tracks. But the game seemed a bit complex in terms of graphics and we would have to call it “Wall-e” to put everything in place.

And the third idea didn’t exist. So we had to think of something.


On the second day graphics and drafts of gameplay were born. Every team member had their business to do irl, which interfered in the development process.

And on the third day we’ve discovered that all the code should be made from scratch, graphics can’t be made as we’ve planned, and the gameplay wasn’t thought over really much… It was made during the process of the final polishing.

The only thing which was coming out smooth and without critical changes was music. Composer hit the spot.

Overall, every Ludum is a challenge for us, but that only makes it interesting.


Want to see more?

Play it.



“Networking programming is hard,” I’ve heard, “don’t do it.” It’s been a common consensus among us programmers that online multiplayer is simply not a beginner-friendly material, let alone a game jam material. At the time, having bits of experience programming networked software in college, I agreed with this consensus. This left a strange hole in my large library of games: I have no online games listed. Perhaps it was the Ludum Dare 34 keynote that motivated me to kick this bad habit. Either that, or the Shia LaBeouf’s video mentioned in the keynote.

Either way, is the first attempt I’ve ever made at an online multiplayer game, and an open-source one to boot. Despite being a bug-laden, lag-filled, unoptimized experience, I’m proud of what I was able to make in the short time given throughout Ludum Dare.

What is is a 2-player online first-person shooter that allows one to hack and disable up to two buttons from the opposing player’s controls at any point in the game. Born out of this Ludum Dare’s theme, “two button controls,” forces both players to improvise as their best abilities are taken away from them. The game is played on the keyboard and mouse, providing each player with the following abilities:

  • WASD or arrow keys to move or strafe. In the latest version (v1.5.1), only one directional key can be hacked at a time.
  • Move the mouse to look around. This cannot be hacked, so both players can turn at all times, even if a directional key is disabled.
  • Left-click or left-Ctrl to shoot a slow-moving bullet. This cannot be hacked, so both players can play offensively at all times.
  • Esc to bring up the hacking menu. While this is up, the player can still move and look around, but cannot shoot. This cannot be hacked.
  • Right-click or left-alt to briefly conjure up a shield, reflecting any bullets back to its source. Players cannot shoot while their shield is up. This can be hacked.
  • Space to jump. This naturally provides players access to higher vantage points. This can be hacked.
  • Hold left-shift to run, doubling their speed. This can be hacked.
  • In addition to these buttons, the radar can be hacked and removed from the opponent’s screen as well.

Combining hacks allows for a variety of strategies to emerge. For example, one could leave the opposing player in the dark by disabling the forward key and the radar. Another may disable the back key and the shield to discourage the other player from playing defensively. Yet another could take the upper ground by preventing their opponent from running and jumping. It plays like the video below, which has an older build that does allow hacking two directional keys:

What went right

Using a Game Jam to learn something new

Historically, I’ve used #OneGameAMonth to learn new features in Unity 5, such as path-finding and the recent UGUI framework. This is for multiple reasons: for starts, even if my game turned out to be bunk, I still took something new and important away from it. Learning just one aspect of a game engine also helps me creatively, developing games that mechanically revolves around one focused feature. As of late, I’ve been focusing on creating Not a Clone mobile remake for so long, I haven’t had an opportunity to learn new things about my game-engine-of-choice. As such, I took the risk to learn and practice the latest UNET framework, using the hacking mechanic to justify the mandatory online connection. Even though the game is very rough on the edges, it’s still lauded for an interesting premise.

Utilizing Unity Standard Asset’s FPS controller

From experience, I knew that the majority of my time during this jam was going to be spent learning network programming. As such, I had to come up with how the game was going to be played as quickly as possible. In this case, I chose to use the first-person controller that comes with the Unity Standard Assets rather than the third-person controller. It comes with the game engine, after all, and it reduces the number of problems I would have to deal with such as camera placement. The rest of the design decisions came naturally from this first choice:

  • Players would fight each other with slow-moving bullets. This would give meaning to the built-in run button.
  • Neither player can hack the shoot button. If I were to allow it, both players could disable each others shoot button, leading to a stalemate.
  • Since the directional controls can be hacked, a player could potentially be cornered. For these situations, a defensive option is necessary, thus giving birth to the reflective shield.
  • This game favors implementing as many useful abilities as possible to balance out the hacking ability.
  • And so forth.

Quick GUI generation

Seeing as menus are a common thing that needs to be implemented in every game, I created a simple GUI manager in my Template Unity Project before the jam. Originally, the GUI manager, along with various example menus for the most common functionalities, was made for a single-player experience. To my surprise, the same code proved to be a time-saving feature for this game as well, allowing me to create a large number of menus in a short amount of time. The hack menu, for example, was simply a re-purposed pause menu that doesn’t stop time, and includes an extra hierarchy of menus that lists all the buttons available for hacking.

Incremental building, frequent testing

Perhaps due to my exposure to Agile development, I always develop with an hourly milestones in mind. In practice, this meant that the first few hours were focused on following tutorials to sync the position of two players, and testing to make sure this worked. The next few hour is focused on syncing the rotation of both players, and testing to make sure this new feature behaved properly. Next hour was on shooting, and so forth. Even the most basic feature was put into its own milestone, followed by thorough testing. To help this, I used tools such as version control (Mercurial + BitBucket) and continuous integration (Unity Cloud) so I can stay focused on coding and testing.

This strategy proved vital for this project since I was just learning network programming, and thus, prone to making errors and mistakes. By testing often, especially after a new feature has been implemented, it helps reduce the time spent on technical problems by keeping the scope of changes small.

Last minute graphical polish

I have a bad habit of focusing on graphics too early in development, which leads to a beautiful game that needs gameplay polishes. This time around, however, I worked on graphics last, which provided me more time to work out technical problems. Unfortunately, technical problems defined my entire development process of, so this isn’t saying much.

What could have been better

One day wasted

As it turns out, I was planning to work with barcode on MaskGarden on the first day of the jam. They overslept, however, and arrived at our real-world meeting place at around 5:00 PM. In a bit of a pickle, I’ve decided to start on my own project at around 1:00 PM. Those doing the math and correctly assuming we live in the Eastern timezone will realize I lost 16 hours. Yikes!

Slow testing, debugging

Network programming is hard. This bears repeating: network programming is really, really hard. A huge annoyance I needed to deal with while testing was the actual setup itself. For a single player game, testing a feature is as easy as clicking the play button on Unity. For networked game, I needed to build the game (a long process on its own), play it, then press play on Unity and connect the build to Unity. I would have to test both the game running on Unity and on the build to make sure when either sends a message to the server, the other receives that information. And this is before I notice something goes wrong! If something goes wrong on the build side but not on Unity, I then have to stop both, host from the build, then connect Unity to the build to check for any errors that may appear on the console. And if I make a fix, I need to go through all this process again to verify it’s gone.

Needless to say, testing and debugging a networked game is a time-consuming process. Since I was just learning how to code with networking, technical issues would occur often, and the grand majority of time developing was taken from debugging and the many attempts at fixing bugs. This experience sure gave me a whole new respect for network programmers.

Missing features

One major feature I never got around learning, let alone implementing, is the latency prediction in most online games. This is pretty huge: I knew that I needed to keep the data sent to the server to a minimum, so I could have drastically improved the user experience by making predictions to player movement and bullets. Sadly, the debugging process alone was enough to punt this feature out of the scope of the jam, leading to a very laggy game. As someone who prioritizes the user experience above all else, this is very shameful.

No play-testing

Sadly, I was never able to find the time to have the game play-tested by other players. Consumed both by the debugging process and hosting the real-world meeting event at the same time, there simply wasn’t enough time to ask others to play, let alone setup. Given this nightmare situation, I simply went with the fastest, minimal plan. Naturally, this resulted with an unstable, laggy, difficult-to-setup game.

Convoluted setup process

The current game requires setting up your computer’s firewall properly, and knowing how to obtain your own IP address to send to your friend to connect to your computer. Due to the minimalist peer-to-peer network setup, a lot of Ludum Dare judges could not actually play the game. This obviously breaks down the most important feature in Ludum Dare: the online feedback of other developers, letting you know what you can improve on next time. It would have helped if I knew how to make the process of connecting 2 players easily, such as creating a lobby server everyone can connect to and find others online to compete with. Obviously, this is well beyond the game jam scope, but it would have been nice to have.

That strange moment where a stranger was staring at what you’re doing

At the same time I was developing, I was also organizing our real-world meeting. Fortunately, the meeting has gone very smoothly, with our participants creating 8 new games, including become a game developer in 60 seconds. That said, the weirdest experience I had throughout this event was when we were visited by a certain tourist. To clarify, we reserved a quiet community room in a makerspace building, so while the makerspace receives a lot of tourists, the room itself remained a quiet and productive place. We did have, though, one persistent visitor who was curious enough about game development to ask if they can see what I was doing. I agreed to this, but immediately regretted it when they sat next to me, staring silently while I try to figure out what I was doing before. This experience only lasted for about 20 minutes, but it was the most awkward moment I had in a jam. I can only say I’m glad I was the only one who suffered from this.

What will I do next

Chanced are very high the next game jam game I’ll work on will not involve with networking again. The time spent on testing and debugging alone is enough to make the task unfeasible in a short amount of time. That said, for any longer-term projects (such as #OneGameAMonth), I think it’s worth learning how to create latency prediction and lobby servers to create a more streamlined experience. Improving, especially down-grading the power of hacking, will need a lot of brainstorming and efforts that won’t be easy to do alone. Efforts on that game will probably remain stagnant for a while as I finish developing Not a Clone.

Also, to avoid the same strange visitor incident from happening again, I’ll need to let the building organizers know that we don’t accept tourists into our area.

Learning to Dance — PostMortem

Posted by (twitter: @wetdesertrock)
Wednesday, December 23rd, 2015 5:10 pm


This was probably the first Ludum Dare in which I was actually almost completely happy with the end product. What I amount that happiness to is the personal goals I set for myself. Instead of having my goal be about making a complete game at the end, I made it about having a game full of music and art that I was happy with. Another goal I had was to try to make another story-based game. I wanted a cohesive experience that used art, and music to help the story telling. My last goal was to not get bogged down by programming. I didn’t want something difficult, I wanted something simple that I could whip out. I knew that programming was the one aspect of LD that (at least in recent times) has bogged me down and de-motivated me to the point where I was not happy with my product. Don’t get me wrong, I love programming, but gamedev programming has been hard for me recently and I wanted to continue my break from it. I also had a bonus goal, which was this: Live record my music. Instead of using all of the software instruments to create my music, I wanted to record it myself. At least a little bit. I succeeded.

With these goals in mind, I knew there was a high likely hood that my success hinged on the theme. So I decided that if a theme was chosen that I didn’t like, I would go with my own theme (I choose the theme “Isolation” for this). A lot of people wouldn’t agree with this, however this time around I didn’t want the theme to be the challenging factor, I wanted it to be a guiding factor. Sometimes if I make a game based off of a a theme I don’t like, I’ll produce a loveless game. Luckily there were two themes for me, which worked out super well. I think that the dual theme was a great point about this LD, many games were produced that were fantastic, as well as a good variety of games.

What follows is a day by day account of my process.


Post-Mortem Documentary of “Pressure Run”

Posted by (twitter: @PixelProphecy)
Monday, December 21st, 2015 2:26 pm

Because I thought making a game in 48 hrs wasn’t hard enough, I also decided to shoot some footage for a little documentary about me making the game. Now the editing and all is finished and here for your enjoyment:

Xtreme Crop Duster Simulator ’82 – The Two-Camera Setup

Posted by (twitter: @rjhelms)
Monday, December 21st, 2015 11:58 am

After writing up my post-mortem for Xtreme Crop Duster Simulator ’82, I had a comment from pkenney asking about how the two-camera setup I created in Unity worked, and how I used Unity’s built-in shaders to achieve the graphical style of the game. A lot of the positive feedback I’ve received about the game makes reference to the graphical style, so I was already mulling the idea of a post about exactly that – the comment spurred me to actually write it up.

Lots of text and graphics to follow, which likely isn’t be applicable outside of Unity and may only be of interest to people keen on this sort of graphical style, so the real meat of the article follows the break. But as a teaser:

Before and after

Before and after

The challenge, which I had run into in previous Ludum Dares, is that square pixels are a relatively recent innovation. The Commodore 64’s multicolor low-resolution mode which I emulated in this game had a resolution of 160×200, displayed on a 4:3 television. This means that the pixels, once rendered, are 1.6 times as wide as they are tall – not a nice ratio to deal with. In my LD32 entry, Red Threat, I handwaved the problem away by drawing the sprites with 2:1 pixels, and scaling the whole thing up 2x to 640×400. It worked, but the effect was graphics that were noticeably stretched if you’re familiar with the real hardware.

This time around, I wanted to do better.


Auxochrome: Postmortem – Please Rip my game to shreds !

Posted by
Monday, December 21st, 2015 1:21 am

Auxo Auxo2

Title: Auxochrome

Description: Time travelling action platformer where you play as a color retriever to collect chromosphores from enemies in land ruled by auxochromes!

Growing Theme: You start of small, can run fast and jump high, but as you eat chromosphores (pixels) you gain color and are able to then scale in size. Once you become as large as the boss, you are as strong as him, however you lose your speed and your jump strength which can make it very difficult to save the land!

This was my first jam and I would like to call it a success!

Things that went well:

  • Art
  • Theme: Growing (We loved the theme idea and came up with an idea relatively quickly)
  • Programming (There was a lot to program in 72 hours and for the most part we got everything implemented that needed to be there)

Things that did not go well:

  • Time management

I didn’t use my time well and rightly so. We only planned to do the jam the day of and even though the theme gave us an idea, we didn’t have much of a direction until we put the boss on the podium (and that was in the 11th hour). So, the reason I say time management is because I realized after I hit submit, that I forgot two super important things.

1. The small enemies were impossible to kill

2. The enemies didn’t scale

Oh and we didn’t have time to fix the broken SpriteFont sooooo we left it in there. But the things we left out and the reason why I am about to ask this quesiton is, the engine was a success the gameplay needs more. So with that said, if you could now:


It would mean a lot to me :) By ripping it to shreds you are helping me for the future version as to what might make the game more fun. Please let me know of gameplay elements I may have missed, story elements I can add or anything else to make it fun!

Things I already know to implement in the full version:

  • More weapons
  • Easier enemy deaths
  • Enemy scaling
  • More story to focus the world (to tie in the greyscale)
  • Everything else that goes with it being a full game (more levels, menus)

I am going to start a devlog on it soon but wanted everyone to play and if you could vote and leave a comment that would be great! We are going to start work on the full version in the new year! Thanks for reading and playing!



Posted by (twitter: @GaTechGrad)
Sunday, December 20th, 2015 4:34 am

I’ve finished writing my post-mortem for Mutant Veggie Arena.

Read it on my site:

Or click the “Read the rest…” link below.


My First Post-Mortem – Little Big Dash

Saturday, December 19th, 2015 10:55 pm

As this was my first Ludum Dare, this is my first Post-Mortem, So I hope I cover everything that people generally cover in this! ^_^ I was debating if I should even do one of these but I figure why not, right? So here goes.

Oh and here’s a timelapse if you’re interested!

What went wrong:

  • Computer Crashes
  • Software Crashes
  • Choosing a genre that I don’t enjoy playing

What went right:

  • Completed the game
  • Fully functional
  • Submitted before the deadline


Details of the Weekend:
So usually I miss ludum dare by a few weeks or sometimes just a few days, but this time I learned the date two weeks ahead of time, and posted notes and reminders to myself all over the place so I wouldn’t forget. At first I was excited, and warming up with my tools, and learning new tools just in case I decided to use them. Then as it got closer the wait got excruciating, I didn’t want to practice anymore I just wanted to get the theme and make something awesome. 😀 Well anyways the waiting was painful, but once the theme was announced I felt great!

I was pleasantly surprised how smoothly the weekend went. I started with a pretty strict time schedule, and I prepared meals ahead of time, because I figured it would be a mad dash and non-stop working once it started. But I was incredibly wrong. Perhaps that was because I had a pretty low bar to reach, my goal wasn’t to make a masterpiece, but to make something fully functional within the time frame. It would ideally have audio and graphics and solid gameplay. I didn’t really care if it was a great game, just that it was complete, and I must say I feel like I accomplished that pretty well.

I only allowed myself an hour and a half for planning and brain storming, because I wanted to have tons of time to work on the first night. The goal being to have some prototype ready before I went to sleep on night 1. That went well, and by the middle of Saturday I had pretty much finished most of the gameplay aspects and mainly had level design, graphics and audio remaining. I felt like I was doing well. Then I lost a lot of my motivation, I spent quite a few hours on Saturday evening watching streamers and I even watched a movie with my roommates.

When I got back to work, I did the basic audio loop for the game, and decided to leave the graphics as simple colors for multiple reasons, I didn’t know what else to make it, and the minimalism seemed to fit for the style of game I was making.  Once that was done I slacked off again, returning to Twitch to check in on the progress some streamers were making.

I’m pretty sure I know why I slacked off so much, and at one point I even considered not finishing at all. It’s simple really, I chose to make a platformer, knowing that I don’t like playing platformers. I like them as games, but I’m terrible at them so once the functionality was implemented, and I was working on the level design I quickly got frustrated having to play test them constantly.

I didn’t get the level design finished until an hour or so before the deadline, and I ended up going with endless generation from premade modules rather than the initial idea of having completable levels. I decided this because I was having trouble coming up with ideas for the levels, and I didn’t think I had time for true procedural generation. Instead I just made 10 segments that the game randomly chooses from as the player progresses. It’s not the best, but each segment it completable and they’re long enough that you’re not likely to survive to see all 10. ^_^

Anyways I feel like I succeeded in my initial goal but I feel like I didn’t have enough faith in myself. I feel like I took the easy way out when I could have challenged myself to make something more complicated. Regardless though I’m glad I participated and I now have an idea for how to approach the next one.


Xtreme Crop Duster Simulator ’82 – A Post-Mortem

Posted by (twitter: @rjhelms)
Saturday, December 19th, 2015 6:41 pm

Congratulations on another great Ludum Dare, everybody. I’ve been having an absolute blast playing through the mountain of games.

I’ve never actually written a post-mortem for a Ludum Dare entry before, but figured that for my fourth go-around I probably should. As such, here is the post-mortem for my entry, Xtreme Crop Duster Simulator ’82.


As mentioned above, this is my fourth Ludum Dare entry (having previously participated in LD30-32, taking LD33 off due to a family commitment.) However, this was my first time making it in for the compo deadline. I used my usual tools – Unity/C#, etc – with the exception that I used Photoshop instead of GIMP this time around (as I finally shelled out for a subscription) and gave Chiptone a spin for sound effects, which worked very nicely.

What went well

  • I actually finished a game for the compo deadline, after 3 Ludum Dares failing over to the jam when I wasn’t ready by 9pm on Sunday.
  • Despite wringing my hands the whole weekend about what I thought was a dubious idea, looking back on it it’s a pretty good take on the theme.
  • I had a lot of success with the retro feel, bringing a lot more polish and sophistication to the emulation of an old system than I had achieved in the past.
  • Wrote my level loader in a way that should be reusable
  • Didn’t go insane, or become miserable from stress and sleep deprivation
  • Made something pretty fun
  • Learned to use SidTracker64, which is an awesome app I’ll certainly be coming back to.

What went poorly

  • The GitHub client crashed. A lot.
  • I didn’t reach all of my targets – I wanted 8 levels and at least 2 songs in the game, only achieved 5 levels and one (very short) song.
  • Some of the sprite work isn’t as nice as I’d like, especially a few of the airplane rotations.
  • Didn’t realize I was writing the game with controller support the whole time, so it’s not reflected in the in-game text.
  • After the compo, I had way more trouble porting to other platforms than I should have – the Mac port went fine, but WebGL never worked right and the Linux port took a lot more futzing with than it should have. It especially didn’t help that each test of a Linux build involved rebooting my machine – hours become an eternity when you’re groping blindly for a fix, rebooting constantly to test small, unsuccessful changes.

If you’re interested in a more detailed play-by-play of the weekend, it follows below the break. Otherwise, why not give the game a try and let me know what you think?


The Village Post-Mortem

Posted by
Wednesday, December 16th, 2015 11:03 pm

Hi all. My name’s Amanda; me and my partner in crime, Jeff, made a game called The Village for this game jam. This was our second Ludum Dare and my third game jam (fourth for Jeff). We wanted to do a simple project because it was a busy week–finals and we were wrapping up another project.

Going ham in The Village.

Going ham in The Village.

We always try to learn something new for each game jam–even if it’s something tiny–so each of us went a little bit out of our comfort zone on this project, and we’re both happy with the results. Jeff did all of the art and modelling. I wrote some of the dialogue. I also had to work a lot faster than I usually do because my co-programmer was wearing his art hat. Jeff, who is normally a programmer/designer, does not do art. But we decided to keep the team to just us two, so naturally one of us had to step up. Using Blender and Photoshop, Jeff made all the models (available for free use on sketchfab) and the tiles for the ground, which we decided to keep simple and textureless, to avoid spending extra time on something that needed to be completely learned.


While Jeff did his art, I worked on the AI for the game. They’re all run by the same, super pared-down finite state machine with minor tweaks for each character. I made a citizen base class with wandering, idle, and “attracted” behaviors for the different elements (food, fire, and wealth), and customized derived classes to add behaviors like fleeing from hazards. Given more time, I think I’d like to speed most of them up a little bit and increase the priest’s sight range. I ran into a problem with the teacher where she could get stuck on the trail of torches if they were lit in the wrong order; we fixed this by making them flicker out so the player could relight them.


In the final stretch, we buckled down and worked and held our bladders and went without dinner (the best portion of every Game Jam). We barely got everything in and working as the time ended. We made our build and published, looking at the clock as it turned to the last second to submit –  I think I might have blacked out for a second at 8:58 when I realized I didn’t have a screenshot. Then came a lot of relief and satisfaction at all the hard work we had put in and revelry in all that we had learned and how much we had stepped out of our comfort zones (actually the best part of every Game Jam).  

That’s pretty much it! We had fun going ham and we learned a lot. If you’re interested in learning more or you’d like to check out some of our other projects, follow me (@ada_astar) or Jeff (@jeffdevsitall) on Twitter.

  • Amanda Fisher

Please play & rate The Village!

Post Mortem: Zen Jen

Posted by
Wednesday, December 16th, 2015 10:13 pm

zen jen art

If you haven’t checked it out yet, play Zen Jen here!

What went right:

Time management and setting realistic goals. In past LDs, I have had overly-ambitious games planned, only to waste time and scrap most of the plans — and have a really strung-together game as a result. This time I focused on the main game mechanic first, and then built around it. It’s still a modest little game, but I feel it’s the most cohesive and holistic game I’ve made in an LD.

Using LOVE for the first time in an LD was great. I’ve been learning it for a few months, building a codebase based on what I know, flashpunk. It was great. Only thing that stumped me was audio (see below).

Music was really simple — as a game about meditation, it’s lots of long pads and enveloping sounds. So I just had fun dialing in synth sounds and piling on the reverb. I left the melody out so the notes generated by the player had room to breathe.

What went wrong:

Only thing that tripped me up about LOVE was how it handles audio. Being used to flash, I thought it would create multiple instances automatically so as to not cut off already playing sounds. Thankfully I found a library (SLAM) that did the trick. Thank you!

The flipside of using my own codebase was that it still has its problems, so I had to wrestle with it a few times during the compo. Hopefully by next time it will have solidified into a robust little game making machine. Can’t wait!


Third Ludum Dare I’ve finished, and I’m having more fun with each one. The community is great, I’m forced to finish a game for once, and lots of good games come out of it. Love y’all <3

[cache: storing page]