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
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.
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".
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.
I approve of people trying to improve the editor experience. This is a good project! I have a nitpick though:
"forking the current panel using Ctrl+F is a game changer, as you don’t have to scroll away from your current code location when looking up something at a different place in the same file."
A game changer over what? Are there editors that don't let you do this? The two I mostly work in are Emacs and Visual Studio, and you can do this in both. (I'd actually have to hunt around for how to do it in VS, I use both side by side because of a whole lot of Emacs muscle memory, but it's there for sure)
It worries me that he's not actually aware of the features available in the editors he's trying to improve upon.
It's likely coming to PC as well. It was announced last year without any console attached. At E3, it was at Sony's keynote, but it wasn't announced as an exclusive. On the other hand, they haven't explicitly said it will be on PC either, it's just an educated guess.
I can't speak for all games, but this sort of visualization is something I believe to be common in large AAA games, and is something I've had (and continue to have) in the small subset I've worked on. On the other hand, it's always been custom code (like the engines themselves) and I would guess not something a lot of smaller studios would feel justified spending time on until they needed it. I don't know if that's true. I've found that just providing some simple easy to use debug line and shape drawing that lives outside the rest of the rendering systems means people will use it for this sort of thing all the time. After a while there'll be a bunch of useful visualizations built up and if none of them do quite what you want, it'll probably be easy to modify an existing one.
I do think Unity and Unreal both probably provide a lot of tools in this department, so the situation outside crazy developers still using custom engines is probably a lot better than I think it is.
Also, it's almost certainly true that way more time goes into mundane, repetitive game testing than you thought. The QA budgets for AAA titles are quite large, and a lot of that testing work is horrifyingly dull. Methods like this post outlines help a lot, but there's no substitute for actual people getting paid to try to break your game.
Something you can do with components if you set some strict restrictions is do static or runtime analysis to determine which sets of components are disjoint in terms of systems that access them. For example, if the combat system only needs access to combat components, and the builder system needs pathing and inventory components, then those two systems can run completely in parallel.
One place this is likely to break down is the transform (position) component, but one strategy for that is to differentiate between read-only and write access. Lots of systems need to know where things are (const access) but few need to change where things are (write access). All the systems that can deal with const access can still run in parallel.
The trick here is you have to strictly enforce all this. You CAN'T have a method for getting an arbitrary component from an entity, and this may drive you nuts. Instead you have to have each system specify ahead of time exactly what components it needs and how it uses them, and then hand them those components, and only those components. As soon as you let someone write "entity->GetComponent(Physics)" in leaf code, you've lost your ability to analyse the dependency tree.
For a lot of games, the other problem you're going to run into is that one or two systems are going to take up most of your time and every other system is just going to sit around waiting for those anyway. Usually those are physics and rendering. Which you might be happily avoiding by making a dwarf fortress style game!
I have a coworker who's got a "toy" engine at home that does all this and some other fairly amazing tricks. He says he's going to open source it, still waiting on that. Sorry for this pointless tease, just wishing he'd hurry up out loud.