Ludum Dare 33
The Theme is:
You are the Monster


Judging Ends in
3 weeks of Playing and Rating games!

Posts Tagged ‘postmortem’

Post Mortem

Posted by (twitter: @JangoBrick)
Monday, August 31st, 2015 4:37 pm

So Ludum Dare #33 lies behind us now, and I take the chance to write a quick follow-up of how this all turned out for me.

There is also a timelapse video of Virus‘ development:

The Preparation

I didn’t prepare much this time. No basic games to get back into the whole process, not many commits to my engine.
What was important though was that I made a list of ideas for the 20 final themes, which helped me a lot in getting creative and was quite a bit of fun, too.

The First Night

I forgot to commit final but crucial changes to my engine, which I consider would be cheating since then I would be the only one with access to that code. I noticed my mistake very late, and after documenting and committing everything there were only about two hours of sleep left.

When I woke up and started Eclipse as well as my timelapse software, I noticed the latter didn’t really work. Everything looked JPEG-ish, even though I had set it to PNG. I spent the last seven minutes before the theme announcement quickly building my own timelapse script, just to realize the original software did work correctly… Anyway.

I was not happy with “You Are The Monster”. Not at all. I mean, I knew that the chance for it was high, but still. I ended up making my biggest mistake, not sticking to the idea I had prepared beforehand. I wanted to do something atmospheric, something calm, like flying a bird. There was my idea – you play an eagle, which looks friendly at first glance, but for something like a mouse an eagle is quite the monster.

I built awesome flying mechanics (really, they deserve to be called “awesome”), made the textures, and put it all together into a lovely little eagle. It would even sit down when you flew it to the ground!
Unfortunately, after spending around six hours on that, I had no idea what to do with it.

My eagle

After sleeping a little, 14 hours in, I gave up. Back to my original idea: playing as a virus that infects all of humanity.

Starting Over

Progress came fast, since I had mostly the whole thing in mind from the start. In just a few hours, the basics were already done, although it was still far from a game.
In the evening that day, I took a break from coding and started with:

The Music

I am bad at making music, there’s no doubt about it. Partly because of my missing experience, I guess – this was the second time I ever made something for real.
It isn’t what you’d expect when you think of the word “music”, it’s rather some disturbed synthesizer sounds with a heavy focus on drums. Those are the only two things I am not that bad at. It turned out OK.

Want to listen to it? Play my game!

Making It A Game

After tuning the music to my satisfaction, I added the progress minimap, tweaked the gameplay and added the main opponent: vaccine production.

I also changed the background to a non-static one, with a pseudo perspective on the houses. Very proud of that!

Final look at Virus

Voice Acting

I appear to be surprisingly good at voice acting. It was my first time to ever narrate anything, and I only did one single recording, but it turned out very well!
One hour of effects work to make it sound like some highly-disturbed walkie-talkie transmission, and suddenly my game got a lot better.

Testing & Fine Tuning

Obviously, when you have played such a simple game for a few hours, you get really good at it. That is a problem, because as the developer, you have had to play it over and over again, which means you don’t know how hard or easy it is for someone starting from the beginning. That is where I got other people involved, basically just playing the game and reporting back how it worked for them.
Then followed lots of fine tuning, since the game turned out a lot harder than I had thought.

After one of them managed to win, I called it a success and submitted my game.

My Overall Experience

This Ludum Dare was absolutely great. I had a bad start, but after that, everything went very smoothly and I am happy with the outcome.

The way I did it this time appears to be how I should always handle game jams in the future. Giving everything you have drains a lot of energy, and you lose more than you gain. If you do this in a more relaxed way, you are not exhausted and get to do more.

  • If you haven’t yet, you can view my entry here: Virus
  • The development is available on YouTube, sped up to just over 5 minutes: Timelapse
  • And please vote :-)

Thanks for reading,

Office Hours Post-Mortem

Posted by
Monday, August 31st, 2015 1:00 pm

Hi there!
I participated in the Jam and created ‘Office Hours’ which is a fun, upbeat shoot’em-up style game!

I’ll be discussing the up’s and down’s throughout the weekend and how I felt about it all. I’ll also show some pictures i took throughout the weekend.

Day 1:

I had originally planned to make a moody, atmospheric game but once the theme was announced and i spent a few hours drawing up some things i decided to scrap it!
I wanted to create a game like hotline miami but still have its own charm. The theme was quite good for a pysological game, and so Office Hours was born!
The first night mostly consisted of some art and a creation of a small codebase.

Beta testing Level ( First Night )

I pushed out a very basic level design and added a player that could shoot some bullets! Not very much was done art-wise besides placeholder.

Day 2:

I knew I had to work fairly hard on the second day because i felt like i could have done more the first day, but it was okay! Having fun was key! The morning of the second day i worked on more art and came up with the player and some NPC’s!

Players spritesheet

I created an entire spritesheet but forgot that the players rotation changes so i only needed to use the down position and the up! The animation looked good and i was fine with it! Surprisingly i spent only 45 minutes on the entire character which felt great! I also went ahead and planned out some basic scenery to make the game feel a bit more alive!

Test of the props!

The second day was also where i went ahead and did a ton of Camera work! The camera shakes quite violently and pulses to the beat of the music ( day 3 ). The camera shake had to be a tricky one because i had simply coded it for a stationary Camera, which obviously , wouldnt work for this game! I ended up redoing the entire Camera and made the movement of the camera on the players position be ‘stabilized’ and then added in the shake as after effects. By stabilizing the camera, i was able to move it freely while shaking it and having no affect on the position of the camera in relation to the player! I also added basic prep work for the camera pulse to the beat and simply made it beat based off of a function i wrote in desmos..
That leads me into the growth of speed!


The entire game speeds up the more kills you acquire in ‘rage’ mode! Its all based on this graph which is capped at different levels for different things. This has to be one of the coolest things i went ahead and implemented as it made the game feel so much more fast paced as it went on!

Day 3:

Day three had to be a music day! I wanted to really make a heavy beat that had a 4×4 kick which could simulate a heartbeat. I also wanted the pulsing to give off the feeling of a heartbeat with the song. Not only that, but I wanted the other office song to really contrast the heavy electro beat! I sampled a song titled ‘Willow Weep For Me’ and it came out great! Of course its a little repetitive, but what office isn’t? The music is always an afterthought in terms of my programming implementation so i didn’t actually put the music in until monday morning! I spent hte majority of day three on music but I also implemented the different maps within the game so that was a day well spent if you ask me!

Second Floor

Day 4:

I spent a majority of monday working on audio and some enemy AI placement and things of the sorts. I had to turn in school related things which took about an hour or two out of my work time! Curse you High School! Other than that, Monday was a day full of scrambling and trying to piece together the game I had!

What I enjoyed:

I enjoy my game greatly! This is probably one of the best things ive made in terms of gameplay but boy is the code ugly . I think the camera effects were awesome and so was the gameplay. Of course there are bugs throughout but I’m not very worried becuase its a jam game and I don’t intend to take it any farther than it is. I am proud of what was created and will can’t wait for the next one!

What I learned:

I learned that webGL in Unity has quite a few problems with the sound engine and the game ran quite poorly in webGL so i opted out of the web build . I had quite a few issues with Unity’s inspector simply because I am still not 100% comfortable with the engine, but it gets better day by day. The game was tons of fun to play but i recognize that the balance is trash. Next time around, i will definitely have to work on balance of the game that still makes it fun!

Want to play?

Click me to play! Please click me!


So who’s the Monster in The Mammoth anyway?

Posted by (twitter: @inbetweengames)
Monday, August 31st, 2015 7:04 am


David here from inbetweengames. After giving everybody a bit of time to may be check out our game ‘The Mammoth: A Cave Painting‘ and reading the awesome comments on the page, I wanted to talk with you guys a bit about the integration of the theme that we decided for. This is going to be somewhat of a spoilerfest so if you want to check out our game with fresh eyes best do it now before reading this. We’ll be waiting here.



Everybody good? Are you ready for a hippie, arty rant? Cool, let’s go. :)

At first glance it’s not very obvious who the monster really is in the game. There’s no clear Sesame Street or Horror like monster at all. The Mammoth itself seems like the first obvious answer but that.. well is that a monster really? Does the game fulfill the theme at all? We think it does, it’s just when we were brainstorming we took all of our obvious first ideas and threw them away. All of those were good ideas and there are a few games in the jam that went for them and executed them beautifully. We just decided for the oddest one that hopefully has more than one possible answer about who the monster is. So let’s look at some of the possible answers together.


A quick excursion into semantics about how we read the theme to begin with. In our minds the sentence ‘You are the Monster’ can mean a great many things.
It can be ‘you’ as the player. It can be ‘you’ as someone else in the world that you’re saying this to – aloud or in your mind.
It can be ‘you’ as the collective you. Everybody. A group of people. etc. So which one did we go with? Basically all of them. Let’s check them out.


The obvious choice for the answer of who the monster is. You’re the mammoth – so you’re the monster. Kind of an odd choice for a monster though isn’t it? But we thought the way Mammoths (and most animals actually) are displayed in cave paintings like the famous Chauvet Cave gives them monster like qualities. The animals are drawn immensely large in comparison to humans in the pictures in a way that goes beyond a realistic depiction of scale and probably has much more to do with the perception of meaning and power. So scale here is based more on emotional and magical evaluations rather than the ones our modern minds would focus on.
On the other hand when we looked up the term Monster on Wikipedia (of course we did) we found this little perl of a quote:

The word “monster” derives from Latin monstrum, an aberrant occurrence, usually biological, that was taken as a sign that something was wrong within the natural order.‘  Wikipedia

The Mammoth in the game is also meant as a totem like representation of all mammoths, THE Mammoth as a whole, as an idea, a shadow on a cave wall – you might have heard that parable before.
So the story of The Mammoth in the game is not really the story of a single mammoth. It’s a legend on a cave wall telling of The Mammoth as a symbol, meaning all mammoths really and how they went away which obviously is what’s wrong with the natural order. The story is told by the hunters whose many hands also mark the borders of the level. In this case you as a player are telling the story by playing in a theatre like performance. Which leads us to..


Very cathartic to smash up the hunters’ village at the end…though I lost my last baby mammoth in the process. Point made, I suppose?Ryusui

Now since this is a game you as the player are the one driving most actions in the game. So when we heard that the theme was ‘You are the Monster’ we kind of went ‘Oh well we have done this before, let’s just do it again.’ Which was based both on the fact that we did a game called Spec Ops: The Line before in our day jobs at YAGER but also had never done a game jam before. So it seemed like a safe option.
So within the game our goal was to turn you as the player into the monster. We give you something that you care about hopefully and then we construct circumstances that in all likelyhood will take it away from you with a clear culprit to project your negative feelings upon. You will either care and seek revenge, in which case you’re a monster, or you won’t care at all, in which case.. well you get where I’m going with this.


