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.

chainNew.gif

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.

trainGhost2.gif

-wednesday-david

Advertisements

Move that gear

\\ [LOOK AROUND]

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

 

// [COLOR DOOR]

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.

stickShift.gif

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.

rgbSliders.gif

 

\\ [MESH COMBINER]

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:

combineTool.gif

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).

combineTool2.gif

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.

combinetest3.png

 

// [MOVE THAT GEAR]

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).

gears.gif

-wednesday-david

Chain

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.

fade.png

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.

image.png

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

driveChainWeight.gif

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.

-wednesday-david

Weight

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.

telescope.gif

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.

log.gif

\\

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]

drive_Chain.gif

-wednesday-david