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

The end of EvaXephon?


  • Total voters
    2,417
Despite all that’s happened, most of Alex’s videos still get millions of views. Interest in the game is still moderately high, so I wouldn’t be surprised if the Kickstarter gets at least an adequate amount of money.

I’m not sure if this is an accurate comparison at all, but Yan Sim is a lot more well-known than other successful Kickstarter games.
His high sub count is the main reason why I’m curious to see how well his Kickstarter will work out. It’s hard to say how far most of his YouTube fans will really go to support the game when the time comes because clicking a subscribe button and watching the occasional update video is free after all. Alex could get tens of thousands of dollars while the Youtubers get hyped, he could get his usual $2k that he sees from Patreon if nobody new is willing to step in, or everybody will be collectively disappointed by the KS/demo and he’ll get even less than what is Patreon is making.

One thing that I’m certain about regardless is that his fandom has been increasingly more disconnected and passive now compared to previous years. Interest in YS has been in steady decline, and it may be so low now that not even a demo of Osana can really save the hype (especially if that demo sucks, which we all know it will).
 
  • Like
Reactions: 2hufag
Here's a screenshot of it if you're interested:

bIVVQ90.png

Why can't he just use a switch statement? It'll make life a whole lot easier, and speed up compile times.
 
Stop parroting other people. You wouldn't gain anything using switches here, you'd just make things less readable.

However, he should fetch the info from data files instead of doing everything via code. It was already a big problem of his in the past, it's quite astonishing he didn't learn anything after all those years.

edit: oh fuck, that was a post from 2016 you had to dig up...
 
Stop parroting other people. You wouldn't gain anything using switches here, you'd just make things less readable.

However, he should fetch the info from data files instead of doing everything via code. It was already a big problem of his in the past, it's quite astonishing he didn't learn anything after all those years.

edit: oh fuck, that was a post from 2016 you had to dig up...

Holy fuck, that's funny. Switch statements play a fundamental role when it comes to compiled languages. If they don't provide you with any gain whatsoever, they wouldn't be included with any of the C family of languages.

"you'd just make things less readable"
You see a switch statement, you instantly know it's matching a bunch of values. Are you really that narrow-minded?
 
No, you're wrong. The compile times would not change.
Even performance-wise it'd be exactly the same only at 3+ cases would C# begin to use a jump table with slight increase in performance at runtime





You're both being fucking exceptional, he literally shouldn't use a switch here.
You should only use a switch if have a single condition that is being evaluated he clearly has multiple booleans being checked and nested within each other.
Honestly, YandereDev is a better programmer than both of you if you can't tell that just by looking and instead just spout the "use switches instead of ifs" meme.

And for shits and giggles here is your "more readable" code.

Code:
switch(Male)
{
    case false:
        switch(Teacher)
        {
            case false:
                FemaleHair[Hairstyle].active = true;
                ...
                break;
    
            case true:
                TeacherHair[Hairstyle].active = true;
                ...
                break;
        }
    
    case true:
        MaleHair[Hairstyle].active = true;
        ...
        break;
}

switch(Male)
{
    case false:
        switch(Teacher)
        {
            case false:
                if(FemaleAccessories[Accessory] != null)
                {
                    FemaleAccessories[Accessory].active = true;
                }
                break;
    
            case true:
                ...
                break;
        }
}

Wow, so much better right?!!

Switch statements are usually much more efficient than using if and else statements. I have noticed improved performance during compile times with switches. Then again, I'm a C++ guy, results may differ.

"YandereDev is a better programmer than both of you"
Really? If you have played his game for any amount of time, you would notice the amount of resources the game takes up, and how pathetically slow it runs. Also, you've never seen either of our code to make that judgment.

This guy explains it pretty well.

We'll leave it at that because I'm here to laugh at people, not argue about bullshit we all don't benefit from.
:story:
 
Last edited by a moderator:
For the sake of not letting the thread go to shit, here's a new Nice Tomeetyou video:

It's funny how a few minor code changes can boost loading speed and framerate so dramatically. I feel like Alex is just shooting himself in the foot by not fixing his code. At the end of the day, all that poor code will just increase the time it takes for him to develop the game.
 
Holy fuck, that's funny. Switch statements play a fundamental role when it comes to compiled languages. If they don't provide you with any gain whatsoever, they wouldn't be included with any of the C family of languages.

I think you're overstating matters. There's genuine performance boost in using a switch statement, but said boost is only noticeable in asymptotic analysis-- that is, you'd have to have a lot of conditionals (we're talking millions in a particular sitting) in the first place in order for the use of switch statements to matter at all vis-à-vis plain if-else statements.

Of course, I've only seen snippets of the guy's code, and it was a long time ago, but I'm inclined to believe him when he says that the primary performance impacts are the graphics, the physics calculations, and the pathfinding-- and except for the last bit, he can't do much in that department (given the conceit of the game; all of the calculations a character instance does per frame are multiplied by a hundred). Long if-else-if chains aren't going to be the death of a program's performance when there are bigger fish to fry like the aforementioned performance impacts, and for that matter, that kind of optimization can be done after the infrastructure of the game is fully developed (to do so beforehand can be easily considered premature optimization, which is improper when you have no idea about the impact of code you haven't implemented yet).

In my experience (in particular, I've done work with Unity in the service of developing a video game myself), unless there's direct flaws in a script (e.g. using the wrong time step), the scripts are just outright doing operations that move up the runtime complexity in orders, (e.g. O(n) to O(n^3)) or there's excessive object instantiation without strategic destruction, the scripts won't have the potential for causing severe performance issues.

I've seen that rather than using integers or enumerations, YanDev uses strings to note certain values such as those for colors, and so in the process of doing things like a color check, he necessarily does comparison of strings (which itself is done in linear time). There's the aforementioned if-else chains. There was something else I saw but I can't quite describe it-- I think it had to do with recognizing a game over scenario, and in that, there were arguably unnecessary comparisons. He compares bools to bool literals in conditional arguments instead of just using the bang. Something about not using polymorphism where he could...? Those are some of the complaints I've seen off the top of my head.

I don't think any of these things matter in the grand scheme.

If-else chains are only slower than a switch block asymptotically. Comparison to a bool literal versus negating the variable with a bang are rendered into the same machine code. String comparisons instead of integer comparisons aren't going to kill anything-- I mentioned earlier that a string comparison is going to run in linear time instead of the constant time of an integer comparison, but we're not working with vacuum tube computers, there's a finite number of such comparisons as far as I've seen where they are, and they don't run on every frame (AFAIK).

And that's to say nothing about the optimizations that a compiler does automatically.

I saw a good bit of a controversy bubble-up with YanDev back in June of last year, and in the process, I saw a lot of people trying to tackle the code issue and only being able to produce "muh nintendo switch statements" and "muh mom's spaghetti code", and even fewer trying to genuinely tackle the issue (I think I saw a comment from one guy in the comment section of a comparatively inferior but still earnest video speaking from a skilled viewpoint). In general, it was a bunch of people who read the TutorialsPoint page on switch statements in C# and not much else trying to talk about the work of someone who's actually done work in the field (it's not like he worked with any of the greats, and IIRC he went to coding bootcamp instead of working out of college, but he's some sense of competent), and even more, these people had a particular idea about how clean and intuitively understandable codebases were supposed to be as if they never graduated high school or college even though it was clear that they generally never coded at all (I watched a video where someone did a comparison between a snippet of YanDev's code and a snippet of a basic Unity script exercise, and the only issue at hand was that the former's code was messier because both-- without considering the complexity underlying the called functions-- would have the same runtime complexity).

Nobody asked "how does this code work in the context of the rest of the code base" or "how often does this particular code have to run". Everyone is just automatically repulsed by messy code even though the only people who have to actually work with the code have to consider the debuggability of the code more than how clean it looks or how clever it is.

The question of performance, at this point, is answered through the consideration of the macro-elements of the game rather than something like the scripts. The questions should be "how should the other students be rendered when they're not in view, if they should be at all?" or "how much should be allowed to be drawn when it's not in view", not "why aren't you using predicates?".
 
Last edited:
It's funny how a few minor code changes can boost loading speed and framerate so dramatically. I feel like Alex is just shooting himself in the foot by not fixing his code. At the end of the day, all that poor code will just increase the time it takes for him to develop the game.
That's assuming he'll ever finish his game. He should seriously get someone else to do his coding for him if he's this incompetent, especially now that his game has been in development for six years. But then again he has a pretty shady past of not creditting people and outright stealing other people's work so he'll probably find it difficult to find anyone willing to work with him.
 
Quite interesting that Yanderedev needs to break game rules (i.e. giggle/radio distraction, asking student to distract other student) to make an OP character to BALANCE a game. I dunno, it sounds unfair to players and usually if your game is unbalanced, you fix the rules and mechanics of a game.
This is my biggest problem with the game. Yandev arbitrarily breaks his own rules without any explanation. How is a new player going to know why Raiburu wont respond to radios? The game never explains it.

More examples of this is the fucking ridiculous system for electrocuting students and the inconsistency in what items show up in your inventory.
 
  • Agree
Reactions: Lexi62
This is my biggest problem with the game. Yandev arbitrarily breaks his own rules without any explanation. How is a new player going to know why Raiburu wont respond to radios? The game never explains it.

More examples of this is the fucking ridiculous system for electrocuting students and the inconsistency in what items show up in your inventory.
Honestly, Raibaru sounds like she's more of an annoyance rather than a genuine challenge. Yandev already struggles at establishing what you can do in Yansim without the usage of his Youtube videos so by not explaining how to take down Raibaru, the player is gonna have absolutely no idea where to even start.
 
In theory, I actually like the idea of Raibaru- she could be a good introduction to future 'bodyguards' or whatever Alex wants to call them. The problem is that Alex doesn't understand good game design and (as said before) Raibaru's ended up as an annoyance rather than a challenge

The easiest way to fix it is to only have her at certain parts of the day; on a Monday she might be with Osana in the morning, on a Tuesday in the afternoon, on a Wednesday during lunch, ect. That still leaves an easy opening for Osana to be vulnerable but also requires the player to stalk her, in case Raibaru shows up, and to plan their elimination methods around her.

Or, even better, Alex can get rid of her and reuse her for a later, harder rival, because he seems to forget that Osana is the tutorial rival.
 
Alex has a “unique” game design philosophy of constantly adding shit instead of reworking stuff, and he thinks the former can be a replacement for the latter.
 
  • Winner
Reactions: MagneticTowels
In theory, I actually like the idea of Raibaru- she could be a good introduction to future 'bodyguards' or whatever Alex wants to call them. The problem is that Alex doesn't understand good game design and (as said before) Raibaru's ended up as an annoyance rather than a challenge

The easiest way to fix it is to only have her at certain parts of the day; on a Monday she might be with Osana in the morning, on a Tuesday in the afternoon, on a Wednesday during lunch, ect. That still leaves an easy opening for Osana to be vulnerable but also requires the player to stalk her, in case Raibaru shows up, and to plan their elimination methods around her.

Or, even better, Alex can get rid of her and reuse her for a later, harder rival, because he seems to forget that Osana is the tutorial rival.
Perhaps worth mentioning that I’ve seen the “actual” bodyguard idea from fans of yandere simulator a number of times, for the last rival. Because her dad is canonically paranoid and also rich.

Also new blog post:
 
Alex has a “unique” game design philosophy of constantly adding shit instead of reworking stuff, and he thinks the former can be a replacement for the latter.
It's called: "Making a case for the producer's role in most creative projects because the idea people have no idea to actually settle for anything."

He should totally add a crafting system.
 
  • Like
Reactions: Adamska and Floop
Back