GetManagerFromContext: pointer to object of manager 'RenderSettings' crash in Unity3d

I recently encountered an issue using Unity3d where I was unable to create a build of a client's project because of a crash that occurred in the Unity Editor during build publishing.  Unfortunately I don't have an image of the crash message dialog, but essentially it said:

"Fatal error! GetManagerFromContext: pointer to object manager 'RenderSettings' is NULL"

which wasn't the most helpful message in the world.  I spent some time trying to track down any obvious issue in the code with no luck, so start looking on the Unity forum and found This forum post which described a very similar issue I was seeing.

Luckily it seems this was a known issue, apparently caused by assigning ProceduralMaterials to Material properties inside scripts.  There have been a couple of fixes for this particular problem recently, the Unity 4.5.4 release notes and Unity 4.5.4p2 release notes both mention fixes related to this issue.

Updating to the vanilla Unity 4.5.4 release from 4.5.3 fixed my particular crash.

TL;DR
If you're seeing a crash similar to what I posted above, and you use procedural materials in the project, try to update to Unity 4.5.4 or one of the patch releases and see if that fixes the issue

Unity 4.3.x doesn't support Google Native Client

While spending some time tonight working with Unity's platform preprocessor defines I noticed I wasn't getting proper results when checking if the UNITY_NACL symbol was defined.  Oddly enough when I set Unity to make a Native Client build, it defined the UNITY_WEBPLAYER symbol instead. After asking on Twitter and making some Google searches, I finally found an semi-buried explanation here and this nugget in the Unity3d 4.3 release notes

• Google Native Client support is not functional in Unity 4.3. If you need to publish to Native Client you can still use Unity 4.2.2.

This change isn't readily apparent when looking at the build window, as you can see in this picture, there isn't any information to indicate the Native Client build isn't supported.  I suspect this is the first step to phasing out NACL support entirely, similar to the removal of Flash build exports

.  Hopefully this helps anyone who stumbles into this when trying to use the UNITY_NACL define

Releasing games for multiple platforms

Today is a big day, I finally released my company's 3D puzzle game, Shatter Crash, for Android on the Google Play Store.  I'm pretty happy about this release, it's something I've wanted to do awhile now, especially considering Shatter Crash originally came out for iPad in July of 2012.

Took long enough....

Actually there is a story as to why it took so long for the Shatter Crash Android version to come out, but that's something for another blog post.  It wasn't a technical reason though.

Since this is all fresh in my mind, I wanted to share a couple tips on stuff to think about when you do a multi-platform game.  This is more oriented for iOS and Android stuff, but will work for any other platforms as well

1. Port your game to the new platform.  This is pretty obvious. I use Unity3D which handles 99% of the stuff for all the different platforms.
2. You should look at the new platform and learn if there are a particular nuances of the platform you should try to handle.  One example, on Android hitting the back button on the main menu generally pops up a quit dialogue giving the user an ability to cleaning quit the app, not just put it into the background
3. Handling product/app store links for the new platform.  For Shatter Crash I added a 'Rate' button so users can rate the app.  On iOS this takes the user to the iOS ttore list, for Android it takes the user to the Google Play listing.  Ideally you can take advantage of a mechanism so the app uses the proper links automatically depending on the platform.
4. Handling UI layouts for different platforms. The iOS devices are pretty nice because you only have a handful of UI resolutions and aspect ratios.  All iPads are 4:3 aspect ratio, and iPhones/iPods are either 3:2 or 16:9.  Android obviously has a lot of different aspect ratios.  Ideally your UI can automatically handle scaling and moving widgets to take advantage of the screen for particular device it's running on, rather then you manually placing the widgets for every possible screen size
5. Way to direct users to the different store pages - When you go from 1 platform to many, you need to make it as easy as possible for people to find the version of the game relevant to them.  One idea here is make a page on you website with links to the different stores you game is on; then make sure to SEO the hell out of said page so it's highly placed on search engines.  
6. Achievement/Leaderboard/etc. - Competitive features like leaderboards and challenges, plus achievements for the collector-mentality players, are definitely nice to have in your game.  Different platforms generally have different implementations of these, which can be annoying to manage.  I created an internal API which my games use for handling leaderboards/achievements/challenges updates and unlocks.  That API in turn works with a binding layer responsible for interacting with the platform-specific system.  In this way I can build in support for all those features, then the platform binding layer handles how the nuances of converting that to the platform game system format 

