Mind Tree Games

Gold Master

Senior Production

Post XXI

This will be the final blog post for capstone. I will be writing a post mortem in the future for this project, but otherwise there will be no more updates. Since my last update, a ton has changed in our game. If you took a look at our game less than a month ago and took another look at it today, you would be blown away. With that being said, however, it makes it difficult to talk about what specifically I did. These past 2 weeks in particular have been so filled with production work that my memory is all melted into one big ball and I can’t really remember specifics. I do know that a lot of my time was spent making builds, testing, fixing bugs and implementing last minute “features” which were necessary for our game. This past weekend in particular saw 25+ hours of work put into it from myself as well as similar hours for many of my team mates.

One of the goals that we were supposed to hit for the senior show is “Gold Master”. Basically just meaning a stable and “complete” build of our game. And by complete, i just mean that it is fully playable from start to finish and has all the art, systems and design we wanted to have in the game. Obviously its impossible to get this because things never work out how you would like them to, but given what we accomplished, we definitely reached the spirit of what Gold Master is.

With our final build submitted and the senior show coming up this Friday, the team is now shifting gears towards preparing for the show itself. Luckily for us, most of it will involve showing off team and individual reels. Afterwards, we get to spend time talking with people about our game as they come to play it and learn more. It should be an interesting experience and I hope that it all goes well.

Our team’s reel can be viewed below. It honestly is more like a teaser than anything, but it should give you a decent grasp of different aspects of the game. It has puzzles, monsters, narrative and cutscenes.


This is all I have to talk about in this post. I will be making a post mortem post in the future (not sure when yet since i’m very busy). We also made a page on itch.io which you can check it out here if you want to download and play the game or find out more about it!


  • We hit Gold Master
  • There was lots of crunch
  • Senior show is Friday
  • Post mortem coming soon to a blog near you

Beta Crunch

Senior Production

Post XX

Recently I have been swamped with work between deadlines at work, deadlines in production and my already busy schedule. But in this madness, some good progress has come for the game. Last time I talked about the Breaker Box system for the game and some of the things I had done for it. But the biggest problem this had was that it was all visual and was not in any way functional as a system. After some complications with integrating it with the circuit system we have, the Breaker Box is finally in a completed state. This isn’t the only thing I’ve done though. I’ve also spent time making builds, bug fixing and polishing features.

The Breaker Box system was much larger than I had originally anticipated it to be. It also to some extent slowed down our progress a little bit which is unfortunate. But now that it is fully functional, it gives our designers the ability to fully implement our levels. So what does this functionality include? I think this GIF will be able to show it first and then i’ll explain what happened. (Please excuse the terrible GIF quality, i’m bad at making these)


What you’ll notice is a few things. First, when you interact with the breaker box, the door animates open and you can see a light turn on. Then you can also notice that the mouse cursor appears, indicating that the controls have switched to mouse controls unlike the normal controls seen in the game. When i mouse over switches, they highlight and clicking on them flips them on/off. You can also see that when I flip the top switch on the first time, it turns off all the switches. This is showing what happens when the circuit is overloaded by too many things being on. Then when I flip the switch again, you can see the gate in the background starting to lift. When i toggle it back, the gate drops because the power has died. Finally you can see the door closing and the light turning off as the controls go back to their previous state. During this whole process of interacting with a breaker box, you can’t move and your camera is stationary. It might not seem like a lot, but this is a fairly large system which was nearly more trouble that it was worth due to the circuit system and its “problems”.

Beyond the Breaker Box which is finally complete, I also spent time doing bug fixes and polishing features. Since we’ve been doing a lot of crunch lately to meet our upcoming deadline of April 25 (when the final build is due), I’ve been making a lot of builds for QA and class. Unfortunately, due to our workflow, we don’t have an easy way to do something like continuous integration or even setting up a build server to handle it for us. This means I’ve got to do it manually each time. And since it would be too easy for things to work on their own, the build always has problems which I need to fix before I can release it to the team. Most of the time, they tend to be bugs which crash the game, but sometimes its because a feature isn’t working as intended or because its just completely missing for some reason. This is probably my least favorite part about working on this project, but it is necessary and helps move our game forward.

