1 Comment

Week of Awesome II – day 6 (belated)

It’s actually the beginning of day 7 (12 hours left in the competition), but I never got around to this last night.

Stopped in my tracks

Yesterday morning didn’t go so well. I wanted to start work on baking lightmaps in Unity to get some kind of global illumination. The first thing I encountered, however, was that Unity would freeze when I started certain levels from the editor. Work was brought to an immediate halt as I tried in vain to debug this. Was my scene file corrupted somehow? I had recently (the night before) changed a bunch of model import settings needed to generate lightmaps. I started panicking a bit.

I caused some bugs while building this level last night.

I caused some bugs while building this level last night.

Some googling suggested this might just be a script that was caught in an infinite loop. It was hard for me to believe that this would cause the editor to permanently freeze. Surely there would be some facility to detect this in Unity? It wouldn’t be hard – just have another thread running that monitors where or not the main game thread has spent too long in a script’s Update. But that’s exactly what it was. While building my final cutscene the night before I had introduced an infinite loop in one of my scripts. I tracked it down by removing objects from my scene until the problem no longer repro’d. 1.5 hours wasted (though after finding out this could be due to a hanging script, I was able to find the cause fairly quickly). Two helpful reminders here:

  • I was making pretty substantial changes to core scripts – I should have tried out a few other levels periodically while doing this, as that would have narrowed the scope of the detective work I would have had to do
  • I had switched a bit into “hack stuff together” mode, and this bug was basically introduced because of that

Light maps

After getting basic lightmap baked and working, I set about figuring if my additional constraints made this feasible. In particular, I need to be able to switch to a “dark” lightmap when the lights go off in my game. After some poking around, I found a way to do this by setting null lightmaps from script. One problem solved.

Light probes in Unity

Light probes in Unity

I noticed that shadows from my one dynamic light had vanished. Or rather that they only appeared when my character walked under bright static lights (which makes no sense at all). This was the beginning of a 6 hour process of trying to get shadows to work properly. I ended up not being able to. I obviously have a flaw in my understanding of how lightmaps work in unity. Supposedly one directional dynamic light is supported with lightmaps – and it is, sort of. Unfortunately it looks like the final lighting term is (dynamic_directional_light + light_map * shadow_term) instead of (dynamic_directional_light * shadow_term + light_map). The only way I could get my character’s shadow to show up in slightly darker regions of the level was to pump up the shadow strength to full, which made the shadow edges look horrible and caused shadows to appear behind objects.

At any rate, I was about to throw in the towel when I decided to try simple projected “fake shadows”. They were quick to set up and looked decent enough (enough to “ground” the character). So I decided to go with it.

As it was now 6pm, I really doubted that I would have enough time to set up the lighting rigs in all 8 levels. This includes placing lights around the scene, and putting in light probes everywhere to light my dynamic objects. It turned out this process went much more quickly than I had anticipated though. It ended up taking only about 20 minutes per level.

GI with many lights using light maps on the left.

GI with many lights using light maps on the left.

Overall, this is the first really big struggle I’ve had with Unity (getting nice shadows to play well with lightmaps). I also find the light probe placement UI kind of finicky. Other than this, Unity has been an absolute joy to use. Most everything works robustly and works quickly.

I finished in good time and got to work on other polish.


Today I have only minor fixes I need to make to get the final submission ready. So hopefully that will give me time to add some more polish and flourish. We’ll see how far I get! Today shouldn’t be nearly as stressful as yesterday though.

There are some noticeable artifacts in my light mapping, but I’m not going to bother fixing them. I tried various light map settings but they still appear. So maybe it’s a problem with the way my models are constructed?



Week of Awesome – day 5 – When It’s Dark

Today was all about level design. After 3 simple “introductory” levels yesterday, I came up with 4 new levels today. Unfortunately several of them exposed bugs in my mechanics which I had to address … so it’s been a good 10 hours of work today.


There was a new mechanic that I was really excited about adding, but in the end I decided to cut it. It’s just not well fleshed-out enough (both in gameplay and in the visuals implementation) to make it in for this game jam.