Those are the ones off the top of my head, would love to hear more on this anyone had more suggestions.

And if you're looking for a fun 3D puzzle game, please do check out Shatter Crash on Google Play or iOS App Store!

Method to get the name of a calling method in C#

When doing quick testing with debug logging it's usually helpful to include the name of the method where a log call originates.  It's pretty easy to include, but it can be a hassle if it's a large method you have to scroll through to find the name, or God forbid if the method name changes in the future.  What would be handy is a quick and easy way to get the name of a calling method at runtime so it's guaranteed to be the correct name.

This is one thing I've wanted for quite some time, and for one reason or another I never spent the time to investigate how to access this until now.  It was surprisingly easy to setup and works very nicely by taking advantage of the System.Diagnostics.StackFrame class to determine the calling method.

Here's what I came up with.  You're welcome to copy and use this code in your own projects.

1:  // Use a stack frame to get the name of the method which called this method   
2:  public static string GetCallingMethodName ( bool includeClassName = true )  
3:  {  
4:      System.Diagnostics.StackFrame lastFrame = new System.Diagnostics.StackFrame(1);  
5:    
6:      // return ClassName.MethodName  
7:      if ( includeClassName == true )  
8:          return lastFrame.GetMethod().DeclaringType.Name + "." + lastFrame.GetMethod().Name;  
9:    
10:      // return just MethodName  
11:      return lastFrame.GetMethod().Name;  
12:  }  

I'm not sure what the performance penalty is for using this at a high frequency, so if anyone has insight into that I would love to hear it!

Busy year doing contracting work and using OpenCV

So 2013 has been a pretty busy year.  Contracting has been going incredibly well and I've had a chance to work on some really cool stuff.  Jumping back into C++ after 2 years away from it was quite fun, although it reminded me how tedious and annoying C++ can be, especially when trying to do small things.  Unfortunately being so busy also meant I neglected this blog for most of the year.

My most recent contracting project is pretty interesting and gave me a chance to learn some new things.  One of my more recent tasks was creating a high-speed image processing tool, which lead me to learn about using the OpenCV library for image processing tasks.  There are some pros and cons to using it, however the pros definitely outweigh the downsides.  OpenCV has a huge amount of functionality built-in for image processing, and the API to use it is quite easy to use.  One of the simplest, yet most powerful, methods I found in the library was imread() which handles reading an image file and loading the pixel data into an object.

There are some gotchas when using OpenCV, one that tripped me up initially was how it stores pixel data.  All game engines I've worked with handle color data as RGB channels, OpenCV uses BGR channels (the Red and Blue channels are switched).  This ended up biting me for a little while during the first round of testing when the tool flagged red images as blue ones.

I should also mention OpenCV assumes you have some level of knowledge of image processing techniques, and is mainly there to provide implementations of those techniques.  Coming into it with little knowledge of the subject like I did will be difficult, expect to do a lot of research to play catch-up for what they talk about.

On a final note, if you're new to OpenCV, I highly recommend checking out these excellent lessons http://opencv-srf.blogspot.com/p/opencv-c-tutorials.html. They provide a great starting point for navigating the OpenCV library and some terrific examples of image filtering operations.

Handling OpenSSL's SSL_ERROR_WANT_WRITE to avoid socket error:1409F07F

I spent a good part of last week working with OpenSSL C++ networking code.  One of the issues I ran into was the network SSL socket no longer sending data for some reason.

