Jump to content
  • Advertisement
Sign in to follow this  
lougv22

Unity Unity Software Architecture - how to make reusable UI classes that inherit from MonoBehavior

This topic is 609 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I am working on an indie game in Unity and I've recently decided to move all of my UIs (user interfaces) into Canvas game objects, which is fine and dandy, but it does require me to re-write some code. Specifically, I have the following architecture that relies on the interface game objects having a GUITexture component:

public class InterfaceHandler : MonoBehaviour
{

	/// <summary>
	/// Hides the GUI Texture.
	/// </summary>
	public void Hide ()
	{
		GetComponent<GUITexture> ().enabled = false;
	}

	/// <summary>
	/// Shows the GUI Texture.
	/// </summary>
	public virtual void Show ()
	{
		GetComponent<GUITexture> ().enabled = true;
	}


	void Start ()
	{
	
	}
	
	// Update is called once per frame
	void Update ()
	{
	
	}	
}
public class InterfaceHandlerA : InterfaceHandler
{

	public Texture2D[] Images;

	private int _imageIndex = 0;

	public int ImageIndex
	{
	    get
	    {
		return _imageIndex;
	    }
	    set
	    {
		_imageIndex = value;
	    }
	}

	// Use this for initialization
	void Start ()
	{
		Hide ();
	}
	
	// Update is called once per frame
	void Update ()
	{
		GetComponent<GUITexture>().texture = Images[_imageIndex];
	}

}

The problem is that with Canvas, there are no GUITextures. Instead I have to use RawImage or Image. So now I have to either re-write the code above (there are many more classes that inherit from InterfaceHandler, InterfaceHandlerA is just one of them) or write all new code that does the exact same thing, except with RawImage or Image instead of GUITexture.

 

This seems like a good opportunity to stop, take a step back, and really think about how to properly engineer this thing. I want it to be re-usable and maintainable, so that if a year from now Unity decides to replace Canvas with something else and there are no more RawImages, my code would still work. I am thinking maybe some kind of Dependency Injection might work here, or perhaps Generics, i.e. something like this:

public class InterfaceHandler<T> : MonoBehaviour

I tried the approach above, but it tells me that type T doesn't have a property called 'enabled'.

 

Any other ideas? What would be the best way to architecture this?

Share this post


Link to post
Share on other sites
Advertisement
I feel like I'm missing critical info here, but in general I wouldn't bother. This smells like over-engineering, but I also suspect that it's possibly motivated by mis-estimations of canvas.

How many uniquely coded UI elements do you really need to tamper with?

If you're doing something unusual then more information is necessary to answer questions about how to structure it. If you're not then look closer at what's available from the engine to makes sure you're not reinventing the wheel or missing some more concise way to do what you need.

Share this post


Link to post
Share on other sites

Is this some weird sort of sprite animation? I can't see any other reason why you'd be trying to switch a texture every frame.

 

If you want to hide a UI element in Unity, then you disable the object itself or the canvas.

 

It looks like you're trying to make a direct 1-to-1 translation of your old code, but the new system isn't meant to be treated that way.

Share this post


Link to post
Share on other sites

Yeah, the per-frame update doesn't make any sense. The index variable gets set on demand, but then the texture is updated every frame. Why not just update the texture in the set method?

Share this post


Link to post
Share on other sites

I feel like I'm missing critical info here, but in general I wouldn't bother. This smells like over-engineering, but I also suspect that it's possibly motivated by mis-estimations of canvas.

How many uniquely coded UI elements do you really need to tamper with?

If you're doing something unusual then more information is necessary to answer questions about how to structure it. If you're not then look closer at what's available from the engine to makes sure you're not reinventing the wheel or missing some more concise way to do what you need.

 

I am not very familiar with Canvas, so it may well be over-engineering, but I can't help but feel there is a way to design this so that it's re-usable and not tightly coupled to a GUITexture or RawImage or some other graphics class.

 

