Ludum Dare 36
Coming August 26th-29th Weekend

Suggest a theme!
Theme suggestions for LD36 now open

Posts Tagged ‘unity’

Post Jam Update… SPEED BLOX VR!

Posted by
Friday, April 29th, 2016 11:49 pm

Hey there Daredevils!

We would like to thank you for your feedback and
taking the time playing our game!

A few changes are up:

  • One of the most common complaints was that sometimes
    the ‘Cool’ Blox obstruct the view of the oncoming ‘Angry’ Blox.
    Now, all Cool Blox become (semi) transparent once you look at them.
  • Music!

Have fun tripping across space-time!

Check out our game here!

Download it here!



84 votes for “Breaking Fat”

Posted by (twitter: @SantiHisteria)
Thursday, April 28th, 2016 5:12 pm

Thank you so much guys… we go for the 100!! :)


Play “Breaking Fat”

Post-Jam Version Of My LD35 Game Is Up

Posted by (twitter: @xanjos)
Wednesday, April 27th, 2016 4:51 pm

Seeing as a lot of you are having trouble with my LD35 game SHAPE.SHIFT() (because of its supposedly challenging difficulty), I’ve decided to put up a (WebGL build for the time being) slightly easier post-jam version that’s more forgiving in terms of distance between obstacles and the time needed to react to them but should still pose a challenge (Of course for rating purposes/bragging rights, the original “super hard” version is still available on the embed link on the main game page as well as on the and GameJolt pages).

In other news, my game currently has 59 votes and could probably do with some more:


Anyway, if you have yet to try out my game give it a play/rate by clicking here. You can also check out the post-mortem for the game by clicking here and to see my previous post on how to get a good score in my game (which mostly applies to the original version), click here.

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.

Robot Escape – Post-Mortem

Posted by (twitter: @rjhelms)
Wednesday, April 27th, 2016 4:47 pm

We did it again, folks! I’m buried in a mountain of great games, and figured I’d take a few minutes from trying to dig my way out to write up a post-mortem for my Ludum Dare 35 entry, Robot Escape.

title screen fullsize

This was my 5th Ludum Dare, and all-in-all I think things went pretty well. After finishing in time for the compo in LD34, I really wanted to do so again, but circumstances conspired against me this time around – oh well. I’ll explain in the “What went poorly” section.

What went well

  • First and foremost, I had fun, and made something I’m pretty proud of.
  • The core mechanics of the game – restricted lines of sight, and reconfiguring yourself to get around different obstacles – worked out really well, both on their own and together.
  • I’m getting really comfortable with my Ludum Dare tool-chain. In the past I’ve always lost some time farting about with Unity’s quirks, but this time everything went pretty darn smoothly.
  • In the same vein, a lot of what I spent time on in LD34 served me well as techniques I was able to reuse this time – in particular, I was able to just drop in the two-camera setup for an “authentic” retro feel I developed that time, and (as predicted) my level loader from that time around was clean enough to reuse – although my level-loading needs were a lot simpler this time around.
  • I experimented with keeping my code a bit cleaner by having a lot of my entities be pure C#, with only a handful of MonoBehaviours responsible for interacting with Unity. I’m not sure I did it well enough to be a reusable approach, but for a game like this it worked really well.

What went poorly

  • I started really late. I have the nasty flaw of being a gigging musician, and the band always seems to find ways to need my time during Ludum Dare. This time around, we were playing a gig out of town on Friday, so I completely missed the theme reveal and didn’t make it home until about 4am. I took a look at the theme as soon as I got home, but didn’t seriously start the clock, so to speak, until around 11am on Saturday. (The gig went really well – it’s only a “went poorly” item from a Ludum Dare perspective.)
  • I lost another two hours to a power outage on Saturday evening. Thankfully, I didn’t lose any work as I’ve got a UPS for my computer. It wasn’t a total loss, however, as I took some time to do a bit of planning on pen and paper by candlelight.
  • I didn’t get the controls right. This seems to be the biggest pain point people raise in the comments on the game, and I agree – I had planned to take some time to tweak them, at minimum, and ideally make them configurable, but I didn’t make it there before the deadline.
  • I wanted more/tougher enemy types, but only had time for two. Similarly, it would have been nice to have a bit clearer feedback about when the enemies were firing on/hit the player.
  • It took a concerning about of time for this game to actually be fun – any beginner’s guide to Ludum Dare tells you to make sure your core idea is fun as quickly as possible, but mine didn’t really get there until pretty late on Sunday.