There are a fair number of error codes OpenSSL will return for certain situations when calling into the API.  Based on the error code returned from an I/O operation you may be required to take certain actions.  In particular, if you write to a SSL socket and get the SSL_ERROR_WANT_WRITE error code, you really need to jump through some hoops.  If you receive SSL_ERROR_WANT_WRITE during a write operation, the OpenSSL documentation states you must call the write method again at a later time, with the same parameters.  Please note I emphasized the last part about the parameters, because there is a huge caveat there.

What the OpenSSL documentation doesn't properly convey is when you retry the OpenSSL write operation at a later point after receiving a SSL_ERROR_WANT_WRITE error, the parameters must literally be the same, DOWN TO THE ADDRESS OF THE BUFFER YOU WISH TO WRITE.  My initial assumption was the buffer contents just needed to be the same, which may be the case, but I found the actual buffer address needed to be the same as well.

It seems OpenSSL internally remembers the address of the buffer passed in when SSL write returns the want write error, and if a different address is used on the next write operation, the socket enters an error state.  In this error state the SSL write call returns SSL_ERROR_SSL, and checking the SSL error queue returns this error:

"error:1409F07F:SSL routines:SSL3_WRITE_PENDING: bad write retry"

I'm not sure if this error state is recoverable.  It may be possible to recover by calling the write with the proper parameters.  However if the original buffer was lost, because you memcpy'ed the data into a new buffer and freed it, then your socket is probably hosed.

In my case, we were trying to send data through the socket first, then queuing a copy of the data if the write failed.  Unfortunately the copy operation memcpy'ed the data we wished to send, so the next time we called SSL write we were sending a pointer to a different data location than the original call.  Our solution was to simply copy and queue the data first, then trying to write to the socket.  If the write succeeded then we just removed it from the queue, and if it failed then we were guaranteed to still have the same data buffer address when we tried to write again.

Removing OpenFeint from Ninja Hamster Rescue

* This is a follow up to a post I previously made here about GREE shutting down the OpenFeint servers with about 1 month of lead time for developers to remove it from their games.

The last month has been incredibly hectic for me.  I've spent the large majority of my time working on a contract job, and the rest of my time spent getting Match and Flip ready for release on iOS before Christmas.  Luckily both of those jobs are winding down a bit, so I was finally able to turn my attention to Ninja Hamster Rescue and purging OpenFeint functionality from the Android and iPad version.  As a quick recap, OpenFeint is social system that provided some nice services like leaderboards and achievements, and was very easy to add to your game.

I'm a little upset about having to remove OpenFeint from NHR, one of the biggest reasons being I don't know of any alternative services offering achievement and leaderboard tracking for Android.  Unfortunately I don't have a choice though, especially since their servers are suppose to stop responding to requests sometime tomorrow (Dec 14, 2012), and I don't want the user experience to suffer from timed out web queries or what have you.  So what does that mean for people who played NHR?  For players using the iPad HD version not much will change, except OpenFeint will disappear and your achievements and leaderboards *should* continue to exist in GameCenter.  For Android players, the game itself will still perform exactly as it did before, the biggest changes being achievements won't unlock and you won't be able to compare your scores to other's on leaderboards.

Ninja Hamster Rescue on Google Play will be updated shortly, and even is getting a Holiday update to add a new level.

Ninja Hamster Rescue HD for iPad will probably take longer to update, as it will need to go through the App Store review process first.

Creating a Colored Unlit Alpha Texture Shader for Unity

Last week I wrote about Creating a Colored Unlit Texture Shader for Unity.  I've used the shader from that post quite a lot on my new game Match'n Flip; however I recently realized it didn't work with alpha textures (textures with transparency).  So I decided to make a short post about creating the same kind of colored shader for a texture with alpha.

Applying a color combine with an alpha texture opens up some interesting possibilities, because you can control the opacity of the texture by modifying the color multiplier's alpha value.  Below is a picture of the default Unity Unlit Transparent shader, and on the right are 2 examples of my modified colored unlit transparent shader.  The opaque section of the object on the top right is semi-transparent because I set the color multiplier's alpha value to 50%(0.5), which the object on the bottom left is full opacity but has a red tint applied.

