Last time we saw that, while we can describe a maze abstractly in terms of its network of paths, we can implement a more causal (that is: physical) approach by simulating its walls. In particular, this allows us to preserve its basic physical shape, which can be of value in game or art contexts.
This time I want to talk more about virtual walls as causal objects in a maze (or any) simulation. Walls are a basic physical object (as well as a basic metaphysical concept), so naturally they are equally foundational in the abstract and virtual worlds.
And ironically, “Something there is that doesn’t love a wall.”
In the functional maze simulation a “wall” is a single datum associated with a given location in the maze. That datum just says whether a wall exists in that location (or not).
We can expand that to give a particular wall various properties, such as transparency (making it a window) or the ability to open (making it a door). We could also give it properties like thickness or strength if our simulation allowed a notion of breaking through walls.
If we imagine a game in which players have lasers, hammers, plus their own physical strength, then walls might be characterized in terms of how effective those things are. A shiny weak wall might reflect lasers but submit to physical strength. A stronger wall might require a hammer.
It all depends, and it’s a bit like that old game of rock-paper-scissors: The rules of causality in a virtual world are entirely up for grabs. You can freely create a virtual world in which paper really does beat rock.
Because why? Because math!
In the virtual world everything is based on math.
As we saw in the functional maze, a wall can be represented by a single bit in a number, the presence of a word in a string, or some kind of variable. In all cases, a single “fact” about reality. We only care whether a wall prevents moving to the adjacent square or not.
That’s location is an abstraction limited to single grid squares and movement is square by square. The only thing that matters is whether a move to another square is legally allowed by the rules.
And those rules say we can’t move through walls.
If the game is more sophisticated, as touched on above, then each wall needs more than a single “fact” to define its properties. The game also needs more involved rules for deciding when a wall can be busted (or maybe just seen) through.
A common extension is a door — a portion of a wall that is passable when open and impassable when closed. In this case (and in the case where walls can be broken down) the wall data must be dynamic so it can reflect the current state.
This means how we represent virtual walls depends on our needs. In a simple maze we may only care that a wall exists or doesn’t. As things become more sophisticated (that is to say, more physical or life-like), the representation necessarily becomes more complex.
At the extreme, the data represents walls (and everything else) at their lowest possible level — as fundamental particles. Which is basically impossible with current technology. (Although quantum computers will allow quantum-level simulation of small bits of reality!)
Even atomic or molecular simulations of large systems (like walls) is beyond common computing ability. The best powerful computers can do today is break the wall into something like parcels — their size and detail generally correlating with the size of the wall. (A bigger wall requires bigger parcels to keep the computing requires manageable.)
Unless the point of the simulation is to capture the detailed and accurate physics of walls, there’s no need to go down to that level.
In most games, for example, a wall can be a single object of a specified size (height, width, thickness) and having whatever properties are necessary for the game. A crucial one in some games might be what the wall looks like — it’s surface texture and color.
For example, a “brick wall” is often just a solid wall with a brick texture. There is no need to simulate the individual bricks… unless that is a factor in the game. Perhaps “bricks” can be removed to create a peephole, or maybe the wall can be broken down and the bricks used in some fashion (say as weapons or to build something).
It all depends on what’s required by your virtual reality.
Note again there is no requirement to stick to reality. Bricks can vanish if touched or turn to frogs that hop away. The numbers can do whatever we want them to do. Paper beats rock!
So if it’s all done with math, how exactly is it done?
I’ve explored the basics of how walls might be represented. Basically, a “wall” is a related data group (set of “facts”) that defines the wall’s nature. Exactly how that data is stored is an implementation detail. What matters is the facts we can obtain about the wall.
One of the more significant facts being its location in virtual space.
As we make the virtual maze more physical, one of the first changes involves the grid. To capture curved walls, or any non-regular floor plan, the grid must be much finer. Previously, we equated a grid square to being a “room” in the maze. Now each square needs to be something more like a square inch.
The actual size depends on our needs. The more precise the virtual reality needs to be, the smaller the grid squares need to be. As mentioned above, an extreme version takes us down to the size of molecules or atoms or even smaller.
Often the grid simply becomes good old X, Y, and possibly Z (if we want the vertical). Then locations — the coordinates — are real numbers. Also, objects extend over many coordinates because they have width, depth, and height.
This makes the notion of location more complicated. A single location might define the center (or some corner) of an object, but it can’t define the boundaries. That requires multiple coordinates.
For regular objects (many walls, for instance), it suffices to provide the coordinates of the edges. As an example, any rectangular box can be defined by just its opposite corners. So just two coordinates can define the boundaries of a square beam or rectangular wall.
With more irregular objects, it takes more coordinates to define the shape. If you’ve ever seen a wire-frame rendering of 3D objects, you have some sense of how many. Each node (point where lines connect) is a coordinate. (Wire-frames are made by simply drawing lines between adjacent shape-defining coordinates.)
These coordinates tell us is where the edges or surfaces of an object are. We obviously need to know that if we’re to simulate the physics of solid objects, because (generally speaking) solid objects can’t overlap.
In light of all this, let’s consider a simple example: a wall.
Let’s say this particular wall “exists” on the X coordinates +120.0 through +145.0, and we’ll define a unit of 1.0 as one foot, so the wall is 25 feet wide. We’ll also say its on the Y coordinates +82.0 through +82.5, which makes it 6 inches thick. (The thickness will become important later!)
For simplicity, we’ll skip the vertical Z direction and stick with 2D.
Imagine we throw a ball at this wall with the goal that it bounce off the wall — a simple real-world event we’d like to simulate as reasonably accurately as possible. (Which we’ll define as realistic flight of the ball.)
Obviously we need to detect the moment of contact. What does it mean for a virtual ball to come in contact with a virtual wall?
We’re sticking with 2D, so a ball is a circle (think of it as the ball’s shadow on the floor). Circles are simple to define: they have a center-point (one coordinate) and a radius. Let’s say our ball has a radius of 0.25 (three inches).
Assuming the ball is within the X coordinates of the wall (120.0 to 145.0), then what matters is the Y coordinates (82.0 to 82.5).
To know when the ball hits the wall, we need to know where its location at some prior moment and we need to know its velocity.
Which brings us to a crucial point: Our virtual reality needs a clock!
In the functional maze, movement was akin to moves or turns in most games — asynchronous.
In most games, the only dynamic is the move itself. Time essentially freezes between moves. (Such games have well-defined state tables.)
In a physical simulation, we need to simulate time in order for there to be motion and change. So the simulation itself always has a notion of what time it is and of time ticking.
Time is a fundamental property of virtual reality!
The notion of time informs the notion of velocity, which is motion of a given speed (distance divided by time) in a given direction (an X-Y vector).
So if we know the ball is at [+130, +80] and its direction takes it in the positive Y direction (without too much X direction), then it hits the wall when the center-point reaches the coordinate 81.5.
If it was on the other side, say at Y=+90 and headed “south” (in the decreasing Y direction), then it hits the wall when its center-point reaches 83.0.
As each moment ticks past, the system looks at the ball’s coordinates and uses its velocity to update its location.
It checks that location for a collision with the wall, meaning the center-point of the ball (plus the radius) is at — or just inside! — the wall. If so, the ball has hit the wall.
What happens next depends on the wall, the ball, and the simulation.
That “just inside” needs some unpacking. The idea of the ball’s motion as well as what happens upon collision are topics that I’ll pick up next time.
For now I’ll just re-emphasize the key point:
When “reality” is just numbers, “reality” is easy to manipulate!
In a virtual reality, paper really can beat rock.
Virtual reality is arbitrary! (Because math.)
Stay virtual, my friends!