I’m truly upset that the horrible hunters did what they did :(TailyILoveYou

The only problem is that I (as the mammoth) am not a monster… the monsters are the bad humans who killed my kids!Galvesmash

Now that we have the more obvious answers out of the way it gets a little more interesting. The Hunters in the game are really the ones killing all the Mammoths right?
So they’re kind of the monsters. Which is a comforting thought because we get to shove the blame on these external evil beings that we have no connection to – if it would’nt be for the fact that..


We are the hunters. We as humans have eradicated more species than anything that came before us including whatever killed the motherflipping Dinosaurs.
It’s quiet possible that we will add ourselves to this list eventually. We are the monsters.


Really loved the sad story for this although I don’t see how the mammoth was a monster in this case.RougeRogue

Now this can mean that we either missed the theme completely or something a bit more meaningful.
For that second option I’ll just leave this one to some of the commenters on our page who laid it down perfectly in my opinion:

Hard to say if you’re the monster or the hunters. I guess, in the end no-one really is, they’re all just trying to survivedickpoelen

Oh my god that was so depressing! I don’t think I was the monster here though, I only cared for my progeny. But weren’t the Hunters protecting their children too when they were hunting instead of watching their beloved die from hunger?

Is there really anyone to blame, is there any monster or is the world itself the merciless beast? The story of the Mammoth and the Hunters repeated several times in the past and will happen again, perpetuating the neverending suffering… but I can’t help to wonder, and I cling to that though as it is my last glitter of hope, is there a way to spare one mammoth child and make the herd anew?Hvedrung

Thanks for reading this wall of text and please let us know what YOU think by commenting here or on the game page!
We’ll write a more traditional post-mortem sometime soon but this just kind of started to write itself after thinking about your comments. :)


Team S.T.E.A.L.T.H. – Postmortem

Posted by (twitter: @IamJacic)
Sunday, August 30th, 2015 4:17 pm

Hi. I wrote a postmortem about my game here on my blog. Check it out to see how much my game changed over the weekend!

Also, you can play and rate my game right here!

Alien Rush post-mortem

Posted by
Sunday, August 30th, 2015 11:10 am

Alien Rush is mine 6th LD entry and mine 5th Compo entry. You can play it here.



What I’m happy about:

  • Gameplay – Most people commenting my game (my friends or other LD participants) says that my game is good, addictive and based around good idea. Personally I also like it :)
  • Game genre – All my former games are platformers or top-down shooters. I didn’t want to make another same game, so I decided to make something different, and the final result is mash-up between platformer, real-time strategy and tower defense.
  • Graphics – In my former games graphics were awful. I think Alien Rush graphics are acceptable, which is already big improvement (and some people even likes graphics!). During warmup, I had a bit of practice with pixel art. Also, I learned how to make animations. I think they adds life to my game.
  • Level design – Most players and I think that levels are nice and fun to play.

What I have mixed feelings about:

  • Theme – Amount of ways LD participants could use it was pretty small, in the other hand,  there were a lot worse themes during votes, or former LDs.
  • My engine – I really like Unity3D and its workflow. But there was one bug in engine that caused me a lot of pain. It caused that some Rigidbodies2D automatically translated into (0,0,0). Everytime it happened I had to restart Editor.
  • Sound – Sound in my game is just SFXR-generated sound effects. I cannot make any music (I’m willing to learn it someday). Besides that, I feel that sound – similar to animations – makes my game alive
  • Splash screen tutorial and learning curve – it translates rules of the game, but now I think that in-game tutorial would be better, ever if I had to sleep one hour less :) Also, learning curve is too steep IMO. I should add easy level 1, which also would serve as tutorial.

What I don’t like:

  • Balance – I hate balancing units and I can’t do it, no matter how hard I would try. As a result, cannons are practically useless, and game feels overall unbalanced.
  • Way I made this game – Shortly after I got idea of game, I sat down and started making it, without any thinking how I will do it. As a result, code is a mess and it leads to last issuse
  • Glitches and annoying things – I fixed all major bugs, but some things are a result of implementation design (e. g. houses blocking units). I couldn’t fix it without remaking almost whole game.

What I hate:

  • I hate that I didn’t make any screens during development or timelapse :(

Anyway, I’m very happy with result. You can play my game here.

Other things about my game:

  • Major inspirations were Lemmings (gameplay, way of commanding units), StarCraft (plot, units) and Plants vs Zombies (HUD, overall design).
  • I’m still thinking about making post-compo version, but I don’t know if I will have sufficient time (school begins soon). In post-compo version, I would rewrite game, eliminating all glitches and annoying things. I’d also like to rebalance game and add in-game tutorial, more levels, more complex A.I. and music).
  • I were going to add menu which would serve as invasion plan, but I ran out of time.
  • If you want to ask me anything about my game or post-compo version, feel free to do it under this post.



Sly Slime – Revenge On All Players

Posted by
Saturday, August 29th, 2015 11:00 pm


The slime is the most common monster in JRPG. Millions of them were killed by players during the whole video game history. So it’s the time for REVENGE!!

After 72 hours of hard work, we made this game – Sly Slime. It’s visually beautiful, fine-tuned, also brutally hard and unforgiven. You are weak just like your kins, so try your best to survive this bullet hell, sneak and send these players to hell! Give them everything you got!

Please visit our game page here, and don’t hesitate to rate and comment!

Good Game, Good Luck, Have Fun!

Monster of the Matrix: post jam progress

Posted by (twitter: @@jespertingvall)
Saturday, August 29th, 2015 5:13 pm

Still having a cold decided to continued working a bit on my Ludum Dare 33 game Monster of the Matrix. In the game you play as a skeleton trapped inside a dungeon crawler. But something is wrong… You realize that you are trapped inside a world that is shutting down. You must escape…! And something is hunting you….!

New version

  • The original Ludum Dare game had one random generated level of fixed size, with one exit. After the jam I split it up into 7 different sized, still randomly generated, levels. It also added a new gameplay element, doors. They made the game much scarier since they limited your sight. And behind every door an agent could lurk…
  • A stamina mechanic was added. You need to rest and can not run the entire time. The agents more a little bit faster than you, so you can not loose them unless you are running from them.
  • More and scarier sounds where added, among them footsteps to the other skeletons and really spooky music from Connor O.R.T. Linning.
  • I also integrated Gamejolts API into the game, giving the player achievements.

Old version of game



Run OGRE Run! – Postmortem

Saturday, August 29th, 2015 3:51 pm

Play the game

Run OGRE Run logo

