Posts Tagged ‘post mortem postmortem’

Developing a microphone controlled game…

Wednesday, August 26th, 2015 4:43 pm

…is first and foremost an awkward process!

We got the idea in a team of 3 on sunday evening and the others decided to leave the jam out of frustration and too less time. I was all alone…

However I said to myself SCREW TIME! I will do it!
I quickly realized that analyzing the frequency of the human voice does not work reliable so I decided to only use volume.

I also lacked an idea in which I could use the assets I had up my sleeve.
I ended up using 2 beautiful resource packs from the Unity3d Assetstore and decided to generate the levels procedurally:



I already had some experience doing procedural stuff but those sprites where giving me a hard time fitting the layers perfectly together. But then again SCREW PERFECT this is a game jam – so I just went with it.

The Mimic chest was chosen as the protagonist of my game due to my love to dark souls. I wondered why those things always have legs. And then it struck me! It is HARD TO MOVE WITHOUT LEGS!

With my newly gained wisdom I designed a movement system for Mimics that does not require stupid legs but only a GOOD DEAL OF MOTIVATION!

After like 15 hours prototyping the actual gameplay and screaming in microphone like an idiot with everyone around me thinking I am nuts I realized: IT IS NOT FUN!

I needed something over the top, epic effects of destruction. And I MADE THEM!

It still was not fun. But then I said to myself: SCREW FUN! Making a game is hard work so why shouldn’t playing a game be hard work as well?

At least it is hard work that makes you laugh. And if one does not like my game he can be at least be sweaty happy that it is over. Leaving early is cheating by the way. It is forbidden on Ludum Dares you know?

So in the end I ended up with an unfun experimental game that looks too good to actually be funny. What do you think?


LD32 Postmortem for Colour Rocket

Posted by
Thursday, August 6th, 2015 3:59 pm

Note: this is a cross post from

Game Jamming for LD32

A couple of weekends ago I participated in my first Ludum Dare, “an unconventional weapon”. My game was called Colour Rocket and the concept was an “infinite runner” inspired asteroid dodger, where you aim was to guide a rocket to an enemy planet through flying asteroids, and use it to return colour to a darkened universe.

At about 5pm on the final day of Ludum Dare, I decided I’d had enough. I put down my keyboard and picked up my baby daughter for a cuddle. She has since forgiven me for ignoring her for the best part of a day. This left me with a fully functional, complete but very minimal game with only three levels. I’m pretty happy that I was able to get that far.

I picked a fairly standard free toolset early on:

– Unity to make the game,
– Blender for artwork, and
– Sunvox for music

What worked


With the exception of one or two minor volume issues, I’m pretty happy with the music I made. There is a different song for each menu screen or level, and although they aren’t going to win any prizes, given its the first time I’ve tried to make music I don’t think the songs are too horrendous.


The artwork was very basic low poly stuff and I quite like the look of the black and white planets before colour is returned to the universe. Its very basic as a few comments have noted, but yeah “programmer art”.


I tried something a bit different with the player controller. The player’s rocket is always at `(0,0,0)`, and the asteroids move around the player. I can’t really say I have a logical reason for doing it this way other than it meant I didn’t have to think about the camera or moving cleanup/spawn regions. In the end I think this worked ok.

What didn’t work

There were a couple of areas where the game clearly fell short. Although its promising to think that most of these would have been easily solved if I’d spent more time on them! In no particular order…

My method for slinging asteroids towards the player was to spawn a whole lot at the back of the screen. However this lead to disconcerting “pop in” in the background as asteroids were recycled. As the asteroids were rigid bodies with collisions, it also meant that the target planet effectively carved a tunnel in to the asteroid field that would sometimes let the player travel through the whole level without touching the controls… oops!

I fixed the pop in issue by running a coroutine to gradually scale asteroids up from 0 to 1 as they were spawned in, but the difficulty and asteroid placement proved to be a bit more difficult. I tried adding some pre-existing asteroids which improved things a bit, but I think if I’d had more time I should have:

  • created some more larger static obstacles,
  • created more asteroid spawn points to the sides, shooting asteroids across the player’s path
  • had the target planets move around instead of sitting still


User Feedback and UI

Many of the comments so far have been along the lines of “the controls stopped working”. At first I thought this was a weird bug I hadn’t seen, then I realised that it was probably related to one of the game mechanics I’d implemented.

So that players can’t just mash the controls non-stop, the rocket has a limited amount of fuel. The idea was to make the player chose between getting hit by an asteroid and running out of fuel by moving too much. (Move around too much and you lose the ability to manoeuvre).

