7 day project postmortem

I promised to write up a summary about my 7 day game project last month, and managed to procrastinate on it for this long.  However I'm planning to do another 7 day game project here very soon, so I figured I should probably tie up the loose ends on the last one before moving forward.

For anyone here for the first time, in September (2012) I challenged myself to create a game in 7 days.  I blogged about each day of the process, and in the end I had a game I eventually released for Android on the Google Play Store as Match'n Flip.  A big reason I decided to do this 7 day game challenge was to help kick start my creative juices and get back into the rapid game prototyping mindset.  As a postmortem for that experience, I'll share a few pearls of wisdom for anyone considering doing a similar mental exercise.

What Went Right

1. Keeping eyes on the prize - 7 days isn't a whole lot of time to get a game kicked out; so it's very important to stay focused on what's important to the game play.  I'm frequently guilty of adding complexity to a game to try to add fun, and while this can sometimes work, many times extra complexity isn't needed.  One of my goals for this project was to create a game around a simple game mechanic, and let the game mechanic stand on its own.  This mindset worked very well for me and help me focus on the core game mechanic and resist the temptation to add unnecessary extra features.
2. Rapid prototyping and iteration - One of my goals for the project was making better use of my time during development and implementing functionality with more friendly tweaking ability.  Unity3D is super convenient because any publicly declared variables will automatically show up in the editor and are available to tweak/change at run time   In the past I haven't used this as much as I should have, preferring instead to hard code variable values and changing them in code on the fly.  While it's debatable as a more 'programmer friendly' approach, it artificially adds extra time for testing small value tweaks for no real reason because you need to wait for the editor to recompile the scripts.  It seems stupid now, but fighting one of the best features of the engine you're using is not a good idea; and embracing it will help you get things done much faster.
3. Sought input from friends - I made it a point to get as much input as possible from friends and family as the game progressed.  This let me get fairly unbiased impressions of the game and specific features before I'd invested too much time in them; and then make appropriate course corrections and changes.  In one of the best examples of this, I told a friend about an idea I had for some game rules I wanted to try out.  After explaining them he looked at me and said, 'Jay that's confusing as hell, no one will understand that in 15 seconds'.  Talking to friends, asking their opinion about the game you have so far, or ideas you want to try, is super helpful.

What Went Wrong

1. Started 7 day challenge at a bad time - I started the 7 day challenge almost as soon as I thought of the idea because I was excited to get momentum for myself to start working.  Unfortunately I didn't think to look at my schedule ahead of time; so the last 2 days happened when I was on vacation to visit my family.  Because of this and the next point I'll talk about, my 7 day challenge ended up spanning almost 2 weeks.
2. Got sick for the last 2 days (while on vacation) - While I was visiting my family I also got sick, which meant any time I could have eke'ed out to work was lost because I was in bed sleeping.  It's amazing how much energy it can take to be creative; while I lay in bed resting I would try to think of game ideas for the challenge.  However usually I was too exhausted to think of anything and would usually fall right asleep thereafter.  Just bad luck there.
3. Had to learn a new GUI system - For this project I decided to switch to a new GUI system (NGUI) for Unity3D (the game engine I primarily use for my games).  While I'm glad I switched to NGUI there was definitely a learning curve to overcome, which ended up chipping away at the time I could have used to work on the game.  Next time I'll get ramped up on any new tools beforehand, so there will be less impact on the actual game dev time.

Summary:

Overall this was a very fun and exciting experience for me.  After completion our previous project, Access Point, I was feeling very burnt out and mentally exhausted.  Giving myself a 7 day challenge was a breath of fresh air, and a great way to get myself back into the mindset of making new games.

Thanks for reading!  I plan to do another 7 day game challenge for myself in the next week or so.  Once again I'll be writing out it everyday, so check back soon!

Fixing Long Load Times in Shatter Crash

Development on Shatter Crash is moving along pretty well, we are currently working on polishing, UI and bug fixing.  One of the things I decided to tackle today was the long load times we were seeing when traveling from our game play scene back to the main menu scene.  This was especially bad on the iPad's, where we could see load times between 10 and 15 seconds.

