And now, should I create separate scene for each group of (question-answer-animation) or maybe one scene and write everything in one script file using many if statements? I’m planning to run this quiz on mobile devices so which solutions gives me lighter binary package? Or maybe scene doesn’t weigh at all?
Personally I’d go with the one script file, it depends on how you’re doing the GUI or the animations, but it should load pretty fast even as one scene file rather than multiple scene files having to unload and load - also, if you want an end result it’s a lot easier containing it to one scene rather than writing to an xml file or playerprefs then referencing it in (and could cause a hiccup in doing so, every write you make to it due to I/O).
Try avoiding OnGUI. nGUI or some other GUI solution which batches would probably be preferable for you.
Honestly, I was going to use onGUI Why should I avoid it? It has some memory lake or something? Where can I find alternative to onGUI? I read the description about nGUI and found that it’s paid lib ;/
Depends on your target platform and how intensive your game is going to be. On mobile you definitely want to use a package like NGUI, or perhaps one of the free GUI alternatives because onGUI is terribly slow and difficult to work with.
If you’re deploying to desktop and are just going to be putting some questions on the screen and you’re happy with how it looks, then I guess onGUI is fine for you.
Shouldn’t use OnGUI mainly due to the drawcalls and some other stuff I can’t quite remember, it’s just plain slower and resource hogging.
Although if it’s the only thing on screen, what you could do is think of how many of these OnGUI elements you might use and make an average number. Then make a script with a few default elements, doesn’t quite matter about where they are in terms of resolution on screen as long as it’s visible, and copy+paste a bunch of them until you hit that average.
Test it on your mobile device if you have one locally, and see if it performs substantially “OK” in terms of FPS / interactivity.
If you can’t find any free GUI alternatives, or dislike them, you could use a raycast w/ quads. Based on touch input draw a ray and see which polygon mesh (quads) are being touched, and then change textures to represent feedback changes (eg: radio buttons). Although that doesn’t quite help with fields all that much.
As has been suggested, try OnGUI first - think of how many elements you may use (eg: 10 elements consisting of fields, radio buttons, etc) and then render this amount on screen (with maybe a fudge factor, so maybe render 15-20 of these on screen to future proof yourself with this decision). If they work on screen, are functional and aren’t with any major performance implications - you should be fine.
Also test an animation, what type of animation did you want? If you want the OnGUI background boxes etc to fold and bend and move around…you may be out of luck with the complexity, and constraints of onGUI - in which case try an alternate method of “closure animation” or another GUI solution as we’ve said.
In Unity, Window > Asset Store and you’ll have access to the store…menu on the right, “Categories”, Scripting > GUI. You can go through other GUI methods here.
Why should I avoid it? It has some memory lake or something? Where can I find alternative to onGUI? I read the description about nGUI and found that it’s paid lib ;/