OnGUI and the new UnityUI system

I'm going to fast forward a bit on this blog to the present day, or at least work I was doing today.  I mentioned before that I started Eruptoid back in the Unity 4.3 days.  Back in those days there wasn't a simple, easy to use, user friendly GUI design system.  Buttons were all created in code with an OnGUI function call.  Button and text positions were all determined in code, and called out sizes in pixels.  This is fine if you're programming for a single target resolution, but as soon as the idea of changing screen sizes enters the equation, all bets are off.  This was especially frustrating when programming for Android, since android devices at the time had screen sizes that ranged from 800x480 to 1920x1080.  So programming a button in the bottom right of a screen 800x480 would require completely different code than one at 1920x1080.  This forced me (and I imagine, everyone else) to do some major workarounds, or purchase 3rd party gui addons such as UGUI.  Here's an example of creating a button in the top middle of the screen that would reload the title screen:

if (GUI.Button (new Rect(Screen.width/2 - Screen.width/10, Screen.height/10,Screen.width / 5, Screen.height / 10), "Back to Title")){
Application.LoadLevel("Title_Screen");
}

Yep.  For each and every gui element I wanted to show on the screen, I had to do a relative position and size calculation manually.  It was tedious, slow, and obnoxious.  Plus, creating a style synergy between your GUI and the rest of your games aesthetic was a process I still don't understand.  So you end up with a pretty plain looking button.

Fast forward to today.  In Unity 4.6, they released a new feature called Unity UI.  It created a graphical user interface for the developer to implement a graphical user interface in their games.  Ground breaking stuff, I know.  It has a ton of features that were handled previously in an arcane style system known as a GUI skin.  Now each individual gui element can have its own style, and the workflow matches much of the rest of the Unity object oriented workflow.  Just drag and drop elements as needed into the inspector and the design area.

It uses a game object called a "canvas" to paint and position the UI onto.  The canvas can be relative to camera space, world space, or screen space.  And best of all, the Unity UI almost painlessly scales your UI elements flawlessly to any resolution.

I say almost painlessly, because there are still some things that feel like need a bit more work.  Text fields on buttons, for example, have an option to scale to fit, but don't have a very good way to constrain what area to scale inside of.  Obviously, text fits inside the button, but buttons can have different outlines/styles, and sometimes the text would end up overflowing outside the graphic for the button with certain styles.  I'm still trying to figure out all the nuance, but its a vastly improved system over the old.

Which brings me to today.  Today I spent most of the afternoon creating new borders for my panels and buttons, and the recreating my old OnGUI buttons and text fields into the new UnityUI version.  It makes things look way more polished than with the stock buttons.  To finish the example, here's a similar button now that does the same thing.

That border and background?  I made that using Blender.  It was a pretty simple process that I'll go into in a different blog post.  But here's a teaser screen shot.

I created a 3D lighted version of the border, and then rendered a 2D texture from it.  Blender is awesome.  Seriously.  If you have any interest in doing anything with art, from texturing to 3D modeling, to video editing and compositing, Blender is what you want to learn.

Blender blender blender blender.  Blender blender.  Blender Blender Blend.  Time for bed.

Materials do not work Thusly!

Last time I mentioned that, even after my week long marathon of unity tutorials, there was still much I did not know and much I did not understand.  I had hoped to be able to make about 14 levels for the game that would become Eruptoid using only the basic primitives that you can create inside the Unity Editor itself, and the stretching things using x/y/z scales.

The idea seemed like it would work at first, until I applied my first material.

The first material is actually a texture I still use in the game today, though I've done some work on it.  The simple grass texture for simulating rolling on a grassy plane.  I also had a simple stone texture for my walls.  Here they are right here:

 

Aren't they glorious?  So, with my stretched out floor and stretched out cubes, I added these textures as materials.

Well, the sides of the wall looks ok, and the top of the floor looks ok as well, but what the heck is going on with the top of the wall and the side of the floor?

Remember how I said I was using basic primitives (cubes) and scaling them to be long or flat?  Yeah, textures and materials don't understand that.  The engine believes that the object is still a 1 x 1 x 1 cube, even though its now a 10 x 5 x 1 block.  So it takes that beautiful texture you see above, and it stretches it out in the direction the primitive is scaled.  The only reason these textures look halfway passable is because I have the texture itself also tiled in that same direction.  That's all well and good for a single individual block.  But here's the thing: these settings work on a per material basis, not a per object basis.  So while the settings on the side here work for the wall we're currently looking at, they don't work for another set of walls.  And since the material is global, that meant I couldn't use only stretched primitives for my level design.  What could fix this?  Instantiated Materials at the engine level.  Unfortunately, that's never going to happen because instantiated materials that work on a per object basis would make about a million other things more problematic.  Lets just say you'd end up redoing your materials for every object you attached them to.  Better instead to do things the right way.

Being discouraged on the prospect of making levels with the unity editor alone, I actually only ended up making one of them.  After that I moved on to different challenges.  Learning experiences, really.  I set out to make game object that would directly affect the player, with physics and animation.

Stay tuned for the next blog post: Physics and Animation do not work Thusly!