Mind Tree Games

Wrap Up

Posted November 30, 2015 by vincentloignon

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

The Flare

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.

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!

MIGS

Posted November 17, 2015 by vincentloignon

Senior Production

Post XI

The title says the bulk of what this post will cover. I will also briefly talk about some of the small updates I’ve made in my minimal time to work on the project since last week. Oh and let’s not forgot where my team is in terms of stages and the upcoming presentation day (less than a week away…).

This week has been a bit hectic on my end. My networking project which was turned in last Thursday ate up the first half of my week with two days in a row of near sleepless nights. Adding on top of that the fact that my Friday has work until dinner, it meant little time to work on things. I did, however, manage to get a few small quality of life improvements to the game. The first of which was toggling the popups. Our game has been using somewhat temporary UI popups to help the player understand what they have to do while playing the game. I’ve shown them in many posts previous to this and while they are incredibly helpful, they are also incredibly immersion breaking. I personally didn’t want to get rid of them and after some talking, we decided to keep them as a “tutorial” style feature, kind of like training wheels. The player will be able to turn them on/off at will and it is there if they need it.

The second part of these changes was the addition of a way to tell if something can be interacted with. Since our previous method involved the UI popups, we needed something more ingrained into the world. Our final decision was an outline when you could interact with objects, similar to what a lot of other games like Left 4 Dead and Evolve used to make it easy to spot. You can see this in action below.

The Flare Box

The Gate

Now that I’ve covered all I was able to do, lets talk about MIGS. I wasn’t originally planning on attending the conference, but about 2 1/2 weeks ago i received a surprising email. I had applied for a free pass to MIGS back in September through their website. They were going to give a free pass to a select few “job seekers” and I ended up being one of the selected few. This meant a huge shift in my plans and was quite a nightmare scheduling wise since I effectively had 2 weeks to plan my trip. I left Saturday, and arrived Tuesday in time to go to 2 out of 3 of my classes. Without access to a powerful enough computer or two monitors, my resources were limited. Not to mention the entire point of the trip was to spend all day at MIGS trying to get a job and to go to sessions. Sunday was incredibly exhausting with several hours of talking to recruiters and developers about job opportunities and later that night following up with every one as well as applying to what felt like a million job positions at those companies. Monday was less crazy since I had talked to most of the companies with positions I was interested in and I had a great opportunity to attend a session on profiling and optimizing UE4 projects. This was probably my favorite part of MIGS (not that I didn’t enjoy all the conversations I had Sunday!).

What does MIGS have to do with my senior team? Well I think that I learned a lot going to the conference, even excluding the talk about UE4. I was able to ask questions to some of the developers about some of the things they did to tackle similar problems in their games that I’ve had in the past. I also went to that UE4 talk which was 3 hours of pure information and I learned an enormous amount of very applicable information. It finally taught and showed me what I can do to improve the performance in our game and what common pitfalls to avoid while developing it. What helped make this even more useful was the fact that at this point, I feel very comfortable in UE4.

Last week we challenged the Proof of Concept Stage and passed into Vertical Slice. That was also the time we learned we would have to challenge Vertical Slice to be guaranteed a spot to present this coming Monday. This was contrary to what we had previously heard from other professors and students and has my team slightly concerned. That being said, we can still present with permission and it is our intention to ask for it. This was also a sudden change in plans for us and due to the difficulties of attempting to get all the required materials for a challenge by tomorrow (which was impossible), we’ve decided to continue focusing our efforts towards the presentation in the hopes we get to actually present our game. This is all I have for you this week, tune in next week for what will likely be an update on where our game is for the presentation.

TL;DR:

UI popups are now toggleable
Interactable objects now have a highlight (like Left 4 Dead)
I went to MIGS and couldn’t do much homework
I learned a lot about UE4 at MIGS
We are petitioning to present

The Storm

Posted November 11, 2015 by vincentloignon

Senior Production

Post X

This week’s update focuses on the storm of updates to our game since last week. The title fits the amount of content we’ve pushed into the game since it was last shown, especially on my blog. I have a few things to talk about first and then i’ll finish up with a little about our stage challenge.

