• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Alexia
      Hi all,
      A small team are currently undertaking a fairly large game project involving multi-playing, taming and other complex game mechanisms.
      We are looking for someone who is experienced in programming a wide range of mechanisms, more information is on our discord server. It is also a learning experience and we wouldn't expect you to know how to do everything we wanted, but just ask that you would be willing to learn how to.
      If you are interested in joining the (rather long term project) just message me and i'll add you on discord.
      Thanks for your time,
      Alexia 
    • By davemacdo
      I'm a formally trained composer (doctorate from Michigan State) who writes what most people would call avant-garde concert music. I love weird abstract projects, and I would like to work with somebody making a weird, abstract, artsy game. 
      You can find more about me and my music on my site. I have worked with acoustic and electronic sounds, including some procedurally generated and interactive computer music. 
      In particular, I would like to work on a project that lets me use Fmod to prepare an adaptive score for a game built on Unity or Unreal. I've been a music professor and would like to get experience working in this medium so that I can be a better mentor for my students. Send me a DM or email <davidjohnmacdonald@gmail.com> if you would like to discuss working on a project together. 
    • By Tuner_z

      Name: One Level: Stickman Jailbreak
      Price: Free
      Developer: RTU Studio
      Platform: Android
      Language: C# (Unity3D)
      Google Play: https://play.google.com/store/apps/details?id=com.RTU.OneLevel
       
      Hello!
      I want to show you my game! "One level: Stickman Jailbreak" is a puzzle game with unusual gameplay where you must help the character to escape from prison. You just need to take the key and get out alive. The game has only one level, and there are many ways to complete it. Not everything is as simple as it might seem at first glance, so there are clues in the game.
       
      Short description:
      Nobody escapes from here!
       
      Description:
      Tommy got into trouble again! Our hero is behind bars. But he's not going to stay in jail for a long time and he decides to escape. Tommy steals a key and gets out of the jail cell. But our friend doesn't go free: Tommy suddenly finds himself in the same room from which he just escaped! The conditions for escaping change every time. In order to go free Tommy will have to solve logical puzzles and you can help him in this!
      At first it will be easy, but the tension will increase, and the tasks will become more complicated with each level. You should use your brain for all 100%, but if your skill is not enough, you can use a hint or ask for help from friends!
      You can solve the puzzles alone or with your friends and spend time well!
       
      Features: 
      Features:
      - 48 unique levels;
      - the game is translated into 10 languages: English, French, German, Spanish, Italian, Portuguese, Russian, Japanese, Chinese, Korean;
      - the function of "help from friend";
      - hints;
      - instructions.
       
      Trailer:
       
      Screenshots:





       
    • By Brandon Marx
      Hello forum,
      I have some decent amount of experience in Unity making games for Software Engineering projects in college, these were very specific projects however and I still am fairly new to building games. I wanted to make a game that uses the shadows of objects for collision detecting (i.e. shooting a gun at a characters shadow causes that character damage. What is the best engine to do this in (game will be 3D), and does anyone have any advice on how to approach this concept? I consider myself fairly experienced in programming, but game dev is just an entirely different beast.
    • By juicyz
      Hey all,
      I've been slowly working on my game called AotW for a while now.  I have come to the conclusions that it would be nice to cooperate with 1 or 2 others to help finish it.  Ive been trying to keep my GDD up to date with my ideas and development so that would give a better overview of the game when the time comes.  Currently I have a basic skeleton of the RPG elements needed but everything can still be discussed and talked about and we can transform my idea to something the group likes.
      The premise of the game is a Diablo-like procedurally generated map with RPG elements that include sockets, inventory, classes, abilities, crafting, loot, items, sockets, and enchanting.  This will be done in a 2D iso view as I can't do 3D art and I enjoy 2D games a lot.
       
      I don't plan on releasing this as this is more of a hobby project for me and I have a full-time job.  Though I'd like to start putting more hours into development and having others definitely will be motivation.  I also want to be able to say I have finally "finished" a game idea to some degree.  If the time comes and we want to release it, then we can go ahead and do so but that's not my purpose or plan. 
       
      Discord:
      Juicyz#3683
       
       
      Thanks,
      Juicyz
  • Advertisement
  • Advertisement
Sign in to follow this  

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

This topic is 526 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