You know, I'm something of a programmer myself.
I agree with you in spirit. If-else does not degrade performance, but cause lots of bugs.
But your arguments are not that hard to dismiss and are sometimes pretty vague. Let me take a try.
1. Unity profiler doesn't accurately represent what causes the performance drops. If physics, rendering and pathfinding take majority of your frametime, it's because you were too incompetent to set them up correctly.
You would have to prove to me, that the profile does not accurately represent performance drops. Thats kinda its whole reason for existing and its not like Eva developed it him self. It shows correctly, that physics, pathfinding and rendering are the cause of the bad performance. Experiments like looking down, looking away from the school or killing all students proves this.
2. Tying into the previous argument, the pathfinding is a broken and laggy piece of mess because it was integrated incorrectly; A simple event system and one pathfinding brain could create an NPC hivemind that would be both easy to manage and efficient.
Thats a really weird thing to say. How would an NPC hivemind speed up pathfinding? Every NPC still needs its own path calculated. It makes no difference, if a student asks the pathfinding brain, who ask the pathfinder for a path, or if a student directly asks the pathfinder. An idea, that would actually speed up pathfinding, is to precalculate paths. Every NPC is on a fixed route and the enviroment doesnt change. So just calculate some necessary paths in advanced.
3. The game doesn't use multithreading, despite the fact that a good portion of the plugins used in the project come with that functionality out of the box.
If you mean he should tick the "multithread" checkbox on his pathfinding plugin, then I agree. If you mean he should multithread his own code however, we already established that his code is not the cause of performance drops. Multithreading introduces just more bugs and is not worth it in this context.
4. Data oriented NPC approach would work well with data oriented pattern like ECS, but Yandere Simulator is using Unity's EC; it makes no sense to use a JSON file for students over inheriting from a base class and implementing their routines in there. It would also make creating special events much easier, maybe we could have had 7 rivals by this point if only these concepts were applied properly.
The json file is for properties and does not implement behavior. Many games use such files to load properties from. Its quite common. As for the different behavior of the different student, yeah he should at least make them different classes. The json file doesn't hurt much. It actually introduces *ABSTRACTION* (I knew you could do it devpai).
5. Implementing new character models would take a day of work for a competent developer. If Yandere Simulator can't have that, then there is something fundamentally wrong with the amount of cohesion present in the project.
You do read this thread right?? The problem with new character models is NOT that they are hard to drop in, but that they would screw up animations. Also this far in, these models this games face. To late to change that ever IMO.
6. Rendering is the most performance tanking task of the engine running Yandere Simulator; we're 6 years into the project and the school still isn't combined into a single mesh, which could halve the amount of time required to render it.
Maybe, maybe. But on the other hand, keeping the school in separate meshes allows the engine to do Occlusion culling or at least Viewport culling. That means, only the visible parts of the school need to be drawn. Not the entire school, which you would have to, if it was just one mesh.
7. Using linear interpolation for easing movement in and out is framerate dependent and only introduces new bugs. It is also a sign that you have no idea what you're doing.
Not unless the value determining the interpolation amount is itself time dependent.
y = interpol(x)
x += delta time
Perfectly frame rate independent.
y = interpol(x)
x += 5
Frame rate dependent
Would help if you could cite some code for you arguments.
8. Lack of any statemachine for NPCs; they can be in many different states (one at a time) and a competent programmer would think of implementing a transition system which would cut both the error potential and development time. Instead, we get hundreds of lines of code dedicated to edge case scenarios.
100% correct.
9. The game does not digress between the gameplay and presentation layer. A competent game designer would create a game that would run 'blindly', and then present that data in a read-only graphical format. Yandere Simulator introduces strong connection between its graphical representation and internal elements of game's structure, which makes the code dependant on the presentation layer that would have otherwise been read-only. This is the worst kind of cohesion, because the player can feel it while playing the game.
Again, some code citation would help. Unity kinda already does this for you, if you consider GameObjects to be gameplay objects and not presentation objects. For example, it does not matter, what model Yandere-chan uses, what hair style she has, what texture is applied or what material she uses. In that sense, the game already does abstract gameplay from presentation.
10. If speedrunning your Discord server provides people with more fun than playing your game, then there is clearly something wrong with your game design.
CONSUME THE you know it. Lol. Agreed.
There is a good video, that makes points I have never seen on here about YandereSims bad gamedesign. Yandere dev cant decide between an open sandbox game and a linear story game and it fucks both modes hard.
The real problem with Yandere Simulator (and no, it's not the YandereDev drama)
