> 4D Blocks
> Version 6
Kinds of Blocks
Block MotionI already told you about all the control keys (in Controls), but there are several important points about block motion that I ought to explain as well.
The first thing is, if you're going to be moving blocks around, you really need to be comfortable switching into and out of align mode. When you're in align mode, you can only point in a few directions, straight along the axes, and that makes it very difficult to point at and select blocks; most of the time you'll have to move to a new position before you can point. In unaligned mode, however, you can just point directly at anything you can see! It's probably best to practice in 3D first. Just as a reminder, "shift-enter" switches you into and out of align mode, and "enter" by itself does a one-time alignment when you're unaligned, without putting you into align mode.
A new element that's present in the block world but not in the maze world is that alignment can fail … for example, when the nearest grid point is inside or on the other side of a block. In that case, the alignment process will stop when you run into the block and you'll be left unaligned. That's another reason you need to be comfortable being unaligned, because you can't always get back to align mode right away.
It's also useful to be familiar with the slide controls. This is discussed further below.
It's also useful to develop the ability to orbit. If you're looking at some structure, often you'll want to move around to another side while keeping your view pointed at the structure. That's orbiting. How do you do it? Well, suppose you want to orbit to the right. First you take a small step to the right (using the slide controls), then you make a small turn to the left to keep the structure in the center of your view. After a while you'll arrive at another compass point and all the diagonal lines will resolve into nice orthogonal ones again. If they're not orthogonal enough, you can always press "enter" to realign yourself.
If you're looking at a single block, you can get the same effect by picking up the block and turning it (turning the block instead of yourself), but if you're looking at a whole structure there's really no substitute for orbiting. It'd be nice to have orbit controls in the game, but there are already more than enough controls. Also, by hand you can orbit at any radius, and it's hard to know how to automate that.
Now let's talk about block motion. The basic idea is simple enough: you select a block by pointing at it and pressing "space", and then all movement commands apply to the block instead of to you. There are several subtleties there, however.
In other games it's common to have a third-person view where you can see yourself as you run around and do things. Controlling a block is not quite the same. In a normal third-person view what you see is the back of the character, but here it's very unnatural to think of what you're seeing as your own back. When you tell a block to turn left, you don't want the invisible front face of the block to rotate toward the left, you want the visible back face to rotate toward the left. So, when a block is selected, most of the rotation controls are reversed, although hopefully the result will feel so natural that you won't even notice.
Another difference has to do with moving sideways. When you're moving around as yourself, if you want to move left, you simply turn left and move forward, but when you're moving a block, you don't want to have to keep track of which way the block thinks is forward (or, worse, its entire three- or four-dimensional orientation). So, the forward and backward commands always move the block in your forward and backward directions. If you want to move the block along any other axis you'll need to use the slide commands, so you definitely need to be comfortable with those too.
But, what if you've gone out of align mode to point at a block, and now you've picked it up and are moving it. Should forward and backward move the block along whatever crazy direction you're pointing? Definitely not! So, what happens in that case is, when you first pick up the block, the program compares the axes that define your orientation to the axes of the absolute coordinate system and matches them up as best it can. When you tell the block to move forward, it will move along some coordinate axis, and hopefully that axis is close enough to your own forward direction that the result feels natural.
My experience is that it works pretty well. If I'm looking mostly north, then north is forward, and if I'm looking mostly east, then east is forward. There's one case that gets me into trouble, though. Suppose I'm facing north, and I lift up into the air and gradually turn downward. The matching algorithm will switch from "north is forward" to "down is forward" at exactly 45 degrees, but I find that I want to hold on to "north is forward" for longer than that, maybe up to 60 or 70 degrees. I guess it's a bias I have as a person who grew up in a gravitational field.
The rotation controls use the same matched axes, by the way.
Now for the final complication: blocks too can be aligned or unaligned. If you pick up an aligned block, you'll be in align mode, where you move one grid space at a time and turn through 90 degrees at a time. Most of the blocks in most of the scene files are prealigned, so most of the time that's what you'll experience. However, if you pick up an unaligned block, or if you hit "shift-enter" to go out of align mode after you've picked up an aligned block, you'll have total control over the block's position and orientation.
Looking at and moving unaligned blocks can be overwhelming at first, but there's also a lot you can learn from practicing with them, especially in 4D. If you want to build structures and solve puzzles in unaligned mode, the "enter" key is very helpful. All you have to do is get the block close to where you want it, then you can hit "enter" to make it snap into place.
When you're moving blocks around, you'll soon notice that they can collide with each other. The collision detection isn't perfect, but it's pretty good, good enough that mistakes are rare. The algorithm errs in favor of not colliding, so you shouldn't ever see blocks interpenetrate; what you'll see instead is blocks that look like they ought to move, but won't. If a set of blocks is really completely stuck, you can always use control-S to untangle them. Note: trains are intangible and can move through anything.
That gives one more way you can get an unaligned block. If you have an aligned block that you're moving around, and it happens to run into something halfway through some motion, it will just stop and become unaligned.
A few other notes: