[R&D] Unity First Impressions #3 #gamedev

We've in progress with a new Unity #game for mobile devices. Working on gameplay with early #prototype and sharing more first impressions.

We can't share a demo and material on #game it so some funny stuff instead  and more funny stuff in the end of article ;)

1. Development in unity is specified for the desktop, but when it comes to mobile devices, small problems that complicate the process and increase the testing time appear. I wasn’t able to find a way to emulate gyroscope accelerometer data etc. while testing in the editor itself. It all comes down to a long compilation process and then you still need to transfer everything to a devise or an emulator, which also takes more than enough time. Another thing that’s even more uncomfortable is editing the touch events, because they cannot be emulated with the cursor. A problem like that did not exist in the Flash+Starling. In fact, there was even a gesture emulation. Here you need to work with what you have. In other words, to use the keyboard and come up with something else. If you want to check the click through rate of the desktop objects, you’ll have to write a similar code, that reacts to the movement of the cursor with the pressed down button. By the way, if you write a code, optimized for multitouch, for pressing more than one button at the same time, during the reaction realization only one will work. It means that you’ll have to write a code for touch tracking anyway and there isn’t a way to make sure if it works in the editor during the quick launch, only after a long compilation and installation process. Long story short, there’s enough trouble.

2. When working with 2D gui objects, the incomprehensible coordinate system with the beginning in the center of the screen brings more problems. What I mean is that a point, which in the standard screen coordinate system is located in the upper left corner of the screen and its coordinates are (0:0), will have (-Screen.width/2 ; Screen.height/2) coordinates in the unity system. That doesn’t seem to be quite comfortable :) Maybe I just haven’t found a way to change the coordinate origin settings yet and everything is a lot more simpler. By the way, 2d elements can be set in the 3d coordinate system. Then the location on the screen can be measured with the floating point number from 0 to 1 and it automatically redraws after you change the screen size. It’s cool, but not when you need a pixel accuracy.

3. I almost managed to repeat the Flash application structure by operating the process from one class (a sort of Main). To do that, you just need to create an Empty GameObject and attach the code to it.

4. There’s also a lack of such ActionScript feature as the addEventListener. For a class, inherited from MonoBehaviour, there’s a possibility to reload the functions, that are called at specific events. There’s a lot of them (https://docs.unity3d.com/Documentation/ScriptReference/MonoBehaviour.html). You could say, that there’s one for every occasion, including the events, that react to collisions with other 3d or 2d objects, the beginning and the end of render, cursor click etc. However, there’s one negative side: if you need to track an event for many objects on the scene, you won’t be able to do that with a simple addEventListener line in the cycle. There’s more than one way out of this situation, but none of them is that simple. Such solutions aren’t good enough, if you need to quickly create something new and check if it works without fixating on the realization of such mechanism.

5. Unlike the MovieClip with one main class, the object in unity and prefab can have as many classes like that as you like. It’s really cool and handy. You can add a code while the program is running and in flash it was impossible. Access to such class: while in MovieClip we’re working directly with variables and methods, in unity GameObject we’ll have to use the GetComponent function. It looks something like this: (myGameObj.GetComponent("sizeClass") as sizeClass).width = 500;  you can save the link in the variable, so that there’s no need to invoke it every time. It codes well)))

6. The physics is great and simple to use. It saves time during prototype creation and especially things like inert object moving and their collision. Before in most cases mechanics like that had to be written manually or you needed an external framework. Here there’s no additional installations and complications. It’s enough to watch a couple of video lessons to make a judgment about the simplicity of physics http://unity3d.com/learn/tutorials/modules/beginner/physics

We've got a demo, working on features and playability but with unique gameplay can't show it as I've told before. So instead of sketches I thought to share funny and completely unplayable demo of Angry Birds in 3D (Web and Android Builds).

Also I'm still planning to expand Unity on Windows Phone impressions in previous article R&D for Moblile Game Development.

Previous parts of this article are here [R&D] Unity First Impressions #2 #gamedev and here [R&D] Unity First Impressions #1 #gamedev

That’s all for now, see You soon :)