Has any progress been made on Osana? How close is Osana to being finished? What’s taking so long?

Are you looking for information about the Yandere Simulator meetup at Anime Expo? Click here!

Are you looking for information about the latest build of the game? Click here!

A lot of people have expressed that they are losing faith in me and losing faith that the game will ever be finished, because it’s taking me a long time to implement the game’s first rival, Osana. I feel a need to defend myself, explain why the game’s development speed has slowed down, and explain why it won’t be this way forever.

In this blog post, I’m going to show you some recent progress that I’ve made on Osana, tell you why it’s taking so long to make any progress with her, and tell you what is being done to speed up development.

Click “Continue Reading” to see.

Have you actually made any progress on Osana lately?

Yes. If you require proof, I’ll show you a video:

This video is intentionally very short because I would prefer not to show off Osana’s events in detail until all of them are complete. I don’t want to “spoil” my future video by showing off all the content this early, so I kept this video very brief.

How close is Osana to being finished?

The remaining tasks that need to be done are:

1. Implementing all sabotagable events (2/5)
2. Implementing all outcomes of a sabotaged event (2/5)
3. Implementing a new character that will serve as an obstacle during Osana’s week (0/1)
4. Implementing the confession cutscene and different outcomes for it (0/1)
5. Implementing Osana’s Befriend/Betray sequence, which is much more elaborate than Kokona’s (0/1)
6. Making all of Kokona’s elimination methods apply to Osana
7. Adjusting student routines so that there are almost always witnesses nearby Osana
8. Bug-testing everything Osana-related

In a world where Osana was my only responsibility and unexpected problems never came up during development, all of these tasks would take 1 week to complete, or even less time than that. However, we don’t live in a perfect world; I have a ton of other responsibilities besides just Osana, and I usually encounter a lot of problems when trying to implement Osana’s assets.

What are all of these other “responsibilities” you speak of?

I’ve already taken the time to explain this at length, but I’ll give you a one-paragraph summary:

I need to make general improvements and polish the game and refine the systems that still need work, I need to create documents for the volunteers so they know exactly how assets must be delivered, I need to record reference footage for animators when requesting animations, I need to record footage of bugs when asking other programmers for help, I need to provide debug projects to people who are helping me debug problems, I need to spend time investigating technical problems that are causing the game to crash for some people, I need to spend time requesting/reviewing concept art that is necessary for new environments to be created, I need to delegate certain tasks to other programmers and review their work, and I need to request and review artwork that will be featured in future videos. This isn’t a 100% complete list of all my different duties; these are just the ones that are easy to explain. In most game projects, one individual would not be responsible for all of the above things, AND also responsible for doing all of the programming, too. In short, I’m doing the job of 10 different people, which usually leaves me with extremely little time to actually work on Osana.

What are these “unexpected problems” you speak of?

Every day, I sit down in front of my computer, totally psyched to do work, totally ready to make progress. I start working, getting stuff done, being productive, building momentum…and then, suddenly, it all comes to a grinding halt. A strange, unexpected problem has appeared. I’ll spend several hours trying to understand and solve this problem, which almost always has a super-obscure reason for happening. By the time I finally manage to solve the problem, I look at the clock and realize that the entire day is gone.

I’ll give you an example of what I mean…

A few weeks ago, while I was trying to implement one of the morning interactions, I realized that Osana had a problem with her knees, as can be seen above. I tried to figure out what was causing the problem, but I couldn’t find the root of the issue. I spoke to the animator who created the animation, and asked him if he knew what might be causing the problem, but he wasn’t seeing the issue at all when he tested the animation.

He sent me multiple animations and asked me to test them. Some of them have the knee problem, some of them didn’t. So, I started looking for the difference between these animations, and I discovered that the problem was dependent on whether or not the animation had a start frame of “0” or a start frame before “0”. If I told Osana to start her animation before frame 0, the knee problem went away. I had finally found the source of the problem! Then I looked at the clock, and saw that multiple hours had passed while I was troubleshooting this issue.

Even if my strongest desire is to get as much work done as possible, I can still run into mysterious problems and spend an entire day just investigating and fixing one issue. This isn’t a unique situation that only affects me; other game developers experience this, too. I remember experiencing this exact scenario many times back when I worked at a game company. I remember watching my co-workers go through it, too. Everyone who has ever worked on a video game can relate to this experience. This is what game development is.

Programming new features into a video game isn’t like making art, or making music, or making food, or any other type of discipline. You don’t just “sit down and do it” until it’s done. You sit down, start to do it, and then you encounter animation issues, framerate issues, physics issues, and other problems. Sometimes these issues are your own fault, sometimes it’s a problem with somebody’s asset, sometimes it’s some core flaw with the game engine itself, but it always eats up your time.