Run OGRE Run is an infinite runner, where you (the OGRE) run through a medieval village causing mayhem. With an angry mob hot on your heels, and an outraged citizenry hurling anything they can get their hands on at you. You must avoid obstacles, dodge weapons, consume pies, and drink ale along the way to stay one step ahead.

We’re a two-man team out of California and Texas, and this is our first game jam. In fact, we only heard about this competition three days before it started and figured it would be a great experience. We have a handful of games in our development queue, but we’ve struggled along the way with scope creep and the daunting reality of large game projects. We were very excited by the idea of a game jam to force us into managing the scale and scope, and avoid getting bogged down as we have in other projects.

After reading the winning theme on Friday, we connected over Skype and shared a Mischief session to sketch out ideas, figure out our base mechanics, and conceptualize the general game flow. Once we had a high level view of what we were going to build, we jumped into a google doc and wrote up a basic game design document (GDD) of the systems, art, and sounds we would need to complete the game, and then split up ownership of tasks. Since we’re both pretty comfortable bouncing between code and art responsibilities, our plan was to build all the logic first using primitives, then tag-team art creation while merging and testing systems, and spend whatever time we had left polishing the results and adding as much candy as time allowed.

Mischief concept sketches and GDD…

Mischief concept sketchesGame design document (GDD)

We started by building systems in separate projects, then importing them as asset bundles into the main project, and used SourceTree and Bitbucket for our version control. We assumed once we had basic functionality in the main scene we could both switch to it and proceed with a Commit, Fetch, Merge, Push routine. After a few of these however, we realized git wasn’t working well with Unity specific files such as levels, materials, etc, so we stopped trying to work on the scene simultaneously and ended up doing most of our refinements in separate projects and merging only once we knew things were ready, or close enough. By the end of day one, all the primary systems were built to at least the first pass stage.

On day two we took turns working on the main project while the other worked on art to deal with version control issues. Art was produced in Blender, Photoshop, and Gimp. Everything is our original art, but the character and houses were originally built for another project so we opted out of the graphics category. The character and houses still had to be modified for this project and the remaining art was created within the 72 hour window, so art still consumed a chunk of our available time. It was great to replace the primitives with final art, the transformation was exciting.

Core logic in place with primitive graphics…

Main menu with character mock-upMap scene view with primitivesMap game view with primities

3D asset creation and testing…

Textured Ogre modelTextured bullet and obstacle modelsTextured ground plane and village houses

The music and sound creation occurred throughout the duration of the project, but really started coming together towards the end. The songs were created in GarageBand, and audio processing was done in Audition. Getting audio into the game was another aha moment that added a lot of polish to the overall project.

Day three was filled working out remaining code issues, creating the logo, theming the UI, and plenty of play testing. Time restrictions forced us to cut a handful of ideas, and take a few shortcuts, but we managed to submit the initial WebGL build by the deadline, and followed that with desktop versions for PC, Mac, and Linux.

Run OGRE Run - Main menuRun OGRE Run - Game map

Ludum Dare was a fantastic experience for us, the time restriction forces productivity over all other things. It’s been so fun to see other perspectives, play other games, and have an immediate audience for our own. We can’t wait to do it again. As for Run OGRE Run, our current plan is to polish it up, add all the things we were forced to cut plus more content and touch controls, and publish it on mobile.

Our software toolset for the build…

  • Unity (Game engine)
  • Blender (Modeling, rigging, and painting)
  • Mischief (Concept drawing)
  • Gimp (Art and textures)
  • Adobe Photoshop (Art and textures)
  • Adobe Audition (Audio processing)
  • Garage band (Music composition)
  • Shadermap (Tiled normal maps)
  • MindTex (Normal map creation)
  • SourceTree (Git)
  • Bitbucket (Git)

Additional software to make it easier to deal with our geographical difference…

  • Skype (video chat, desktop sharing)
  • Telegram (chat, image and file sharing)
  • Teamviewer (desktop sharing)

High score (1857) play through…

Play the game

Super Snack Time! Post-mortem

Posted by (twitter: @adsilcott)
Saturday, August 29th, 2015 1:04 pm

Play the game here!

We were a team of four people this time, though one person had to leave after the first night, and I was busy Saturday evening and Sunday morning. Since we were especially limited on time and resources we really needed a simple idea. Besides, I like simple ideas because it’s easier to focus on making one concept polished and fun. Of course all of our initial ideas were very complicated, until…
The player-plant

