The dumbest way to solve a maze [video]
youtube.com
youtube.com
Thanks for introducing me to something that sets such a low bar on TV technobabble!
I did not watch any more episodes.
So, plot a torus with the center on the offenders home, and most crimes will occur on the disk. This would also work with the pattern a radial lawn sprinkler would make.
Unfortunately, while neat theories, the reproduction crisis is happening in criminology as well and I can’t find a good systemic review that says either theory is particularly good. But criminologists believe them, so the show isn’t that far off in those regards.
I dunno, they use a whole swathe of dodgy nonsense already.
Here's the most obfuscated way to generate a maze. Compile
char*M,A,Z,E=40,J[40],T[40];main(C){for(*J=A=scanf(M="%d",&C);
-- E; J[ E] =T
[E ]= E) printf("._"); for(;(A-=Z=!Z) || (printf("\n|"
) , A = 39 ,C --
) ; Z || printf (M ))M[Z]=Z[A-(E =A[J-Z])&&!C
& A == T[ A]
|6<<27<rand()||!C&!Z?J[T[E]=T[A]]=E,J[T[A]=A-Z]=A,"_.":" |"];}
char M[3],A,Z,E=40,J[40],T[40];main(C){for(*J=A=scanf("%d",&C);The thing is, that’s exactly what his first solution was. A fan. His first solution is literally how air blows through the maze. (I suppose it’s technically when happens when you release air into an evacuated mass but still).
Also he suggests that collisions are needed to add “pressure”. Not true. He had pressure in his first modeling and no collisions are necessarily to model.
You can see it by noting that the molecules that are very far apart are still bouncing around as though hitting other molecules (and they also mention it at 3m19s or so).
So there isn't a fan and they couldn't realistically add one. If they did, they'd essentially have to bias particles towards a prior-knowledge correct path through the maze (which is solving a maze by already having a solution), or actually run a gas simulation.
If there are no inter-molecule collisions, there is effectively 0 pressure. (Ignoring the pressure that the walls of the container "feel", which is presumably not being modeled)
But that is exactly what pressure (of an ideal gas) is? No intermolecule collisions are required to model the behavior of a gas as we know it.
I'm not 100% sure if fluid dynamics uses a subtly different definition (though how hard the medium is to compress is a fairly universal definition).
Obviously thermodynamics does break down if you've only got a small number of particles, but then 'pressure' also kind of stops working as a concept when you've got mostly vacuum.
Roughly speaking if you put a bunch of bouncing particles in a box then even if they don't hit each other they're going to hit the walls of the box more often if you decrease the volume. This means pressure is proportional to density so inversely proportional to volume i.e. pV is constant.
If the maze were already filled with a gas, and a fan were pressurizing the whole thing from one end, a pressure wave would be traveling through the maze towards the exit, sending the first particle out the door much faster.
Notably, a fan would first saturate all dead ends closest to it. Basically turning deadends into walls at their entrance. But, again, this only works if you have pressure. Right?
The first problem is that it's not immediately obvious. Hitboxes aren't tied to what is visible, so just looking over a map won't tell you anything. Playtesting the map also isn't foolproof, because sometimes the lack of a hitbox where there should be only manifests under very specific conditions which may or may not be in the realm of developer expectations.
The second problem is that it's just very complex, and complex things are hard to build right the first time, find any problems, and fix them. Are these two overlapping polygons a bug or intended? Should this polygon have a hitbox? What about this particular face on the polygon, should it have a hitbox or not? How accurately should we be calculating collisions?
The third problem is that game developers, and especially programmers, are paid bad and work in bad conditions. Any programmer worth their salt wants to jump ship over to the enterprise side of things ASAP, where both the pay and the conditions are much better. So you're left with not necessarily skilled/motivated programmers left to deal with complex programs (games) rife with the potential for bugs.
I read ignorant shit about the game industry all the time on HN, but this is so beautifully ignorant, arrogant and demonstrative of what is wrong with software developers that if wish HN had gold to give.
I suppose John carmack, George Romero and jonathon blow would be sad to learn they’re not worth their salt.
Lest someone argue that I’m picking outliers, you’ll just have to take my word that in my years at Microsoft and then in games I have seen brilliant programmers (and bad ones) in both environments. And many of the best in games tried to stick it out at “enterprise software” (google, msft, SV unicorns) but always left within a year despite bags of money being hurled at them.
Sorry if this sounds harsh but I am so tired of people who’ve never walked a mile in the shoes, telling a walker how they must suck at walking. It’s endemic on HN, for all kinds of things, not just games.
Odd examples to choose.
Jonathan Blow made two games with engines developed from scratch. I don't know how you think that's "not particularly impressive" for a solo person, unless you have never tried to actually ship a game. With or without a custom engine.
I was just trying to pick programmer examples that people would know. Probably didn't make my point very well, which was that there are plenty of programmers "worth their salt" in the gaming industry, and who chose to stay in it. To state otherwise is just fucking idiotic.
For most additive geometry constructed maps, cracks can form to create collision holes which otherwise look solid, or the map may not be entirely closed and have a gaping hole into the void. This is very difficult to get right.
For maps which carve out empty space from solid space and then add geometry back (subtractive, such as Unreal), there may be cracks caused by numerical imprecision but collision errors here are relatively rare.
t - duration of simulation for each individual particle
N - number of simulated particles
I believe if you leave t fixed, and then increase the size of the grid, then yeah, the number of simulated particles you need probably increase exponentially (or worse) for finding one that reaches the exit.
But you probably want to increase t with the grid size as well, and I think that would mitigate this to be less bad than exponential. This is basically diffusion, and characteristic distance travelled by diffusion is proportional to sqrt(t).
Sure you can have bits of wall pieces in the maze, but you'll never get into contact with those, as that would require you to remove your hand from the wall.
> Imagine, for example, deciding to put your right hand on the wall of Taylor Swift’s pupil. You’d literally get lost in her eyes!
You would have to first take your hand off the wall in order to put it on the pupil. The idea is you put your hand on the wall at the entrance and never take it off, not put it on arbitrary walls.
> However, suppose the maze is actually quite agreeable, so much so that we wouldn’t mind spending a few extra cycles in the search for v; in fact we vaguely hope, nay, decidedly wish, that the search will take as long as possible,
I guess as well that the "thinnest" hallway is of length: 1 pixel. If the particle is also 1 pixel in size, then wouldn't the simulation be the path finding (backtracking?) algorithm? I don't remember the details, maybe I misunderstood something (last time I saw this was at university)
Another way to see why that can’t be like backtracking is that it is memoryless, while backtracking keeps track of what was visited.
You can try all of the solutions on the wiki, and they don't consistently succeed, even where they're claimed to solve all levels.
It really forces you to be really creative, even if you'll never succeed. I'm enjoying the process much more than the results.