koobas.hobune.stream
A game entirely made with the new UI ?
HI, I have been doing games in SpriteKit, Cocos2D, UIKit, Flash before but am new to Unity. I want to to create a 2D game with large (perhaps x3 or x4) pixels. It is a strategy game with a scrollable hex tile map (about 150x150 tiles). The game doesnt have any physics involved, but I would like to have some small effects when the units are battling maybe. The game is for mobile, and maybe web, osx and win also later. I am using 4.6.0beta18. The camera will probably be orthographic ?
I am now a little confused as if to use UI-GameObjects (Rect Transform) or regular GameObjects (Transform) . What are the PRO's and CON's of using the different types ? Is there some things that CANT be done on a rect transform, like some kind of effects or something ?
Is there any implications of using one or the other when considering that would effect the enlarged pixel art style ? Maybe some enlargment stuff with the camera ?
I would like to be able to do:
Slide in/out menus
Particles (tiny sparks here and there)
Effects with shaders (tinting, blur)
Tap objects to triggers events (game logic)
Scroll a map with tiles larger than the screen size (ScrollRect looks nice)
Pixel perfect (if possible)
Hi, did you come to any conclusions about this? Can you share your thoughts?
Hi Carlos! I tried stuffing a bunch of tiles inside a ScrollRect and got a lot of issues with lag which I could not really figure out so I witched to regular 2d sprites and moved the camera ins$$anonymous$$d, and now the movement is smooth. $$anonymous$$ore info on the subject here http://answers.unity3d.com/questions/801417/translating-a-game-object-with-many-child-objects.html and also here: http://forum.unity3d.com/threads/is-scrollrect-insufficient.263833/
I have seen lots of complaints around related to the speed of moving rectTransforms as opposed to regular Transforms. It may be possible to build a full game with later updates. But at this stage I would not suggest doing it.
All of these things can be done using solely the new UI system. However, a lot of the actual game backend would need real code. But every UI feature you described can be handled almost entirely without any code. (The scroll rect stuff would probably require a little bit of code to manage.)
