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!

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 🙁

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.

• 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!