Since I am working on an Escape Room setting where the player should be allowed to freely walk around without teleporting, the play area becomes hugely important. First the terms:

- Boundary: The
**actual line**the player has virtually drawn to limit the available play space - Play area: The
**biggest possible rectangle**that fits inside the boundary

## Stable Fit

My actually very simple goal is now to **create the world inside the play area**. It cost me multiple days (ok to be fair, I also did solve tons of other problems in parallel, but this one really kept me busy).

Here is the catch: **0,0,0 can be anywhere** and to make it even harder, the boundary can be **rotated **in any way around Y. The player can even dynamically change 0,0,0 by **re-centering**, e.g. long-pressing the Oculus button when using the Quest. I had actually hoped that VRTK would already solve this issue, but either I didn’t understand the concept or it does indeed not provide it.

The picture below illustrates the basic issue (with some debug output on top, “geometry” is the interesting part):

So my goal expanded: How can I **calculate the correct rotation and offset **to draw the world into the correct place, always being inside the purple boundary?

### Rotation

Given 4 points of a rectangle, it is possible to calculate the rotation using arc tan (I am not a math guy, so this took me a while). A good approach for both can be found at **DashW’s GitHub**. Centering is luckily merely a question of something like:

`new Vector2((x1 + x3) / 2, (y1 + y3) / 2)`

My approach is very similar (I found the above page only later unfortunately) except that I don’t rotate the camera but the constructed world. As mentioned in the comments on GitHub, the solution is actually deprecated. It turns out, Oculus added a **new tracking origin type **called “**Stage**” which does two things: it does the rotation calculation and will create the play area in a way that the rotation is zero. 0,0,0 will then be put into the center of the rectangle. That is convenient.

The catch is, it **only works for Oculus Quest**. If you have a Rift or other device or want to test locally, you are back to doing the math on your own. So I decided to actually keep my solution. I still set the tracking mode to Stage though as it brings one crucial benefit: it **disables re-centering**. The player cannot interfere with the play area any longer which is really important for scenarios where one needs a stable fit, e.g. placing furniture or, an Escape Room.

### Position

The next challenge was to identify the corner inside the boundary, that will represent X and Z pointing inside, so that the constructed world can be anchored there. I use a bit of a weird algorithm which I came up with after some trial and error and quite some automated tests.

```
// determine correct anchor point
float rot = GetPlayAreaRotation().eulerAngles.y;
int i = (rot >= 90 && rot < 270) ? (boundaries[0].x >= boundaries[1].x ? 3 : 2) : (boundaries[0].x >= boundaries[1].x ? 2 : 3);
```

As a result I get the index of the boundary corner which then is my offset for the world after rotation. Below an illustration of what happens when the wrong corner is picked.

## Padding

Something that can really **break the immersion** in my opinion is when suddenly the **Guardian **system kicks in and reminds you that there is a physical world around you. This will happen **automatically **(and cannot be deactivated for non-developers) whenever the player gets close to it.

When constructing a world inside the boundary, this means that every time the user approaches a wall for example, the **boundaries will pop up**. To mitigate this, we can use the concept of padding by **artificially reducing** the size of the play area. This will of course make the gaming world slightly smaller but my measurements show that already **15 centimeters** make a big difference.

A for me surprisingly interesting part was how to actually add the padding to the offset calculated one chapter earlier. I somehow had to move the point into X and Z direction.

After a bit of tinkering the solution is actually quite simple: Since we can calculate three points, the fourth one can be derived through (D being the unknown one):

```
AD = BC
(Dx - Ax, Dy - Ay) = (Cx - Bx, Cy - By)
Dx = Ax + Cx - Bx
Dy = Ay + Cy - By
```

## Putting it all together

Once the math was solved I built a UI (more on that in another blog) so the player can now adjust the settings to his needs. The grid is created with a couple of **line renderers** which seems to work out just fine so far and it actually has a nice glowy touch out of the box. There are alternative ways of drawing lines as **described here** but for now I won’t bother with that as I quite like the result.

Right now the player can only change the padding but the editor already supports adjusting grid size as well which I might work on in a future version (imagine having wider floors to walk through for more convenience). Currently without any scaling adjustments its more like an artsy room generator ðŸ™‚