Beginning of the end

It’s the beginning of the end; we have a lot of work to do.

Starting off the week, we knew that the gear interaction was too complicated. So, I implemented Levi’s design for a more concise, simpler version of the interaction. This version consists only of rotating a large gear opposite from the Door Gear, then opening the door to the tunnel on the Door Gear.

After getting some inspiration from the concept of a socket wrench, I decided to adjust the gear rotation mechanism, and it ended up feeling a lot better.


Next, I shifted my focus on the transition to nighttime. I began working on the Sunset Interaction, which is initiated at the end of the Tunnel and transitions the game to the night state. First, I investigated having the player scrub through an image sequence of real-life footage of a sunset.

But, we realized it would be difficult to get good footage for this interaction. So, we decided to make a mini diorama of the Mountaintop, and have the sunset interaction take place there.


As we began making the final push for beta, I improved the Loggman exit sequence, by adding a NavMeshAgent to the Loggman so that he can properly walk away from the player. It needs some tweaks, but it’s getting there.


After that, I worked finishing up the Tunnel Interaction. I created a script that both fades the player out and fades in a full-screen video as the player gets closer to the end of the tunnel. Once they reach the end, it transitions into the sunset interaction.

Lastly, I added a placeholder billboarded screenshot of the model for Falter, the final NPC in the game, as well as a placeholder dialogue sequence and cutscene.

We are behind, we have a lot of work to do, but we can do it. It will be a rough journey, but I have faith our team, and I think we can do it.




Trolley problem

As we continue on, I’ve been finishing up the desert interactions.

Firstly, I had to make some adjustments to the drive chain interaction. We decided that it didn’t make much sense for the player to sit down whilst in the interaction, so I got rid of that. The reason I had the player sit (and disabled the player’s movement) during the interaction was to prevent them from walking around in midair if they exited the interaction between floors (since they wouldn’t be connected to the NavMesh between floors). Since we got rid of the sit, we decided it would be cleaner to also remove the option to exit the interaction until it was finished. So, now the player cannot exit the interaction until they reach the second floor or return to the first.

I also made it so that the player hoists actually hoists the drive chain weight above the second floor before the cutscene plays, so that they can visualize the transition more. Now, it’s less jarring.


Next, I worked on the one desert interaction that hadn’t been made yet – the railroad switch. This interaction is based on the classic “trolley problem” thought experiment.

In the desert, the player finds a train buried in the sand. Nearby is a small section of railroad tracks, and a railroad switch where the track splits into two. Next to the switch is a lever. If the player pulls the lever, the switch mechanism activates, and a short cutscene plays involving the Desert Ghost.



Move that gear


The first thing I did this week was work on improving the drive chain interaction. Previously, the player didn’t really “move” along with the weight, and exiting the interaction before reaching the second floor resulted in a jarring transition. To fix this, I made it so that if you exit in the middle of the interaction, you can see the protagonist sitting on the weight. In this state, you can either look around or re-enter the interaction, but you cannot move. Movement is enabled once you either reach the second floor or return to the first floor.driveChain.gif



After that, I focused on the door to the first floor of the clocktower. Levi had mentioned that we should use an RGB slider for this door (you have to adjust the sliders to match a certain color, which then opens the door). As I was about to work on it, I had the sudden inspiration to try and combine the concept of RGB sliders with a stick shift mechanism.


However, after getting some good feedback from Campbell, I realized that a stick shift just added an unnecessary layer of complexity to the concept of RGB sliders, a concept that many people might not be familiar with in the first place.

So, I ended up switching to a more basic RGB slider setup, which I think works quite nicely.




As the weekend began, I turned my attention to a little tool we were in need of – a script to combine separate meshes into one mesh. This is useful for when you have large amounts of environmental objects like trees and ferns. Combining them into one mesh decreases the amount of draw calls and the amount of dynamic batching that Unity has to do, which results in improved performance.

Here’s the tool in action:


I then added the ability to combine all meshes whose MeshRenderers use a certain material. This is especially useful when combining objects that use multiple meshes (for example, our trees have separate meshes for the trunk and the leaves).


In the above gif, you have to manually choose the target material. To prevent having to do this, I then added the ability to loop through all of the child objects of a GameObject and combine meshes based on what materials their MeshRenderers use. So essentially, now you only have to run the script once, instead of having to keep selecting a different material like in the above gif.

Here are the results of testing the combined meshes versus the old individual meshes.




Lastly, Levi finished up the design for the Magic Window interaction, so I made the first pass of that interaction (it involves moving a gear into “window space”, rotating the window, and then moving it back out of window space).




Unfortunately, this week was a bit light in terms of programming progress. The programmers were mostly focused on finishing up midterm prototypes for our Console Programming class, so that took up most of our time.

Fortunately, it looks I will be able to devote my whole spring break week to working on Ponds.

Now as to what I actually did this week;

The first thing I did was clean up some of the code for fading in/out the player when entering an interaction. Before this was handled with direct calls to the PlayerFade script attached to the PlayerDisplay GameObject. To decouple the fading code, I now just have the PlayerFade script listen for our InteractionEntered and InteractionExited events, and handle them accordingly. This way we won’t need to have a bunch of unnecessary references to the PlayerFade script floating around.


The second thing I did this week was make the first pass of an interaction for the clock tower. Previously, the drive chain weight “elevator” functioned similar to Eric’s mountain elevator. But, a suggestion was brought up to have an interaction where you actually lift yourself up whilst in the interaction. I thought up a way to apply this to the drive chain weight interaction: as you (the player) enter the interaction, you see a section of grabbable chain. If you pull on it, you can hoist yourself up to another section of grabbable chain. And so on and so forth until you reach the top of the clock tower. Not only does this make the journey up the clock tower more interactive, it aligns with the newly revised interaction guidelines given to us by Levi.


