Rune Skovbo Johansen
Creative Programmer & Designer


Creaking Gorge and The Cauldron

Since my last post in July where I finally got a vision down for the level design in Eye of the Temple, I've been feeling super productive adding new areas and features to the game.

In August I added two new areas and in September I've been revamping the in-game UI and the speedrun mode. Only problem is I haven't kept up with these blog posts. To avoid this post getting too long, I'll cover the new areas here and save the UI work for a later post.

Creaking Gorge

Creaking Gorge is an area where you move along and into cliff sides and atop wooden scaffolding. It's by far the most vertical area in the game, spanning more than 50 meters vertically. It's a fairly non-linear area too with multiple paths that can be followed in an order you choose. The verticality combined with the fact that not all of the paths can be seen, since they carve into the cliffs, means that it can be a challenge to keep track of your orientation and where to go next. It's an area of contracts since the bright and wide open space of the gorge itself is interspersed with ventures into cliff caves with narrow corridors and dark suppressing chambers. Creating Creaking Gorge was mostly a level design job, as the elements and mechanics of it were already present in the game, apart from the wooden scaffolding which is purely visual.

The Cauldron

Following Creaking Gorge comes The Cauldron, a smaller area taking place over flowing lava and involving fire traps and puzzles.

The first thing I did for The Cauldron was start working on the lava surface. I looked at existing solutions like this Lava Flowing Shader, but its unidirectional flow is more suited to a lava river than the kind of lava pools I have.

I ended up offsetting texture look-ups in two directions according to some sinus and co-sinus functions. Additionally there's a texture that maps distance to walls, so the flow can be slowed there and the lava also be darker. Here's that texture, and its effect on the lava. The bubbles are made with a particle system emitting sphere meshes, but they looked bad when I just gave them fixed or random colors. I ended up making the regular lava texture based fully on world space look-ups, not UVs, so the bubbles could be mapped identically. After adding steam particles, a better lava pattern, and baked lightmaps, the result looked like this: After getting the lava into shape (which frankly is purely visual too but adds a lot to the feeling of the area), I got cracking working out the puzzles. For the fire-based puzzles here, I had to generalize a bit how fire propagation worked so that anything that can catch fire can be lit up by any fire source. The result is some simple puzzles where the player has to use fire in new ways than previously.

Two distinct new areas done in one month! I'll have a hard time beating that in the future I think, but here's to hoping.
Read More »

Level design workflows

Let me talk a bit about my workflows for doing level design in Eye of the Temple since I recently had some progress in that area.

I've been in something akin to a level design writer's block for a long time, being able to rework individual small areas, but unable to start the major world redesign that I've been intending for over a year.

Maybe calling it writer's block is pretentious - the fact is that I've never done this sort of work before, so I may just not have developed the necessary workflows to deal with it. Anyway, I think I might have finally cracked the nut.

I've had plenty of ideas, but fragmented and not crystallized enough to get down on paper. How do you start planning a non-linear world meant to be highly interconnected and interdependent? I can talk about what eventually worked for me.

I've long pondered what type of document could help me get ideas down on paper in a quick way. In addition to text documents (glorified to-do lists) I've been using tilemaps for sketching level designs. These tilemaps naturally lead to obsess over details though. What recently helped me move on was allowing myself to draw free-hand inaccurate lines and gloss over the contents of rooms. It's difficult because I have ideas for the rooms that are important and which informs their shapes. The fear of forgetting those details if I don't put them down right away is there, but have to be ignored to get on with the broader strokes.

In order to inform what to draw in those broader strokes, I consult my documents with intended progression of a given section of the game. What puzzles are encountered, what abilities are learned and used. This is an iterative process where both documents are altered. Finally, after watching Boss Keys episodes by Mark Brown (@britishgaming), I tried using his dungeon graph notation to document, then refine, how dependencies in the world works. I already had loosely these ideas in my head, but getting things into the right document form can help immensely. These 3 document types, progressions described in text, a world map sketch, and a dependency diagram, each make certain aspects of the creative process easier, and iteratively refining them all in a complimentary manner now helps me plan out the complex world. The tilemaps are convenient in that the rough sketches can be refined into more detailed plans over individual rooms where each tile is planned, but my lesson was to only do this later, as necessary. This is not to say that these will be the only document types I use for planning out the world. None of them capture the three-dimensionality of the world well, and white-boxing may well be the next thing I look into. That's it. A lesson learned in using various forms of documents that fit various aspects of the job in order to be able to get on with "getting things down on paper".

P.S. Be sure to check out Mark Brown's awesome dungeon graph template on his Patreon.
Read More »

New pots feature, mixed reality, Discord server, Yonderplay event

It's time for a new update on the development of Eye of the Temple.