Towards the beginning of my updates on friday, I was able to add more features to our existing systems. Holdable items were now able to have infinite quantity which is used on items like the flashlight which aren’t restricted by a quantity. Holdable light sources were able to have time added to their duration. I also added some visual feedback to things such as the gate and reloading the flashlight (which it didn’t previously have). Another major update that came out of this a system for doing voice lines in C++ while keeping some of the more specifics in Blueprints. This means that I can call a function in the C++ code which tells the player to say a sound and I can specify which sound using an enum. Then in the blueprint, i can override this function and define what sounds to play based on the enum i passed. The list goes on a bit more. The main point is that friday added a lot of updates to some systems in place that made future content easier to do.

The gate now shows “HOLD” with the E key to better instruct the player

Another shot of the gate. This also shows the fixed flare which you can now see even when not looking directly (this was a bug before).

HOLD R to “reload” the flashlight which recharges it by shaking

There were some major bug fixes which all also happened this weekend which fixed some of the larger problems which “plagued” our game. This included things like fixing our liftable gate to not break things with the inventory, improving the circuit box’s interaction, being able to see flares when not looking at them, general flare improvements with the lighting, and most importantly of all, I fixed the game breaking bug we had which would crash the game. If you are interested, the moral of that story was essentially this: If you don’t want your variables being deleted every 60 seconds or so by the Garbage Collector in what seems like seemingly random events, and if you also don’t want the largest pain in the ass debugging nightmare, then always put a UPROPERTY tag over every single variable in your C++ code. It is a hard learned lesson as this bug has been in our game for weeks now with what felt like no foreseeable fix.

This week also focused a bit on the darkness and the scripted events for it. While I did not implement most of the code in the scripted event themselves, I provided some useful actors and code which is to be used in conjunction with the event. In particular, i created an actor called a Light Dampening Volume. This actor is placed in a level, you customize the volume for it which defines where it affects light. When a Holdable Light Source enters the volume, it is dampened by a percentage which is defined by the volume (can be customized on an individual basis). This will be incredibly useful in the near future as we start implementing more scripted events and need this kind of behavior for the darkness. You can see it below in its original form (which was instantaneous) and its updated form (which linearly interpolates to the desired dampened value).

Instant Change

Gradual Change

While these images show a drastic change in the intensity of the light, this was purposely exaggerated to demonstrate that it works. The amount the volume would actually change could vary based on what the darkness is capable of doing (due to progression) and what is necessary for scripted events or even levels.

Lastly, I’d like to briefly talk about our challenge. This week, we are challenging the Proof of Concept stage. If we pass, this will put us into Vertical Slice and make us eligible to present in roughly two weeks to have a change of moving forward into next semester. This is a very big deal for us and we are hoping that our challenge goes well. This is all I have to show for now this week but before I go, I have an updated video showing off our current game. Enjoy and tune in next week for more updates.

TL;DR:

I added lots of cool features to the systems
I added visual feedback and quality of life improvements
I created a system for voice overs
We can now dampen light held by the player (including dropped flares)
We are challenging Proof of Concept!

The Calm Before the Storm

Posted November 4, 2015 by vincentloignon

Senior Production

Post IX

This week’s post will be relatively short as I have little to show for it. I have been incredibly busy this past week with a midterm project for Mobile Devices and my Networking assignment. Add the fact that I was away for most of the weekend, It has left little time for Capstone. Not to say I haven’t done anything! This week’s focus since I have been busy in my other school work has been on planning for the upcoming weeks. The intent being to focus my efforts in the next two weeks before our upcoming challenge and hopefully our presentation.

We have recently been working on the design of the vertical slice level and what the shadow will be. Since we decided to make the shadow scripted (for the time being), Chris created some documents which outline the different scripted events, what they do and so forth which will be used to craft them. We have also laid out the features we want to try and have by the presentation which is coming ever closer. My primary focus in the coming weeks is patching up the inventory system to be feature complete. This includes fixing the game breaking bug which involves items/inventory and making it so items are limited. I will also be implementing reloading for the flashlight, functionality for voice over lines and most importantly some scripted events for the shadow.

I’m going to purposely leave this post short since there isn’t much else to write about. This week has been pretty bad for me in terms of workload and stress and there’s sadly been no time to do work on Capstone. This coming week will be a different story since we plan to challenge the proof of concept stage next week. This week is what i’m calling the calm before the storm, despite the fact that it is already a hurricane in terms of work. Tune in next week for more info on the stage challenge.

TL;DR:

I planned my next two week’s priorities
I did nothing else this week for capstone 🙁
We are challenging next week

Systems v2

Posted October 27, 2015 by vincentloignon