And I currently have 8 UI elements that have scripts inheriting from InterfaceHandler above. Most of them either call the Hide or Show method (or both) and set the texture property of the GUITexture component. Here is one more of them, this one alternates two image to create a very simply animation:

public class InterfaceHandlerB : InterfaceHandler
{
	private int _imageIndex;
	private float _speed;

	public Texture2D[] sweepingFrames;

	// Use this for initialization
	void Start ()
	{
		_imageIndex = 0;
		_speed = 3.0f;
		
		Hide ();
	}
	
	// Update is called once per frame
	void Update ()
	{
		if (CurrentState == State.Clean)
		{
			GetComponent<GUITexture> ().texture = sweepingFrames [_imageIndex];

			_imageIndex -= 1;
			_imageIndex = Mathf.Abs (_imageIndex);
			
			CurrentState = State.None;
		}
	}

Share this post


Link to post
Share on other sites

Is this some weird sort of sprite animation? I can't see any other reason why you'd be trying to switch a texture every frame.

 

If you want to hide a UI element in Unity, then you disable the object itself or the canvas.

 

It looks like you're trying to make a direct 1-to-1 translation of your old code, but the new system isn't meant to be treated that way.

 

Nope. That particular script simply sets a texture, to the GUITexture component, that shows what level the player is on in a mini-game, i.e. something like Level 1, Level 2, etc. Although one of the other scripts inheriting from InterfaceHandler does simulate a very simple two image animation.

 

Basically, I need a generic, re-usable way to hide or show a GUITexture, RawImage, or Image component and to also provide capability to change the texture (or sprite if it's an Image, as Image doesn't seem to have texture) attribute of said component to different images.

Share this post


Link to post
Share on other sites

You can use mechanim within canvas so that it's a lot easier to edit and manage your animations and they can be timed instead of frame locked.

Share this post


Link to post
Share on other sites

Nope. That particular script simply sets a texture, to the GUITexture component

 

So doing it in the Update function is the wrong place.

 

If you want to animate graphics, use their Sprite system. If you're changing text, use the Text object and change that. If you want to hide or show images, enable or disable the object or the component. Wrap these calls in functions if you like but trying to abstract away the entire engine is just going to cause more trouble than it solves.

Share this post


Link to post
Share on other sites
As others pointed out already, it would be better for you to just direclty use the methods and properties already available. Hiding an Image should be done by deactivating the game object. (This way, it also doesn't matter if it is an image, a text, or a composition of multiple UI elements.)
Same goes for setting the image: just assign it directly, unless you want to apply some special logic that really needs to be encapsulated in another component.

Besides that: You should store references to components you're using multiple times. Searching for them every time using "GetComponent" takes more time. If it is done once a frame, it's really worth the refactoring.
Also, you should calculate your _imageIndex with something like this._imageIndex = (this._imageIndex + 1) % this.sweepingFrames.Length;

Share this post


Link to post
Share on other sites

 

Nope. That particular script simply sets a texture, to the GUITexture component

 

So doing it in the Update function is the wrong place.

 

If you want to animate graphics, use their Sprite system. If you're changing text, use the Text object and change that. If you want to hide or show images, enable or disable the object or the component. Wrap these calls in functions if you like but trying to abstract away the entire engine is just going to cause more trouble than it solves.

 

 

I am not sure that creating abstractions would cause more problems. For example, currently I have 8 UI scripts for the minigame in question, which are tightly coupled with GUITexture. Now that I am switching to Canvas and planning on using RawImage components, I have to write 8 more scripts, tightly coupled with RawImage. Then what happens if I decide to add some Image components? I have to write more scripts, tightly couple with Image. While if I can somehow write generic scripts that handle all image components, that would save me a lot of extra code.

 

Somebody above mentioned using the Graphic class, instead of RawImage or Image, since both inherit from it. That sort of works, but Graphic doesn't have texture or sprite attributes, so I still have to write tightly coupled code.

 

I am currently pondering an architecture utilizing the Adapter design pattern. That might be what I am looking for.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!