The shader itself is pretty simple, I modified Unity's Unlit-Alpha shader to support a Color property and handle the color combine operation.  The shader will appear in the shader dropdown menu under NAKAI/Unlit/Transparent Colored.  In case you're wondering, the Unlit-Alpha shader was written using Unity's ShaderLab Shader Syntax, I highly recommend reading up on the operations involved.  As before, you are free to copy and use this shader as you wish, Enjoy!

// Copied from Unlit-Alpha.shader, but adds color combine(tinting)
// Unlit alpha-blended shader.
// - no lighting
// - no lightmap support
// - Added per-material color

// Change this string to move shader to new location
Shader "NAKAI/Unlit/Transparent Colored" {
    Properties {
        // Adds Color field we can modify
        _Color ("Main Color", Color) = (1,1,1,1)
        _MainTex ("Base (RGB)", 2D) = "white" {}
    }
    
    SubShader {
        Tags {"Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent"}
        LOD 100
    
        ZWrite Off
        Blend SrcAlpha OneMinusSrcAlpha 

        Pass {
            Lighting Off
            SetTexture [_MainTex] { 
                // Sets _Color as the 'constant' variable
                constantColor[_Color]
                
                // Multiplies color (in constant) with texture
                combine constant * texture
            } 
        }
    }
}

OpenFeint servers shutting down Dec. 14, 2012

Today GREE announced OpenFeint servers will be shutting down on December 14, 2012.  This very truncated transition period gives developers less than 1 month to replace or remove OpenFeint functionality to their existing games.  While this would be short notice in the best of times, giving 1 months notice during the December time period is, the hands down, worst possible time they could make this move.  Right now most mobile developers are hurriedly working to get new games and updates finished and submitted in time for the big holiday rush and before the App Store locks down for the winter holidays.

If you're wondering what OpenFeint is, in short it's a predecessor to Game Center.  Most notably developers used it for leaderboards, achievements and adding other social aspects to their games before Game Center came along.  While OpenFeint adoption has dropped since Game Center was introduced, many older (but potentially popular) apps still use OpenFeint because their developers haven't felt the need to switch it over to Game Center.  Developers must now make the choice to drop their new projects to update their older games, or face the specter of allowing their older games to use a service that no longer exists.  To really twist the knife in the whole experience, GREE informed developers that failure to remove the OpenFeint SDK from your games by December 14, 2012, "violates the terms of the OpenFeint Developer Agreement".  GREE is pushing developers to migrate to their OpenFeint games to the GREE Platform however I'm very suspect on how many developers will choose to migrate to that service given this experience.

While I removed OpenFeint from my iOS games awhile ago, I'm still using it for the current version of Ninja Hamster Rescue on Android.  This raises a new question, are they any other services out there that provide leaderboard/achievement type functionality for Android, or was OpenFeint the only one?

Creating a Colored Unlit Texture Shader for Unity

When dealing with Unity materials, one easy and convenient feature is the ability to change the Main Color of a shader to tint the color of the texture it uses.  This can be used for a lot of different situations, like changing the color of a tile on a selection grid or changing the background color of a 2d game, to name a few.

Unfortunately I found the ability to specify a shader color missing in Unity's Unlit Texture shader.  The Unlit Texture shader isn't affected by lights, which is very convenient when you don't want to include lights in a scene or want to manually control the brightness of a texture.  It makes sense why the Unlit Texture shader doesn't include the color combiner support, the Unlit Texture shader is the simplest and fastest shader they have, and adding a color combiner would add extra instructions which would rarely be used.  Since I needed the ability to color tint an Unlit Texture for my new project, I decided to extend the existing Unlit Texture shader to support a color multiply operation.

