choas

Oh, yeah, the specific example listed was solved within roughly a month of the comic being posted. But the idea still applies, as seen with the twitter post above.

only because people never stopped asking it to be able to id birds.

It took almost exactly 5 years from publication for that to be commonplace.

Feature requests never account for the performance hit.

PM: You know real world?

Make it like that

Almost all game-slowing doors are just hidden loading screen baked into the gameplay.

I wouldn't mind seeing that! After V-Worlds was declared "completed" MSR tried to find a product group to fold it into, but nobody wanted to own it. I don't remember if XBox existed then, but the code just sat there for a few years, then I heard they opensourced it. When my kids were playing ToonTown I found a bug that let you slide behind the background and move around, like you could see that a clerk behind a counter was just a legless floating torso. The method of getting there seemed to be exactly like a V-Worlds bug, so I wondered if Disney might have been using the code. But it could have just been a common graphics bug, I dunno.

I remember finding another bug while creating a demo with a snaky sea creature swimming around. To animate a multi-segmented object you had to animate each segment separately. After the animation ran for a minute or two, enough unrelated interrupts would happen in the computer that would throw the body parts out of sync, making body parts either merge into each other or move apart, and the whole thing would look like crap. Same thing if you had somebody ride in a car or on a train - the car and character were animated separately and you'd end up with the character floating along behind the car.

I asked the dev about making the animation itself an abstract object whose position would be moved around, and attaching in-world objects to it, with position offsets. Each animation step would be computed just once instead of for each body part (or for the person and the car), and all the parts would be rendered with offsets from that one position, guaranteeing them to stay in sync visually. He said yeah that's a good idea, but we're not working on that code anymore. Oh well.

Another bug involved moving from room to room. The engine only loaded graphics for the current room, so when you went through a doorway it would load the new room and dump the previous one, causing a very unnatural visual delay that looked like a glitch in the matrix. The way we coped with this was by putting an entire world in a single room, so all the world's graphics were loaded all at once. But this not only limited the world size, it meant we had to create our own version of the room system in script. To keep track of where players and objects were, we put invisible barriers in doorways and used event handlers when things passed through them. Then we used this to enforce which players could talk to each other or hear sounds made in a given "room".

I suggested loading a cluster of rooms at once - the current one and those that were one connection away. Then when an avatar passed into a doorway the new room's graphics would already be there, no glitch, and the graphics for nearby rooms could be loaded and unloaded in the background. Again, nice idea but we're done working on that code. Sigh. I really wish I had joined that project about 6 months sooner. Not like I'm a genius or anything but these seemed like really fundamental things that should have been addressed up front.

Okay, rant over. I haven't thought about this stuff in quite a while - I'm kind of amazed so many details are still in my head. I must have agonized over it a lot at the time lol.

I think before that even

They just mirror the viewmodel