Are those the only issues holding back Osana’s development?

Oh, no! Not by a long shot. Let me tell you about the BIGGEST problem that I face on a daily basis, a problem that affects everything about the project, not just Osana.

In Part 1 of my February “What’s Taking So Long?!” video, I had this to say:

When Yandere Simulator was a small project with just a few scripts, compiling the code took less than a second. Now, Yandere Simulator has over 300 scripts, and it takes 30 seconds to compile the code every time I want to make any change, no matter how small. It also takes 30 seconds to launch the game every time I want to test something. In short, it now takes a grand total of 60 seconds to check any change I have made to the game’s code, when it originally took less than a second. If I want to make 60 changes to the game in a single day, then 1 hour of my day will be spent just sitting there waiting for the code to compile. As a result, the simple act of writing code and checking out the changes has slowed down drastically.

But that’s not all; it gets worse. Yandere Simulator is developed with Unity 4, which is a 32-bit program. That means it’s limited to using only 4 GB of RAM. If the game ever goes over 4 GB of memory usage, the Unity editor crashes. The game’s school scene is HUGE, containing over 3 gigabytes of assets. If I re-load the school scene more than 2 times, the game crashes, and then it takes 30 seconds for the Unity editor to restart. If I want to test a change, but I know that the Unity editor is about to crash, I won’t launch the game immediately; I’ll compile my code, close and re-load Unity, and then launch the game. All three of those actions take 30 seconds. The end result is that it can take me up to 90 seconds to test a minor change!

When the code took less than a second to compile, I was making lightning-fast progress with the game. Now that it takes up to a minute and a half to change anything about the game’s code, progress is painstakingly slow. This is horribly frustrating!

I’ve tried examining the output log that Unity generates when you make a new build to see what’s taking up so much memory…but there isn’t just one culprit. It’s a “death by a thousand papercuts” situation. Over 1 GB of memory is taken up by over 1,000 individual textures, most of which are less than 1MB in size. Sometimes I try to investigate the issue and search for potential solutions, but I never manage to make any headway. It’s extremely frustrating to spend an entire day trying to fix a problem with no progress, because all I can think is, “Damn, I could have used today to work on Osana…”

When I was working at a game company, I could run over to one of the senior engineers and say, “I’m having a problem and it’s blocking my progress, please help me!” and I’d get the help I needed within minutes. But, being a solo indie dev working alone means that every time I run into a problem, nobody is there to help me. I just have to struggle through it myself.

Have you considered taking a day or two a week and just dedicating it 100% to Osana?

It wouldn’t work. I am in contact with dozens of people every day. Spending 1 day away from e-mail means that the entirety of the subsequent day will be spent catching up with all the correspondence that I didn’t reply to on the previous day.

So, what have you actually accomplished over the past 8 months?

In my opinion, a lot.

https://www.yanderesimulator.com/Additions.txt

https://www.yanderesimulator.com/BugFixes.txt

Just because you haven’t seen much progress on Osana, you shouldn’t conclude that I haven’t made any progress whatsoever. The slow progress on Osana means two things: I’ve been making progress elsewhere, and there are tons of obstacles in my way that impede my progress (not just with Osana, but in general). Just because you’re not seeing progress show up in builds or YouTube videos, it doesn’t mean that I’m not doing a whole ton of work behind-the-scenes.

Will your game development ever be fast again?

I’d like to direct your attention to a video by a YouTuber named 2kliksphilip:

In the early phases of a game’s development, you make progress really fast. Then, around the midpoint, progress is really slow. Then, once you get close to the finish line, progress speeds up again. This happens to every game.

Progress will always be fast when you’re setting up the foundation of any project, because you’re bringing it from “nonexistence” to “existence”. You’re rapidly setting up a bunch of cool stuff, and you can show results really quickly. However…any game, whether it’s developed by me or developed by any other team, will eventually reach a point where all of the low-hanging fruit is gone, and the only things that remain are the time-consuming, difficult tasks, and dozens upon dozens of minor issues that each need to be addressed.

Imagine the jump from the number “1” to the number “2”. Nothing will ever be as big of a leap as that; that’s a 2x leap. From “2” to “3” is only a 1.5x leap. From “3” to “4” is only a 1.33x leap…etc. Diminishing returns. Right now, I’m at a number like “50”, so when I make progress, it looks minuscule compared to my previous progress…but that’s because all of the coolest things have already gotten into the game, and now what remains is the boring slog you have to go through in order to bring a half-finished project into completion.

It’s easy to look at somebody’s work and say “Wow, that guy is awful! I can do better than that!” But, if you try to replicate his work, eventually you’ll hit the exact same stumbling blocks. Starting a game is the easy part. Getting over the halfway hump is the part where most amateur game projects die.