I mentioned in the previous paragraph the deadline of April 25. This deadline is when our class requires us to have a final, stable and complete build of our game. What this means for us as a team is that we have roughly 3 weeks to make sure that everything is in, working and feels good. This isn’t really a lot of time, especially since we only just recently became feature complete (our narrative, art and audio isn’t even all in yet!). It is going to be a long crunch these next three weeks and all of us can feel it. The good news is though that once that day hits, we are free from the crunch and will have a few days to relax from the pressure before the senior show which is on the 29th.

This is all I will be talking about in this post. I will probably be making only 1 or 2 more updates before the 25th depending on what gets done by me and how busy I am. This will all be followed by a post mortem after everything is over, including the senior show.


  • Breaker Box is done
  • Fixed bugs and made builds
  • Lots of crunching…
  • Deadline is in 3 weeks


Pre Alpha

Senior Production

Post XIX

It has been a little while since I’ve made a post about my senior production team so I felt it was necessary to bring an update on my progress. These past few weeks have been interesting to say the least. Last week I was at GDC so I was unable to do any work and the week before was a lot of time spent on my other classes (in preparation for GDC). Not a lot has happened in the production space, but there are some features and upcoming deadlines worth mentioning.

Before I went to GDC I was working on the new Breaker Box system. While this system is still incomplete, it has progressed enough to warrant more information. I spent a lot of time thinking about how I was going to implement the system because a large majority of it needs to be completely dynamic. Since no two breaker boxes are guaranteed to be the same, the goal was to cut down on the amount of work a designer would need to do to both create new Breaker Boxes and to modify existing ones. While thinking about this, I remembered my solution for the radio conversations and it sparked an idea. I tried a few things but eventually settled on this solution.


My biggest disappointment with this is that there is no easy way to store an array of structs while still providing nice editor access in Unreal. Not without making modifications to the engine and that is unfortunately not an option due to workflow concerns (as well as the time commitment needed to create this). Nevertheless, it works well and I even went a step further to provide the designer with safeguards incase they made mistakes. For example, the breaker box always verifies the settings before creating everything and It gives out helpful errors to the log which say what is wrong. The process to create a breaker box is fairly simple and is just 3 steps.

  1. Create a breaker box in the level
  2. Create a Blueprint class inheriting from BreakerBoxSettings and customize the properties available to you (as seen above)
  3. In the properties for the breaker box you put in the level, tell it to use the settings class you just created with the combo box

The result of this can be seen below!


The next big step is to hook this up with the circuit breaker system. This is a work in progress and as of this writing isn’t complete. This would make the system fully functional in terms of the functionality the breaker box is supposed to have. However, there is also a huge part of the breaker box missing which is the way a player interacts with it. Unfortunately, this system hasn’t even been started and will take a bit longer due to needing a new interaction system. More info on this will be given in a future post.

I have also spent a little bit of time since coming back from GDC doing bug fixes for the game. Some of these have been outstanding bugs which have gone from sprint to sprint without being addressed due to being minor inconveniences and not game breaking. Others were newer and impacted gameplay systems. The most notable of these bugs was a bug with dropping items (in this case, we were dropping flares). Dropping a flare which had 50% of its energy gone would cause future flares that you used to start at 50% energy instead of 100%. This is obviously a major problem for gameplay and after half an hour of stepping through code using the logs for guidance, I was able to fix it. The reason it is notable is because the cause was due to a problem with the order of operations for dropping an item which would cause it to retain information on accident.

At the beginning of this post I mentioned upcoming deadlines. This could probably be figured out from the title of the post. Next week we are challenging the Alpha stage. This means that this coming week will be a huge crunch to make sure we are feature complete. This is only the start of the crunch though because for the next month or so (until the senior show at the end of April), we will be challenging a stage each week. This will be a tough month for all of us and hopefully none of us go crazy in the process.

This concludes my update for this week. I will hopefully have more to talk about next week with Alpha.


  • Went to GDC
  • Started implementing the new Breaker Box system
  • Fixed some lingering bugs
  • This next month will be crunch
  • Challenging Alpha next week!


Senior Production