Overall, this is what I accomplished:

  • I now track which levels are completed (for unlocking purposes on the main menu)
  • In making level 4, I found a bug in the shooting script and had to fix that
  • I improved the particle effect for the gun smoke
  • Level 5 worked out just fine, done in under one hour
  • Level 6 required some gameplay mechanic fixes. Unfortunately I’ve just discovered a flaw in level 6 that lets it be completed too easily. I can’t think of a quick fix right now, so I’ll have to spend time on this tomorrow.
  • I made the camera track player movement smoothly
  • I finished a level 7, but it doesn’t demonstrate anything terribly new. Again, I don’t have time for another mechanic I wanted to add.
  • I changed the coloration of some of the levels, for more variety. I’ll work harder on this when I try lightmapping this weekend.
  • I added logic to detect some cases where it becomes impossible to complete the level, and I pop up a “reload” button. Yes, there is some “figure out by dying” gameplay here.


Oh! and I now have a title: “When It’s Dark”. Not terribly original, but I needed something.

I’ve published a Unity web player version of the game here:



Week of Awesome – day 4

Forcing myself to end this day a little early (it’s only 7:30pm!) so I can get some R&R and not get too burned out.


Today was reasonably productive.

  • I tried to get svn working with Unity, but in the end I decided it wasn’t worth the time at this point
  • I changed my lighting setup so it’s not so harsh directional. Of course now I’m using 3 directional lights, and running into problems when Unity switches my spotlight to per-vertex instead of per-pixel. I’m hoping to be able to bake my lighting eventually, but we’ll see.
  • Saved some space by shrinking textures. Changed the material color for the main character
  • Changed some gameplay dynamics
  • Put in “level title” functionality
  • Wrote down very detailed steps on what meshes are required and what I need to do to them in Blender, so that they work nicely with my Unity game objects.
  • Made a simple GUI for when you’re in the level and need to return to the main menu, or reset the level.

So now I basically plan out the level on paper, and then start building it in Blender using my checklist. I’ve built the first 3 levels today, and It’s taking about an hour to create each (plus the time to fix bugs I encountered).

Blender workflow

Blender workflow

I’ve got some decent ideas for the next few levels. Hopefully in the end I’ll have around 8. Will I be able to get them all done tomorrow and then just work on polish? (And perhaps release a build).

Unity workflow

Unity workflow


Week of Awesome – day 3

So day 3 has come to an end, and still I haven’t begun level design in earnest. Oh well!


I still have some new games mechanics to flesh out, but I’m worried the levels won’t be interesting enough. At any rate, here’s what I accomplished today:

  • I found a GUI skin and made a main menu that can load an arbitrary number of levels (just one so far)
  • I implemented the soldier toy logic, which involves shooting. I found a particle effect in the Unity asset store that works for me
  • I implemented a door opening thing based on triggers/levers found in the level
  • I improved the walking animation and footstep sounds of the main character
  • I implemented the level exit functionality
  • I crystallized how I plan to implement my level files (walls, floors and collision layers being separate objects)
  • I spent too much time in Blender trying to make things
  • I plopped in a background image instead of just having black (not sure I’ll keep this)

I’m still not revealing too much about the gameplay yet. Perhaps by Friday I’ll have a test build I can sent out to people to try out (hopefully running in the Unity Web Player).

As for big issues I’m seeing (other than the level design), I’m worried about my lighting. I really want the game to look nice, and so I plan to use light mapping. I haven’t tested this out yet though to see how much work it will be. Perhaps I’ll trying that tomorrow. Currently I’m just using a single directional light (with shadows), and an ambient term. Things don’t look that good.

1 Comment

Week of Awesome – day 2

Well day 2 has come to a close. I have most of the gameplay basics up and running now. I need to actually start working on level design! Hopefully the mechanics will be good enough for an interesting game.

Let’s list the various tasks I accomplished today, other than the bulk of the work on the gameplay mechanics.

I have a fully 3d simulated physics world, but I also need to move objects by tile in some cases. I’ve decided to leverage the physics system to move by tile, but it ended up being a bit hacky. I was not able to figure out how to use the object’s actual (capsule) collider to accurately move it in code, so I ended up using a sphere collider instead (roughly based on the object’s size).

