"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!

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.

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.

It's like an obsolete technology fractal.

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

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

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.

Perl actually is when used in taint mode. http://perldoc.perl.org/perlsec.html

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.

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.

"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.

I had one for an older laptop. Worked fine, but I didn't use it much just because I wasn't at my desk at home very much.

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.

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.

Even though it solved a problem we don't usually have today (this story notwithstanding), it was still one of the most amazingly useful programs ever.