A more detailed run down of the jam follows below the break – but if you don’t want to read that, why, you could always give the game a try and let me know what you think!



Posted by (twitter: @Oli_mus)
Tuesday, April 26th, 2016 6:52 pm
Play now to The Experiment!
The Experiment is a weird game.
A simple, short and easy game.
A game that anyone could make,
but so far no one had done… until now.
It isn’t a game for anyone!
You hate him or love him.
I challenge you to enjoy it as I have enjoyed making it.
Welcome to my world.

Are you ready for “Breaking Fat”?

Posted by (twitter: @SantiHisteria)
Tuesday, April 26th, 2016 3:35 am

Some people say that it is an overly difficult game… Others say it is frustrating… Very few people have been able to finish it… but you… ARE YOU READY TO COMPLETE “BREAKING FAT”??

Stop cry and retry it again!! Do you remember the classic old games? They didn’t let you try and re-try the same level until you win… so demostrate you are a winner!!! 😉

You can play it here… GOOD LUCK!


Fight against evil doctor to break the curse and get back your original body!! If doctor’s minions touch you, you’ll be one of them and you’ll be much slower in this moment… but not all is lost… you must find the gold key to scape.

A story about evil enemies, curses and metabolism changes…


Be quickly… be one of them… and escape!

SHAPE.SHIFT() Post-Mortem

Posted by (twitter: @xanjos)
Monday, April 25th, 2016 10:05 am

I’ve just written up the post-mortem for my LD35 game SHAPE.SHIFT() which you can view by heading straight to my blog.


To see my previous post on how to get a good score in my game (because apparently it’s ridiculously hard), click here and if you haven’t tried the game yet, give it a play/rate by clicking here.

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.

Mushroom Muncher: Environment

Sunday, April 24th, 2016 1:53 pm

Click on the image to play!

Hello everyone, Luka here from Kuality Games. Here’s a small post if you’re wondering how we made the environment for our game, Mushroom Muncher. I will be focusing on the texturing part that I did, by just explaining the basics.


First of course, we started off with the basics in Unity. Our designer Rafael set up a basic white-box of what was to be our main level in the game. Since we had time constraints because of the jam, we simplified things and decided that our level was supposed to be an arena where enemies would attack the player infinitely. This also reduced the amount of level design we had to do, as well as art assets. At this stage we had the basic level layout and overview of object scales/sizes.


First white-box of Mushroom Muncher arena.



Most of the environment work was done through texturing. I decided to try Substance Designer for the first time and first thing we did was prepare base materials for our environment. Plan was to finish up materials at first and then apply them to the environment meshes that we would model, in Unity. This approach can be different of course, from the traditional “Model it, Fix the UV, Texture it in Photoshop/Gimp”. It didn’t seem like this approach saved a lot of time, but it did give us a lot of control and flexibility in terms of randomizing the look of textures in the game. By using substance materials, I was able to easily blend textures together and instantly randomize the look of Stones, Rocks and Dirt as well. So once the base materials were finished, I started to blend them together in Substance Designer and also exposed a lot of values that made it possible to edit materials in Unity, here’s the example of this:

Procedural texture properties (Unity's Inspector window)

Procedural texture properties (Unity’s Inspector window)

Here we can see couple of options where we first start off by choosing the surface (Ground or Cliff for example) and then we can start tweaking individual properties. You can see the example of this at work below:

Randomized Rock material - clean.

Randomized Rock material – clean.

Rock material - with dirt.

Rock material – with dirt.

As you can imagine tools such as Substance Designer in this case can be extremely powerful, for both big and small projects. I would recommend any game developer to try them. Here’s another example:

Stone- clean.

Stone- clean.

Stone - with striation.

Stone – with striation.

At this point base materials were done and they were ready to be used in Unity. Learning and preparation took most of the time, but it was worth it as at that point I could produce random and unique texture for our environment in matter of minutes.



This part was rather simple. Our artist Jenny first sculpted the base rocks in Zbrush, after that moved them to Maya where the low poly meshes were made and some Zbrush decimation errors were fixed. As a last part, she UV-mapped the rocks and exported them to Unity. Applying materials and assembling the scene was done in the game engine.


All of the base meshes we used in the environment including the ground sculpt.

In Unity:

After the meshes were prepared, we had everything ready in order to assemble the arena in Unity. Even though we had the ground sculpt prepared, we had to scrap it and go with the flat surface in order to avoid some of the gameplay problems we were having and particles intersecting with the ground. There could have been much more done about the ground, but in the game itself ground texture tiling wasn’t that visible and it didn’t make much of a difference in the end. We added some extra props quickly in order to make the arena a bit more interesting as we were running out of time.

Shot of the arena from the side.

Shot of the arena from the side.



It was very interesting to work with Substance software for the first time and approach things differently, that is why I would recommend this to any artist/game developer out there. We did face some problems such as these procedural materials increasing the loading time of our game significantly, but that was due to bad optimization of these materials by me in Substance Designer itself. Even though optimization can help, these materials can still be quite heavy so that is something to consider.

In the end what we managed to create in three days still looks nice and doesn’t mess around with the gameplay, so I would consider that a success. If you have any questions feel free to ask on Twitter: @KualityLuka. You can also find us on Facebook.


Transformagician – Performance Optimization

Posted by
Saturday, April 23rd, 2016 3:16 am

The jam is over, the entry turned out great and the WebGL build (which most people are going to play) runs quite badly. What to do? Optimize!

Identifying the problem

When trying to improve performance you should always go for the elephant in the room. In most cases taming the alpha male is enough (including this one). Run the profiler on the target build and see what is up (milliseconds) and what is down (framerate!). Let’s look at the rendering performance of the following scene.

Image 1: Benchmark scene

Figure 1: Rendering performance in Unity editor

Not bad! The deferred renderer does a pretty good job at batching drawcalls.

Figure 2: Rendering performance in WebGL build

Very bad! The WebGL build seems to fall back to forward rendering before a deferred lighting pass. Maybe this is why the batching is botched, I’m not quite sure, but there most certainly is a drawcall problem.

Solving the problem

One solution immediately springs to mind: Mesh.CombineMeshes. After some modifications the script works like a dream.

The walls in the scene are combined into a single mesh and the floors into another. As long as all the meshes share the same material there will be no trouble and the combined mesh looks just like a bunch of individual objects.

The only difference being a drastic reduction in draw calls. Let’s see just how drastic we’re talking about here:

Figure 3: Rendering performance in editor (with MeshCombine)

Mere three times faster… I think we can do better.

Figure 4: Rendering performance in WebGL build (with MeshCombine)

Fifteen times faster! I rest my case.


Use the profiler, identify the worst offender, smite it and rejoice. There are further optimization I could do, but why bother. At this point it’s already an effort in diminishing returns.

Getting less than 60 frames per second? Time to look in the mirror and get to work!

Post-mortem ultra combo!

Posted by
Saturday, April 23rd, 2016 2:29 am

I’ve not done a postmortem since #27, Deadline so I thought I’d include my streak of failures from 28 to 34 as I finally broke the streak!

28 – You only get one: I had decided on a turn based battle game, and got a day or so into it and ended up getting sick. This was the first LD I had made that used the pathing system I wrote.

29 – Beneath the Surface: My usual libraries were in a big state of disarray as I ported everything from XNA to SharpDX11. I think I made a character walk around and that was about it. The idea I had was to lead an earth cult where you dig deeper to gain power, but I had no idea how I was going to do the digging part.

30 – Connected Worlds: I went through several ideas and never got anything playable. Full details.

31 – Entire Game on One Screen: Kind of a tricksy theme for us 3D folk. I’m fairly sure I worked a bit on a game called DeathBall where a ball bounced around a level and you had to avoid it. I was very rusty and didn’t get very far as I hadn’t been coding day to day for awhile.

32 – An Unconventional Weapon: Was very prepared for this one and had my libs beaten into good shape. I had this really serious story about an ultimate weapon shattered into pieces by a Goddess that you had to recover to help an overthrown king. I had planned on the final confrontation making the weapon do something silly like turn enemies into chickens.

I had just written a new physics system and it was a bit dodgy and difficult to use. That plus making my first map outdoor – an approach to a barbarian village – means I quickly burned up all my time just getting something running. BSP maps are notoriously difficult to make for outdoor areas, and I had all the usual problems.

33 – You are the Monster: Was in the middle of adding terrain to my libs so they really weren’t in any shape to make anything with. I grabbed Unreal and started trying to use it and got very very confused. Trying to make something over a weekend with middleware you’ve never used is pure madness, but I learned a lot. I don’t even think I got as far as trying to do something for the theme, I think it was just “how do I make draw something derp”.

One huge issue I had that weekend was every now and then Unreal would flip out and do a full build. That took 2.5 hours on my old machine (I have it down to 25 min with my new one).

34 – Growing: For this I started in Unreal, and was a bit more familiar with it this time. I settled on a top down slasher game with loot that “grows” as you gain XP. I had basic move and attack going but hit a wall with unreal’s UI system. I was determined to use C++ for it and it led me down a bad bad rabbit hole. In another spot I forgot to call the base class on a virtual and it led to some really really strange behaviour that took hours to figure out.

35 – Shapeshift: This is the first LD that I’ve ever thought about themes ahead of time. In the past I had always heard Yoda in my head saying “Clear your mind must be!”, but this time I told Yoda to bugger off and thought up a few ideas for each of the top themes.

For Shapeshift I had the dead obvious idea of an RPG involving Lycanthropy. A simple quest to retrieve the “Chalice of Life” would lead to an accursed monastery with doors that would only open for one with the curse of a were-something.

Things that went well:

Unity was a good choice. It flipped out on me a few times but was solid overall.

Code! I’ve been programming full time again so code flew from my fingers.

RPG stuff I’ve been really into lately so the stat/item/buff/combat code was quick.

Music: I made 3 pieces of music with Bosca Ceoil, only one of which I ended up using but I couldn’t stop playing with it. Really fun to make stuff with.

WebGL! My first ever web playable game! I know many LD folk hate running exes.

Fun! I had a blast making the game and I’ve pined all week to work on it more while doing my regular job.

Things that went not-so-well:

A storm knocking the power out.

Click-to-move: When I got fighting working, I remembered why I don’t really like top down click-to-attack games. They kind of all suffer from missclicks, where you miss what you were trying to attack and end up moving instead. The movement makes you miss again and again and you just end up walking stupidly around the enemy while they are shiving you in the kidneys.

I spent a bit of time looking at Torchlight 2 (omg what awesome music), and totally ripped off how they handle clicks and click holds and their shift to hold position thing. It makes it a bit better but I still think click-to-move is rather flawed.

UI: Just getting a health bar going was difficult. I ended up watching one of the Unity training videos to puzzle out the UI system. It was really confusing and I hate watching videos to learn stuff, and much prefer a blog post I can skim through.

Ultimately I didn’t get an inventory gump in, which is really vital for a slay & loot festival like this. Especially frustrating when you can see you are picking up tasty treasure and you can’t use any of it.

Comas: The main problem I’ve had in this jam and all the past failures has been tiredness. Even a frugal meal can often send me spiraling down into a food coma. After it kind of wrecked my weekend efforts I decided to try a ketogenic diet. Hopefully I’ve stuck with it and the next time I’ll be in better shape for long sessions.

Super Shapeshift Bros – Postmortem

Posted by (twitter: @comanche_ak)
Friday, April 22nd, 2016 5:24 pm

I’m thinking about adding the game to the Steam Greenlight program. So that’s the features that will be in final version:
1) Changing the engine (It will be Godot Engine);
2) AI for single player campaign;
3) Network Multiplayer;
4) More customizeable stuff (Faces, hats, textures, etc);
5) Add other figures;
6) Level editor for community;
7) 4-8 player mode;
8) Dynamic camera;
9) Larger arenas;
10) Add jump button;
11) More arenas;
12) You will contol your figure while flying.

