Ogre

There used to be a site called Forgotify that would only play songs from Spotify that had zero listens. So each song played, of course, removed that song from the set that could ever be played by Forgotify. Doesn't look like it's around any more, sadly.

I'm with you, came here to ask this too. This is how I would have read it:

"Crack engineer" someone who is an excellent engineer, I feel like this goes back to at least the early 20th century, certainly long before gaming culture.

"Cracked engineer" a damaged person who is an engineer

Shrug. Language changes all the time!

The Merchant Princes series is fun, and I really enjoy the story of why he wrote it. It starts out as fantasy for basically the whole first novel and then some. But you can find some evidence from the start that it's really sci-fi, and by the end of the series it has dropped all pretense. It's sci-fi through and through.

This is all because he had an exclusive contract for sci-fi with his other publisher. But not an exclusive contract period. So he stealth wrote a second sci-fi series without actually breaking that contract until later.

I'm not sure if The Laundry Files was done for the same reason. It's possible. I haven't read those past the first novel. But I'm a big fan of everything else he's done.

"Moving left" is NOT an input. An input is "The controller is pushed to the left" (with perhaps a numeric value of how far it is pushed to the left). "Firing once" is similarly NOT an input. "The fire button is down" and "The fire button is up" are inputs. That is how well implemented first person shooters have worked since the Quake days (I think Quake 2 actually).

The point of the article is actually that the server doesn't validate anything. There's nothing to validate. The only data it gets from the client is the state of the controls. Then it runs the real simulation. The client only ran a prediction of what it thought the server would do. Sometimes, it's wrong and corrects itself when it gets new values from the server.

You can handle orders of magnitude more users with the same hardware if you don't have to run the game simulation on the server.

Just today I was arguing for not moving something off of Oracle. No one's really happy the thing in question is on Oracle, but it is live in production and most of the time does what it needs to. It ain't broke. Changing to "something else" carries way too many unknowns for my comfort level.

If I'd read this last night... I still would've argued the same thing, but I would've been really unhappy about it.

The author also created SpaceChem, which is one of the best programming/engineering games out there. For just programming games, I'd call it my second all time favorite just behind Robot Odyssey, an ancient Apple ][ game.

This gives some great context to where SpaceChem came from. Thanks Zach!

I only skimmed it, but I didn't see anyone in there who took years. They were all on the order of months. Entirely possible I missed it.

That said, adding networked multiplayer to a game is very difficult. But designing a game around networked multiplayer is not nearly as hard. Single player or local only multiplayer games can get away with lots of assumptions that completely break multiplayer, and detangling all of those assumptions is the most time consuming part of converting a game. If you do it "right" from the start, you don't ever allow yourself to make any of those assumptions and everything just works. If you know you're going to build a multiplayer game, then write it as a client server architecture from day one even if you know you're not going to play with other people for the first several months of development. Future you will thank present you.

In the 1990s, people used to write these things called plugins to add features, like support for specific video containers and codecs, to browsers. Now I guess browsers have to have everything built in or not at all. "Progress".

Yeah, see my reply to myself, I beat you by a few minutes =) Whether 6X the searches is worth it or not is something only testing can answer, I think.

Partly answering my own question after mulling it over, the difference in the pre-pass is that you're not actually coming "from" an edge or going "to" one when you're doing the flood fills, you're just testing which edges are connected to any given empty cell. But I still think there might be something to this idea. The simplest thing I can think of is to do no-backwards searches out from all the empty cells on each edge and see which other edges you reach. That's potentially 6x as many searches (slightly smaller and with some early outs since the connectivity is bi-directional), but at least it's still finite and predictable and isn't who knows how many raycasts. I don't know if that's acceptable for the pre-pass or not. But I also think there might be smarter ways to do it that only require a single search from each empty cell but remember directions traversed so you know if a particular path you've reached an edge along implies visibility or not.

Maybe you can do the 6 searches in parallel, such that whenever they meet you know you've found a connection between the two edges they were coming from? I don't know if that means any less work except in cases where all 6 edges are trivially connected.

For the actual occlusion test, you have a "don't go backwards" rule. If you have to go backwards to reach a chunk, you know it's not visible along that path (but may be on a different path, which you will eventually find). Without having thought about it a whole lot, does that work for the inside-a-chunk tests too? If you have to traverse an edge facing back towards the face you're coming from, does that mean there's no visible path from the first edge to the second? And if so, would that give a meaningful reduction in connectivity?

Glitchiness of occlusion may be driver or hardware dependent. I've been using it successfully, but haven't tested on a variety of hardware. The bigger issue is the two way communication between GPU and CPU. You want your pipeline to be one way, otherwise you either have stalls waiting for results (poor or inconsistent framerates), or things becoming visible one or more frames later than they should. For some applications, the latter is acceptable. For Minecraft (style) chunks, it might mean sometimes large amounts of terrain popping in a frame or two too late, which could be very noticeable.

It seems like a combination of both might be feasible. Do something smart like this article on the CPU, which feeds into a greatly reduced set of occlusion queries, small enough to perhaps not introduce significant stalls using the first method.

However, in this article's case, he's specifically targeting the mobile edition of minecraft, where hardware occlusion is not yet universally available! So fast CPU versions are definitely warranted, and I think he's got a really good solution.