>>14573779
>>14573802
The solution really is just using objects properly.
I'm not a game developer so I'm not familiar with optimizing performance in a game engine. I imagine there's issues caused by amateur models, improper texture sizes, and who knows what else. He seems to utilize a lot of sprite effects that, if not managed carefully, could be ruining performance. I doubt he's taken time to configure occlusion culling, mipmaps, Level-Of-Detail optimization… although Unity might have some of that built-in by default. I'm really not familiar enough to say.
The problem is that he's using if/then/else trees to determine state, and everything in the game is chained together which means it all has to run in sequence. This also slows down development because debugging this would be a nightmare.
Each actor should have a script attached (this is obviously a necessity with Unity) and that script should have a behavior run every cycle (or frame, usually). This should trigger a private member function that handles behavioral changes. Instead, it's all embedded in these huge scripts.
He's running checks to see if the object is a teacher and if it has a flag set. Instead, Teacher should be a derived Person class with its own states and behaviors. Their main loop should do nothing more than check for whatever is important in that state. I'm reasonably confident that Unity can switch scripts, too, which means that each possible state could have its own script, reducing clutter even more.
I think that's really the most egregious error here: the massive trees are embarrassing, but they're a symptom of a great problem. He doesn't know how to utilize objects even though object-oriented programming is popular precisely because it moves us away from the style of coding he's doing. C# exists specifically to do the sort of things Java is good at but without being Java (because Java is just awful). It has all kinds of object-based optimizations that you just won't get from handling things like this.
He's literally setting an alarm manually when he could be calling an Alarm class to get the time, handle countdowns, display a UI element (which should also involve calling on a UI class)… the list goes on and on. He's doing things in-line that should be, at minimum, their own separate functions. Most of them would be better-off with classes, though.