2

I use the MVC programming model. I am running into a problem using Unity's hierarchy inspector. Say I have a Controller script: C_CardDrag. Now, because this drags a UI item thats nested several layers deep, it won't be readily apparenty that this C_CardDrag script is attached to an icon within in the card, and NOT the root object. You see what I mean in the image below (the blue highlight is where the C_Drag needs to be attached, NOT the top level object, otherwise the whole thing gets dragged when I only want the icon in the middle dragged). enter image description here

I feel that it can be VERY confusing to design and name classes when they need to appear on nested objects.

Do you have any design practices I can follow to make script names clearer to where they are attached?

For example say I have a Tree object, and it has several brances. And lets say I have a C_Tree script, and a C_Branch script. How would you handle making it clear that C_Tree goes on a Tree, a TOP level object, where as C_Branch goes on a nested UI object?

Update:

Found a good resource here: Component based game engine design

Community
  • 1
  • 1
Aggressor
  • 13,323
  • 24
  • 103
  • 182
  • 1
    The MVC model doesn't really apply (well) to a component-based framework like Unity. The GameObject (or prefab) can have components that can be either logic, data or managing the view (or a mixture). Having scripts that require to be added to objects in a certain part of the game object hierarchy and naming them based on their place in the tree rather than their purpose sounds truly awful. Instead, design your game objects and their scripts to behave as a union *and* to interact well with parent objects. – CodeSmile Nov 01 '14 at 20:07
  • 1
    I bet the confusing part stems from taking a good approach (MVC) applying it to a framework that doesn't actually support or condone the use of MVC, therefore this will actually make things more complicated than they need to be because you may not be taking advantage of the pros of a component-based framework with instantiable prefabs. – CodeSmile Nov 01 '14 at 20:12
  • Interesting thank you, can you suggest a good resource that explains a framework I can adapt to make sure I maintain consistency? – Aggressor Nov 01 '14 at 20:22

1 Answers1

1

Like any software that is being developed, you should only apply the appropriate Architectural and Design patterns that fit that project.

For example:

I was building a game that would be used for different devices. Although Unity lets you switch from Android to iOS seemingly easy. This game could be played completely differently on different devices, so I wen't with MVC.

Another game was built around Peer to Peer.

So overall you have a lot of options.

The way you can organize your files is by folders in the Project section of the Editor. I like to use something like this:

enter image description here

enter image description here

You will notice the Model is not in the Hierarchy. I don't use MonoBehaviours for models. In some cases, even the Controller could be non-MonoBehaviour code. That is why I prefer to have all the organization happen in the Project not the Hierarchy.

apxcode
  • 7,696
  • 7
  • 30
  • 41
  • Since you went with MVC could you perhaps show an example of how you would organize your GameObjects in hierarchy view? – Aggressor Nov 01 '14 at 21:53
  • Added, you will notice the Model is not in the Hierarchy. I don't use MonoBehaviours for models. – apxcode Nov 01 '14 at 22:14
  • Interesting, if you are doing a multiplayer game does that affect using MVC or no? – Aggressor Nov 01 '14 at 22:29
  • It doesn't, MVC is very versatile. – apxcode Nov 02 '14 at 01:09
  • So when you say you will have all the organization happen in the project, do you not have ANY objects in the hierachy at launch? You initiate them all from scripts first? – Aggressor Nov 02 '14 at 03:19
  • 1
    The only things I keep in the scene are static objects like buildings, boxes, things like that. Enemies I like to spawn on nodes. – apxcode Nov 02 '14 at 05:59
  • 1
    That is a good idea, since you might be working with level designers that need to move objects around. – apxcode Nov 02 '14 at 06:10