The first thing I did was use Unity's cool profiler tool to get a sense of where time was being spent by running the game on my computer. However this ended up failing horribly because the editor continually stalled or crashed while I did deep profiling, probably because the call trees were incredibly deep.  Doing regular, non-deep profiling, didn't flag anything that jumped out as problematic, so I began to suspect the issue had to do with asset loading. As a note, as far as I know Unity's profiler doesn't give much details about asset loading/unloading, so this was simply a theory. (As a note, I didn't have wifi access at the time, so was unable to directly profile the game running on the device.)

I began to suspect the extended load times had to do with our GUI solution forcing Unity to pull in a lot of textures and create a number of object hierarchies.  I tested this by creating an iPad build with most of the UI ripped out to see how much faster the main menu loaded.  To my surprise, it only dropped the load time from ~15 seconds to ~14 seconds...looks like the GUI isn't to blame. I eventually resorted to brute force debugging by removing objects from the scene and pushing a new build to the device to see if things got better.  This certainly wasn't an ideal debug flow, but it did work.

I eventually found the cause of the load time spikes was related to how we referenced the puzzle data for Shatter Crash's game levels.  Our puzzle data is stored in ScriptableObjects for convenience, and each 'level' contains lists with hundreds, or thousands, of entries which define each piece on a puzzle board. For simplicity, I had created a script and prefab which directly referenced each of these puzzle ScriptableObjects (about 30), and this prefab was referenced in the main menu.  Removing the reference to this puzzle container prefab dropped our load times from ~15 to ~3 seconds...sweet problem found!  It seems Unity was taking a long time to load the main menu because it was loading and parsing all the list data in each of the puzzle data files.

Now that I knew the cause of the problem, the fix was fairly straightforward, although a bit tedious.  I changed the puzzle loading system to use Resources.Load to dynamically load the puzzle data we needed on-demand.  I generally shy away from using the Resources.Load() much because it's a real pain in the butt to keep asset paths up-to-date, and when I do I generally write unit tests to validate the existing paths are good.  While I was copy pasting strings, I came up with an idea for a new tool to automatically create Resource paths, hopefully I'll have a chance to create it in the near future

*UPDATE* - The game described here was ultimately released as 'Shatter Crash'.  I edited several places where I referenced it by its old name 'Access Point' to refer to the new name

Handling Texture Tiling and Offset in a Unity3d Vertex and Fragment Shader using TRANSFORM_TEX macro

When doing some test work, I found my Cg shader wasn't handling texture offset and tiling properly, resulting in distortion such as below:

The Unity shader on the left properly handles a 3x tiling factor for the texture, while my shader on the right doesn't properly handle the same 3x tiling factor

My shader setup was pretty simple, here's a snippet of the important parts:

#include "UnityCG.cginc"

sampler2D _MainTex;
float4 _Color;

v2f vert ( appdata_base v )
{
    v2f o; 

    o.pos = mul (UNITY_MATRIX_MVP, v.vertex);

    // Texture offset - BAD
    o.uv = v.texcoord;
    return o;
}

half4 frag (v2f i) : COLOR
{    
    return tex2D(_MainTex, i.uv) * _Color;
}

I bolded the problematic part, which is the Texture UV handling in the 'vert' program.  Simply grabbing the v.texcoord will work when there is not tiling or offsets in the texture, but breaks once those elements are introduced

After snooping around, I found the solution is to use the TRANSFORM_TEX macro in the UnityCG.cginc to make sure the texture's offset and tiling are properly applied.  A small caveat to this is you must, "declare float4 properties for each texture before the vertex program, with _ST appended" (Quoted from Unity3d shader docs).

Here's a snippet of my shader with the new changes:

#include "UnityCG.cginc"

sampler2D _MainTex;
float4 _Color;
uniform float4 _MainTex_ST; // Needed for TRANSFORM_TEX(v.texcoord, _MainTex)

v2f vert ( appdata_base v )
{
    v2f o; 

    o.pos = mul (UNITY_MATRIX_MVP, v.vertex);

    // Texture offset - GOOD
    o.uv = TRANSFORM_TEX(v.texcoord, _MainTex);
    return o;
}

half4 frag (v2f i) : COLOR
{    
    return tex2D(_MainTex, i.uv) * _Color;
}

With this happy little change, our shader now properly handles the tiling and offsets of the texture.

 

For those curious, I gleaned this information from the Unity3D Vertex and Fragment Programs and the ancient Unity 2.x Shader Conversion Guide.  The info pulled from the Shader conversion guide regards the _MainTex_ST property needed for TRANSFORM_TEX to work. 

UPDATE - Dec 1, 2013 - The Unity 2.x Shader Conversion Guide seems to have disappeared from the internet.  This information is all still relevant for Unity 4.x release versions