This week’s post will be short and uneventful but i’ll give a quick status update. After a long, crazy week with the Montreal Game Festival, we have slowed down a bunch and priorities have shifted. This week hasn’t had a large amount of progress on the programmer side due to an upcoming due date for an assignment in another class which every programmer is currently worrying about and scrambling to finish. This isn’t to say nothing has been done though.

This week we got a lot of small features in such as a new Light Actor system which will allow the designers to place lights in the level (our special actor for this) and it will already come with useful features such as a mesh, the light, direct integration into the circuit system and so forth. It will make the process of creating the updated level 1 a bit easier in terms of setting up the lighting system. Item Dispensers have also seen a slight upgrade and they can now have set quantities available to be dispensed. They can also be destroyed upon running out which is a useful feature. This makes it more robust and can now be used as a general purpose dispenser in levels, without having to create a new blueprint explicitly for each item pickup. The monster has also had some slight upgrades visually and is now less smoky and more bug like (think bees).

Our group has also focused this week on meeting the Greenlight requirements. This is something specifically for the class which is required and is more or less a bunch of documents. It happened to work out nicely for the programmers as this meant we didn’t need to implement a lot this week, allowing us to focus our energy to the other 3 programming classes we have.

This is all I have to talk about this week. Hopefully this next week i’ll be able to show off a new system currently in the works which involves the breaker box.


  • Not a lot of programmer features added this week
  • We are doing the Greenlight stuff
  • New Breaker Box system coming soon

Montreal Game Festival

Senior Production


This last week has been an important step forward for my team and i’d like to take a moment to talk about it. This past weekend, two of my producers and one of our designers took our game up to the Montreal Game Festival where we showed off our game, along with a bunch of other indie games. This meant that we had a very important deadline to hit and the build got a lot of work before the Saturday when the event occurred. During this small crunch, we as a team realized a few things and really got to see how we all work under pressure and tight deadlines. This ended up working out well for us and was an eye opener. But what did this mean for the build?

The original intent when we signed up for this event back in January was to show an updated version of our first level. This was something that we’ve been slowly working on but the keyword here is slowly. We hit a bit of a bottleneck and this delayed the level and we ended up realizing last week on Wednesday that there was no way we could get this updated version of the first level done in time. This is when we made the decision to revamp our existing level to better show off some of the new things we plan to pursue in our game. It meant removing a lot of old content and putting in brand new content that hadn’t been implemented before. It meant new art assets and new functionality all in the span of roughly 72 hours. The team quickly went to work on this and we got a lot done.

I personally was working on a new system in our game which involves a radio the player finds at the beginning of the first level. This radio is important to the narrative and revolves around having radio conversations with someone on the other end who is guiding the player. This meant two things for me.

1. We needed to be able to create conversations from sound files.

2. We needed to be able to play the conversations.

What I created was a robust system which is relatively easy for the designer to create conversations and play them. With it, I also quickly created a small radio which is what you pick up that initiates this part of the gameplay. Below I have put the class which I created for creating Radio Conversations just to show how simple it is. Essentially, it is just creating data which the RadioComponent uses to play sound files in a particular order with specific delays.

What makes this particularly interesting is that the designer can create these in Unreal’s Editor and easily play them. Just by creating a blueprint class which inherits from RadioConversation and setting the default values for the VoiceLines and VoiceLineDelays arrays.

25 26

Beyond this, I also spent time fixing bugs and managing the other programmers to make sure we kept our priorities straight and could meet our deadline. Overall, I think we did a great job considering how little time we had and it showed how dedicated to the project every member of the team was.

This is all I have to talk about and show for this week, but in the near future I will be posting a tutorial on how to use Git (specifically showing off TortoiseGit). This is intended for people who have never used Git before but is also there to serve as a guide for those who don’t fully understand how to do everything. Keep an eye out for this sometime this week!


  • We had a small crunch
  • We took our game to the Montreal Game Festival!
  • I created a system for Radio Conversations


Senior Production

Post XVI

This week’s update encapsulates a culmination of work from this week and last week. I decided against posting something last week due to the low volume of work to discuss and show. Since my last post a bit of major changes to the game have been made and i’d like to spend a little bit of time talking about them. A good chunk of the updates weren’t done by me specifically as they were tasked to one of the other 3 programmers in our group.

