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

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.

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!

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 :).

New Project Day 2 of 7 Recap

Unfortunately I didn't get much tangible work done yesterday through a combination of sleeping late and going out with friends.  I felt a little guilty about not making much progress, but then figured I need to have fun like everyone else.  Being a game developer and small biz owner, it's very important to balance work and life so you don't get burned out.  Anywhoo onto game progress....

Spent a bit of time thinking about game and scoring mechanics to use with this game.  I know I'll eventually try out several different ideas, but I want to keep the ideas as constrained as possible so I don't go too far down a path that won't work.  In addition to brainstorming, I created a puzzle board management system that will link with the front-end display system.  I made a system like this previously for Shatter Crash and figured I'd use it for this game; however I'm starting to think I will not use this system for this project.  If this were a longer, more in depth project I probably would, but for such a small and short game, I think it'll just add another layer of abstraction that will get in the way.  Oh well lesson learned...

The one cool thing I did get done was add the ability to randomly colorize the tiles on the board.  I'm pretty sure I'll eventually change this to use unique icons instead of colors, so the game is color blind friendly, but this is a cool step for now.  As an additional cool note, this screen shot is the game running on my iPhone.  It's funny to think of publishing to the iPhone for the first time on this game as a small step.  Just one of the benefits of using Unity.  In fact I could have had the game running on the phone yesterday, but I was actually too busy to take my mac out of my bag and set it up (I started making the game on my PC).

New Project Day 1 of 7 Recap

After deciding to do this week long project yesterday, I jumped right in and started getting my hands dirty.  I'm using Unity3d to develop this game, I've been using it for 3 years or so now so I have a pretty good feel for working with it.  I also decided to make this an iOS/Android project.  If you want to ignore this wall of text, there's a movie at the bottom showing my progress.

I spent a bit of time mulling over what type of game to make.  7 days isn't a lot of time, especially when working more or less alone on this project.  I eventually settled on making a puzzle game that focuses on tapping and swiping.  Tapping and swiping are fun gestures to use on your phone, so I figured that would be a good basis to start from.

I started out making a system to lay out a grid of tiles to represent the puzzle pieces.  Once I had a grid layout working, I began working on some basic input so I could tap to select a tile and then tap another tile to force them to flip position.  To add some life to the tile movement, I used Prime31's GoKit Tween Library to animate the translation and scaling of the tiles so they felt more interesting.

Next I started working on the drag selection and line drawing system.  This turned out to be fairly involved to get working, especially the line-drawing part.  I initially tried using Unity's built in line rendering system, but that exhibited some annoying deformation when the line changed direction, resulting in an non-uniform line...ewww

Luckily I came across a blog with some solutions to this particular problem.  I ended up implementing a custom line rendering system using the Unity'd Graphics API, which worked wonderfully.  You can see the results in the movie below.

That's it for the 1st day recap.  Today I'll be working on adding the ability to unselect a tile when dragging, adding some constraints to the drag system, and beginning to create a backend system to track each spot on the board.

New Short Project Intro...I Guess

Today I decided to make a new game and ideally finish most of the heavy work on it within a week.  To help keep myself honest and on track, I also figured I may as well blog about the experience.  I'm not 100% sure what the game will be, however I'm leaning pretty strongly to doing a simple 2d tile-base puzzle game.  Mechanics for that are relatively simple to create, and there are a lot of cool game variations possible.

Why am I doing this?

My last project Shatter Crash took a little over a year to complete from start to finish.  I still enjoy playing the game and tinkering with it; however working on one project for that long, and as 1 part of a 2 man team, got exhausting.  Doing something short and focused on a tight set of core mechanics will be a breath of fresh air.

What are my goals?
Mainly to have fun and help get myself re-grounded and re-focused.  Finishing off Shatter Crash took a lot of energy and became a grind at the end.  I also want to focus on making something deliberately small in scope and laser focused on a core set of small features.  I tend to feature creep quite a bit, so this is also practice on keeping things small.

Obviously I don't have much to talk about right now as I'm just starting to get things ramped up.  I plan to do at least 1 entry a day to talk about and show off my progress.

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

System.Serializable attribute annoyances in Unity3D

I recently discovered the [System.Serializable] attribute introduces an unfortunate quirk when used in Unity3d, which is very annoying to get around.  When you mark a class as Serializable, Unity will automatically instantiate an object for any field you define of that class type.  Even if you want that field to be null.  Take the following code:

[System.Serializable]
public class SerializableDataClass
{
    public int SomeValue = -1;
}

public class NormalDataClass
{
    public int SomeOtherValue = -1;
}

public class MyMonoBehaviour : MonoBehaviour
{
    // Will Never Be Null, not expected
    public SerializableDataClass DataObj1 = null;

    // Will Remain Null Until Assigned, as expected
    public NormalDataClass DataObj2 = null
}

Logically, you'd expect MyMonoBehaviour's DataObj1 and DataObj2 fields to initialize to null and remain null until assigned an object to reference.  Unfortunately this isn't the case, DataObj1 will automatically have an object created and assigned to it, even if you initialize it to null and try setting it to null in other areas like Awake()/Start()/Update().  This behavior becomes very disruptive if you have logic that triggers based on if DataObj1 != null.

Unity3D EditorWindow Formatting Tip

During the past several months I've done a bit of work extending the Unity3D editor to create custom editor functionality for my upcoming game.  Unity makes it ridiculously easy to implement custom functionality in the editor, however their documentation can leave something to be desired.  One of the hidden nuggets I found is EditorGUIUtility.LookLikeControls() , which exposes custom formatting for certain EditorGUILayout elements.




Here's an example of using EditorGUILayout.EnumPopup() and EditorGUILayout.LabelField() to show some enum and string values.  As you can see the description label on the left is cut off, which makes this GUI very unusable.  EditorGUIUtility.LookLikeControls() lets you change the default pixel size of one or both of the content display fields for these methods, so you can make your GUI's much more readable.



Here's the same menu using EditorGUIUtility.LookLikeControls(250), which expands the first content zone to 250 pixels, and provides a nice amount of space to clearly mark the inputs for the menu.  And as you can see at the bottom, calling EditorGUIUtility.LookLikeControls() with no params will restore the GUI system to the default layout for these elements.