Once we had the idea, and we knew it was going to be a parody, then the issue was how to do the art in a way that paid tribute to the source without copying it. I do a lot of traditional/fine-art (My work: and I’d been thinking for a while that it would be interesting to do a game in a very painterly style. I did some quick sketches of mario in ArtRage and then used Aseprite animate them and export a tilesheet. It looked pretty good so we decided to go with it:
Painted Spritesheet for the


Even though we wanted a more organic look to the game, I decided to use Tiled to create the level, because that would make it easy to experiment with different layouts, and the excellent Tiled2Unity tool would generate the collision meshes for me. Once I had the level laid out in a way that worked well with the bouncing marios, I used Tiled’s “export to image” feature, and Ian used that as a reference to paint the lovely background that you see in the game.
Painted Background

Probably anyone who’s used Unity for 2D has made the mistake of leaving the “fixed rotation” option off on your sprite’s rigidbody and then watching your character spin and flop around unexpectedly. For this game I wanted mario to have a silly, clumsy quality, so I left it off intentionally. The challenge then was getting a reasonable amount of these clumsy marios to the end of the level. I used several invisible triggers to tell mario when to jump. Each trigger had a percent change of triggering, so we would end up with marios taking random paths through the level.

Marios moving through level
While Jesse made a mario spawner and worked on the plants, I painted the title screen as quickly as possible. I’m sure I didn’t spend more than 20 minutes on it. My plan was to hand paint the title text as well but that just would have taken too much time.
Quickly painted title screen

At the end of Saturday we were at the testing stage, and while it was already making us laugh (a good sign!), we had a lot of ideas for how to make it better. I assumed I wouldn’t have time for any of them. But Monday morning I was determined to add them. I added the “withering” plants feature and the heart counter as ways to add challenge and excitement to the game, and Brian added a score counter and cleverly tied the rate that marios spawned to your score, which leads to a hilarious avalanche of marios if you get far enough. At this point I think it went from being a silly game to one that was actually fun to play.
Many marios

Of course I always forget how stressful the submission process is, especially when you’re already exhausted from lack of sleep. But in the end I’m very happy with what we made. There’s only a couple of minor things I would have done differently. Much gratitude to my team, and to everyone who has left feedback!

Play the game here!

Wild Flirting: the post mortem

Posted by (twitter: @calendulagame)
Saturday, August 29th, 2015 12:35 pm

Hi all!

Blooming Buds here with the post mortem of our first Ludum Dare entry as a team. Some things went right while others went wrong, but in the end we came up with a quite positive balance.

The game

In Wild Flirting you take the role of a monster trying to find love using a dating app. The problem is that you have the social skills of… well, a monster. You’ll have to check user profiles and learn about their personalities while you chat, so you are not uncovered and banned from the app.



The process

We have to admit that we had a hard time finding the game idea. We started with a point and click game about being a disguised alien in a spaceship. You had to eat people without getting exposed. We had some more mechanics and contents planned, but we decided to go to sleep and keep thinking before committing to that idea.

The next morning we were not fully convinced with the idea, so we started from scratch! We discussed the idea for like three hours, and then the “Dating app simulator” thing crossed our minds. We switched to the new idea pretty fast, since it was more affordable and heavily focused on design, which is the part we enjoy the most!

We splitted the work into four groups: design, code, art and music.

The design focused on building a huge dialogue database. We had to create a narrative big enough for 10 different characters, each one with its own personality and its own set of questions and answers. We ended up with about 12 pages of script. At first we thought that it was going to be easy, but then we realized that coming up with this amount of meaningful content was really hard and time consuming.

Before the magic


After the magic

On the programming side, we started from scratch. First, we coded a parser to store and link every conversation with each character. After that, we implemented a simple conversation scheme (question-answer-question-reply), trying to mimic the flow and aesthetics of apps like Whatsapp or Tinder.

With the aforementioned coding finished, it looked like we were close to be done. But nothing further from reality. The main scene transitions (between character selection screen and conversation screen), the intro screen, the art positioning in a pretty and usable way… All these “details” took about 60%-70% percent of the development time.


Let me see your guts, Unity

The art team had to build a good environment for the game (the monster’s chamber) with a few animated details. Besides from that, any dating app would need profile pictures, so we had to draw a portrait according to every character designed, which somehow represented its personality.

For the music we had the chance to use a Farfisa Professional 88 organ of a friend of us. That brought exactly the kind of sound that we were looking for. A perfect mix of the 60’s seductive songs and dark humor.

The real MONSTER

What went wrong

  • Distance: lesson learned. The problems in the development of a game are directly proportional to the sum of the distances between all the members of the team, or something like that. We made the whole game separated.
  • Not very modular: our game basically occurs in a single scene, which usually means problems when dealing with Unity + Git.
  • Testing (minimal): we had no testing. Ah no, wait… two people.
  • Last hour bugs: The two testers found some bugs just before the deadline. So we were in a hurry!

What went right

  • Scope!: we are proud to say that it was, surprisingly, highly accurate. If we had decided to put some other mechanics or content we probably wouldn’t have finished on time.
  • Organization was key: knowing what each of us had to do at every moment kept us busy and focused.
  • Team work: we had constant communication, allowing us to help each other and providing feedback when needed.

What we used

  • Code: Unity, C#
  • Art: Photoshop, Illustrator
  • Music: Farfisa Professional 88, Cubase, Audacity
  • Collaboration tools: Google drive, Gtalk and bitBucket

Thanks for reading and feel free to try Wild Flirting!

Try it out:


Postmortem: Slavery Simulator 2015

Posted by (twitter: @SebBernery)
Saturday, August 29th, 2015 10:34 am

Here is my postmortem for the 33th edition of LudumDare. Theme was “You are the monster”. You can read it on the vikindie blog.


My game is a basic tycoon game where you have to organize the “triangular trade” : get soldiers in Europe to capture slaves in Africa and produce new world’s goods to send them to Europe.

Slavery Simulator 2015

Final game

Idea finding

When doing LudumDare, I try to be original in the theme interpretation. I’m a little disappointed because my game doesn’t reflect what I planned initially to match the theme. I was thinking about moral choices for the player (“Pay 100 for a medic or 10 slaves died”, …) and I wanted to have an authority in the game trying to fight slavery, with some navy tracking your ships, and laws passing like Habeas Corpus. The goal was to create frustration for the player so he could say “Oh, fuck, humans right bill passed”. The idea was that “YOU are the monster” don’t designate the game character but the player himself.
I love tycoon games and was very happy to create one for LudumDare (I usually create character centered games).


I used HaxeFlixel. It’s my 4th ludum dare game using that fantastic game engine. For the first time, I used it fluently (I praticed a lot last months). That was awesome.

The HTML5 export had never worked for me, so I planned to create a flash game. I live in France, so the end of the jam is at 3AM. Midnight, I said to myself “Hey, it could be a good idea to test if the game works with flash !”. Spoil: it didn’t. It was VERY slow and buttons was all the same color (the button’s color is an important thing, I will speak about it later). I spend some minutes to optimize the game but it was still too slow and buggy. So I tried the HTML5 export. I didn’t belived. It worked. That was awesome (let’s be honest, I don’t like flash).

I still use a proven and reliable IDE : vim, tmux and my personnal configuration ;-). If you are interested, here is my vimrc.


