Wrap Up

Senior Production

Post XII


The topic of this week’s post is actually about things that went on last week before presentations. I avoided posting this last week simply because I was already overwhelmed by capstone as it was and I didn’t feel it necessary to post it immediately.

During the last week of crunch before presentations, a lot of important features were added to the game which improved the gameplay. The build also had a large amount of progress made on it because we had less than a week to finalize our game and presentation. One of these important features was an update and fix for the Light Dampening Volumes.

In a previous week, I talked a little bit about the Light Dampening Volumes and how cool they were (they still are). However, one thing I noticed while doing some updates to the flare was that they were fundamentally flawed in their execution. This had only recently manifested itself as a problem because of some of the things that we needed to do. In this particular case, I was transitioning the flashlight and flare to use a timeline for their light intensity so chris can make them look pretty and do cool flickering stuff when they are close to dieing. What it boiled down to was this. The volumes would detect and store when holdable light sources such as the flare would enter. They would also smoothly interpolate to a dampened light intensity by directly modifying the intensity of the light source and just keeping track of these values in the volume. At the time, this was fine because the light intensities never changed nor needed to change. However, with the use of a timeline to modify the intensity of the light over its lifetime, this became problematic. The solution? A good ol’ refactoring.

I decided this was a good opportunity to re-organize this code as well as bring it to C++ instead of blueprints which is what it was originally. I essentially took a bunch of the functionality from the volume and put it in the Holdable Light Source class instead. It made more sense for a light to manage its own intensity and how much it should be dampened. The volumes would still keep track of what lights entered them and how much to dampen the lights. The main difference is that the lights themselves would interpolate their intensity based off a dampening value which could be added/subtracted to them. What does this mean? It means that now you can do something like flicker a flash light by messing with its intensity in a timeline and have that intensity be further dampened by the light volume. You can also completely reset a light’s intensity back to its original, un-altered values which are stored when a light is created.

The UI was also updated during this week. Previously, our game only had the popups which indicated which buttons to press to do things. While these were useful, we decided to keep them turned off by default and are still there for those who need it. This, however, didn’t tell us anything about our items like the flashlight. One of the things that was annoying is that you had no way of knowing how much battery your flashlight had left. This is where our new UI comes in. We still wanted to maintain a very minimal UI and the result is shown below. The main problem we had was there wasn’t enough time to iterate on the UI very much and get feedback so it is fairly un-polished, but it portrays the information fairly well.

The Flashlight

21

The Flare

22

Another major change to the UI was the inclusion of tooltips. Another problem our game had was that it wasn’t necessarily clear how the player was supposed to do things in the game. Even simple tasks such as picking up a flare or opening a gate were suddenly difficult. This was partially due to hiding the popups by default and also due to design choices. We needed something that could tell the player the information they needed in a way that wasn’t too intrusive and was minimal. Our solution is the tooltip system seen below. I took inspiration on its look from how Amnesia did a similar system. When you look at or do something for the first time that has some sort of tooltip, it will fade in the text, hold it for a few seconds and fade it out. A tooltip only ever happens once, so you can’t get the same one twice. You also can queue them up and it will display them in the order that they were triggered. The system could likely use some tweaks such as the speed of the fading and other small things but it was an overall great addition to the game. It gave us the chance to tell the players important information without being too invasive to the play space and without seeming out of place.

23

In other news, a few important bug fixes happened during this hell week. Simple things like flares no longer breaking the inventory when being blown out by a wind volume, scripted event triggers going off just by a player looking at them (while standing close but not in them), and even fixing a bug with flares breaking light volumes. Man it sure seems like flares are the problem child.

Since I wrote this after the presentations and after the results were released, there is a tiny bit more to mention. On Monday, 11/23, my team presented The Last Light to a large group of faculty, students and family members. We demoed our game the following night to the faculty. We were thrilled to find out Tuesday night that our game had indeed been chosen to move on into the next semester. It is a large step for us because we were a narrative driven survival-horror game and if history told us anything, it told us that our game had a bad chance at making it through just by the genre choice alone. However, it would seem our game went through because we presented it well, our prototype was solid, we knew what we wanted and we know what needed to be done next semester. That being said, I am sad to see some of the games get cut because there were a few that I thought were cool and didn’t make it.

This concludes the post for this week which was actually last week. I will be posting a post mortem in the near future about this project. Keep an eye out for that if you are interested in those kind of things.

TL;DR:

  • Fixed Light Dampening Volumes by refactoring them into Holdable Light Sources
  • We added some UI for items
  • We added tooltips to the game
  • Fixed some pretty nasty bugs
  • Presented and demoed our game
  • We made it into next semester!

Leave a Reply