Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Mar 2013
Offline Last Active Today, 01:49 PM

Posts I've Made

In Topic: Unity Software Architecture - how to make reusable UI classes that inherit fr...

Today, 12:52 PM

While you're creating the UI, you know what you're using. In general, this should be Image (those are using Sprites). In some special cases, e. g. when the content is generated on runtime (e. g. once a second or more frequently), then the RawImage should be used, and only then. (If the Image is generated very seldomly, you could generate a Spriteout of it, but since its a somewhat costly operations, you can't do it to frequently, since this would have a huge impact on the performance.)
Right now, you might still have some GUITextures, but since you're starting to use the new UI system, you should get rid of anything done in the old UI system as fast as possible. Once that is done, you don't need those tightly-GUITexture-coupled anymore.

In the end, if there is no reason to do otherwise, you should _only_ have 1 Image component in use.
And even if you'll need to use RawImage additionally for some special cases, you will know if it is a generated Texture (-> RawImage) or a predefined Sprite (-> Image). So you know the proper type and you won't need abstraction.

Btw.: you have 8 tightly coupled scripts. What are those scripts doing?

In Topic: Unity Software Architecture - how to make reusable UI classes that inherit fr...

24 October 2016 - 02:59 PM

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;

In Topic: If-else coding style

09 July 2015 - 02:47 AM

I really doubt it's the style if if and else clause. If it really is then they are going to be hell to work with, just look how many answers people gave for what style they prefer.

But sadly, this was the problem, since the accepted solution is:

What was that pattern?

SomeType result = null;

if (somecondition)
    result = something;

return result;
Personally I'm not a huge fan of that, since it forces the reader to track the state of "result" as they look through the code, but it's used in many other places in our codebase, and consistency adds value.

Regarding the Name "GetSomething": properties in C# should never have a "Get", or "Set" as a prefix, so the name is wrong in any case.
But let's say, in order to get the value you want, you would need to do some calculations (the "magnitude" in Unitys Vector2 and Vector3 as an example), would you call a Method to get this value "GetMagnitude" or "CalculateMagnitude"? Does it matter for the calling site, whether or not the value is cached in a variable, or calculated on the fly?
In my opinion, "GetMagnitude" would be more suitable, since it doesn't define how the magnitude is retrieved. A "GetMeSomething" method doesn't imply the return of a member variable, and it shouldn't. You can see it this way: if you have a Vector and you want to get it's magnitude, you call it with "give me your magnitude" (assuming you can talk with your Vector, which I honestly can't do), what translates to the method name "GetMagnitude".

Before you respond, you should keep in mind: for me, object orientation isn't that much about the manipulation of data (member variables), but it's more about objects and their interactions.

In Topic: If-else coding style

07 July 2015 - 07:51 AM

As I tried to state earlier: "someCondition" is probably neither a member, nor a parameter, nor a local variable, nor a property. It's very likely just a placeholder for the real condition, as well as "something" is probably a placeholder for an evaluation/calculation.

In Topic: OOP: calling overridden method C#

07 July 2015 - 07:45 AM

If all components are assigned to the same GameObject, you should instead use the RequireComponent-Attribute.
public class SpartanKing : PlayerShape 

public class PlayerData : MonoBehaviour 

public class Player : MonoBehaviour
    void Start()
Unity will automatically assign the required components, as long as it's possible to assign them. Otherwise - an abstract class is required, such as "Collider" - you'll get an error message while trying to assign the component to a GameObject.