I used Krita… and tried to do something. I spent one hour to draw the map (saturday night, 1AM, before bed). Probably something like one hour more to create all buildings and the boat. No animation, no different images when buildings upgrade, … That pretty sucks and lead to a static game. But I consider that graphics are not very important in a tycoon game, and I hate those business simulation games where graphics go AGAINST the game (think about Railroad Tycoon 3 where the 3D hype leads to unreadable informations).

Yes, this is a Mapmonde.

Yes, this is a Mapmonde. This was my game before assets creation.


It was the last thing I did. It was probably midnight past thirty, I plugged a MIDI keyboard, opened LMMS, then Pixitracker, tried to do something audible … Nothing came. So I used Abundant music, it generates music procedurally. In less than one hour I had one music that correctly fits my games. Really happy about it, the game without music would be boring. The main problem, there is only one music, no sound effects and the music don’t transparently loop (you can hear the transition).
Next step, learn how to tweak the generated midi to humanly customize it.


Honestly, I was very lucky, my game system pretty works. I created the concepts and tested them individually but I only tested to play a complete game once. I changed things after that and never tested again before submit.
After submit I saw some issues :
When harbour storage is full, it displays hundred same messages every seconds. Logger window become useless and it may hides informations (like events).
The soldier price is not updated when you upgrade barracks, so I suppose many persons didn’t understood why upgrade barracks. In fact, the soldier price raise each time you buy one. When you upgrade barracks, you divide by 4 the soldier price.
When a boat is in USA, it loads tobacco first, then sugar if space left. Unfortunately, you can have big reserve of sugar in America but you can’t sell it. As you don’t sell it, price raise. But you can’t sell it, so it’s very frustrating. (And the sugar price raise too fast).

My saturday afternoon fuel : carrots and sun.

My saturday afternoon fuel : carrots and sun.


LudumDare games are usually played in something like less than five minutes and you have one minute to convince the player to continue his game session.
The best I could do would be an interactive tutorial, or at least, a visual help. I absolutly did nothing like that. The only help was a special screen with boring text.
To let people understand the game, I made color changing button depending of actions availables. With that, even if you don’t understand anything to the game, you just have to click green buttons and something good will happens.
The only exception is the boat parts which is always green but is not always a good choice to make.
My theory is that if the player randomly play by clicking on available actions, he will progessively understand what happens and the meaning of the actions (and of the game). After some time of random play, he will be able to do more intelligent actions because he saw what happened with his choices.
At the begining of the game development, the buttons which can’t be used (not enough gold, …) was hidden. This solution seems bad for me because the player is not aware of all actions available in the game and what to do to unlock them.

Theorically, there is a loose condition : if you don’t amass 5000 Gold until Jan 1700. There is an ending with a fucking awesome sentence, but nobody will see it because you can’t really loose. During my tests developements, I was able to do bad investments which leads to a situation where you can’t do anything (not enough money).
I didn’t want to frustrate the player which don’t know the game by letting him loose in the ten first seconds without telling him before 20 minutes of play. So I changed some part : now, all essentials first investments are done automatically : there is a village, a plantation and a slave. The first soldier is free. Even by doing whatever stupid, you will be able to slowly earn money to make better investments.


I’m very happy with this game. I hope you will enjoy playing it as much as me developing it. I wan’t to participate to october challenge, maybe I will reuse Slavery Simulator and continue the development, it depends on the users feedback, ideas to enhance the concept (already got some) and my motivation. Follow me on Twitter if it may interest you.

Here is my compo page : Slave Simulator 2015 . To play the game, it’s here.
Ps: don’t forget to look at Am I the monster?, game made by a friend who invited me in his appartment to do LudumDare and prepared me good tasting coffee.

Path of a Psychopath – A Post-Mortem

Posted by
Saturday, August 29th, 2015 9:12 am

I am incredibly happy with this summer’s Ludum Dare results. Not only feedback has been overwhelmingly positive in areas we only started experimenting in, the game managed to get 3.11 on kongregate which is huge new record for us and motivation to keep ever going.

Now, what is this game, you may ask?
It’s an interactive story with a somewhat uncommon interpretation of the theme: instead of straight up Godzilla-style destruction we went for the more subtle dictatorship-building kind.

What went well:

  • We kept it simple. This may sound silly but it feels like the hardest part of every LD is planning small, then cutting most of it off to fit in time. We focused a lot on doing the MVP (Minimal Viable Product). We made just enough conversations and cutscenes for the story to have a beginning, an arc, an ending. We could have added so many more, had the ideas for them all. But rather than shipping a game with 8 incomplete and ugly and inconsistent levels, we decided to have the 4 we had and polish them.
    We added effects, refined the texts, had playtesters fish out the bugs and try to break the game by clicking everywhere they shouldn’t be clicking. This all ended in a much better experience all-together. Keep in mind, a longer game is not necessarily better.
  • We dared to go for minimalism.
    This saved us both time, effort and probably made the game better all around.
    Instead of full figures and faces, we used silhoutettes. Easier to draw (art is a weaker side of our team compared to the visual wonders some others make here :) ) and it allows the player to place the characters of their own imaginings into their place. We had a very clear idea of how our monster would look but others from all around the world would probably have different ideas so we settled for an evil-looking hat.
    The other artistic decision was making the game full grayscale. It ties in well to the old-timey atmosphere and generally dark storyline and also saves us the color-picking effort.
  • Teamwork. This is the 6th Ludum Dare the full team takes part in and by this point, we work together really well. There is a general sense of who is a master of what and how much progress we should be making by the nth day and the need to ask each other what we should be doing once we finished X task is smaller every time.
    Despite our scheludes being all over the place, we managed to make our best game yet.
  • Shine, polish and juice. We added a bunch of effects that really help the atmosphere appear. See one below for example.

