Archive for June, 2013

Unity3D: the editor/code duality

So as most of you know I have been doing Flash for a long time and recently I have been doing Unity3d (well mostly NGUI you could say). It has been mostly fun and mostly rigid.

Rigid???

Yeah I would say rigid. Unity3d imposes you a way to work that is mostly to use the editor and not programming. They really really want you to use the editor. And coming from Flash this feels really weird. Probably because after 6 years of using Flash you kinda learn that the most you can do in code, the better and easier it is. Also, if you constantly switch between the editor and the code, it gets confusing, always switching paradigms.

GameObject for president!

GameObject is the root of everything you do in Unity, but one of the most annoying thing is that you can’t extend GameObject… Come on, let me do it, just the tip ;) . Here is what I would do if I could; I would make myself APIs for 2D. Moving something in x would be

gameObject.x = 30;

instead of

gameObject.tranform.localPosition = new Vector3d (30,  gameObject.tranform.localPosition.y, gameObject.tranform.localPosition.z);

Man have you seen the size of that thing just to move something in x???? Let me make it better for myself, I don’t care about 3D, I wouldn’t have a z value I would call it depth and it would make the code way more readable.

Encapsulation, what encapsulation

The other thing that bugs me is that to interact through code with a gameObject hierarchy you created, you basically have to know how it is built and you have to get your pieces using Find or GetComponent. Find statements are the ugliest ones as they use a string to get you what you want and is really error prone.

So you add your Script to your gameObject (proof that the editor is taking precedence over code) but to have interactions between multiple gameObject you have to do it through their scripts which you have to know their types, but have no idea if they exist and are linked or not. You’ll know at runtime when the error pops up.

Everything on a GameObject

Basically my point here is that you can’t do anything if it ain’t on a gameObject. Some core functions just won’t work if it ain’t. Like the WWW function(used to load stuff from the web) (really cryptic name if you ask me). It won’t work if it ain’t called from a MonoBehavior and MonoBehaviors can’t be instantiated, it needs to be added to a GameObject. So what about Models, code that only keep the states of an application or that loads data to hold it. Models have nothing to do with GameObjects, they should be allowed to use the WWW function. But no, if you want to, you need to create a GameObject, add to it a loading script, and wait for it to pass you back the data. Doesn’t that sound devious to you?

Let it define itself

I like Unity3d; it allows you to build for Android / iOs very easily, but the way it is so rigid really annoys me. I think that a project that is so young like Unity3D should not force the users down some path, it should let them find incredible and unthought ways of using it. I want to do 2D / UI with it and right now it is pretty annoying to do so.

, , , , , ,

6 Comments


NGUI Unity3d : Getting Screen size

I have been doing some Unity recently and so far it has been going very well. Hum, I bang my head on the wall sometimes but overall it’s fun. Except for when you search for something trivial and you can’t find anything. You see, they can say what they want but Unity isn’t a mature tech yet.

I am mostly doing UI, so I am using NGUI. It’s pretty neat, does pretty much what I want, but sometimes it doesn’t expose what I need, like the size of the screen. Well Unity has the Screen class where you can get the width and height of the screen and that is what I was using until I ran into some problems. I started by testing on my Nexus 4, then on the Nexus 7 and everything was fine until I tested on the Nexus 10. You see the Nexus 10 has a huge resolution and it was bigger than a little value that I hadn’t figured out what it was doing yet. The maximum height value on the UIRoot Script. This is actually a pretty nifty little thing. You see NGUI does some magic in the back when the resolution of the device exceed this value. It will scale the size of a pixel to be bigger that 1×1, scaling your content at the same time. When this happens the values of Screen.width and Screen.height are not measured in the same pixel unit has the NGUI one. So if you scale some background according to the number of pixels of your screen, it will be scaled way too big.

DisplaySize.instance.width

So I made this little static class to get myself the screen size in NGUI’s unit. I basically get the activeHeight from the UIRoot and I derive the NGUI Screen height and width from it. Here is the code:

public class DisplaySize{
	protected static DisplaySize _instance;
	public static DisplaySize instance{
		get {
			if (_instance == null){
				_instance = new DisplaySize();
			}
			return _instance;
		}
	}
 
	public GameObject gameObject;
 
	public float width;
	public float height;
 
	public void CalculateSize(){
		UIRoot mRoot = NGUITools.FindInParents<UIRoot>(gameObject);
 
		float ratio = (float)mRoot.activeHeight / Screen.height;
 
		width = Mathf.Ceil(Screen.width * ratio);
		height = Mathf.Ceil(Screen.height * ratio);
	}
}

So somewhere in your initializing code you need to pass it a gameObject that is a children of UIRoot and call CalculateSize. After that you can call DisplaySize.instance.width from anywhere in the code.

I am pretty new to Unity, so if you got a better way to do this, leave it in the comments.

, ,

No Comments