- Joined
- Dec 27, 2015
even in 2080, regardless of what hardware it's run on, it'll still hog all the memory, bring the CPU to its knees and run like a slide show
Cultcow EvaXephon / Yanderedev / Alex Mahan / Alexander Stuart Mahan / cannotgoogleme - Edgy weeaboo coomer with pedo tendencies and 15+ years internet history as a lolcow, now known as a disaster developer behind eternal debug build called "Yandere Simulator", confirmed groomer and dollfucker
- Thread starter Juan But Not Forgotten
- Start date
- Joined
- Feb 4, 2013
Hey now, be nice to extreme scoliosis lady. She can't help that her tits grew way over on the right side of her body and that het left boob is twice the size of her right.
- Joined
- Apr 16, 2019
Oh my god, you’re right. When you actually use your eyes and think about the perspective, it can’t be unseen.
Hare Tomorrow Gone Today
kiwifarms.net
- Joined
- Jan 7, 2020
Alex Mahan has become pretty normal for successful people on the internet these days. It's not about talent, it's about being starved enough for validation that you'll post Youtube videos every day and farm ads for a corporate leviathan that sees no problem with directing kids to videos about Mickey raping Minnie to death. The web is now run by people who, in my day, would have been operating shady online casinos that required you to click on ad banners to spin a virtual wheel of fortune.
But regarding his code and use of Unity, I'd like to speculate on it. It's hard to say for sure what he's actually doing just from looking at a decompiler but...
First of all, it appears he's running one script for all students. There's been a lot of talk about the code, his "if else" spaghetti versus switch cases, but I don't know if in 1,700+ pages this thread has discussed Unity's structure and why Alex has programmed Yandere Sim like this:
Unity is "object oriented", which for our understanding in this thread could be simplified to say all the code is actually dragged and dropped into objects in the game and executed while those objects are present. This is handy and easy to learn in a lot of ways, especially for creating things like a user interface where you can place a "button" object on screen and then program that button's behavior directly into the button. You tell the button "if you're clicked on, execute the following code", and it's easy to compartmentalize and understand for humans.
However, there's a pitfall here and I think Alex has fallen into it. It's that you can drag and drop the same code into different objects. Therefore, if you wanted to write code for three buttons, you could write a single script and drag it into all three buttons.
This isn't REALLY what object oriented coding is meant to do, but it's possible and it would put all the code in a single document so that when you're programming you're not juggling between a bunch of different tabs. You could just make a unique program interaction with all three buttons and it would be faster because you aren't re-using any code at all anyway - the if statements are only checking what button is being clicked.
This forum has thrown around the idea that a case switch would benefit Alex's code, which has been rebuffed by a few others. The answer lies in between, as many answers do. Case switches are actually faster, but they're limited to switching a specific variable. You define with:
This is great, and when you have a lot of them they're treated as a dictionary lookup, which is faster than making a unique evaluation of each case like you'd go through with an "if" statement. However, you can see you're locked in to needing to know what the case is. It needs to be case 1, or case 2, or case "cabbages" or however you've defined the switch. It has to be that one thing. It doesn't work as conveniently if you need to check if, say, a particular character knows judo AND is also a student. It still can work, but then you'll start getting into nested statements again and it isn't necessarily saving computing time.
This is why more experienced programmers have been saying Alex needs to invest into inheritance, which structurally requires some planning. The simplest way to put it - and I know it's been explained before through video and elsewhere on the forum - is by imagining every student behaves exactly the same but has a unique reaction to a stabbing. You could call that reaction "Stabbing()". You'd have the parent code, which defines all the things all the students always do, and then a child class, which inherits from the parent. All you need to write is a unique Stabbing() class as an override in the child.
Now, in a really complicated game, you have many different types of students doing many different things, so using inheritance can become confusing if you don't know how it's organized. It's easy to imagine why Alex would become frustrated with another programmer who tried to refactor his code this way; it would make it to where Alex doesn't know where the code is anymore without parsing through a large density of information. It is what any reasonably complex game is going to need and it's more efficient, but you need to be familiar with the structure or else it can be like navigating a choose your own adventure book.
The inheritance concept is just an extension of what object oriented programming revolves around. Each object does its own thing, and if a set of things all behaves the same except for some specific variances, you still want to compartmentalize the code into the objects. That said, Alex may be using inheritance already, albeit not very well. In his mind perhaps every character needs to check if they're a ninja, or a Russian, or a teacher, or an eggplant before they know what class to call. It's honestly difficult to say because programming is always an exciting, experimental stew of seeing what works and trying to program fail-safes in case your program behaves in a manner that is theoretically impossible. Everyone approaches the stew a little differently and there are no recipes that make exactly what you want, or else you wouldn't be programming it (because after all, if it were already written it wouldn't need to be written again).
Finally, all this said - as for animations? I personally hate how Unity handles animations. In an effort to be user friendly, it has its own node-based animation interface. Having a lot of unique animations can lead to strings pointed everywhere like a conspiracy board. You actually CAN call animations from script, but frankly using their system is an extra pain in the ass thrown on top of the normal agonizing tedium of animation.
In a nutshell, if Alex plans to change the characters at some point, he won't have the freedom to change the models themselves. He might be able to change the hair or the face, or some other superficial details, but if the models are changed someone will have to re-animate everything.
But regarding his code and use of Unity, I'd like to speculate on it. It's hard to say for sure what he's actually doing just from looking at a decompiler but...
First of all, it appears he's running one script for all students. There's been a lot of talk about the code, his "if else" spaghetti versus switch cases, but I don't know if in 1,700+ pages this thread has discussed Unity's structure and why Alex has programmed Yandere Sim like this:
Unity is "object oriented", which for our understanding in this thread could be simplified to say all the code is actually dragged and dropped into objects in the game and executed while those objects are present. This is handy and easy to learn in a lot of ways, especially for creating things like a user interface where you can place a "button" object on screen and then program that button's behavior directly into the button. You tell the button "if you're clicked on, execute the following code", and it's easy to compartmentalize and understand for humans.
However, there's a pitfall here and I think Alex has fallen into it. It's that you can drag and drop the same code into different objects. Therefore, if you wanted to write code for three buttons, you could write a single script and drag it into all three buttons.
This isn't REALLY what object oriented coding is meant to do, but it's possible and it would put all the code in a single document so that when you're programming you're not juggling between a bunch of different tabs. You could just make a unique program interaction with all three buttons and it would be faster because you aren't re-using any code at all anyway - the if statements are only checking what button is being clicked.
This forum has thrown around the idea that a case switch would benefit Alex's code, which has been rebuffed by a few others. The answer lies in between, as many answers do. Case switches are actually faster, but they're limited to switching a specific variable. You define with:
This is great, and when you have a lot of them they're treated as a dictionary lookup, which is faster than making a unique evaluation of each case like you'd go through with an "if" statement. However, you can see you're locked in to needing to know what the case is. It needs to be case 1, or case 2, or case "cabbages" or however you've defined the switch. It has to be that one thing. It doesn't work as conveniently if you need to check if, say, a particular character knows judo AND is also a student. It still can work, but then you'll start getting into nested statements again and it isn't necessarily saving computing time.
This is why more experienced programmers have been saying Alex needs to invest into inheritance, which structurally requires some planning. The simplest way to put it - and I know it's been explained before through video and elsewhere on the forum - is by imagining every student behaves exactly the same but has a unique reaction to a stabbing. You could call that reaction "Stabbing()". You'd have the parent code, which defines all the things all the students always do, and then a child class, which inherits from the parent. All you need to write is a unique Stabbing() class as an override in the child.
Now, in a really complicated game, you have many different types of students doing many different things, so using inheritance can become confusing if you don't know how it's organized. It's easy to imagine why Alex would become frustrated with another programmer who tried to refactor his code this way; it would make it to where Alex doesn't know where the code is anymore without parsing through a large density of information. It is what any reasonably complex game is going to need and it's more efficient, but you need to be familiar with the structure or else it can be like navigating a choose your own adventure book.
The inheritance concept is just an extension of what object oriented programming revolves around. Each object does its own thing, and if a set of things all behaves the same except for some specific variances, you still want to compartmentalize the code into the objects. That said, Alex may be using inheritance already, albeit not very well. In his mind perhaps every character needs to check if they're a ninja, or a Russian, or a teacher, or an eggplant before they know what class to call. It's honestly difficult to say because programming is always an exciting, experimental stew of seeing what works and trying to program fail-safes in case your program behaves in a manner that is theoretically impossible. Everyone approaches the stew a little differently and there are no recipes that make exactly what you want, or else you wouldn't be programming it (because after all, if it were already written it wouldn't need to be written again).
Finally, all this said - as for animations? I personally hate how Unity handles animations. In an effort to be user friendly, it has its own node-based animation interface. Having a lot of unique animations can lead to strings pointed everywhere like a conspiracy board. You actually CAN call animations from script, but frankly using their system is an extra pain in the ass thrown on top of the normal agonizing tedium of animation.
In a nutshell, if Alex plans to change the characters at some point, he won't have the freedom to change the models themselves. He might be able to change the hair or the face, or some other superficial details, but if the models are changed someone will have to re-animate everything.
CJ_Sucks_At_Life
kiwifarms.net
- Joined
- Nov 27, 2019
I'm not super into programming and I see what your saying now. Its just that the if/then statement debacle is a easy thing to chuck around the thread because its easy to show with a single screenshot. In reality its way worse than that. There is just so much inefficiency in the code.
My example being the student scripts. I don't know how they are now (probably similar, I watched a couple of videos and they use similar methods to mess around with the code) but at the time of this video's release they were absolute dogshit.
TLDR: All the students run the same code, with the behaviors of every single other student in their code. They just have different variables to tell them to run certain parts. Example: Jimbo has the code for Jimbo's behaviors. But also has Cindy's, Jimmy's, and so on's code. Basically just a jumbled mess of code.
I haven't been on thread much as well but its also a easy example to throw at his lack of professional training.
(no professional training and his experience at a company was only a junior programmer)
An example of his lack of programming knowledge
I'm pretty sure adding this is just personal preference to variables. However don't qoute me on this.
But in summary its just a easy target to attack.
Last edited by a moderator:
Hare Tomorrow Gone Today
kiwifarms.net
- Joined
- Jan 7, 2020
What I mean when I say inheritance may be getting used sub-optimally is this: Let's suppose you're programming "Asparagus Simulator".
Unity comes with a few classes built in. Commonly used are Awake(), Start(), and Update(), which occur in that specific order (that is, an object is "awake" before it "starts", and it begins updating after it starts). Update is the only one that occurs every frame and you use is it for things that need to be persistently updated. All of these classes are already programmed for you by Unity, and these classes are inherited from "MonoBehavior", which is the default parent class Unity provides for you. But you can make your own classes that do their own specific things. Let us suppose your game also includes a grape and cantaloupe. You could write code like this.
In this case "TasteLikeCatPiss()" is a class that's full of its own code. You call that class from somewhere else. If that class is declared to be "virtual", you can then override it in a child script so TasteLikeCatPiss() could do practically anything.
But now let's say we have one script that controls if this object is a grape, cantaloupe, or an asparagus. It might read like this:
In the above, for simply the technical understanding, you have an enum, which is basically an integer that identifies itself through a text format. "Default" is actually 0, Grape is actually 1, and so on (-edit whoops, sorry, forgot to add a 0 "default" to the enum. enum starts at 0 and "default" is always 0, so we need an empty enum here). It's handy to read and understand as a human and harder to make mistakes with. But now let's say you need to break down Grape(). What kind of grape is it? Well, Grape is a class. It's a whole box of code all by itself, so you could make a child of this code that finds out what food the object is and then ALSO redefine what a Grape is by overriding the Grape() class.
See? You have bad code that should really be object oriented across the board, but then all of your scripts inherit this bad code. The child contains the code from the parent. It contains all the case switches, AND it contains Disappointment() and TasteLikeCatPiss() even though a grape will never access that code. So it's absolutely possible to be using inheritance but still be using it poorly. So who knows? It's relatively fundamental, and his NPCs must be getting unique instructions from somewhere (there could be several theories from where) so Alex may be using it and just isn't using it well.
Regarding adding a "this" prefix to all the global variables - this makes a lot of sense to me. Solo projects are nice in that you personally will always have some mental attachment to your own code. You can still get lost, but even when you do you'll have some memory of what you're doing and you'll understand your own organizational scheme. People talk about needing to break work up into parts and achieve things in fragments, but when you work by yourself you can totally just start at the beginning and plow through until you get to the end. YOU do all the work, so who cares what gets done first so as it leads into the next thing!
But working on a team requires an additional level of coordination. So this guy looked at Alex's public variables, which are variables that can be accessed by other scripts or from Unity's drag-and-drop UI, and he put "this" in front of all of them so he'd know if he was tampering with code that might be accessed by scripts he's not currently looking at. You wouldn't want to change that variable and then have to debug hundreds of outside dependencies that were stealthily screwed up by that. Meanwhile, if the variable doesn't say "this", he knows he can just change it and everything that variable affects is there in its own, safe, contained space.
Continuing to use the code I wrote as an example, you see how I've got "public" in front of the enum declaration? That's because a child class can only access the parent variables if they're set to public or protected. It's important to be aware that changing that variable might cause issues with all the child scripts too, but you cannot see that from the parent script. What that programmer was doing wasn't hacky or wrong - it was a good practice and it was good he was doing it.
And the end of the day, I feel like this is all Alex's real value to the rest of us. What we learn by examining his work and taking apart what he has done wrong, it allows us to build better projects by avoiding his mistakes. The NiceToMeetYou videos are wonderful. I feel like just hearing about practices Yandere Sim should be using is a fascinating, practically story-driven way to introduce potential new programmers to concepts they should be asking about.
Unity comes with a few classes built in. Commonly used are Awake(), Start(), and Update(), which occur in that specific order (that is, an object is "awake" before it "starts", and it begins updating after it starts). Update is the only one that occurs every frame and you use is it for things that need to be persistently updated. All of these classes are already programmed for you by Unity, and these classes are inherited from "MonoBehavior", which is the default parent class Unity provides for you. But you can make your own classes that do their own specific things. Let us suppose your game also includes a grape and cantaloupe. You could write code like this.
In this case "TasteLikeCatPiss()" is a class that's full of its own code. You call that class from somewhere else. If that class is declared to be "virtual", you can then override it in a child script so TasteLikeCatPiss() could do practically anything.
But now let's say we have one script that controls if this object is a grape, cantaloupe, or an asparagus. It might read like this:
In the above, for simply the technical understanding, you have an enum, which is basically an integer that identifies itself through a text format. "Default" is actually 0, Grape is actually 1, and so on (-edit whoops, sorry, forgot to add a 0 "default" to the enum. enum starts at 0 and "default" is always 0, so we need an empty enum here). It's handy to read and understand as a human and harder to make mistakes with. But now let's say you need to break down Grape(). What kind of grape is it? Well, Grape is a class. It's a whole box of code all by itself, so you could make a child of this code that finds out what food the object is and then ALSO redefine what a Grape is by overriding the Grape() class.
See? You have bad code that should really be object oriented across the board, but then all of your scripts inherit this bad code. The child contains the code from the parent. It contains all the case switches, AND it contains Disappointment() and TasteLikeCatPiss() even though a grape will never access that code. So it's absolutely possible to be using inheritance but still be using it poorly. So who knows? It's relatively fundamental, and his NPCs must be getting unique instructions from somewhere (there could be several theories from where) so Alex may be using it and just isn't using it well.
Regarding adding a "this" prefix to all the global variables - this makes a lot of sense to me. Solo projects are nice in that you personally will always have some mental attachment to your own code. You can still get lost, but even when you do you'll have some memory of what you're doing and you'll understand your own organizational scheme. People talk about needing to break work up into parts and achieve things in fragments, but when you work by yourself you can totally just start at the beginning and plow through until you get to the end. YOU do all the work, so who cares what gets done first so as it leads into the next thing!
But working on a team requires an additional level of coordination. So this guy looked at Alex's public variables, which are variables that can be accessed by other scripts or from Unity's drag-and-drop UI, and he put "this" in front of all of them so he'd know if he was tampering with code that might be accessed by scripts he's not currently looking at. You wouldn't want to change that variable and then have to debug hundreds of outside dependencies that were stealthily screwed up by that. Meanwhile, if the variable doesn't say "this", he knows he can just change it and everything that variable affects is there in its own, safe, contained space.
Continuing to use the code I wrote as an example, you see how I've got "public" in front of the enum declaration? That's because a child class can only access the parent variables if they're set to public or protected. It's important to be aware that changing that variable might cause issues with all the child scripts too, but you cannot see that from the parent script. What that programmer was doing wasn't hacky or wrong - it was a good practice and it was good he was doing it.
And the end of the day, I feel like this is all Alex's real value to the rest of us. What we learn by examining his work and taking apart what he has done wrong, it allows us to build better projects by avoiding his mistakes. The NiceToMeetYou videos are wonderful. I feel like just hearing about practices Yandere Sim should be using is a fascinating, practically story-driven way to introduce potential new programmers to concepts they should be asking about.
Last edited:
- Joined
- Apr 16, 2019
No man I talked to Yandere Dev on Discord and he said the programmer did that because he was a stupid dumb poopy head. Nice try gremlin!
CJ_Sucks_At_Life
kiwifarms.net
- Joined
- Nov 27, 2019
I see how you see this. Kind of reminds me of a disaster like Fyre Cay. The marketing campaign so bad that its basically the prime example on how to not market something. But the fact that people are paying him to do this just makes me sad honestly. There are so many other projects that probably lost attention because this game was hogging it. The fact that there was no patreon rewards as well kinda just makes me feel sorry for the people tricked into this. Thanks for the discussion on how variables worked though! Was great!
- Joined
- Jul 25, 2016
India became a superpower before even Osana got finished. Virgin Yanderedev vs Chad Streetshitter.
CJ_Sucks_At_Life
kiwifarms.net
- Joined
- Nov 27, 2019
- Joined
- Apr 16, 2019
Are we getting to the point where when the game turns 6 years old, everyone will realize that’s not a good thing?
- Joined
- Jan 4, 2019
Nah Jay is still in denial and thinks this game is going to get completed regardless of the time. Kudos to Alex for keeping the charade up for so long.
- Joined
- Nov 26, 2017
Jay sounds like he's very carefully choosing his words and being polite since the game is a big draw for his channel, but he might know it's a dumpster fire doomed to never be completed.
And he's right: why the hell won't Alex just release it early access and let the players be your free QA team. Well, you know, other than arrogance and thinking he's going to have a perfect playable demo to show all those gremlins.
And he's right: why the hell won't Alex just release it early access and let the players be your free QA team. Well, you know, other than arrogance and thinking he's going to have a perfect playable demo to show all those gremlins.
- Joined
- Jun 28, 2019
I remember, Alex once said that he didn't wanna look back on his twenties and see his whole life poured into life yandere simulator. And to that I can only say congrats, man. Because instead you can look back on the past decade and see your whole life being Kiwi Farm fodder.
- Joined
- Jan 10, 2020
By the time the game is out it'll be old enough to star in these hentai games.
After months of lurking I make an account for this one dumb joke
- Joined
- Apr 19, 2019
He still keeps adding shit to the game rather than just making and deciding the core mechanics.
If you were to even use the free version of unity you could have something up and running within two weeks. Scripts exist for Line of Sight and enemy detection you can build the stealth parts rather quickly and then fine tune them.
If you were to even use the free version of unity you could have something up and running within two weeks. Scripts exist for Line of Sight and enemy detection you can build the stealth parts rather quickly and then fine tune them.
- Joined
- Aug 1, 2017
Some of that's gotta be him being bitter about skullgirls and wanting to prove He Can Code, because really if you can describe any part of a game's mechanics with a direct comparison to a different game there's almost certainly a package on the asset store to do that for you. Either that or he's just a cheapass on the top of the Dunning Kreuger hill and thinks writing it all himself can't possibly be hard (IT IS).
Forgive me, but programming nerd gotta nerd. Skip if you dgaf about unity.
That's a method, not a class. MonoBehaviour is the base class and Awake(), Start() etc are just virtual methods that get overloaded when you subclass it. (also, start() before awake() - start is basically the surrogate constructor, awake() is the 'i just became active in the scene' hook). You're dead on about the enum switching being stupid, although it can be completely fine if it's controlling some simple aspect of the class that's not going to change in derivatives or change very little based on a very specific thing the subclass might need.
Of course.. in order for enum switching to be viable he'd have to use them instead of a gigantic mass of bools.
Also regarding the 'this.' prefix on everything : A bunch of automated code-generation-from-template tools (including roslyn, aka the actual C# interpreter being run in reverse) will do this just to explicitly block any possibility of variable name conflicts. I'm guessing the new guy threw out some boilerplate with one of these or the converter yandev used when he 'ported' YS from JavaScript to C# did it.
Forgive me, but programming nerd gotta nerd. Skip if you dgaf about unity.
That's a method, not a class. MonoBehaviour is the base class and Awake(), Start() etc are just virtual methods that get overloaded when you subclass it. (also, start() before awake() - start is basically the surrogate constructor, awake() is the 'i just became active in the scene' hook). You're dead on about the enum switching being stupid, although it can be completely fine if it's controlling some simple aspect of the class that's not going to change in derivatives or change very little based on a very specific thing the subclass might need.
Of course.. in order for enum switching to be viable he'd have to use them instead of a gigantic mass of bools.
Also regarding the 'this.' prefix on everything : A bunch of automated code-generation-from-template tools (including roslyn, aka the actual C# interpreter being run in reverse) will do this just to explicitly block any possibility of variable name conflicts. I'm guessing the new guy threw out some boilerplate with one of these or the converter yandev used when he 'ported' YS from JavaScript to C# did it.
Last edited:
- Joined
- Apr 10, 2019
- Joined
- Aug 19, 2015
And every time he adds a new feature or "easter egg", his code gets more bloated, slow, unorganized, and incomprehensible to anyone who isn't him. At least his failures can be learned from, though.
- Joined
- Jul 25, 2018
Failures like what? Don't be a massive lolcow? For 99% of the population that isn't something that needs to be learned in the first place.