0
\$\begingroup\$

I want to be able to position 10 various game objects (sprites) within the area of the screen which will be dynamically sized accordingly to the screen size of the device. The area in which I want to position the items will be about 70% of the screen. The objects will be rectangles with irregular size (slightly irregular). The object should be positioned randomly (or in grid) within this area but they should not overlap. The objects will be a drop targets for other object which I will drag onto them.

To summarize I need:

  1. The area in which I can place objects.
  2. Random object position-er.

As I have been reading and watching various tutorials I have become very confused about how should I approach this.

Should I use a Rect to draw the area on which I will then place the objects, or should I use GUI/UI elements i.e. panel? Are the GUI/UI elements suitable for achieving this or are they meant to be only used to create games menus not for actual game play?

\$\endgroup\$
  • \$\begingroup\$ In Unity2D, you can use the sprites as GUI elements too. Are you talking about the new Unity GUI introduced in version 4.6? \$\endgroup\$ – MichaelHouse Nov 27 '14 at 16:46
  • \$\begingroup\$ Yes I've been thinking about the new UI elements from the Unity 4.6 since they are available now. \$\endgroup\$ – Krzysztof Gorak Nov 27 '14 at 17:15
0
\$\begingroup\$

In case if everybody will be looking for something similar, I have found what I have been looking for in the youtube tutorial made by Stuart Spence "Unity3D - Unity 4.6 UI Objects Created at Runtime". Also the release of Unity 4.6 brought the functionality which I wanted. Hope it'll help somebody.

| improve this answer | |
\$\endgroup\$
-1
\$\begingroup\$

GUI and 2D game objects are fundamentally different.

Generally speaking, a GUI element is a 2D element (texture/text) that will accept some input and could potentially live in some screen hierarchy (e.g. a panel in a container).

A 2D game object/element is... well, it's whatever a game object is in your game. It can move on its own, it could react to input, it could react to other objects, it could rotate for absolutely no reason other than a funky idly animation.

Most GUI systems will be geared at simplified behavior of a GUI element as described above, which means that if you want to do something a bit more complex than just show/react to input, you will find a GUI system to constrained for game elements.

With that said, there's nothing to prevent you from treating your game objects as GUI elements.

| improve this answer | |
\$\endgroup\$
  • 2
    \$\begingroup\$ I disagree. GUI and 2D game objects are NOT fundamentally different. Both can be based on sprites and both are of type MonoBehaviour. Especially when using world space GUI the destinction of both fades even more. \$\endgroup\$ – aggsol Nov 28 '14 at 8:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.