On realising that players were thinking of a game mechanic as a big, my first reaction was in truth a bit defensive…

well, it mentions fuel on the first screen and there is a fuel bar on the GUI, so it should be obvious, right? RIGHT?!?!?!!?!”.

Then I realised that the comments were actually letting me know that the game mechanic was a bit too obscure. To be “intuitive”, every important player action in the game needs to have visual or audio feedback.

It wasn’t enough to hope the player read three paragraphs of text, or noticed a small fuel bar in one corner of the screen – I needed flashing text, colour or sounds to notify the user they were about to run afoul of a crucial game mechanic.

This is even more important in something like Ludum Dare where players may only spend a minute or two with your game.



What I learned

To summarise, there were two main lessons for me from this Ludum Dare entry:

  1. Don’t get defensive about feedback – listen to what the players are saying, and try to work out why they are saying it.
  2. Audio and visual cues are critical for communicating game mechanics.

I enjoyed the weekend a lot, and I’ve been playing and enjoying some of the other entries. Bring on the next Ludum Dare!

Last weekend (May 29th – May 31st) I participated in Mini LD #59 with four of my acquaintances from reddit. This is the first time for me to participate in a MiniLD as I am usually a full LudumDare Compoplayer. MiniLD usually runs for more than two weeks, but since we all have time commitments to other things in life we all decided to jam it out on its last weekend.

All of us originally met on gamedev reddit and started a gamedev text chat on google hangout where we often talk about games, show our progress what we have been working on in our spare time, share and exchange ideas etc etc. Its a lot of fun to hangout with like minded people.

Everyone in our group appreciated the MiniLD #59 theme which is basically swapping your sprite sheet with someone else’s before submitting the game. The demo sprite sheet was released on the website, which introduces us to the dimensions and layout of the sprite sheet we needed to create. The impact of this is that you have no idea how your game is gonna actually look like until the end. For e.g; you might have created a sheep in your game and it may get replaced by a turtle or spikes or a blank tile or anything else that you cannot even imagine of. This makes the game design a little more challenging because the game should not be art driven. We cannot rely on a certain style or objects with specific representation and let it drive the gameplay. We have to make sure our game will be understandable and playable even after replacing the sprite sheet with a random one.

We started our 48h game jam around 9:30PM on Friday (May 29th). Everyone was equally motivated and determined to deliver a finished game by the end of 48 hours. We used google hangout as our primary communication tool since all of us reside in different towns and cities.


The Beginning

Like any other game jam we began with a brainstorming session that lasted for an hour or two. We discussed few game ideas within the limits of the sprite sheet layout as it was an obligatory to follow the standard. We also discussed our skill sets as it was our first time working with each other. To comply with the theme (Swap) we settled on a mechanic that that will allow the player to swap their position with any other object in the world provided the object is configured as swappable. We also had this notion that the player has somehow acquired a super power that allows them to slow down time and swap any two objects in the world provided the objects are configured as swappable. For e.g. if an AI unit is shooting towards the player, they can swap their position with another object in the world in order to dodge the incoming attack. Cool, right? Everybody liked the idea and the work began.


  • Whats the setting of the game? we don’t know.
  • Whats the purpose of the mechanic? we don’t know.
  • How the game will be played? we don’t know.
  • Whats the win or lose condition? we don’t know.
  • How the player will progress in the game? we don’t know.
  • Is it a puzzle or a brawler or obstacle avoidance? we don’t know.

We never bother to ponder long enough on these questions and left those unanswered and this is exactly what bit us hard in the end (IMO). Not having a clear vision about what the end product will look like kept us unproductive from time to time. We often question each other about the kind of game that we are trying to make.

Work Distribution

Stephen was working primarily on the art assets and also learning how to make music using Reaper at the same time. He came up with this cool business man looking dude and other assets in the game. Here is our sprite sheet that we submitted. Hopefully someone is using it :)


Zach was our main sound guy. He started pumping out awesome loops within two hours using his big stack of musical instruments. Listening to those kinda makes me feel like making a game similar to Audiosurf. He was also involved with level creation and contributed to art as well.

John, Larry and I was mainly working on programming tasks.

John helped us in overcoming all of our git nightmares.

BTW, Larry loves drawing on people’s faces. See what he did to my face 😀



