Design of code in this segment

[Scott_Turnbull]

I’m struggling with the code design in this section, I’m a software engineer and coding in Unity is sometimes counter intuitive. I’m trying to understand good Unity code design here but the things that seem counter intuitive to me.

1. We’re grabbing mouse input in different classes, which seems like it can get lost. Is this common in Unity? I would normally think of this as collecting mouse input in a single place and dispatching that to the appropriate handler.
2. Using a return in the Update method of the UnitActionSystem breaks out of the entire method right? Seems like this is going to be a problem if we have any code after it we still want to execute. I’d normally think to use something like break instead, Is that a bad practice in unity? (or to point 1, it would dispatch to the right handler and I wouldn’t have to break at all.)

[Brian_Trotter]

@Scott_Turnbull

We’re grabbing mouse input in different classes, which seems like it can get lost. Is this common in Unity? I would normally think of this as collecting mouse input in a single place and dispatching that to the appropriate handler.

Unity’s input handling mechanisms were designed to be as flexible as possible, both in the old system, and the new one. In the old input system, centralization seems to be a bit of an afterthought. The new input system is even more flexible, but it is easier to enforce a centralized input system. A great example of this can be found in our Third Person Combat and Traversal course.

@Scott_Turnbull

Using a return in the Update method of the UnitActionSystem breaks out of the entire method right? Seems like this is going to be a problem if we have any code after it we still want to execute. I’d normally think to use something like break instead, Is that a bad practice in unity? (or to point 1, it would dispatch to the right handler and I wouldn’t have to break at all.)

break is extremely useful in a loop, such as a for, foreach, do while, or while loop, but isn’t the correct syntax in the case of the Update method. While we do often refer to the Update() method as the “Update Loop”, it’s not really a true loop.
What Hugo has designed with this Update method is a simple state machine. In this case, the order of the if statements is critical. If there is any code that must run in each Update() method, it should generally come before the if condition statements. For example: You might have a timer that needs to update consistently. Best practice is to update the timer at the beginning of the method rather than the end.

Another alternative is to use an affirmative design instead of a blocking design for the Update(). While this can allow for post branch executions, many designers prefer a blocking design for readability.