The source for the new shader is below, you are free to copy it for your own needs*.  Use the 'Create--Shader' command in unity, then paste this code into the new file.  The shader will appear in the shader dropdown menu under NAKAI/Unlit/Texture Colored.  In case you're wondering, the Unlit Texture shader was written using Unity's ShaderLab Shader Syntax and I added a few extra lines to support the color combine operation.  Here's a picture of it in action, Enjoy!

// Unlit color shader. Very simple textured and colored shader.
// - no lighting
// - no lightmap support
// - per-material color

// Change this string to move shader to new location
Shader "NAKAI/Unlit/Texture Colored" {
    Properties {
        // Adds Color field we can modify
        _Color ("Main Color", Color) = (1, 1, 1, 1)        
        _MainTex ("Base (RGB)", 2D) = "white" {}
    }

    SubShader {
        Tags { "RenderType"="Opaque" }
        LOD 100
        
        Pass {
            Lighting Off
            
            SetTexture [_MainTex] { 
                // Sets our color as the 'constant' variable
                constantColor [_Color]
                
                // Multiplies color (in constant) with texture
                combine constant * texture
            } 
        }
    }
}

*You are free to use this for your own games.  Please do not sell it on the Unity asset store or anywhere else. :)

iPad thoughts from February 2010 revealed on October 2012

I was going through my blog looking at old drafts and stumbled upon a draft with my thoughts about the iPad shortly after it was announced in 2010.  The creation date for this post was 2/10/2010.  It was interesting comparing my previous thoughts about the iPad, and tablets in general, with the reality of their existence now.  I do feel kinda proud about the book market prediction, especially given Apple's press event earlier this week where textbook on the iPad got a lot of love.

Other than this intro section, the entry below is unmodified from my Feb. 2010 blog draft (even left some annoying spelling errors in there).

-------------------------------- Look back in time ---------------------------

I'm about 2 weeks late writing this, but figured it's a good time to put my thoughts out there regarding the iPad.

I have to admit I hopped Apple wouldn't announce a tablet, since I honestly don't see the market role it will fill. I assume I'm in the demographic Apple is trying to reach with the iPad, given I'm a relatively young, tech-savvy person with disposable income. The problem is I just don't see any reason why I'd need one, given I already have an iPhone and a couple computers. Talking with some of my co-workers, the couple areas we could see it being popular is with people traveling a lot, or people who want it because it's an Apple product.

From Jobs's presentation, I get the feeling they're definitely going to push the e-book market and try to take market share from the Kindle and Nook. I'll be interested if they can gain access to a comparable amount of book content to compete against those two systems.

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!

Trick for visualizing arrays of serializable classes in the Unity3d inspector

In the Unity3D editor,the inspector will automatically show the names and values of any variables you declare within a MonoBehaviour -derived component. This is incredibly useful for debugging the values of properties while testing, and also provides a very easy avenue to tweaking the values of exposed variables.

However what do you do if you want to nest a class of related properties in a MonoBehaviour -derived component?  By default the names and values of the variables within the nested object will appear in the inspector.  This is where the System.Serializable attribute is necessary, applying the System.Serializable attribute to the class will tell the Unity inspector to display the names and values of the variables in the inspector.  This makes the System.Serializable attribute a very handy tool!

One common using for serializable nested subclasses is in lists/arrays to hold configuration data for any number of things, such as inventory descriptions and properties, level lists, difficulty modifiers, etc.  Unfortunately when you put a serializable class in a List or Array, the way each instance element is named leaves a lot to be desired for the person editing the data.  Each element is named "Element ", which doesn't give any high-level information regarding what data each element contains.  In order to find the element with the data you wish to modify, you'll need to expand each element and look at the properties until you find the one you're looking for.

This shows an Array and  List of the same serializable class.   Each element is named "element ", which doesn't give any high-level information regarding what each element contains.

But wait!  There's an undocumented (as far as I know) trick to drastically improve this!

When you declare a public string as the first variable in a serializable class, the inspector will use the value of that string in lieu of the "Element " tag for each instance data element!

