Live-Updating Osana Checklist

Every animation, cutscene, gameplay mechanic, feature, model, scripted event, and voiced line related to Osana is in the game. In that sense, she is “finished.”

However, I can’t release her until I’ve tested every feature related to her to confirm that everything is working properly – and that is a lengthy and elaborate process. When I test a feature, I don’t just test it once; I test it about 5~10 times in a row, doing things differently each time, to make sure that there aren’t any circumstances that would cause something to break. This process has been revealing a lot of aspects of Osana that require fixes and improvements. The last thing people want is a buggy and unstable Osana, so I’m taking the time to fix bugs, remove exploits, resolve game design flaws, and improve anything that looks janky.

Instead of attempting to estimate Osana’s release date, I’ve decided to use “Trello” to create a page where you can see a live-updating checklist of every feature that I’m currently testing, and every issue that I’m currently fixing:

https://trello.com/b/J0BiY9CS/yandere-simulator

You might be wondering, “Why does this phase of development take so long?” For a detailed explanation, scroll past this gorgeous artwork by Esther-shen!

If you’re watching the Trello checklist like a hawk, you might notice that, sometimes, hours will pass without any of the checklist items being checked off. This is an indication that I’ve encountered serious bugs or game design flaws that are taking an exceptionally long time to resolve.

There is one particular checklist item that has taken far more time than previously expected. And that item is…

That item at the top of the to-do list – “Create Schemes for each one of Osana’s elimination methods” – exposed a large number of issues that I had not anticipated, and fixing those issues ate up a huge amount of time. I’ll provide you with a couple of examples…but, first, I’ll summarize what Schemes are.

“Schemes” are like walkthroughs that guide you through specific elimination methods. You may ask, “Why does the game need to contain something like this?” the answer is that the player should be able to learn any information they require within the game itself, instead of having to rely on third-party sources. If it wasn’t possible for the player to learn about elimination methods within the game itself, the player would have to go watch a video on YouTube if they want to learn how to do stuff, and that would just be lame.

Before you say, “That’s weird and unnecessary! No game has ever done that before!” I’d like to mention that Hitman 2016 had a functionally identical feature called “Opportunities.” In my opinion, going down the checklist of all Opportunities and experiencing all the content in a mission was one of the most fun aspects of the recent Hitman games.

There are 17 different ways to eliminate Osana! Some of those methods involve complex scripted events, and even fully-voiced cutscenes! Because the Osana demo is packed with so much content, I think there is a very real possibility that most people who play the demo won’t even realize how many different options and activities are available! To ensure that players know exactly how much content is in the demo (and how to access all of it), I think it’s absolutely imperative that there is a Scheme for each of Osana’s elimination methods.

Now, here’s where it gets complicated…

When a Scheme is active, some instructions appear at the top left corner of the screen. When the player completes that objective, the instructions update to describe the next objective.

In order for this to happen, there needs to be code checking whether or not a Scheme is active, and also checking whether the or not the player just completed a specific action. If a Scheme has 10 steps, this means that there will be 10 different places somewhere in the game’s code that are checking whether or not the player has just completed an action that should move the Scheme forward.

Updating a multitude of scripts, testing the Scheme, and fixing any bugs related to the Scheme is a huge investment of time. As a result, it is very – VERY – time consuming to make a Scheme become fully functional. Because there are 17 elimination methods, that means there are at least 17 Schemes, which creates a tremendous amount of work. I estimate that creating a functional Scheme for each of Osana’s elimination methods would add multiple weeks to her development time! That’s the last thing that anyone wants…but, without Schemes, people might not know how to access all of the content in the demo!

Fortunately, I arrived at a solution: Instead of editing dozens of scripts just to make the instructions update automatically, I have given the player the ability to advance the instructions by pressing a button!

In the Osana demo, only the first 6 Schemes will have instructions that automatically advance whenever the player completes an objective. The rest of the Schemes will require the player to manually press a button to advance the instructions. I know, I know, it’s a little unconventional…but this reduces the amount of time required to complete Osana by multiple weeks. Sometime after releasing Osana, perhaps I can update the game to make Scheme instructions automatically update. There! Problem solved!

Well, aside from that, there is a completely different aspect of implementing Schemes that has eaten up a lot of my time…

To implement a Scheme, I must first write out the instructions that will be shown to the player. These instructions need to be short, simple, and clear enough for any new player to understand. While writing these instructions, I think critically about the game’s mechanics from the perspective of a completely new player who is experiencing the game for the first time. As I do this, I often realize that there are certain aspects of gameplay that might frustrate new players. Whenever this happens, I try to solve the problem before moving forward – and that can sometimes require me to add new features/content to the game. For example…

Some of Osana’s elimination methods require you to put a note in her locker. Osana will only take a note seriously if it references her “Dark Secret”. In order to learn her Dark Secret, you must eavesdrop on two conversations that take place on Monday. But…what if the player missed those two conversations? Should the player really be permanently locked out of any elimination method that involves putting a note into Osana’s locker?

