u/AblazeInt

I wanted my monster detector device, the Rift Field Meter, to have a more unique way of displaying the information. Among others, I considered mercury droplets and cymatic patterns for the display, but I thought ferromagnetic fluids worked best here.

Even so, this went through multiple iterations. At first I made a more classic black ferromagnetic fluid, but it turned out to be too dark and difficult to read to the player. I then added glow/emission to the peaks of the fluid, which definitely made it look cool and easy to read, but it seems to sci-fi for the base game theme (1960s military research lab, fitting since ferrofluids were invented at NASA in 1963).

A sand-like surface ended up as the final version, since it also interacts nicely with the light from the side Flux Cells so that it can be read even in total darkness.

The "display" is based on a sub viewport which renders a displacement map, which is then applied to the screen mesh. An Area3D on a specific layer is used to find only objects that can be detected. Besides the peaks of the detected entities, there is also an animated noise layer to make it look like it also picks up interference, and the player can look sideways to pinpoint only the real signal.

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

Since I needed an elevator for the Ravensworth Grand Hotel nightmare, I added a couple of extra gameplay features to make it more interesting, including openable ceiling to climb on top of the elevator, removable floor tiles to go below, sensor doors, visible counterweight, doors on both sides of the elevator, and a call button you can spam like in real life thinking it will arrive faster. If you reach the top, you can also see the mechanism above.

Inspired by the classic "birdcage elevators" from around the 1900s.

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

Since the begining of the project I wanted to make an in-world map. And specifically because I want the map to be easy to read and use, I design the levels mostly horizontally, with minimal overlap between different elevations.

On the left side you can see current objectives for each of the 3 playstyles. In this case here, the shadow (stealth) path has failed because the player was spotted by the monster. I want these to be sufficient for guiding players, without needing location markers on the map. Also, surrounding the map, different clues that the player discovered will appear.

The map texture is rendered in a subviewport, containing 2 layers which gradually reveal based on player proximity, one regular (visible here), and another one for secret locations, which reveal only when discovering and entering such areas (these will appear in red).

It took a lot of tweaking to get the pose of the hand/map to look nice standing and crouched, when looking forward, up or down. In case you missed this from my previous posts, the player character is full body.

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

I want Psych Rift to be riddled with secret passages and rooms, and this is one way to reach them.

All the props in the game are physics bodies, and you can manipulate them as you wish, and large/heavy objects can be thrown to damage walls.

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

100% hand-made. 0% AI.

I want Psych Rift to be riddled with secret passages and rooms, and this is one way to reach them.

All the props in the game are physics bodies, and you can manipulate them as you wish, and large/heavy objects can be thrown to damage walls.

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

100% hand-made. 0% AI.

I want Psych Rift to be riddled with secret passages and rooms, and this is one way to reach them.

The occlusion culling feature in Godot works great out of the box, but it has a limitation. It only hides meshes, and has no effect on lights. And from what I have seen, even when a mesh is hidden, lights will still see it when rendering shadows.

Since Psych Rift has mostly indoor environments, there is a pretty high density of meshes, and especially lights. Wherever you see a light source (lamp, etc.), there is an omni light there. This quickly adds up to hundreds of omni lights, and thousands of meshes and rigid/static/animatable physics bodies in a level.

To keep performance in check and still target my goal of running on RTX 3060 (high settings, native 1080p@60 fps), I made a custom system to be able to hide lights as well. I build my levels from what I call "blocks". A block is a scene that represents one individual piece of a level, like a single room, or a part of a corridor. These are all connected together to form the whole level.

Alongside regular occlusion culling, my system makes use of VisibleOnScreenNotifier3D nodes to detect when a block is not visible to the player and can be hidden, including lights. When a block is hidden, all rigid bodies in it are also disabled, to help the physics engine as it searches for collisions (floors and walls stay on, since monsters might still be moving in those areas).

It's not perfect (occlusion culling is not "airtight" and usually leaks) and there is still room for improvement, but it gets the job done overall. You can tell when the lights are still on because they light up the fog when running in wireframe mode.

(This video is made from two overlaid recordings, but they are not perfectly in sync so it may look a bit wobbly sometimes)

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

The occlusion culling feature in Godot works great out of the box, but it has a limitation. It only hides meshes, and has no effect on lights. And from what I have seen, even when a mesh is hidden, lights will still see it when rendering shadows.

Since Psych Rift has mostly indoor environments, there is a pretty high density of meshes, and especially lights. Wherever you see a light source (lamp, etc.), there is an omni light there. This quickly adds up to hundreds of omni lights, and thousands of meshes and rigid/static/animatable physics bodies in a level.

To keep performance in check and still target my goal of running on RTX 3060 (high settings, native 1080p@60 fps), I made a custom system to be able to hide lights as well. I build my levels from what I call "blocks". A block is a scene that represents one individual piece of a level, like a single room, or a part of a corridor. These are all connected together to form the whole level.

Alongside regular occlusion culling, my system makes use of VisibleOnScreenNotifier3D nodes to detect when a block is not visible to the player and can be hidden, including lights. When a block is hidden, all rigid bodies in it are also disabled, to help the physics engine as it searches for collisions (floors and walls stay on, since monsters might still be moving in those areas).

It's not perfect (occlusion culling is not "airtight" and usually leaks) and there is still room for improvement, but it gets the job done overall. You can tell when the lights are still on because they light up the fog when running in wireframe mode.

(This video is made from two overlaid recordings, but they are not perfectly in sync so it may look a bit wobbly sometimes)

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

This is some behind-the-scenes footage from the General Office from the Ravensworth Grand Hotel in my previous post. For lighting, I do not use GI or lightmapping, the entire scene being lit with only a few omni lights.

The Lashers are animated with blend shapes and skinned with bones. I could not use VATs here since the material vertex shader applies after the skinning, and would produce incorrect results. The solution was to use blend shapes, which apply to the mesh before skinning.

You can find more videos on YouTube, wishlist the game on Steam, or join the Discord for a chat.

Lenore's deadly hair has 13 independent strands rigged with 111 bones, and is animated with a mix of regular keyframed bone animations, spring bone simulators and IK chains.

For lighting and materials, it's my usual basic setup I described in this post.

This is a more practical use of the VAT (Vertex Animation Textures) technique from my previous showcase post. The effect is composed of two VAT meshes, one for the wall, and one for the bricks, because of my self-imposed 4096 vertex limit per VAT mesh. The brick wall has 437 individual bricks and 3496 verts, animated through bone chains, and the wall surface has 4016 verts. While doing the animations is pretty straightforward, the tricky part is finding ways to do it as a single mesh, so that it can be exported to VAT.

An effect like this would be tricky and/or expensive to do through traditional/procedural methods at runtime, but with VATs it's quite efficient. The downside to VATs is the VRAM usage for the .exr VAT textures which need to stay uncompressed (this effect uses 2.5MB VRAM), and the fact that LODs do not work with VATs (mesh topology needs to stay intact). But I think the effect is worth it, and I will be using it for many more cool effects in the game.

Compared to my previous video, I made improvements to the VAT shader, so that now I can have flat normals calculated dynamically, and no longer need to include normals in the VAT texture. This halves the VRAM usage and runs faster because no more normal texture samples are needed. Overall the effect including the VAT shader updates took 2 days to complete.

My implementation was originally inspired by this Godot VAT plugin.

YouTube Steam Discord

EDIT: Thank you so much for the awards!