Ok, 72 hours were hard for me but I’ve finished my game. It’s not exactly what I wanted to do, the first idea was to make a platformer with controls like in Super Shapeshift Bros. The plot was about 3 different types of tribes: right -angled triangles, squares, and pentagon people; The new type of shapeshifting virus attacked these tribes and they have started to lose their shapes and angles. The main concept was like The Legend of Zelda: Majora’s Mask – the player can transform from one type to another (from triangle to square, for example), so the main character (The Triangle) like Link – the chosen one, who can fix the problem by finding the Mighty Circle.


When I’ve started makimg a prototype I added the second triangle and tried to play with it. Few weeks ago my wife gave me a present for my birthday: it was Nintendo WiiU with two games – Super Smash Bros and Splatoon. I’ve played Splatoon a lot, but SSB was only for parties. So I thought that it would be cool to make this type of video game. Competitive game for parties.

Running on TV

I thought about differences between a triangle and a square. The mass was the first. Triangle can simply rotate at high speed and it can be rotated by player. Square can be rotated only by a physical impulse. That was great to use this feature because you can use shapeshifting to stop at any horizontal point you need. Square can also push the triangle, and after that, the other player can lose the match.


Two players one one gamepad

The big problem was Unity Engine and its Input System. All three modes for two players should not be a part of one mode but Unity Input System is awful so when I’ve added new mode, the old one didn’t work. I’ve decided to make all-in-one. I’ve also cut 4 player mode because of time.