I am still getting frustrated with MonoDevelop quite a bit. It feels more snappy than visual studio, but the typing completion is so awful. Tabbing back and forth between windows doesn’t work properly (or maybe it’s just different than VS, and I liked VS’s way better). Shift arrow-select never does what I want it to. It doesn’t work properly with the international keyboard, so I keep having to manually switch to the US keyboard every time a new code window is opened (one can only imagine the hacky code behind MonoDevelop’s editor that results in this bug). I know I can setup Unity to work with visual studio, but I haven’t bothered yet.

I downloaded a bunch of sound effects from soundsnap, and polished up a few of my own that I had previously recorded.

I wrote a Blender python script to apply uv coordinates to a mesh based on how it is aligned with the x/y/z axes. uv-unwrapping in Blender scares me, so I just wanted a programmatic way to do it. Now my level floors are looking better, as I can have textures:


I procrastinated about setting up svn for my Unity project. I’m still just backing it up by copying it to another physical drive once a day.

I tested things working in the Unity web player. Super easy to do! For the most part I’m loving Unity.

I’ll share more screenshots and hopefully a video later on this week.

1 Comment

Nearing the end of day 1

Most of today was spent getting models into the game and basic player movement and level loading done.


Scrounging around the web for free or inexpensive models is always a daunting task. Without fail, there were problems with every model I found. I like to play the guessing game of “what could possibly be wrong with this model?”.

The free boy model I found on the Unity asset store is ok, but only works with legacy Unity animations. I tried some tricks to get it to work with Mecanim, but the animations got corrupted and were not useful. The bear and soldier models were just a mess and required a bunch of time in Blender to fix (half the meshes with inverted normals, individual meshes not aligned properly, etc…). Not to mention the soldier mesh is about 25 different submeshes all with different materials – so it will be very expensive in terms of draw calls. I’m not proficient enough in Blender to bake this into a texture or anything. This model is definitely not “game ready”.



1 Comment

Week of Awesome II – The Toys Are Alive!

The theme for the game jam was announced last night: “The toys are alive”. I’m not a huge fan of specific themes like this, but I did manage to do a good amount of brainstorming last night.


I’ve got some decent ideas, but I’ll need to prototype further in my head, on paper, and finally in Unity.

Today, at least to start, I plan to keep going through some Unity tutorials.

The ideas for my game generally require some sort of partially tile-based world. That is, I need a grid representation of the world to script to (to run game logic against). The grid representation will help constrain the game world so it’s more understandable to the player. But I also want it to be a full 3d rendered environment with flexibility in how it looks. I suppose two examples of games done in this manner would be Back to Bed and Monument Valley.

Should I just use re-usable basic building blocks at the tile level and do all level building in Unity? Coming up with an internal representation of the game world would be easier then. Or should I use Blender to model the levels, giving me the utmost flexibility, and then in unity somehow try to define “gamelogic layers” (or can I mark up the model file in Blender somehow). When modifying a level, I certainly don’t want to have to keep two representations in sync, so that kind of sounds like a pain.

The former seems like the better choice. Is there anything in Unity that can help me constrain where I can place my building blocks, thus making level design easier? Will I have performance issues if my colliders are based off individual little tiles instead of a single large mesh?

Developer's blog for IceFall Games

Casey's Blog

Developer's blog for IceFall Games

Coherent Labs » Blog

Developer's blog for IceFall Games

Developer's blog for IceFall Games

Simon schreibt.

Developer's blog for IceFall Games

Dev & Techno-phage

Do Computers Dream of Electric Developper?

- Woolfe -

Developer's blog for IceFall Games

Ferrara Fabio

Game & Application Developer, 3D Animator, Composer.

Clone of Duty: Stonehenge

First Person Shooter coming soon to the XBOX 360

Low Tide Productions

Games and other artsy stuff...


Just another WordPress.com site

Sipty's Writing

Take a look inside the mind of a young game developer.

Jonas Kyratzes

Writer, game designer, filmmaker.

Indie Gamer Chick

Indie Gaming Reviews and Editorials

The Witness

Developer's blog for IceFall Games

Developer's blog for IceFall Games

Developer's blog for IceFall Games

I bake games

Developer's blog for IceFall Games

A Random Walk Through Geek-Space

Brain dumps and other ramblings

The ryg blog

When I grow up I'll be an inventor.


Get every new post delivered to your Inbox.

Join 315 other followers