Kono Sekai wa Fukanzen Sugiru Episode 7 Discussion

Sooo....why not give one of the spare debugger stones to Amano? He's still a debugger technically. Even if he doesn't want to do the job anymore, like Haga he could simply never use it. Just seems like a very minor inconvenience to carry this god-stone around in case of emergencies, too minor to pass up on keeping one.

That was my least favorite episode of the anime so far.
I found Amano to be a little too annoying this whole episode. That's not to say he is not justified to be angry, I just thought it was overexaggerated.
That alone would not be a enough to make it the worst ep for me, my main issues have to do with the game.
I don't get why the debuggers' game would freeze completely when they left the currently loaded area.
It makes sense that they would freeze temporarily if the designers forced the area to load when the patdown failed, but they would return afterwards.
If they skipped the loading zone, they would basically end up out of bounds. Their client would not think there is a floor but the server would.
The server is not the problem here after all, since everyone around them is able to move normally, so it's a client side issue.
If that's case, they would be rubberbanding on the client side but they would look normal on the server side.
They would probably not be able to perform some actions though, as their client would think they are constantly falling.
And, as we know from Namiko, Debug Mode seems to only work when not in certain animations, such as taking damage.
So falling could be preventing them from using it, yet I don't see any good reason to not be able to talk or move their bodies.
That was the best explanation I could come up with. Please reply to this comment if you have any other ideas.