GDC in March is well behind us and I had a great time there. Among other things, I got to show off Eye of the Temple at the European Game Showcase (and saw a lot of other cool games too). This was a private event for specially invited people from the network of the organizers.

Now, Eye of the Temple has been selected for Yonderplay, an event that's part of the Nordic Game Conference in Malmö in Sweden and open to everyone at the conference. This will go down on May 25, the last day of the conference. This is the most public showing of the game yet, and I'm very excited about it! If you'll be at Nordic Game Conference yourself, come by and say hi and give the game a try.

Mixed reality

At GDC I also met some of the fine people from LIV, a platform for mixed reality recording (and more) for VR content. I've been integrating support for LIV in Eye of the Temple (it's very easy) and a handful of people from their community has been helping me test the game both with focus on mixed reality and in general.

Apart from testing and feedback, I've also been allowed to create and use some gifs from their recordings. Being able to show Eye of the Temple in mixed reality is very exciting to me, since it shows the physical nature of stepping around in the game in a way that's been impossible with regular purely virtual footage. Here's a few examples: These gifs are featuring ThreeDee from ComedyPipe. I tweeted them here and here.

I would love to have mixed reality gifs with others playing the game as well. If you have Vive or Oculus Rift with a mixed reality setup and is up for it, please get in touch!

Discord server

For a long time I've been using itch's forum feature to talk with early testers of the game, but I'm now beginning to move more towards Discord. I've only just learned about Discord recently, but have been happy with it so far. Feel free to join! Here's an invite link to the Eye of the Temple Discord server


Last but not least, I just implemented a new feature in the game: Pots!

Pots contain gems. You can tap the pots gently to get the gems out a few at a time or just smash the pots with your whip or torch to get all the gems all at once. But that would be a shame for such antique and rare pottery, now wouldn't it?

The pots give players more opportunities to use the whip, which I think was much needed. They also add more physicality to the game, since the pots (and the shards if they're smashed) are physics-driven objects. Hopefully it also adds just a bit of player expressiveness potential and unpredictability to the game.

A player can intentionally smash a pot, or intend to just brush it softly with the whip to tease out gems in a non-destructive way. This can however still accidentally make it topple over and fall down and get smashed way below. Players could set goals for themselves to smash all pots or avoid smashing any. Whether this will happen in practice is yet to be seen but it at least feels nice to me to allow for different approaches like this.

I made this silly and crudely acted video showcasing the new pots. Do you enjoy pottery too? Let me know in the comments!

Read More »

New trailer, public Steam page and Eye of the Temple in the press!

Last week I took a dive into the world of PR with Eye of the Temple.

There is a new trailer you can see on the website or right here below.

And Eye of the Temple now has a Steam page: Eye of the Temple on Steam

If you have a Vive or Oculus Rift, and think Eye of the Temple looks interesting, you can totally add it to your wishlist on Steam now! ;)

After that I took my first stab at contacting the press with a press release. The story got picked up by UploadVR and a handful of smaller outlets (see list on the Sanctum Dreams website). Considering I'm an unknown small indie developer with no experience with the press, I'm pretty happy with the results.

This week I'm at Game Developers Conference in San Francisco. I'm mostly here with Unity, but I'll also be showing Eye of the Temple at the European Game Showcase.

Exciting times!
Read More »

January 2018 update

It seems like I didn't blog since July. How scandalous! Well, here's an update on what I worked on for Eye of the Temple since then.

Presented as a series of tweets, because that's what I have time for.

Note: Add blockers seem to sometimes randomly block some of the embedded tweets for some reason.

Prettier background environment

The cold snowy mountains didn't give the feeling I was aiming for. Failing to find anything ready-made that fit the bill, I created my own lush, mountainous environment.

Failed attempts at mixed reality capture with StereoLabs ZED stereo camera

I think a mixed reality video would be the ideal way to show off Eye of the Temple, so I invested a bit in this. Unfortunately it didn't go well due to a combination of a bad choice of immature tech, and an insufficient green-screen setup. I might revisit this in the future though.

Glowy light for certain platforms

New build for testers with whip and other improvements

I finally finished developing the whip and got a build out to the testers.

Trying to recruit people to test the speedrun mode (never had any luck!)

The speedrun mode is super fun and challenging to me, but nobody else seem interested in it. Besides asking on twitter I also contacted some of the notable VR speedrunners and people who has posted about VR speedrunning on Reddit, but got nothing out of it. If anyone reading this have a Vive and would like to try it, do let me know!

Implemented a new type of dangerous rooms for the temple

The reviews for this feature are through the roof.

Got serious working on the big level design overhaul

Still far from finished with this one.

Worked on a texture tool "Bricker" to easily create bricks and carved shapes

More on that in another post.

Contracted a few pieces of concept art to get inspiration for improving the visual look of the game

And finally, introduced this little birdy