What went wrong:

  • The aforementioned scheludes. We didn’t plan ahead enough for the LD and families and stuff so I believe if we had more working time we could have done some more features and scenes.
  • Spaghetti code. We did not have a conversation-framework so we made one on the fly – making the final debate that has a large conversation tree instead of the randomly rolled standard kind of the first 3 was a lot of pain and copy-pasting. Seriously. For lack of better ideas to name them, I made 40 functions with the names one, two, three… forty.
  • Recording device. Our music is praised a lot in comments but it was recorded with a camera that was lying around the house. It would probably be even more gorgeous with an actual microphone.
Very sinister!

Very sinister!




Play the game by clicking here!

Creating Brood’s Art: Environments and Interfaces

Posted by (twitter: @seconddimension)
Saturday, August 29th, 2015 6:35 am

Brood Title Screen

Brood screenshot

Written by Adam D., a team member in Second Dimension Games. We created the game Brood for Ludum Dare 33. I’d like to apologise for the length of the article, but I wanted to be thorough and hopefully some people will find it helpful and informative.

I’m very pleased with our entry into this LD (play it HERE), it was a close call but I managed to come back for another competition. We all worked together on the game concept, but my specific role was to create the environment artwork, the UI, main menu (and help screen) and the large monster. I also got the chance to do some animation, specifically the tentacle animation, which made for an enjoyable change. I thought I’d write up my working process for designing the screens and environments of Brood for anyone that was interested.


MISHMASH post-mortem

Posted by (twitter: @bodozore)
Saturday, August 29th, 2015 1:25 am

Hi all,

I’m on vacation in Bulgaria, and saturday it was rainy, so I decided to enter LD. Of course sunday was sunny so we went to the beach instead. Anyway, I worked appx. 8h on the entry, and being not home meant I was only with my laptop and without my usual software and tablet. I took my notebook to the beach and draw the assets which I photographed.

I used this very image and cut my assets from it

I used this very image and cut my assets from it

Note that while cutting assets from the photos I added a small drop shadow. I was afraid that the paper texture would create a mess visually, and also I wanted to build on the “craftwork” visual.


I used Playmaker. It’s the first LD I do with Unity and Playmaker. It’s very helpful for small routines and animations, but it can be a pain for more complex algorithms. I wouldn’t say there are complex algorithms in this game, but I lost time at some point doing one thing it would have taken me less time with scripting (it was making the multi-color jauge for the planets)

Overall a great experience. I ended up rushed things a bit on sunday night, to put at least some music and to put together the title screen I had in mind. My only regret was I didn’t have time to test the game properly, although I’m used to iterate a lot. Comments on the game so far seem to support this idea, as the major complains come from things I just didn’t test, like gameplay loopholes.

Here’s my work time breakdown :
– 3h for basic gameplay scripting on saturday. Tested only a bit to check if it was at least fun and functional
– 1h or so of drawing, best assets creation of my life, lying on the beach
– 1h or so of processing assets, back to reality, this was the most painful step.
– 2h for extra scripting (menus, fx)
– 30 min for music composing

I wish I took more time to test the game and to put more sounds in it, but I think my gf would have killed me.

Comments so far have been great and constructive, from my friends or from LD devs. Now I’m starting to wonder where will I take this prototype. Will I turn it into a full game and release it ? I need some more time to consider the question.

Title screen

Title screen

If you want to play the game it’s there!

Guard-Master Post-Mortem

Posted by
Friday, August 28th, 2015 8:48 pm

For our first LD we created an inverse-stealth game called Guard-Master. You can play it here. The core idea was to create a typical stealth game where you control the guards rather than the intruder. Simple right? Well not quite.

What went right

We started the jam with an epic 3-hour brain-storming session. Peter had read about the 100-10-1 rule on Reddit and we were keen try it out. You start by coming up with 100 simple ideas and then culling them down to 10 of the best (and doable) ideas. Finally we selected one of the top 3 ideas that we felt was easiest to get done. We liked one of the other ideas so much that we’re actually prototyping that one now as well. You can checkout our list of ideas here. Be warned though, some of them are very outrageous! I’m really glad we took the time to work through this process. In past jams I have been in teams where we jumped on an idea way to quickly, just because it was easy to visualize and then regretted that decision later.

The other thing that worked well was creating the levels with the Tiled map editor. At first we were worried that we wouldn’t be able to find a level editing tool for the perspective we had chosen. As it turns out Tiled not only supported it but also exported in a format that Phaser could load and display easily.

Finally, something that I think we did well was the aesthetics. We chose a simple pixel-art style for the characters and tileset. Peter did a great job creating all of the environmental bits and pieces. Visually everything came together quickly. In fact we had a lot of props that didn’t make it into the final game because we didn’t have enough time to code-up their behaviour.

What didn’t go right

We’ve read over and over again that you should prototype the minimum viable product of your game first. Everything should be coloured boxes and all you should care about is the core gameplay. I’d be lying (a lot) if I said we did this. We didn’t really have anything playable until the end of day 2 and that would be being generous with the term playable. It was only once we started playing our game that we realized how not-fun it was.

In our original concept for the game, the intruder would try and sneak his way to the exit without being detected. We also wanted him to incapacitate unsuspecting guards along the way. I spent ages tinkering the A.I. to try and get this to work, but it was a bit too hard. More often than not the intruder would just wander into the guards field of view and be easily disposed of.

Eventually we scrapped this idea and went with a much simpler hide-and-seek approach. The intruder will now just pick the furthest hiding spot from all of the guards and if you don’t find him within a minute you lose. This approach was a bit more fun. We also changed the guards from auto-firing to manual shift-click fire. This made it a bit more of a challenge to hit him once he had been discovered. It is still a bit broken though. Since the intruder always picks the furthest hiding spot, he will predictably be in the same place once you reload the map. Bah, well at least the first playthrough might be fun-ish :p.