Senior Production

Post VIII

This week continues a similar trend to the previous week. Most of my efforts have been focused towards continuing to build and improve the systems in our game. Being a huge fan of cool systems and hierarchy based systems, i’ve been going nuts over the structure of everything. Sadly, a lot of the work is in the backend and is hard to show, however, there is a bit of gameplay features that are new to the game as a result of these systems being developed which I will show in this week’s post.

For starters, lets revisit the topic of interactable objects and the inventory. I have overhauled these systems a bit this week and some of the improvements include being able to remove items from the inventory, being able to drop items, more functionality such as handling events like being equipped/unequipped, being dropped and more. The player is also capable of reloading items which is a feature used by the flares (and soon to be flashlights) to turn on the flare (essentially striking the flare with the friction cap to ignite it). Another feature (although still needing improvement) is dropping items. While still in its early stages, it is important to the gameplay. I could keep rambling on about the systems, but seeing as there isn’t much to show for it (visually speaking), i’ll skip to the more visually interesting things.

One of the features which was added last week was the ability to interact with objects properly using E. You would see this popup on your screen when you looked at an item which was allowed to be interacted with. An example of this was the box of flares which would give you a flare to use. This week, I was also able to add a feature called reloading. In our game, there will definitely come a time when you need to “reload” your flare or flashlight because they ran out. And since flares don’t just magically start lit up, this was how we would start a flare. In terms of the flashlight, this would bring you to a small “minigame” per say where you would need to perform an action to recharge your battery. I also managed to get an important feature working in our game which is the ability for light sources to be expendable. Previously, they were infinite only because I hadn’t gotten around to it yet. This was further pushed on the flashlight specifically giving it a flickering which shows up when the batter is low and an increased flickering right before dieing. A neat little feature which will hopefully inform the player of the time left with their light without needing UI. Below are a few gifs of these actions. I apologize in advance for their terrible quality but i’m not exactly very good at doing gifs.

Flare Dropping

Flare Reloading

Flicking Flashlight

As for the challenge we did last week, the good news is we passed and are now chugging towards reaching the Vertical Slice Stage. The obvious bad news is that we have a lot of work ahead of us if we want to make it to that stage. We are all excited to have the opportunity to push forward into next semester and are definitely hoping that we will be one of the games chosen to move on after the “cuts” in a few weeks.

Tune in next week for more updates on my progress with the prototype. This coming week will likely involve further pushing our existing systems to create mechanics as well as fixing some nasty item bug which is causing the game to crash. Oh the joys of programming.

TL;DR:

I made more systems and improved existing systems
Light sources are expendable
Items can be reloaded
We passed our challenge
We have a game breaking bug 🙁

Systems, Systems Everywhere

Posted October 21, 2015 by vincentloignon

Senior Production

Post VII

Seeing as the topic this week is systems, I figured i’d start out the post with a meme. Woody’s face is quite reflective of just how much there is to make systems wise. Jokes aside, there really is a lot going on in the backend of our game and I’d like to take a little bit of time to talk about some of the cool things i’ve done with it this week.

For starters, our interactable object system which I talked about last week is more or less done and in working action! The system will create a small interface button which indicates what button to press to interact with the object. This can be toggled on and off at the designer’s leisure and the code that defines what to do when an object is interacted with is left open ended to be whatever we want. You just override a function in blueprint and do what is needed. For example, a flare might delete its instance in the world and add a flare to the player’s inventory.

Speaking of inventories, there is now a working inventory system. While it is still in a primitive state and only allowing basic functionality such as add and switch, it is built to allow flexibility across the board. Much of the functionality is open to blueprints despite being C++ based and it is very easy to work with. This will be an important system for the game. It is, however, lacking a few features that will make it even nicer. For example, it currently doesn’t store important information about the objects stored in it, such as how much time is remaining on a light object. This will be improved on further in the near future. A system for defining behavior in regards to an item such as when it is allowed to switch off and what to store when switching is also something i’d like to get in. This would allow each item to behave independently of each other while still making it so the system handles everything. An example of this would be the flare not allowing you to switch to another item while it is lit, but you can drop it or throw it still while a flashlight might not let you drop it, but you can switch whenever.

Another system i’m looking to get into the game is dropping and throwing items. While the prototype does currently feature these, they are very hacky and are in no way written to be good. They were thrown together for testing and will be re-worked to work with existing systems. Currently, these are on the backburner. While they are important to the game, the inventory has a higher priority and it is likely the inventory will provide a lot of functionality useful to these tasks.