This shows the Arrays and Lists of the same serializable class.  Which do you think it easier to work with?

This makes data management much easier by providing a high-level view of the information each element contains.  Additionally whoever is editing the data can change the value of the string description to suit their tastes.

Expanded view of the List container to show the inner properties of each element. Notice the "String For Description" string is the first element in the class, and the value is used to name each list element.

Hope you find this information useful, leave a comment if you know of any other little Unity tricks, I'm always on the lookout for more!

Making use of C# extension methods in Unity3d

I recently started using C# extension methods in Unity3d and found them very helpful for my workflow, so I decided to share.  During development of my recently released game Match'n Flip my goal was to rapidly prototype new game play modes quickly, so being interrupted by small things was very disruptive.  So far I've only done very simple helper methods, but these handle things which previously broke my workflow because of small nuances.

One particularly useful extension set I created are methods to move a game object along one axis, such as move a game object along the global x axis by 5 units.  Conceptually this is a very simple operation:

transform.position.x += 5F;

is essentially all you need to do, however because Unity doesn't allow you to change just 1 element of the position Vector3, instead you need to do this:

Vector3 temp = transform.position;
temp.x += 5F;
transform.position = temp;

Conceptually not difficult, but writing those 3 lines can easily break your train of thought as you're working and slow down your creative process. Additionally these little snippets are annoying because you actually have to look at them a moment to see what the transform operation is, since the meat of the operation is done on a new object not related to the object you want to modify (temp Vector3 local variable vs the position vector3 transform property).

To reduce these brain train killer situations, I created a set of ShiftPosition transform extensions methods to handle the annoying part of these operations.  Using these I can do the same operation as above one neat line and in a way that's intuitive to see what's going on:

transform.ShiftPositionX(5F);

Under the hood the ShiftPositionX/Y/Z extensions are still modifying a temp Vector3 which is re-assigned back to the transform.position property.

Here's a small snippet of what the TransformExtensions class looks like, sorry for formatting getting hosed.  Feel free to use this in your own projects if you wish, or if this is interesting to anyone, please contact me and I'll expand on this with more helpers/details!

public static class TransformExtensions
{

#region ShiftPosition

public static void ShiftPositionX ( this Transform tran, float offsetX )
{
Vector3 temp = tran.position;
temp.x += offsetX;
tran.position = temp;
}

public static void ShiftPositionY ( this Transform tran, float offsetY )
{
Vector3 temp = tran.position;
temp.y += offsetY;
tran.position = temp;
}

public static void ShiftPositionZ ( this Transform tran, float offsetZ )
{
Vector3 temp = tran.position;
temp.z += offsetZ;
tran.position = temp;
}

#endregion ShiftPosition

}

Hope you find these useful!

Match'n Flip Released on Google Play™ Store

Yesterday we released our new free game, Match'n Flip for Android™ on the Google Play™ store.  Match'n Flip is a simple, relaxing puzzle game about finding and matching tile patterns.  You can find the app by clicking on the image below.



I'm extremely excited to publicly release Match'n Flip for people to try out.  I've been running a closed beta with some close personal family and friends, but this is the first time people will really be able to see the game in action.

One of the exciting things about this game is how it was originally conceived and came to fruition.  The core concept for Match'n Flip was born out of a 7 day game development project I started and blogged about last month (links below).  After the 7 days project was over I was left with a game that was fun and felt good to interact with, but lacked polish and focus.  Instead of starting a new 7 day project, I decided to spend a few weeks polishing up the game experience, getting friends to play and iterating on the concept and feedback mechanics to really make the game feel solid.

I'd like to thank all the friends and family who helped and supported us, you guys are great!

Day 1 Dev Blog
Day 2 Dev Blog
Day 3 Dev Blog
Day 4 Dev Blog
Day 5 Dev Blog
Day 6 Dev Blog
Day 7 Dev Blog

New Project Day 7 of 7 Recap (finally)