Final thoughts

Overall we had a lot of fun. It is also really encouraging to see the feedback we’ve gotten. Even though we made a broken game, people seemed to like the idea and could see its potential, which is all we could really hope for. The biggest lesson that we’ve learned would be to always prototype the minimum gameplay first! 

Post-Mortem on Minotaur

Posted by
Friday, August 28th, 2015 1:35 pm

Part of the preparation for the next Ludum Dare (because, hey, it’ll be here rather sooner than later) is looking into the past at how the previous entries worked and how they didn’t. First, let’s recap how our time was roughly spent during the three days of the jam, while working on Minotaur:



We met at 9 o’clock, six hours after the theme was announced. I don’t think there is any way to improve this, since a good night’s sleep is crucial for doing anything. After an hour or so of smalltalk, setting up the project/workstations and deciding which engine we were using (Phaser), we were ready for brainstorming.

We had a few ideas what kind of game we wanted to do. Some ideas were really just other themes or settings, but in the end we had two ideas in competition. The one that didn’t make the cut was “You are the (Flying Spaghetti) Monster, converting people with your noodly appendages and meatballs, while Zeus throws lightning at you”. Hey, we can’t all be genious writers. As far as time goes, the brainstorming was done reasonably quick, without rushing things.

After we settled on the Minotaur theme, we split into three groups doing stuff. I can’t comment much on how my coworkers faired, since I was doing the graphics. I’m really a programmer, but Ludum Dare is perfect for dabbling here and there and I know how to use gimp somewhat effectively. The others were working on extending the game skeleton with the actual game logic, some basic AI and implementing procedural level generation. Unfortunately, we had to scrap that last one.

Graphics-wise I should probably look up how to improve the workflow. A lot of the time was spent creating mirrored and rotated versions of tiles. Since I was doing a bit of shadows and working exclusively with bitmaps, I had to fix the highlighting after mirroring/rotating the tiles. Maybe I can improve that aspect. I also would love to work more with higher levels of abstractions than pure bitmaps. I kinda did so with using copious amounts of layers (Achievement unlocked – “Layer Madness: Create a meaningful gimp file with more than 200 layers”), but there has to be a better way to work, possibly using vector graphics, texture editors/generators and specific programms for working with spritesheets/tilesets. Other than that, I think doing graphics simply takes a lot practice. Doubly so, creating them efficiently.

The big I-wish-we-could-have-done-this thing was animation. With my crappy workflow, animation would have required drawing each frame manually. The horror! It’s certainly possible and how a lot of people do it, but a programmer doing animation during LD? You gotta “cheat”. Again, with vector graphics you can draw key frames and let the computer interpolate the frames in between, but that is hardly possible with bitmaps. Something to research for next time.

My coworkers made better progress, but hit a bump in the road with pathfinding. Sure, everyone and their mother knows of A*, but it’s not like a language construct you can write down with a few keystrokes. First, you need a data structure, that actually supports the algorithm. Second, you have to implement and use it. Third, your actors need to decide where they want to go before they can calculate a path. In the end, the game didn’t end up using A* pathfinding, but a simple state-based movement, that worked well in the purely orthogonal maze, by cleverly choosing angles to deflect when hitting a wall.

We have plans to vastly improve working with simple state machines and pathfinding for the next LD, should we decide to use Phaser again. Now we know.



The second day is the day for the actual game logic. Having the mobs and the player move around is nice, but not exactly a game. Again I can’t say where the chokepoints for the programming side were, but I gathered, that a more systematic approach using OOP patterns (even if javascript is often called a functional programming language) right from the start would have saved a lot of time. Evil, global vars! Fight the monolithic functions! Say no to god objects! And for the love of Elune, don’t repeat yourself!

On the graphics side, I was busy doing some decoration objects, that later were reused as different sprites for the same game object to provide some variety. The only decorative thing in the level were some fountains, and those were the worst sprites I made. Oh well.

A big time waster was doing a big spritesheet for the mob groups. We decided that mobs could band together to form a group. Since collective behaviour and movement was basically impossible with the crude AI and movement we had, two or more mobs would simply fuse to one object with the sprite of a group. This time I had no shadows to worry about, so could copy+paste and rotate to my heart’s content, but it still took some time to create the spritesheet. If we have our better AI for the next game, I’ll be able to save on that side, since grouping can be done a more abstract level and the mobs simply stand close together (if we even need grouping).

At the end of the day, we had our game almost complete. However, from my previous entries I knew that instructions and tutorials are absolutely crucial for LD. People just don’t have time to figure out the game. So I decided to do a tutorial. For that I created a very small level and added a page-through collections of short texts, like “Strange creatures have invaded your labyrinth […] and if they band together, they get stronger.” They don’t outright tell you what to do in meta terms like mobs and highscore, but should still provide a quick introduction to the game. I really hope this solves the problem. Ludum Dare is not the time to create elaborate tutorials, that are longer than the main game.

At that point I also discovered a really annoying engine limitation: Reseting the game is not as easy as it should. The solution was to reload the page to reset the game. Ugh!



We all had to work on Monday, so not much development was done on the game. In the evening, I extended the main level for some additional gameplay (still short though) and fixed a bug. After that, an unfortunately very short round of playtesting to check the winning/losing conditions and browser support, then it was already submission time (actually sleepy time). Even though the jam has a day more, the third day is not the day to do any heavy work, since most people have to work on mondays.



Better preparation for common patterns in game development goes a loooong way. It’s not just that you can do stuff faster, but also more is possible because a reasonably well constructed program enables more features with a few lines of code than a horrible mess of spaghetti madness. Also, for graphics proper workflow and tooling is crucial. I don’t know much about audio, but maybe it’s the same. We chose external music and sound effects, because programmers make for horrible musicians (for us anyway).


[cache: storing page]