What about those tinyBuild guys? Are they doing anything to help?

C# compiles way faster than Javascript. Unity 5 is a 64-bit problem, so it’s not limited to just 4 GB RAM usage. Porting the game to C# and Unity 5 would solve two of my biggest problems. The task of porting the game to C# / Unity 5 was been given to tinyBuild. Here’s what I said about them on May 6th:

tinyBuild has the project files for Yandere Simulator and has started their own “branch” of the game. Their branch stems from one of the most recent builds of the game. They will convert their branch to C#, get it to run on Unity 5, optimize everything that is inefficient, and then focus on adding every feature that I’ve added since the day our branches split. At that point, we’ll abandon my branch and begin using their branch instead. Until then, my branch will be used to develop Osana (or a prototype of Osana), demonstrate features that the final game will have, and keep people interested in the game by adding new content.

Earlier this month, tinyBuild informed me that they have finished converting all scripts to C#, and finishedand porting the game to Unity 5! However, tinyBuild started their branch 2 months ago, so the Unity 5 build of Yandere Sim lacks all of the fixes/changes/additions that were made over the past 2 months.

It would be very time-consuming to manually re-create all of the work that was done from the point in time when their “branch” split from my “branch”. They would need to implement every new asset, fix every bug I fixed, and add every event that I added since their branch was created. Instead of doing that, they are going to take the latest build of the game (June 28th), look for the files that were changed / added over the past 2 months, convert those scripts and scenes to C# / Unity 5, and then get everything working.

If I keep making fixes/changes/additions while tinyBuild is trying to get their version of the game to match the latest build, then they will never be able to catch up. The only way that the Unity 5 build will ever match the Unity 4 build is if I stop working on Yandere Simulator for a short period of time, give tinyBuild some time to catch up, and then resume working on Yandere Sim in the new Unity 5 branch.

It’s really hard to justify intentionally halting all progress on Yandere Simulator, especially during a point in time when people feel like I’m not making enough progress as it already is…however, we’re in luck!

From June 29th to July 4th, I will be unable to work on Yandere Sim, since I’ll be in Los Angeles for Anime Expo! This is tinyBuild’s big opportunity to get the Unity 5 version to match the Unity 4 version. Hopefully, when I get back from Los Angeles, a Unity 5 build of Yandere Sim will be waiting for me, without the crashing problems or the 60-second compile time problems! From that moment forward, the game’s development should proceed at a much faster pace!

Can you just hire someone else to work on Osana for you?

Oh boy, I sure do wish I could! However, hiring a programmer to help me would create some complications:

It would take a lot of time to introduce someone to the project, show them where the important scripts are, show them how the game operates, show them how a rival is implemented, etc. More importantly, any new programmer joining the project would doubtlessly observe that some of the game’s most important scripts have room for improvement, and would want to refactor and optimize these scripts. While the game’s core systems are being ripped out and put back together again, it wouldn’t be possible to continue making progress on the game. It’s difficult to predict how long this would take; it could take 2 weeks, a month, or multiple months! In the end, we’d probably have a net loss of time.

It’d probably be faster if I just finish Osana myself and don’t introduce any new programmers to the project until after the Kickstarter.

Closing thoughts?

It’s painful to hear people saying that they’re losing faith in the game, or that they’ve lost interest in the game, or that they’re going to stop following the game, all because of the development speed. It hurts more than words can describe to sacrifice 3 years of my life for a project, then watch people slowly stop caring about it. If you feel disappointed with Yandere Simulator’s slow development speed, just try to imagine the amount of frustration and disappointment that I feel! Believe me, there is nobody on earth who is more frustrated about this than me!

Developing this game has sucked up way more years of my life than I expected it to. When Yandere Simulator is finished, I’m going to look back and see a giant hole where my late 20s were supposed to be. I really, really want to move on and do other things with my life! I really, really want to finish this project! But, even when I’m working 10 hours a day, 7 days a week, it’s excruciatingly difficult to make even the slightest amount of progress, because of all the problems that were named above; juggling numerous responsibilities, dealing with all sorts of unexpected problems, 90-second long compile times weighing me down, etc.

 

But, there’s something that’s even more frustrating than anything written above. The most frustrating thing about this entire situation is the fact that, whenever I explain why Osana is taking so long, my explanations seem to go completely ignored. I still hear people saying “Osana’s late because YandereDev is lazy!” all the time, no matter how many blog posts or videos I make to describe the obstacles that are impeding my progress with Osana. Working 10 hours a day, 7 days a week, trying to make your game’s development go as fast as possible, and hearing that you have a reputation for being “lazy” and “slow”, is absolutely heartbreaking.