NOTE - So I'll admit this 7-day project ended up stretching out much longer than I thought it would in terms of the overall duration. I plan to do a postmortem regarding this project and some of the lessons I've learned to improve the experience when I do it again.

Spent my last day on this project getting my hands dirty with GUI stuff, which ended up swallowing most of my day. I decided to use the NGUI plugin for creating my UI's in Unity for this project, and while it's nice I was scrambling to learn enough to get it functional in my game in any usable form.  I did get a basic score and time display working and added a flare text pop-ups when you gain points, which feels good.

I also spent a bit of time improving the feel of the game by added sounds and animations for user input actions like pressing tiles, dragging times, flipping tiles and detonating tiles.  Below is a small clip to highlight the user feedback.

You can really see the tiles pop-up larger when selected or dragged over while creating a drag connection.  I deliberately made the tiles scale up very large because this will be an iPhone game, and I wanted the tiles to grow large enough so the player can see them under their finger.  I originally used a small scale up, however when I was testing on the phone it didn't read well, so I decided to make it crazy large and felt pretty happy with it.

As for the game mode I talked about earlier, I've decided I probably won't go with that for the final game I release. I kind of liked it, however it felt very un-directed and lacking in substance.  I'm going to spend some time trying out more of a simon-says type mode where you need to create matches based on combinations of shapes the game presents you.  I'll post updates on that as it develops.

I plan to doing a postmortem summary as a different post, however I just wanted to say this "7-day" project was an awesome experience for me and really pulled me out of a funk.  Once I digest some of the lessons from this first experience, I plan on doing another 7-day game in the near future to keep my momentum and creative juices flowing, so stay tuned!

And as a final note, a fellow Raleigh studio BitMonster Games released Lili, their first iOS game today.  I highly recommend you check it out, it's a beautiful game.

New Project Day 6 of 7 Recap

NOTE - What I talk about for today actually happened last week.  Some life circumstances, visiting family and getting sick on my travels, caused this recap to be delayed until now.

I settled on a game mode I'm going to use for the final game.  It's less ambitious than the mode I originally wanted to expand out, however it's also much easier to understand.  After showing the previous game to some friends, the generally feedback was the rules were too complicated to easily pick up in under a minute.  We all felt the game play was interesting once the rules were understood, but the time it would take to explain that would cause most people to abandon the game early.  I want to revisit this game in the future, but doing so will require gradually building the player's knowledge of the mechanics up over the course of time....ie a longer project.

The new game mode I'm doing is still match-3 based, however I'm doing some twists to try to make it a little more interesting.  The game will be similar to what I showed previously where the player will be able to move tiles around the board, then create connection lines between similar tiles to create detonations.

The twist will be in how the player's actions are scored. Rather than score only based on the tiles being destroyed, I want to score based on the link the player creates between the tiles.  I'm going to start easy at first, so I'll probably make diagonal links between tiles be worth more than up-down, left-right links.  It's not a groundbreaking idea, but it's a start to something different. One thing I've noticed is people think in the up-down, left-right quite a bit; so incentivizing thinking outside those directions will be a good initial challenge for players. 

New Project Day 5 of 7 Recap

In case you haven't read some of my previous blog posts about this project, I'm currently working on making a Match 3 type tile game.

I spent a bit of time today working on a new game mode and then showing it off to some friends to get feedback on the mechanics.  For the new game mode I wanted to try something a little more interesting than the usual generic 'score x point in y seconds' or 'play this to infinity' type goals you see with a lot of Match 3 games.  I've taken some inspiration from the iPhone app 10000000 (Called 10 million) which uses Match 3 game play to drive game play in a larger context.  

The new game mode prototype I created is kind of like a boss battle; you fight against a boss that continuously spawns new minor enemies.  You must make frequent small tile # matches to remove the minor enemies that spawn to prevent too many from building up.  In addition you must also create large tile # matches to damage the boss and eventually kill it.  I put up a web player build for anyone who wishes to play it:

NOTE - There is no win/loss condition for this prototype, and everything i describe above is purely represented by the text values displayed on the upper left of the screen. There's no time limit, I'll probably add that at some point so the game doesn't go on forever.  Also this is a very very prototype build I'm sharing for the sake of being open about this project. If things don't work I apologize.

Boss Battle Game Type Prototype

Overall I like the direction of this game type. There's definitely a bit more of a challenge than the normal game play you see in a Match 3, however that may not be a good thing.  Casual players may be turned off by having to manage # of enemies + boss health + time limits + tile management.  That's a lot of concepts to drop onto someone at once, if this were the culmination of some other game modes with introduced these elements slowly, I think this could be very powerful.

I'd love to hear comments!

New Project Day 4 of 7 Recap

NOTE - I'm posting this one a day late, I worked very late into the night yesterday and didn't get a chance to do the recap before I hit the sack, sorry about that!

*Warning* Some programmer talk here, skip to the next paragraph if you're not interested*

Today I made a push to start implementing more game modes without gutting the existing game functionality.  The existing general game logic is working very nicely, which you've seen from my previous blog posts.  One thing I'm fighting against is the code isn't well organized given how fast I had to create it.  The majority of the game logic is in one class, however there are some snippets in other areas as well.  I don't want to start modifying that too much in order to implement new game specific logic.  In the past I would have used inheritance to extend the existing game logic class and add the new game specific stuff.  However since the logic is a bit scattered, and that fragmentation will likely get worse as I continue, I decided to try something different: a form of composition.  For each new game mode, I create a custom game logic class that registers delegate callbacks for certain events generated by the core game logic. This lets me modify certain areas of the game, and add entirely new things, without changing the underlying game.

Very simple code org. chart

I showed off a build of the current game to a friend today and got some great feedback from him.  We ended up talking for about an hour about some new ideas and game modes I should try to flesh out tomorrow.  In addition, he whipped up some new art assets for me, little cubes that animate!  Adding these instantly made the game look 100% cooler, hopefully we can get some more stuff in there to really spice things up.

I put up a web build of the game here for those feeling adventurous.  There are no directions on how to play, no scoring and no end goal, this is just to show off the mechanics I have in there right now.  Feel free to leave comments/suggestions if you have any.  Depending on how productive I am, tomorrow I'll try to add a build with one of the new game modes implemented.

UPDATE - I'm told by Bryce, who gave me the blocks, that the blocks aren't rotated correctly. Guess I'll add this to the blooper reel. Tomorrow's update with show a better view of them.

In case you missed it, link to the web build: Build1

New Project Day 3 of 7 Recap

Today was both a productive and unproductive day.  It was very productive on one hand because I got a good bit of stuff done; however it was unproductive because most of what I did ended up not being used. That's the life of prototyping games though, sometimes you only make forward progress by seeing what doesn't work and throwing those ideas into the trash bin so other ideas rise to the surface.

Sometimes this is a little discouraging and other times it's a lot of fun throwing a bunch of ideas out there to see what sticks.  What's more important is sometimes the failed ideas lead you down the path to better ideas you end up using.  Here are a couple pictures, one is trying to do some of my own art for the tiles (horribly failed). Other one is a feature I'll probably end up keeping.

Tried adding an icon to the tiles, decide my art skills aren't up to the challenge

Added the circles to the tile drag line to indicate connections between tiles.  Pretty sure I'll keep this. 

And to cap it off here's a video of one of the game mechanics I tried out.  In case you don't want to hear my silky voice narrate, this video shows off shifting tiles around the board before linking groups of them together (they're linked by color) in order to create an explosion.  It's an interesting idea I may continue looking at, it does feel gratifying to move the tiles around and create a large link and explosion.  I may show it to some friends to see what they think, please leave a comment if you have an opinion too!

 

Oh and on the project name front, one of my old bosses suggested Drunken Falcon Punch.  I'm not going to say it's a horrible name, but if anyone comes up with some better suggestions I would definitely welcome them :).