While I would like to keep talking about the systems and all the fun stuff I did in C++, there is another important topic at hand which I didn’t mention earlier. This being our stage challenge this week. We’ve worked hard during this stage to figure out our game, do research into topics that will help our game and push our prototype further. We believe we are ready to move on to the next stage and hopefully this will be the result of our challenge tomorrow. It is also important to mention our game now has a working title! It is currently being called The Last Light and the narrative has made some changes since its original incarnation. While I won’t go into those details in this post, I might revisit this topic in a later post.

I have prepared a small video showing the current prototype. It features a new level which better fits the direction our game is currently moving in than the original level we created. I did mention it in my previous post and so you should read that if you want more details about the level.

TL;DR:

I’ve been doing a lot of systems
Interactable objects work
Inventory works (on basic level)
We are challenging the next stage
We have a new level!

Refactor and Replace

Posted October 13, 2015 by vincentloignon

Senior Production

Post VI

This week for me was focused primarily on refactoring the code base and preparing to be scaleable. This has been a task i’ve avoided mostly because the existing code was pretty gross to begin with but having too much work was a pretty good excuse not to do it either. This week’s post will also be fairly short as nothing has particularly changed code wise besides a lot of stuff being redone in C++ instead of blueprints. However, I do have a few things to talk about in regards to the prototype. Lets start real quick with the code.

So the original project was purely done in blueprints and I had not even touched it at all. I was busy working on BBR (rest in peace…) and my designer and artist worked on this prototype. They did a fantastic job of putting the prototype together, but the code base and the organization were not scaleable and would be problematic moving forward. This is where I come in to help. I don’t think I quite understood what I was getting myself into at first but the further I dug through the blueprint code, the more I realized how badly it needed to be redone. It felt a lot like the kind of code I would write in a game jam when there just wasn’t enough time to do anything fancy or good. So what have i done? I’ll break it down into a few things.

I started by refactoring the project files itself. If you saw them, you would understand how bad it really was. We had no organization and for some reason there was a folder in the root content folder that acted as its own content folder. Not to mention the world outliner being a total mess. After several tries of refactoring the project files (and failing spectacularly because of the dependencies on each of those files), I finally succeed in making it reasonable.

Next step was to rewrite the item system. Our item “system” was kind of thrown together and was a bunch BS which pretended it was a system. It didn’t make a lot of sense and there was tons of duplicated code and parts. I created a system that would allow us to do a lot of cool things down the road with both items and interactable objects. I started with an InteractableObject class which is an AActor and defines functionality for subclasses to implement as needed. It also provides a volume for them to specify which represents the box in which the player’s vision needs to overlap in order to show their interactable functionality whatever that may be.

This class is what I based the HoldableItem class off of which defined more functionality specific to the items. I then recreated our existing items in the system and they functioned more less the same but in a more scaleable system.

I also worked a bit on the character class we were using. Since the prototype was originally based off the first person shooter template, it had some blueprint code and assets from that. It also meant that our character class was based off the template’s character class which was all in blueprint. I then had the pleasure of rewriting all of that in C++ so it could be less messy and so that I could work on it down the road with less problems. This is still a work in the progress, but all the base functionality from the first person template is working (besides the shooting because that was removed).

Now that the more technical stuff is out of the way, I can also briefly talk about the direction our prototype is heading. The group and I talked a bit about it and decided to scrap the level we had already created. This is partially because it was incredibly messy and more a less a proof of concept but also because it didn’t fit what the designer had in mind for the beginning of the game. Our new level puts you at the exit of a subway next to the entrance of the mall. This is all underground if that wasn’t clear previously. The level in the prototype is still in progress so it’ll be best to show the image our designer has created for it. The main point of this level is to introduce the player to flares and a basic puzzle like opening a powered gate.

Now before I end this post, I have one last anoucement to make regarding the team. For a while, we have called ourselves Mind Tree Games. And while I had not previously posted this, it has been so for several weeks now. But what kind of team would we be if we didn’t have a logo? Our artist nick gave us a beautiful new logo to go with our team name which is below. It really is a remarkable piece of art and I hope we can one day make it a poster because it would look pretty awesome.

TL;DR:

I have the ‘joy’ of refactoring our code
We made a new level
We have a logo!