## Non Euclidean Room – Postmortem

Posted by
Friday, December 23rd, 2016 1:33 pm

For Ludum dare 37, I worked on a game about wandering around a strangely connected room. The idea obviously come from the works of Escher on “impossible” geometries. The connection with the theme is to have only one big room, but using portals to make it interesting to visit.
You can play and rate the game here : http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=18943

At first I wanted to have puzzles, like pointing lasers to open doors. You would use portals to change gravity and walk on the ceiling. I also wanted to have markers for the player to place around and help you navigate the room. In the end, I only had time for portals and a simple room, with a couple of interesting visual tricks. The scope is smaller, but by focusing on smooth portal transition, level design and polishing, the game ended up pretty well.
Here is timelapse recorded during the creation of “Non Euclidean Room” :

Portals :
Making portal feel simple but a lot of things can go wrong. At first I simply wanted to plug a copy of the room at each door and teleport everything around. That can work but it limit what you can do a lot. You cant have two doors close to each other. Basically you can only have doors on the external faces of the room.
Then the next technique is to use a render texture to produce a view from the portal exit with a second camera. An object will use that texture to display it on the main camera.
Here is the code (in Unity C#) I use to place the portal camera according to the main camera and transforms from Enter and Exit portals :

```Quaternion Rot180 = Quaternion.Euler(0, 180.0f, 0); Vector3 LocalPos = EnterPortal.transform.InverseTransformPoint( MainCamera.transform.position); Vector3 RotatedPos = Rot180 * LocalPos; PortalCamera.transform.position = ExitPortal.transform.TransformPoint( RotatedPos); PortalCamera.transform.rotation = ExitPortal.transform.rotation * Rot180 * Quaternion.Inverse(EnterPortal .transform.rotation) * MainCamera.transform.rotation;```

You use the main camera location in the local space of the entering portal, you pretend it’s a local position in the exiting portal and get it’s world location to place the portal camera. The rotation by 180 degrees is there because the exiting portal face opposite to the entering portal. You do the same on the rotation of the camera.

Portal camera location

This technique can certainly work, but will need a render texture per door. So I tried something else.
I used only two cameras, and the stencil buffer. The idea is to first mark (in stencil buffer) the portal pixels on the screen by drawing them from the main camera point of view. Then draw the scene through the portal, by placing the camera at the correct position, and using the stencil as a mask. Then rendering the usual camera above that, without overriding the portal door.
For the player motion himself, I just teleport the player when he pass the middle point of a portal to the relative location in the second portal.

Portal Anatomie

A second trick that I needed is to use a clip plane along the portal door. You want only objects from beyond the portal to be visible. For that, you can use an oblique projection matrix. This technique create a near clip plane in an arbitrary orientation by distorting the camera projection matrix. There is some downside though, as some visual glitch can appear when the camera is near the clip plane. If you stop in the middle of a portal, you can sometimes see the screen edge disappear. Another idea, that I didn’t have time to test, is to send the clip plane to the shader, and use the instruction “clip” to discard pixels that are on the wrong side. That way, no need for a custom projection matrix.

Oblique projection matrix

After having that first version working, there was only one visual glitch when going through a portal. You could not see a portal trough another portal. That was very obvious when walking through a portal : every other portal will pop into existence. To fix that, I needed to display portal through portal, at least for the nearest portal from the camera.
The idea is to use the stencil bit masks to read and write two separate portal indexes. That way I could tag a door, and a door inside a door. This did limit the portal count to only 15, as there is only 4 bits left in the stencil buffer for each index. But this was enough for the small game I had in mind for Ludum Dare. I could also take the nearest 15 portals from the camera, but it was already time to start the level design so I limited myself to 15 total. You may notice that there is 16 doors in the game. In fact the final door that let you leave is not a portal, it’s a regular door. The portal transition is smooth enough that you don’t notice. Since the LD, I improved the tech quite a bit in a post-compo version.

Visual style :
I decided quite early on the visual style I wanted for the game. The reference to Escher’s work is obvious : black and white with thick lines and a shading made by changing line density. I choose a style a bit more sketchy and, of course, animated. The strokes are placed on the screen and move with the camera. The animation is there to hide that fact. I blend 3 layers of strokes, and 3 times per second, each one have a chance to pan and rotate. This give an unpredictable animation. Some people found the effect a bit too disturbing after a while. I want to revisit it later.

The second part of the visual effect is the edge lines. The issue with portals, is that I render everything in “forward” so I don’t have a “normal buffer” to run my edge detection on. I don’t have a proper “depth buffer” either because of the way I render portals. So, I needed to use only the color buffer to make my edge detection. To detect normals, I simply render the absolute value of the pixel normal in the color buffer, modulated by the lighting intensity. So to have the luminosity of a pixel, I can use the value of the color (average of red, green and blue). And I can use offsets in hue to detect edges by sampling a pixel to the right and a pixel to the bottom of the current pixel.
I also wanted to detect depth discontinuities, so I had the idea to modulate the pixel color by the depth, making some sort of fog. Surfaces with the same normal but at different distances will then have a slightly different colors, and could be detected by the edge filter. The fog gave a moody atmosphere to the scene but I liked it. To complete the look, I added a Gaussian bloom filter, to give some gradient to the flat blue interactive objects.

Scenes from the game :
– Penrose infinite stairs

– Twin scenes through portals

– Falling through an empty space

Future post-compo version :
As much as I like the game as it is, a simple exploration game where you make your own path, I wanted to do more. In the beginning, I wanted to change orientation when you go through portals, letting walk on walls and ceiling. But I used the Unity Controller. And that controller cannot be rotated around freely. The collision capsule is fixed on the Z axis. So I did with that constraint. But now I started to extend the game in a Post-Compo version. The idea is to make a second room and exploiting everything I couldn’t in the base game.
– Infinite recursive portals :

– Proper puzzle with blocks (and laser later) + walking on walls :

I hope to complete that second room in early January 2017, with interesting puzzles and a longer playtime.

## [Almost] One Room Post-mortem – Part 2

Posted by
Thursday, December 22nd, 2016 6:21 pm

On the first part I wrote about how it was the birth of the idea. Today I want to talk about execution and learning, because if you remember correctly, the main idea was to learn Unreal Engine 4.

The starting point was to let the player find a number combination for a door. Every number will be in a copy of the same room, but every room will be lightly different.

We started thinking how to hide the numbers and we wanted to go beyond the easy way of hiding behind the furniture. We wanted the player to think out of the box, and our main fear was to make puzzles too hard to be guessed. With the time restrictions of a jam the harder part is to balance a game, and to balance something as subjective as a puzzle difficulty is only doable if you can make people play it, we hadn’t people.

The first thing we did was to draw a generic room layout with 4 doors, one on every wall but not in the center. Rooms in real life don’t usually have the door in the center, it wastes too much space and from a gameplay perspective, it will limit what you can place there and may compromise room walkability.

On the other hand I’ve started “coding”. For those who have not worked yet with Unreal Engine 4, it has a visual programming system called blueprints. In the editor you create logic by connection boxes; for example, you have the “branch” node, it receives a boolean expression and it has 2 outputs, one for true and the other one for false evaluation, the flow of the code will go from one output or another depending on the result of the expression, exactly like an if-else statement on traditional programming.

The first thing I coded was the num picker the player will use to put the numbers of the combination. The idea is simple, you will have a collision box to know when the player is next to the picker and everytime the player hits the mouse left button, we will increase the number up to 9, then, it will go to 0. Also, we will need various of these number pickers because the combination will have 5 numbers and every picker lets the player to select 1 number from 0 to 9. To be able to reuse this asset we will create a Blueprint Class, something like a object oriented class that groups code and other assets. In our number picker blueprint class we will have a box mesh, a UI text widget, the collision box and the code. We will be able to instantiate as many as we need and we will be able to access its public local variables to interact with them in the level blueprint.

Honestly, I’ve been coding for more tan 15 years and the mental switch you need to do to work with blueprints it’s remarkable. Not in terms of difficulty, in the end it’s logic flow and it does not matter if it’s a box or a code block, but more in terms of how do you have to do the flow. It’s hard to describe to me, because it’s not something specific. For example, for the num picker you need to increment an internal integer that stores the number on the picker, something that for me was a single line of code ( this.number = (this.number+1)%9 ) transforms in some nodes: a getter to get the value, next increase the number, then get the module and finally store it in the same variable. It can be done in less steps with a Math Expression Node, but it’s an example. What I’m trying to explain is that even when you know how to code the learning curve of the Engine, specially learning where do you have to go in the editor because it’s full of buttons and windows and tabs.

Back to puzzle design, we decided that we will need to teach the player that he needs to find numbers. That’s why we locked all the doors in the initial white room and put a first codelock there. Also this first puzzle is the easiest one, a giant black 35 in the ceiling, only partially hidden due to it’s like an humidity stain. Locking the player also gives us the moment of surprise when he opens the doors and finds the same room over and over again.

Once Carlos told me how the basics of blueprints and the event system I started to prepare the door unlock code. Meanwhile Carlos was working in the assets we will need, the furniture, doors, etcetera. We needed functional and easy to create assets and whats more generic, easy and reusable furniture in the world? Disclaimer, no brand or company funded the creation of our game. IKEA of course! :V

We relied in UE4 vertex painting tint every room, we used a material with a color parameter in some assets, giving us an incredible power to get all the rooms done with a minor impact in performance and a huge time saving. The only texture applied to the assets was a baked ambient occlusion to give them the correct shading.

Finally to create the puzzles we used different techniques. For the distance one is a simple material that changes the opacity depending on the distance from the camera. Something similar happened with the reflection, we have a copy of the same room below and the floor uses a material that changes the opacity in this case with a Fresnel function. We wanted that the details that changes in every room helps the player to find the clue. For example in the light one there is a second lamp, no other room has it, the green room is the only one where the statue is different.

And it’s all, we wanted to do more content, but I’m happy because we marked us a minimum product and we delivered it as we imagined it, but the process was good enough that if we had more time, more content would be done fast, spending again the major part of the time designing new puzzles.

## [Almost] One Room Post-mortem – Part 1

Posted by
Monday, December 19th, 2016 6:16 pm

Ludum Dare #36 was very special to me. I was on my town, at 1400m above the sea, with barely no connection to the Internet (only a weak WiFi signal from the town hall, no mobile access). I was alone, and I wanted to use the jam a perfect moment to learn Unity3D. I spent the days before the event day to watch some videos and I was able to complete a little but full game.

By creating [Almost] One Room for this one I wanted to repeat in the sense of learning. But this time I was not alone, I joined forces with Carlos Coronado (@carlosgamedev); he’s the creator of Mind: Path to Thalamus and an unnoficial Unreal Engine evangelist. He is also a friend of mine and one of my clients. Some years ago a guy of barely 16 years came to the gamedev forum I had and asked for a project to join and learn, we made a barricade system for L4D. Now this time it’s me who is asking him for help.

The idea was simple, I’ll “code” (with blueprints) and Carlos will do the art and will show me the basics of the engine and will aid me every time I get stuck and ¡spoiler alert!, it was often.

In fact we have not opened UE4 until the afternoon because Carlos was late and I spent the whole morning taking notes on paper about ideas with the theme in mind. When Carlos arrived I presented the best idea I had and we wanted to spend as much time as we can in the design stage.

We wanted to make a puzzle game playing with the idea of a room escape. For me it’s very important to find a twist to the Ludum theme, to go further than the obvious choice and that’s why I did not want to make a game with a single room. I played with ideas like turning the words, “What’s behind Room One?” or “You’re the room”, tried to think in a twist in the “CounterStrike rats map” making the players not humanoids. Finally we found something in the Room Escape idea that we liked, only one room, but many times.

The initial idea was to be locked in a room like a normal room escape but once you opened the first door you will find the same room again. From this point we started to think how you will need to open the doors, from lockpicks with mini-games to find-the-pieces ones, but it was hard to find something really fun, or something that the player cannot solve by trial and error. And more important, something we can achieve in the given timeframe.

At some point we though we nailed it, the room will be “the same” but in different timelines, past, present and future, and you had to change things in a time to affect the others and unlock the exit door. It was great, but it was impossible to find something readable enough to be solvable and not frustrating.

Time was running out and finally we went back to the beginning and started again to think. Then we decided to follow the KISS principle and we decided to make a simple puzzle game: Find the combination of the exit door. The twist? That the number will be hidden in the room, one number per room on different versions of the same room.

We then started to design how to hide numbers, but I will write about it in the second part 😉

[cache: storing page]