The first major change is in regards to the monster and how it functions. Previously we were attempting to make the monster something that was very heavily controlled by scripted events and triggers to give the desired effect. This past week we’ve been pushing towards a complete overhaul of this system in favour of a monster which is closer to some of the original ideas proposed last semester. This of course means and AI controlled monster which actually has a physical presence in the level. This has some large implications and we don’t yet know if it will be what we want but I sure hope so. With this also came an update to the light system. The light system now uses the actual lights in the level to determine whether the player is in the dark or not and this has an effect on the behavior of the monster.

We also have been making some major pushes in the code base to refactor some of our blueprint to C++ and improving the usability of various systems to make level creation an easier process. This has been a group effort and has so far had good and bad parts. The good part being that now things have become a bit simpler and less complex due to the move to C++. The bad part is that in the process, there have been conflicts with merges as well as small bugs being introduced. Some of this could have been prevented, but what is done is done and we are addressing the problems which lead to this outcome.

My work this past two weeks has been mostly around the flashlights, refactoring and helping to manage the other programmers. This coming week in particular might have me being a bit busier with the push for the indie game festival this coming Saturday which my group will be presenting our game in. It is a bit scary since so much still needs to get done on the design and art side. I will also be creating a document which will help teach the team members who are struggling to use git in order to prevent some of the problems we encountered this past weekend with merge conflicts.

This is all I have to talk about in this post. Unfortunately this semester has less to talk about in my blog posts due to the separation of a small workload between 4 programmers but hopefully in the near future there will be more interesting topics to cover.


  • Major changes to the monster
  • Major changes to the light system
  • Huge push to refactor Blueprints into C++
  • Lots of merge conflicts this past weekend

Let there be Flashlights

Senior Production

Post XV

This week has been very productive on the programmer front and there’s a little bit to talk about in today’s update. My task over the weekend was to prototype some flashlight functionality. For QA this coming Thursday, we wanted to test a lot of features and one of those are changes to the flash light. Since we aren’t yet sure which system we want to continue with, we have 3 flash lights to test. I’ll go into a bit more detail shortly. We have also planned to test out or newly created Kiosk mode. This will be what you see when you enter the game, with the main menu being displayed in front and it will also be what you return to if you should idle for too long in game. We also have an update light detection system which uses actual lights to determine if you are in the dark or not. Since I didn’t work on the systems other than the flashlight, i’ll focus on them.

The first flashlight we plan to work with  is just the flash light we have been using. It is meant to be more of a baseline from which to better gauge the new ones. It currently can be recharged by holding R and that’s is honestly all it does. The rest is automatically taken care of for you. The second flashlight is an improved version of this flashlight. It implements some of the features that the designer intended from the start, but never made it into the build last semester due to time constraints. For starters, it uses an active reload system to recharge the flashlight which currently requires you to enter this reload mode by pressing R (pressing it while in the mode will leave it). While in the reload mode, you have to alternate clicking the left mouse button and the right mouse button to recharge your flashlight. It also has the ability to turn the flashlight on and off with F which is a long needed feature. The last flashlight tries to utilize batteries to achieve a similar goal as the original flashlight. Instead of holding R to recharge it, you press R to consume a battery, automatically recharging your flashlight to full. This means that batteries would need to be placed in the level.

I also spent a bit of time working on an object which will make testing new items easier. It is an item dispenser you can place in the level and it allows you to specify how many to give you and a few other properties. It even lets you tell it what text to display on the object so you can know when you see it. This item is interacted with using our interactable object system so it even highlights when you are looking at it. An example can be seen below.


While this week was pretty good for the programmers (due to our need for features), the following week could prove troublesome. There are plans to implement a monster AI which will keep one of the programmers busy, there is growing concern amongst us that there isn’t enough work to split between the 4 of us. Hopefully we will be proven wrong but it is looking to be problematic. Next week’s focus will likely be on the monster and polishing up some systems like the flashlight further.

This is all I have to talk about this week, but there will be more to talk about next week.


  • Other programmers made a lot of cool things
  • I made a lot of flashlight updates
  • I created an item dispenser!
  • We might not have enough work for 4 people