That's it for now. Hope you enjoyed this glimpse into the development, and see you soon. Back to working on the game for me! Remember you can also follow the development as it happens following @EyeOfTheTemple or @runevision on twitter.
Read More »

July update: Trials and triumphs of whips and levers

Here's the latest updates on the development of my Vive VR game Eye of the Temple.

For the past several months I've been working on improving the whip I prototyped last year. In the last post, I showed how it could grab levers, but there were a lot of issues and the whip and lever didn't exactly look pretty. Now see what it looks like now:

This feels really good to use now. It didn't get to this point without a lot of issues on the way though.

The whip

A bit of background on how the whip is implemented in broad strokes. Using physics joints etc. quickly turned out infeasible when I did the prototype last fall. Instead, I’m keeping track of positions and velocities of “links” in arrays in my own scripts and doing very custom simulation with lots of tweaks and workarounds. One of the needed things to make it behave whip-like is that in the spring code that maintains distance between adjacent links, one link should affect the other slightly more than the other affects the first. This is to simulate the fact that the whip gets thinner towards the end, which is critical for whip-like behavior.

Collisions with level geometry works by doing sphere-casts, one per whip link per frame, which is around 30. The spherecasts are from the previous position of a segment to its new position, and if anything was hit, I move the new position to the intersection point, which should be in between the old and the original new position. That's the basics.

There's special logic that makes the stick of the levers "sticky" and "unsticky" at specific times, which aids the behavior, but the way the whip curls around the stick (or fails to curl, sometimes) is still driven by the regular simulation apart from that. For all other surfaces, there's no special logic. It uses the sphere-cast based collision avoidance I mentioned above.

I should say there's a glaring issue in my collision approach which isn't shown in the video, which is that collision fails against moving surfaces, such as the moving platforms. I'm not quite sure if I want to solve that, because it's going to add tons of complexity to the code, while probably also degrade performance significantly. I've chosen to ignore this for now, since there's no lack of other things that need to be done that are more critical.

The lever

The lever has caused me all kinds of problems. Doing a lever that works properly, particularly for VR, is apparently a complicated problem. I made a video about my woes here:

I found out that levers could be made to avoid sliding out of their joints given three criteria are met:

First, the collider of the lever handle must not overlap with any other colliders in the world. The tricky thing here is that it's not easy to see that overlapping colliders might affect the handle, since the handle is firmly locked in place. But they do affect it in very non-obvious ways. So I ensured the handle collider doesn't overlap with any other colliders.

Secondly, the rigidbody must have its position set to locked.

Thirdly, the center of mass of the rigidbody must be overwritten in script to be set to the pivot that the handle should rotate around. Unfortunately, this leads to another problem. Sometimes the lever handle would get completely stuck, in which case no amount of forces would make it move one bit. After some experimentation, this seemed to happen if the handle is exerted to forces while the connected rigidbody (which is kinematic) simultaneously move. (Some levers in my game sometimes get moved around.) I worked around this by disabling the rigidbody position locking at strategic times and then reenabling it again. This seemed to fix the issue.

Polishing it up

After I had gotten most of the technical issues resolved, I set out to create proper 3d models for the whip and lever to replace the simple cylinder placeholders I had before.

And as the last step, I added the ability for the whip to be rolled up (which it now is by default). The whip is still fully simulated while rolled up, which is what gives the rolled up whip its nice juicy appearance. There's no animation or pre-canned movements involved in the whip at all.

The transition where the whip gets rolled up is done by pulling at specific segments of the whip towards a specific point on the handle. This happens to also be how the whip remains rolled up in general.

In the video I do a little upwards flick and then the whip rolls up. This is purely "role playing" though. The rolling up is actually triggered just by pressing a button on the controller. ;)

If you've been following the development of Eye of the Temple, does the whip related gameplay change how you view the game? What do you think it adds to it?
Read More »

June update: Verticality, puzzles, whip

Here's the latest updates on the development of my Vive VR game Eye of the Temple.

For the past month I've been mainly working on improving the whip I prototyped last year. It can now be used to grab levers at a distance, and then you can yank the whip backwards to activate the lever.
There's still some way to go, especially with getting the audio cues right. The physics will never be quite like a real whip, but making it satisfying to use is the top priority.

Apart from this I've been looking into designing more puzzles for the game. I'm no expert puzzle designer, but bit by bit I come up with some that I think work well. The latest involve tall rotating towers, activated by levers (no whip use necessary for this one) where you need to step around on and in them at two different levels.

This also marks my increased effort in making better use of verticality in the level design. Experiencing the great heights is a draw of the game, and I'm figuring out how to use that optimally. I don't have a new build with these new things yet. The work right now is on smaller isolated pieces and puzzles, and once I have a set of those that fit nicely together, I'll begin integrating it all back into the overall world design.
Read More »