Very cool! I made a similar thing[1], but I didn't put as much attention on the controls or the camera concept. I had hoped to gain some intuitive understanding of 4D space, but in the end I did not succeed.
How did you do collision detection and physics here?
Also shameless self promotion - if you're interested in 4D collision detection (and rendering, and rigid body physics), I've made a semi-tutorial-style repo here:
+1 to these books - they have some really interesting worldbuilding. Even the later books have some good parts (quite a good Moria-like sequence, some more exposition on the current state of the insane remnants of Cunuroi society), but they definitely do lose the plot a bit. I'm still not sure myself what really happened in the end.
This is what I do too, including hacking PuTTY to support it. I offered the patch upstream, but it seems they were not interested due to security concerns (even having it off by default). Fair enough, I suppose, but a man can dream...
This is the explanation that made it click for me, although in my experience it seems like he's wrong about being able to rule out the need for doing certain checks when you already "know" the origin is not in that section due to how you got to where you are. Not sure if my implementation was just shitty, but you'll get weird results when objects are very close if you don't exhaustively check every sector - probably due to numerical imprecision, if I had to guess.
Another nice thing about this one is that in the case where the objects intersect, you can just keep iterating mostly the same algorithm to get the intersection points, rather than needing to use Expanding Polytope as with GJK.
This is pretty cool. I've had thoughts (or dreams, more accurately :) of a language like this every time I get a runtime 'type error in q. I gotta say, I prefer q's syntax, though :)
I had to figure this out recently, a couple things that really helped me are Erin Catto's GDC lectures (particularly [1]) and Allen Chou's game physics articles [2].
I think of a Jacobian as a way to transform the velocities from however they're stored for the interacting objects into linear world-space velocities.
For example, in 2D rigid body physics, rotational velocity is usually just a single number representing how fast something is spinning. Given a radius from the center of a spinning object (e.g. object origin -> a contact point in world space), the instantaneous linear velocity is the rotation speed times the tangent to that radius. Therefore, the Jacobian is just that tangent vector - multiplication by that vector transforms scalar rotational velocities into 2D linear velocities. The Jacobian for the object's linear velocity is just the identity matrix.
The rotation Jacobian is more complicated in 3D and 4D, but the principal is the same - find a matrix (at a particular point, usually the contact point or the joint location) to multiply with whatever represents rotational velocity to get the linear velocity.
Yeah, I've mostly ignored it so far as well. I did get Dual Contouring working on 4D signed distance fields, but the resulting meshes are kind of janky. My thoughts are to eventually get boolean operations working on arbitrary tetrahedral meshes and do some CSG, or create a Blender-style 4D mesh editor.
Another game idea is The Incredible Machine in 4D, but it would be so hard to play, and even harder to design the puzzles.
I've been working towards making something like a 4D Descent, but I keep getting sidetracked by problems like 4D physics, collision detection, and mainly how to model interesting 4D objects.
What Marc's done with Miegakure, from what's publicly visible, is pretty incredible. I have no idea how he's managed to seemingly create a coherent 4D world while only being able to view a slice of it at a time. I guess it's a bit like using ed instead of a modern text editor.
I mostly love K/Q, and recently rearranged my career to do more of it. There are some things to be aware of, though:
* If your code doesn't spend most of its time in primitive verbs operating on large vectors, it's gonna be more or less as slow as any other interpreted language. Q and kdb+ can be fast and beautiful if you can arrange your problem in the right way, but it's not magic.
* The internals are locked away. If you don't like the way something fundamental works, tough. I've known some folks to go to heroic lengths with debuggers and hacked up shared objects to get Q to do what they want. You could also get Kx to add the stuff you need (they're pretty reasonable and responsive). But, you can't really take it apart and put it back together again like you can with, say, Lua, Ruby, or Python.
* Relating to the above point, one of the weaknesses of the language is that there are a lot of useful (even necessary) features packed into weird corners. There's little room for abstractions beyond the basics, so you get stuff like CSV parsing controlled by the structure of lists passed to a function called "0:". It's getting better documented lately, but it's still not pretty.
* Various annoyances (no real module system, no lexical scoping, etc...)
In many of those cases, I'm not even sure what could be done without compromising some other aspect of the language. Most of the time (at least for me), it's really a joy to use.
kdb also allows you to do much more than SQL, since a select is more or less just syntactic sugar for a certain set of operations on columns as arrays. The full language is available in the context of the query, or you could just treat your table as a bunch of arrays in the context of a larger program.
It's a really elegant way of dealing with large amounts of data, although the downside is that you've typically got to build a lot of the nice-to-have dbms type infrastructure yourself.
It would be interesting if BigQuery or Redshift ever figure out that they could have a much more powerful system if they stuck an array language on the front of their storage engines.
It's quite handy, though the syntax for it is rather clunky compared to the rest of the language in my opinion.