Standard GIF

The art style was chosen to be cute and funny, the primitives do the job very well. Faces and most of art were made by hope42morrow for the first concept but his work fits well for now. Music was written by me on Nintendo 3ds system. Levels are not really good for now. But people liked TRIANGLE OF DEATH arena which is not quite triangle.

Скриншот 2016-04-23 01.14.48

Thank you for playing the game! It’s great that one of my dreams come true!

Here is the video showing how to play the game. It’s in Russian, but you can understand the basics without words.

You can play and rate the game here.

Ludum Dare pro tips: polish up your Unity builds

Posted by (twitter: @rjhelms)
Friday, April 22nd, 2016 12:31 pm

We see a lot of Unity games every Ludum Dare. In the past, I’ve heard some griping about this, but let’s face it: Unity is perfect for game jams. It has its quirks and limitations, but when time is of the essence, you can’t beat a platform that’s easy to work in and lets you forget about the basics, and jump right in to seeing your idea in action.

However, this can be a bit of a mixed blessing: because Unity handles so much for you behind the scenes, there’s a few steps that are easy to forget about when it comes time to package up your game and submit it, but which go a long way to polishing up the impression your game makes on people rating it. Unity’s gotten a lot better at handling these things in a sane manner, especially with version 5.3, but it still benefits your game to give things a once-over.

If you’re not using Unity, feel free to ignore this post, but if you are – read on! I’m mostly going to be focusing on standalone builds, but it’s a good habit to get in the practice of thinking of these things even when you’re intending on making a web game.


Transformagician – Postmortem

Posted by
Thursday, April 21st, 2016 11:32 pm

JUST A GIF! A small one this, tiny!

Play it here!

or read on.

Many earth shattering revelations await you.
(Hyperbole is the best medicine after a long jam)


LD is usually my solo jam, but this time I didn’t work alone. Ranquil created the graphics (you can read more about that here) and I, of course, programmed the lot. My last team LD was a disaster (my bad on many levels!) so I’m glad this one turned out well, really well in fact.


A few Ludums back I had an idea about shapeshifting. Stealing a top secret prototype from a well guarded research lab, avoiding detection by masquerading as objects in the level. The AI would react believably to anomalies in the world, including walking furniture. A bit too ambitious you could say.

We went though a few other ideas, but settled on cutting the above design down to manageable size: non-human enemies, a set amount of items and clear AI behavior rules.


As a programmer I’m a fan of not reinventing the wheel, i.e reusing code (i.e. being lazy!). The level generation system is from this past LD gem (look who’s saying) and it was originally created for this project. In essence, twice recycled code. What can I say, it works.

Everything else is custom though. Nothing too difficult or out or the ordinary so in the end we even managed to pump out a build at the 48 hour mark. The final 78 hour version includes improved graphics, a fancy ending cinematic and some gameplay balancing.


The lax jam rules allowed us to utilize royalty free sound effects and music. Fortunately Ranquil knew a few (rather interesting) web-zones full of the stuff. Links in the description.

Music really does elevate the mood to new heights, doesn’t it.


None! I don’t believe it myself, but it’s true. Working in a team for 72 hours does help, I guess.



Try it now!

Robot Escape: Linux and Mac builds now available!

Posted by (twitter: @rjhelms)
Thursday, April 21st, 2016 9:15 am

I’m pleased to announce that the Mac and Linux builds of Robot Escape are now available.

I admit these are only somewhat cursorily tested, so please reach out to me if there’s any problems with them.


Play Robot Escape Here

Protecting Unity Web builds

Posted by (twitter: @lightspeedlucas)
Wednesday, April 20th, 2016 9:05 pm

not this time, thiefs!

Hello! The last time I was in a Ludum Dare my game was a little bit stolen by one of those browser games websites and to this day it’s still there, without my permission. This time I took some precautions! I want to share a very simple way to do it, in case it’s of interest to anyone. (more…)

Lets see how far can you get!!

Posted by
Wednesday, April 20th, 2016 8:43 pm

Are you really good at space shooting games! Well here again my Project for this Ludum dare compo!

Star Shift Journey!!



Can you get Further than Level 5 or 6?? Lets see then, try it out now (and don’t forget to vote, Please!) =D

[cache: storing page]