Senior Production

Post XIV

After a long an unproductive break, I am back to continue working on The Last Light. I spent all semester talking about it and the development process and I will continue to do so this semester as our game was not cut. This week in particular will be short because it was the first week of classes and nothing interesting happened development wise.

This week, my new humongous team met up for the first time since break and began to talk about this semester. Being the programming lead focused my efforts towards making sure that the 3 new programmers and myself had work to do over the weekend. It was a good opportunity to patch things up and prepare for the upcoming level as the design team and producers scrambled to figure things out. It’s been an interesting experience so far for me since i’ve never really managed people.

What I was able to do so far has been mostly bug fixes. Last semester, I did my best to keep the code clean and bug free, but you can never really iron all of them out. I started with the notorious gate bug where slipping past the gate you have to lift will break your inventory, making the game unplayable. This wasn’t too hard to fix, but it required a little bit of digging to find the problem. The solution ended up being to make sure the inventory was properly re-enabled when the player completed opening the gate. This, however, would be problematic when people snuck under the gate without opening it and would render the code useless. To solve this, I went ahead and put an invisible wall behind the gate which gets automatically removed when you fully open the gate. This makes sure that players can’t sneak under the gate, breaking the systems. Hopefully, this will be the end of the problem.

As for next week, i’m not quite sure whats on the table just yet. I missed the last team meeting due to being out of town and i’m still figuring things out. It does seem like we will be focusing our efforts towards menus and “kiosk” mode as the teachers like to call it.

That is all for this week, but i’ll be back next week with the next segment.


  • Met with the new team
  • Fixed game breaking bugs!


The Last Light – Post Mortem

Senior Production


As you could probably tell from the title, this is a post mortem of my project this semester. A lot has happened in the past few weeks and I’d like to spend a little bit of time to talk about my reflection on that time.

This semester, my team and I decided to create a game we call The Last Light. Being a narrative driven survival-horror game, we knew going in that it would not only be difficult to pull off, but it would also likely be large in scope. This doesn’t even take into account things like my experience in Unreal Engine 4 (I started with no experience whatsoever), or even the likely hood of our kind of game making it through to next semester (historically, narrative games and horror related games don’t do so well, we were both). The deck was stacked pretty high against us. But this didn’t stop us. We put our hearts into the game and the result, I think, is pretty good. The process, however, wasn’t without its problems.

So the biggest problem for me at least was not knowing the engine. This meant that I had to spend a considerable amount of time learning and getting comfortable with it. That ended up being a month due to how my work schedule panned out. I probably could have done it in a week if I was able to actually work on the project like a full time job. It felt like a very long month in my eyes and my work felt very difficult because I knew nothing. Luckily, everything eventually clicked and I was able to do work an order of magnitude faster; but for a few weeks, I was definitely concerned about my choice to do this.

The other problem for me was the genre of our game. I’m fine with narrative based games and survival games, but horror really isn’t my strong suite. I don’t really like to play horror games and I certainly don’t like to be scared. This initially seemed problematic for me, but I realized as I continued to work on the game that it wasn’t a problem at all. My work focused on systems, tools and a little bit of gameplay and I almost never dealt with anything scary. On top of that, it turns out that like a lot of things, you get de-sensitized to it after a while. My group all had this problem with the project. After a little bit, we were no longer able to tell if things were actually scary or if they just seemed cheap and bad. We relied heavily on feedback from people outside the group on whether or not it worked because we had no real way to gauge it.

As for the team, I think we worked pretty well together. There wasn’t any personality clashing and everyone was reliable. The work got done and with a good level of quality from everyone. Going in, I was definitely afraid of ending up with team mates like the ones I had previously in production 2 (lets just say, it was bad). I am very happy with each and every member on my team and It was a pleasure to work with them this semester.

But what does this mean for the future? Well, seeing as our game made it into next semester (apparently we are the second horror game to ever make it at Champlain), we have a lot of work to do. This means that our team will soon be expanding, potentially 2-3x larger than it currently is. Our goals for next semester are just as ambitious as they were this semester, but somehow I think we’ll be able to pull it off again.