Of course not! That wouldn’t be fair to the player. So, I decided that there should be an alternate way to acquire Osana’s Dark Secret. To solve the problem, I updated Info-chan’s “Services” list to allow the player to purchase Osana’s Dark Secret directly from Info-chan. This is an improvement to the game’s design – and it only happened because the act of implementing Schemes for all of Osana’s elimination methods caused me to think critically about where a new player could get frustrated with the game.

(Artwork by guivaz2014)

What I just described happens literally every time I start writing instructions for a Scheme; I realize something important for the very first time, and need to take action to fix a game design flaw or remove an exploit. This is what I call “Hidden Work”; it’s when you think that there are only a small number of simple tasks remaining, but once you actually start working on those tasks, you suddenly discover a bunch of small problems that each require a unique solution. It’s very easy to say how much “Work” is remaining, but it’s impossible to know how much “Hidden Work” is just below the surface.

I’m sure you’ve heard of “Schrodinger’s Cat” before; it’s a thought experiment which describes a cat that is both dead and alive simultaneously, until you check on it to find out which state it’s in, at which point it becomes either dead or alive. Osana is like that, too!

As of right now, Osana is finished – but, as soon as I start writing the instructions for a Scheme or bug-test one of her elimination methods, I might discover a game design flaw or bug that needs to be fixed, at which point she still stop being “finished”, and will require more work. I won’t know until I check, so as of right now, she is “Schrodinger’s Rival” – finished and unfinished at the same time, pending some more bug-testing.

If you don’t want to read everything I just wrote and just want a quick status report on Osana, here it is: Osana is finished, and now I’m just bug testing before I release her. The process of bug testing is taking a very long time, because I’m being super thorough and fixing every problem I find. I don’t know how many more issues I’m going to discover, so I can’t predict when I’ll be done bug testing.

Even after Osana is done, I still want to update the game’s graphics before I release the demo. So, it’s not like Osana will be released instantly as soon as I finish bug testing.

You can check this Trello link to follow my progress as I tick tasks off the checklist one by one: https://trello.com/b/J0BiY9CS/yandere-simulator

Didn’t you say that Osana would be released on August 1st?

I said “maybe,” remember?

At the time I said it, it was a realistic estimate. However, the act of implementing Schemes revealed a lot of bugs / game design flaws that needed to be fixed.

The problem with attempting to estimate Osana’s release date is that it’s nearly impossible to make a meaningful prediction, because I have no way of knowing what kind of new obstacles are going to come into existence in the near future. I can’t predict the number of new bugs/exploits that will be discovered, and I also can’t predict what kind of unnecessary obstacles other people will create for me that will take my time and attention away from development.

That’s why, this time, I’m not even going to bother estimating the release date at all; instead, I’ve provided you with a live-updating checklist so you can see for yourself how many tasks remain and observe the pace that I’m working at. This is honestly what I should have been doing in the first place.

Why does the number of tasks on the checklist keep changing?

Because of the sheer amount of content and mechanics in Yandere Simulator, I couldn’t possibly remember absolutely everything on the first try. I simply wrote as much as I could remember. The process of playtesting Osana regularly leads me to remember many of the other things that also need to be tested. As I remember / realize what else needs to be tested, I update the list.

What a massive blog post! Instead of using your time to write this post, you should have used your time to work on the game!

Well, I can’t just leave people in the dark, can I? I have to communicate with my audience; I have to describe what I’ve been up to, and I have to provide an explanation for why Osana isn’t done yet. A thorough, transparent description of the situation is the least I can do for the people who check this blog.

Anyway…because it has become tradition to upload a new build on the 1st and 15th day of every month, I’ve updated the game again. Here’s a list of all the fixes/changes/additions in the latest build.

Fixes/Changes/Additions

You’ll notice that this list is extremely short, because I have been spending the overwhelming majority of my time on Osana, and practically zero time on miscellaneous little bug fixes.

• Fixed bug that made a cake float in the air, visible through the window of the Cooking Club, when Yandere-chan joined the cooking club’s club activity after 5:00 PM. (I can’t believe this bug wasn’t noticed until now.)
• Fixed bug that caused the game to only be able to display certain tutorial pop-ups, even if the player was trying to use the Tutorial menu to make completely different pop-ups display.
• Miscellaneous fixes throughout various areas of the game, like updating the “Kidnapped Musume” video thumbnail to feature the new basement.
• Fixed bug that allowed the player to buy products in the street scene without actually having enough money to afford those products.
• Minor, miscellaneous adjustments to the Student Profile screen (centering the reputation graph and Info-chan’s static).
• Updated most of the classroom models and textures to match the art style used by the rest of the game.
• Fixed visual glitch that was causing the bottom half of some students’ eyes to appear white.
• Various code optimizations that resulted from speaking with a very helpful programmer.
• Re-positioning certain props in the school environment to prevent clipping.
• The framerate when shadows are enabled should now be better than before!