Here’s my first pass of the interaction in-game:


My implementation ended up being a sort of linked-list system – each grabbable node holds a reference to the “previous” and “next” nodes in the chain. If the “next” node is null, then the player has reached the end of the chain. When this happens, I then initiate a quick cutscene showing the player arriving at the top floor of the clock tower.



We made a lot of progress this week, especially on the core path.

The first thing I did was make a rough prototype of a telescope interaction with the Bird Cyclist. This bird will appear somewhere along the mountain path as you ascend the mountain, pedaling furiously, and you have a chat. Later on, you can look through a telescope and see them cycling in the distance.


I transitioned back to the Desert for a bit to make its core path roughly complete. To do this, I added a placeholder door interaction and transition to the Tunnel.tunnel.gifIf the player walks to the end of the Tunnel, they will be teleported to the lightmill on top of the Mountain.


Levi mentioned we needed a pause menu;

so, I made a pause menupause3.gifAfter that, I worked on a mountain interaction/sequence: the Loggman interaction. This character is a grumpy log that tripped and fell over while walking on the mountain path, and you must upright them to unblock the mountain path so you can continue.



Since the Desert building is now a clock tower, Alexis had the idea to have the player travel up to the main clock room by riding on one of the clock weights (aka the things that power grandfather clocks via gravity). I implemented a basic version of this in a similar manner to how Eric made the elevator for the Mountain.

[Chain Driven Clocks]



What time is it

Rotation: what is  it?

The window’s rotation mechanism made it too easy for players to get their hands crossed up. So, I altered the form of the mechanism. Now it is a circular disc with only one handle.


But, I was running into a bug where, when rotating the window, sometimes the window camera itself would become jittery. I arrived at the conclusion that this was because of the sharp variance in values caused by allowing the user to manually rotate the window – since even though it snaps to a right angle once they let go, they have full control while grabbing the handle.


So, I decided to restrict the player’s direct control to only rotating the disc, then smoothly Slerp the window’s rotation to match the disc’s rotation once the player releases the handle.


Next, I decided to prototype some visual effects for the tunnel interaction. We knew we wanted to use live-action video, so I first took a look at playing video files in Unity. I heard that Unity recently released a newly revamped VideoPlayer system in the 5.6 beta, but for now I’m just using the old MovieTexture system (since we’re using 5.5).

If you try to import a video file into Unity (with 5.5 and below, at least – not sure about 5.6), it will try to convert it into an OggVorbis video file (.ogv) using Apple Quicktime. Not a big deal if you’re on a Mac and have QuickTime, but the Windows version of Quicktime has been unsupported for 2 years now (most recent version was released in 2014). I’m working on Windows currently, and even if I wasn’t, I’d prefer to not use Quicktime if I don’t have to.

Fortunately, if you convert the video file to an .ogv yourself, you don’t have to deal with any Quicktime shenanigans. So, I found some stock footage of a bird, converted it to an .ogv, and brought it into Unity. The movie texture was very easy to set up.

I wanted to apply some effects to the video. Drew suggested that I use a convolution filter and showed me an example of such a filter in glsl. A convolution filter works by taking a pixel in an image, finding the surrounding pixels, and then averaging the colors of the pixels into one color in accordance with specified weights. By adjusting the weights you can get common image editor effects like edge-detect and emboss, and beyond.

Convolution filters can also work with fragments in a fragment shader.

After converting the example to Unity Cg with the help of Drew and John, I was able to apply some cool effects to the video.


I found this playlist of simulated mechanisms created in Autodesk Inventor. Feeling inspired, I worked on a little mechanism as part of the window interaction that ended up becoming a clock interaction. (in the below gif you can also see a convolution filter effect applied to the window pane)


Before, the building in the desert was a train station. We decided that we should change it, to make the optional trainwreck interaction in the desert more out-of-place. Now it will be a clock tower.

I also made a little robot with Unity primitives and animated a dance for it.




This week I primarily focused on getting the magic window ready for testing.

First thing I had to change was that rotation mechanism. The placeholder was just a flat disc on a pedestal with a handle. I ended up changing it to a two-handed valve.

Then, I set up a test interaction.


As can be seen above, I set up and tested the logistics of a basic “pressure plate” interaction, where the player would have to pick up a ball (in the window realm) and pull it out of the window to drop it on a pressure plate.

However, through further talks with Levi, I was reminded of one of the primary design pillars of the interactions – that they have discrete states. So, we decided to have the window snap to right angles, rather than what is seen in the above gif (where you can freely rotate the window).

The next step was to package up the window so it would be ready for QA. The plan was to create a desert “playground” scene with some of Alexis’ desert art, and then to set up the magic window and a few toy interactions within the scene.

the desert ruins, and the window within

It took a bit of work to get everything working again, but now we’ve got a nice lil desert scene with the magic window, ready for testing. Currently, the only thing you can interact with in the window realm are     a few spheres    that can be picked up, and will fall to the ground (and bounce) when dropped.


Another thing I did this week: I made a ghost shader. This will be used for ghosts in the desert. These ghosts will be visible from far away, but will disappear if the player approaches them.

This is accomplished by first calculating the world position of each fragment in the fragment shader, then finding the distance between each fragment and the player, then setting the alpha based on this distance.