P.S. I doesn't make sense that the tower they were playing Jenga with would have physics. Maybe they could make the environment become a physics object after detaching from the ground, but that sounds like a terrible idea to me, for objects that where not meant to be broken off in the first place.
(I know that they made the castle float, but I thought that was achieved through terraforming. It's not crazy to think that a Debug Mode would provide terraforming. If the engine was powerful enough to support it, I could see live editing of the map as a useful tool to debuggers)

@gorkthe134th
Your technical explanation about what should happen (normally, at least) to players that skipped the hidden loading makes sense, but the way I see it, it's not the shitty debuggers' entire world that froze up, it's just their characters that stopped moving after they were sent flying through the gates before the game could finish loading the outside area for them.
Once again, the developers didn't take into account that such a bug could happen.

I'm not sure I understand your last point about the tower having physics.

@Avvenirista I hadn't considered only their characters being frozen and I just thought of a way that could happen.

So far I've been assuming that the game doesn't take control away from the player, as that would be impossible with current VR technology.
But, as we've seen in the opening, to play the game the player is sitting in a device and they probably lose control of their real body.
That means that it would be possible to take control away completely for cutscenes and the like.

Knowing that, what if the patdown is a cutscene?
Before initiating the cutscene, the game would need to wait for the player to land, so that the guards can start moving to their location.
But in this case, the position the guards would need to move to is outside of the castle. (It would not be out of bound as all of this is on the server side)
Since the outside of the castle is a different scene (in Unity terms), they probably explicitly forbid NPCs from walking outside the scene bounds.
Failing to move the guards, either the game would crash (which would mean they will disconnect from the server soon and probably be saved) or they would be softlocked as their game waited for the guards to get close to them, even if that would never happen.
In the meantime, the game would have already disabled their movement (when the cutscene started), so their characters would now be frozen.

There are a few questions to still be answered though.

• Why were Haga and the others able to move in the cutscene if it takes away your control completely?
  I guess the game only takes away your control completely until the guards reach you. After that you might need to answer questions or something like that, so the player needs control of at least their head. The guards never reached Sakai and the others, so their control is still fully disabled.
  
• Why were Haga and the others able to initiate the cutscene at all, if the server is waiting for the guards to reach Sakai and the others?
  The server can't be just waiting for the guards, it needs to also be moving NPCs, handling player movement etc. So the code handling the cutscene is almost definitely run on another thread. The thread created for Sakai and the others will block waiting for the guards, but not the whole game.
  Cutscenes can therefore be initiated, but you would think that this one needs to finish before it can be initiated again.
  I believe it would probably make more sense if a player passing through was assigned any unoccupied guard in the area and if there were was not any, new ones would spawn. That way any number of players could pass through the gate and at any rate without interfering with one another.
  In this case, there are exactly three guards and none are occupied since they have given up on getting to Sakai and the others.
  No new guards need to spawn and those already present are unaffected, so Haga and the others can pass through normally.
  

I have already written a lot about the freezing so I will be brief about the tower.
The tower is probably part of the geometry of the map, it is static. When parts of the map like towers fall in cutscenes and the like, either they are objects to begin with or they are deleted and an object version of it is spawned where the original was, so that it can be animated.
It's not unlikely that there is an event for that specific tower to collapse, which would mean that there is an object version of it and an animation of it collapsing, but it IS unlikely for that object to have physics, let alone not being a single object and each individual brick being it's own object with physics accurate enough for them to play to Jenga. Physics this accurate are hard when it's the focus of the game and this game is not even finished!
That's why I was considering the possibility of the engine automatically creating physics objects when breaking a part of the map geometry.
But that would mean that the map geometry would need to be updated constantly, which sounds like a terrible idea.
(Also I'm surprised that the game lagged when spawning a few dozen monsters, but not when a lot more than a few hundred physics objects started falling and colliding with each other. That many physics objects even being near each other would cause lag!)

Hope this clears things up.

I congratulate and thank you if you have read the whole message. I'm sorry, but it turned out longer than expected.

@gorkthe134th
Haga, Nikola and Amano were able to move around freely before, during and after the patdown so that section probably wasn't a regular cutscene but just a scripted event that signaled the start/continuation of the main quest and stealthily loaded the inside (or outside) area of the castle.
For reference, here's how things went down in the original comic:


I'm afraid I can't keep up with all the physics talk, however I'll still offer a possible explanation: maybe all that baffling stuff with the tower is happening because the physics engine employed by the game is highly advanced (the game is installed on a piece of hardware capable of running a full-dive ultra realistic VRMMO, and that sounds like near future sci-fi technology to me) but also incredibly poorly implemented and optimized into the game itself?

I'm not suggesting that the whole sequence of moving through the tunnel is a cutscene.
Basically what I'm saying is that these steps happen in order after a player gets near the gate:

1. The game waits for them to be grounded
   
2. Their controls are disabled
   
3. A guard walks to the player until they get within a curtain distance
   
4. The player regains control of their head and arms (possibly more, it's not clear), so that they can talk to the guard
   
5. The guard pats the player down
   
6. The player regains full control
   

What would have gone with Sakai and the others is that step 3 would never complete, so their controls would still be disabled.
(The start/continuation of the main quest is irrelevant to this conversation, as it happens after the patdown.)


That's what I was thinking too.
It's curtain that more powerful engines and hardware will be developed in the future and it's always possible for developers to optimize curtain parts of the game and implement others thinking "if it works, it works", especially early in development.
What gives me pause is that physics would be so optimized that they cause no lag, while spawning like 20 monsters is enough to do so.
If the engine is so good that it can handle hundreds of object falling and colliding with each other, I find it hard to believe that it cannot handle spawning 20 monsters. And I also find it hard to believe that the developers could mess up that badly in the code for spawning monsters, as this game is an MMORPG, which means monsters are spawning frequently e.g. near players in dungeons. Optimizing the spawning would be top priority for this game in particular.

I see.
Your theory makes an awful lot of sense.

Maybe that has something to do with the polygon models used for the monsters. A large number of insanely detailed monsters all spawning together in a relatively small area could definitely cause a momentary slowdown for the players.

Oh, I can totally believe that. What's crazy to me is that a company would seriously send human debuggers in a such a broken game , but that's another story.

In the first place, my point was that, no matter how complicated a monster was, spawning it should not be as hard as calculating the result of 5 times as many collisions. But now that I think about it, it could be the case that this specific monster doesn't use the general code for spawning.
After all, we've only seen this monster used as a boss and that area was supposed to be inaccessible during the main quest anyway.
So what if every time the game spawns this monster, it attempts to initialize the boss fight and performs some heavy calculations to do so.
Something in that room could be overriding this behavior to make them babies instead, but only after some of those calculations have happened.
That would mean that spawning this monster in particular, even as a regular enemy could cause some lag, so spawning 20 of them at the same time...

There are cases of (mostly older) games that use a piece of code 99% of the time, while one element uses it's own version of that code.
Combined with the fact that this is a unique spawning condition, I can see a game as broken as this one working that way.
I should not be underestimating the ability of developers with restrictive deadlines to implement features in the most inefficient way possible.

@gorkthe134th
All right, so let me get this straight: some (if not all) of the Kitra-like monsters in that room could have been mass spawned as bosses instead of regular mobs because the developers mislabelled their IDs in the system?
I like this theory a lot.

I see.
Your theory makes an awful lot of sense.

Maybe that has something to do with the polygon models used for the monsters. A large number of insanely detailed monsters all spawning together in a relatively small area could definitely cause a momentary slowdown for the players.

Oh, I can totally believe that. What's crazy to me is that a company would seriously send human debuggers in a such a broken game , but that's another story.