As we set sail into the development, we had some intermittent discussions about the overall look and feel of the game. The style of our game was completely dependent on the art direction so we had to stand by a little before we had some mockups. Once we had those we came up with the style that the player will play as an angry office worker. An angry office worker who somehow acquired a super power that allows them to swap positions of two objects in the game world. The player will then have to disrupt a normal working day and wreak havoc in the workplace that they hate completely.

By this time, we had a somewhat clear idea about the type of game we are working on but we were also a little ignorant about the way the game will be actually played. We continued working on these smaller game mechanics (while not paying attention to the overall bigger picture) that we hoped will come along nicely in the end. When most of those individual components were ready, I personally had a lot of trouble giving all those features a purpose that may or may not constitute a game. At this time I knew that we are quite behind in our deliverable. We stayed focussed and tried to push it through as much as we can but unfortunately it all fell apart in the end. Our first level was incomplete in many aspects and there weren’t enough art assets ready to populate the level. Clock kept ticking and only 4hours left to submit the game. It was then I proposed that we must call it off and accept failure :(.

Technical Problems

Unity3d and source control don’t like each other, at least from my experience. Often times we were facing problems with merging each others changes and losing library references every time we try to pull new changes from the repository. The solution wasn’t straightforward and every time this happened we either have to search the entire scene for the missing references, fix them and push it back to the repository or stash our local changes, pull the latest commit from the repository and redo all the changes. This was getting annoying and it wasted a lot of our precious time.

The End

This is the second time I failed in a game jam. At least we tried.

“Trying and failing is better than not trying at all”

It was a bit disappointing that we were unable to produce anything after spending 48h on it. But again:

“If you have never tried, you have never learned”

And we definitely learned a lot of new things in our quest to make a game in 48h. This learning is not only limited to the game development or third party unity plugins that we used in our game, we learned about each other, the dynamics with which we work, our interests and familiarity with variety of tools and tech and everyones thought process. This will definitely benefit us in our next undertaking.

A screen capture from our incomplete game:


Till Next Time!


Skull Bomb Post Mortem

Posted by
Tuesday, April 21st, 2015 6:46 pm

Cross posted from my blog at

I did my first game jam this weekend! I participated in the jam portion of Ludum Dare 32 and made a little game called Skull Bomb (play it here). The theme was “An Unconventional Weapon” and after it was announced I brainstormed a bit before settling on ‘blowing yourself up’ as my interpretation of the theme. I didn’t want to have my player character blowing up other humans so I decided to make the game about a world taken over by evil robots. This also worked in my favor that I didn’t have to program any sort of realistic AI.

I’ve been really wanting to do a Ludum Dare since I learned about it but being a dad, having a job, etc always seem to stand in the way of coming up with 48 uninterrupted hours on the jam weekends. This time I decided to not let that stop me and jammed in the hours after my kids bedtime, for a total of maybe 16 or so hours over the 72 hour jam period. I’m really glad I did!
What went well:

I made a game! Not waiting for the perfect moment and the planets to align allowed me to actually make something.

I scoped correctly. I picked a topic I was able to finish in the time I had without crazy crunching.

Used Unity 5. That went well, Unity ran smoothly, few crashes and weird bugs. I think it crashed once.

Using Unity’s Navigation for AI. Setting up the enemy units as Navmesh Agents worked great. I made an array of destinations and selected randomly from that to get enemies moving around un-predictably. Easy and effective.

Simple Sound Design. I added some spooky synth drones that I made with Logic X’s built in Sculpture synthesizer. Sculpture is a physical modeling synth and I love the timbres you can get out of it, I thought they set a good, ominous and abstract tone for the game.

Narrative via Voice Over. This was probably the best received aspect of the project. I wrote a simple voiceover script describing a dystopian sci fi world overrun by machines and laid out the players mission. I had my girlfriend read this and did a bit of editing and mixing in Logic. Details I was happy with that people commented on as well were the cut-up phone maze style strings of numbers that added to the overall dehumanizing atmosphere. Using a voice over was cheap and easy (maybe 2 hours work to write, edit, mix and implement) and added a whole narrative layer to the game that I thought was very effective. Because it ran in the background at startup it allowed the player to experience the narrative without having to wait, read or otherwise be delayed from experiencing the game play. Several people commenting on the game remarked on how well the voice over worked so that was definitely a high point.

New Genre/Mechanic. I’ve never tried to make a stealth / sneaking style game and was quite happy with that aspect of it. I definitely learned a lot and enjoyed working with the form in a short format. This is perhaps my favorite aspect of jamming, the chance to try out different genres or ideas in a short form, low stakes way and get feedback.

Art Style. The art style that I chose was simple, minimal and achievable. I was happy with the result and felt like it worked well with the theme. I got a few nice comments on it so I consider that a success, especially since I consider myself a non-artist. I also got pretty close to my initial ‘vision’ visually.

Getting Feedback / Iterating. By posting the build a few hours before the deadline I got some very useful, maybe critical feedback about playability, controls and clarity. This included a lack of clarity on where to go which I tried to address and not locking the mouse cursor which lead to issues in browser based play. Catching these early was good. I’ll definitely aim to do this in the future, getting those little bits of feedback before finalizing was great.

What went poorly:

Level Design. Several people commented that they wandered around, didn’t know where to go, couldn’t find the goal. The way I laid out the level had no clear (or unclear) path through it, it was just a big box. After getting that feedback I added a moment in the beginning where the player falls from high up and gets a chance to see the black box that represents the server. In hindsight I really gave the player almost no clues as to where to go. I even was considering initially having the monolith change it’s location each time player spawned to add replayability and difficulty. I realize now that that would have been a mistake.

Difficulty. The difficulty was very inconsistent. Sometimes the enemies randomly left big clear paths, sometimes they created impossible, inescapable situations. With more time or better planning I would have set up some more carefully planned routes for the AI to patrol that interlocked, created gaps etc. As Twitter friend @ChrisLaPollo points out though that these are the types of things that you learn in making a jam game and can polish up after.

Browser Support. Annoyingly Google Chrome dropped support for NPAPI plugins right before the jam breaking support for Unity Web Player. The game played fine in other browsers but this was just kinda annoying.

Control Tuning / Playtesting. Several players complained that the movement speed was a little slow. I actually bumped it up a bit but probably could have taken it up a little higher. More playtesting earlier probably would have helped this but given that I was jamming on my own in my apartment I didn’t have local playtesters available. In the future I’d like to try and jam with a team and / or at a space with other people. I think this would have helped a lot to catch this and some other issues before posting.

Play the game here, or watch a video below:

Into the Shadows Post-Mortem

Posted by
Saturday, September 13th, 2014 6:00 pm






Our game:

What Went Wrong:
– We started with 3 people and good ideas, but the ideas proved to ambitious and 1 person quit, so we only really started after about half the time had already passed.

– A lot of people thought our game was too hard. We can both beat it easily, along with a few other people, but most people struggled with it.

– The game is pretty short, which is partly why we wanted to make it so challenging. We didn’t end up with enough time to make the entire game that we had planned, so we had to settle for limiting the game to one area, instead of implementing a whole story with multiple areas.

– We didn’t have time to make custom audio. The sound effects actually turned out pretty well (we didn’t make them ourselves), but there was no music. For our game from the last competition we had time to make an entire custom soundtrack with multiple tracks. Here is our last game if you’re interested:

What Went Well:

 The game is pretty well polished. Despite not being able to complete our entire idea, when we realized that we wouldn’t have time to add much more, we dedicated the last few hours to polishing what we already had.

– The mood turned out very well. We added flickering lights and eerie sound effects that really contributed to the creepy mood of the game. People have said our game is scary, and we’re glad to have been able to achieve that with simple looking enemies (shadows) and without adding any gore.

– Despite many people thinking it was too hard, we think the game mechanics themselves were actually pretty innovative. Many people did games with the idea of pressing a button to go into another world, but our game has a bar that shows how far into the other world you are and if it fills up you lose. This, along with the flashlight mechanic that drives the shadows away, makes for very interesting and unique game-play.

– There is a Nick Cage Easter egg somewhere in the game.


The Future

We had a good idea for this game and it turned well, but we would like to release a post-compo version sometime in the future. This would include many more areas and possibly some of the story that we didn’t add. The difficulty level would also be changed. Many people thought that the flashlight didn’t do much to stop the shadows even though it actually slows them down considerably. Therefore, we’ll try to make it FEEL as if the flashlight does more and possibly make it actually do a little more. With a bigger game we could also have more progressive difficulty, so that people would get used to using the flashlight in easy areas before it got to difficult. We’re also planning to add many other features like lit-up areas that would act as safe-zones and a lantern with limited uses that would drive away shadows if you are surrounded.

Praise the Sun!

Our first jam

Posted by
Wednesday, April 30th, 2014 10:48 am

Well this was unexpected


This is my first completed Ludum Dare jam and this time I did the incredible choice of teaming up with some friends.

Me and Samuel (Blixt Gordon here on Ludum Dare)worked tirelessly on the game for the first two days on the game Surf Ace. I have heard that finishing a Ludum Dare

game was something really hard and that we should keep the ideas streamlined and simple. F**k that we thought lets to a game where

you can not only surf and flip (which to be honest, would have been awesome!) but also catch fish on a spear and then ride it.

“Oh brains you are fantastic creatures” – Me

I had my hesitations about the completion of this game up until the last day when one of our friends came to record the hilarious sound effects and another friend

helped out on the fiddle to create the track for the game. This all took place in the last 5 hours so you can understand my concern.

The last hours was by far the best part of the development when we had the game ready and just played around with the details.

That is, right until we figured out there is no tutorial to our game and the controls are unique to our game so it was a must.


As you probably have figured out by now it went splendid, we got a good game out of it and most important. We had an awesome time making it!

If you have read until now, here is a potato for the long post (had a lot to say I guess).


Sincerly mrhill






Post Mortem: Chrono Blood Ninja!

Posted by
Sunday, September 8th, 2013 1:33 pm

Well it’s about time I got off my ass and did a post mortem. I won’t bore you with too much of an intro, so let’s get right to it!

My Entry:



  • Super motivated and minimal fatigue
    • Coding always puts me in a super conscious state where nothing else seems to  matter, but it’s surprising how little fatigue I felt over the 48 hours.
  • Got collision and controls dead-on
    • I spent the larger part of the first 24 hours on this and it was totally worth it. Everything from that point on is a walk in the park as long as I don’t need to go back to re-adjust the basics.
  • The tileset is literally a 16×16 black square

    • At first I thought I should use a placeholder and worry about it later, but turns out the black on white actually looked great(got even better when decorated with blood). This saved me countless extra hours that I now wouldn’t have to spend on making tileset and background!
  • Blood on black is too awesome
    • I thought about implementing some blood effects 36 hours into compo, and it instantly became the defining feature of the game. The blood particles synergized so well with the black tiles that I puked rainbows from my mouth just looking at it…
  • Nothing went as expected, and everything worked better than expected
    • I went largely without a plan and decided on directions as I go. Yet the end result was at least 10 times more fun than anything that I had imagined in the first hour.





But, alas…


  • Music. Is. Horrendous.
    • Not sure what I was thinking. It was totally a “screw it” moment. It was 8 hours left before the end. I was just starting to get tired. I made the music 30 minutes ago and I thought, what the hell, it’s not that bad, couldn’t make anything better anyway, it’s better than nothing…… NOOOOOOO D:  D:  D:   Shitty music is NOT better than nothing…. D:
  • Wasted at least 8 hours on procedural map generation code that I didn’t use
    • I had decided to use procedural generation because it would make the game indefinitely re-playable, while not having to spend time to manually produce content. That was not the mistake. The mistake was that I tried to do some complex generation code which is horribly difficult to get right, and worse, generates maps which ARE NOT ACTUALLY FUN TO PLAY. I wasted 8 hours on this, and in the end I scrapped the whole file and went with a brain-dead basic platform generation code that I wrote in 15 minutes.
  • Lack of incentive for player to get better
    • As it is, you basically beat the game if you are able to survive indefinitely. That is, if you are able to kill fast enough that your clock counts upward, not down. The problem is that there is no incentive for the player to want to get good. They play, die and stop playing. I thought about adding a boss level but was reluctant during the 48 hours, as I did not have a very good idea of how to make the boss fight fun to play.
  • Lack of menu and restart button
    • Not having a restart button was actually very silly. When I finally got around to it post-compo, it actually only took 3 lines of code… THREE… to implement it. And one of those lines is a ‘ } ‘. The menu on the other hand is something I never learned to make. At the end of everything I had 8 hours left, but I was tired by then and felt it was good enough as it is.





Finally, some principles that I followed, and some that I aught to follow in the future:

  1. Don’t make plans. Build up series of interrelated ideas on the go.
  2. Don’t make a game that you just want to make. Make a game that you want to play. 
  3. Only decide how to implement the theme once you have at least half a game.
  4. Make sure the end result will be fun before digging into that large new feature.
  5. If it obviously sucks, for the love of god don’t leave it in!
  6. And always, always make the player awesome.  



In all, I think it was a really good result for a first Ludum Dare! I managed to finish a game that I’m happy with on time, and it was so much fun!

The first post-compo is already out and there will be more to come. Boss battles and game objectives will be the priority now… Here’s a boss sprite to entertain you while I figure out what he does!


[cache: storing page]