Programming
Level Streaming
Technical Summary:
Level Streaming was a late addition to the game, but a change that I think really benefits the overall game. Level streaming allows for us to have one main level that we can the open sub-levels as we see fit inside of the main level. This worked quite well for when we wanted to create two maps with some differences, allowing for us to copy and paste and assign them to a new level. Level streaming also works really well with a loading screen, allowing for us to have an actual functioning screen.
Typical level opening in Unreal Engine doesn't allow for a loading screen since the level you were previously in will get cut off depending on where the UI is made visible, but the transition between the levels causes the UI to freeze, which if it's removed after the level loads can't be utilised to the best of its abilities. However, because level streaming takes place during gameplay, the Loading screen can be utilised and has some movement to it.
Another benefit of level streaming is that it allows for us to keep variables the same consistently, without having to store them in a specific place. Before this, our game used a Game Instance which can save variables and the values given to them through levels, however, to take advantage of that, we have to cast to the game instance every time which can be quite annoying, whereas with level streaming all the variables could be assigned to a component or actor and be persistently used with no impact on performance from casting.
Reflection:
Level Streaming is an incredibly useful tool that can very easily help to cut some need for casting to a game instance, and can have some very positive effect on how the game runs. However, if there was a way to improve this, I would completely change how the streamed levels are set up. Having the landscape and the buildings as there own level, or even a persistent collection of assets since both levels use them. I would then further add two more levels, with the relevant assets for day and night which I could load in and out. This would allow for an even faster load speed instead of opening another level to load the same things in again.
Spaceport Wall
Technical Summary:
By the end of Alpha, we had programmed the Spaceport wall to just destroy itself, which got the message and idea across, but to really enhance the scene, we wanted to make the wall crumble into pieces. This was something I did look into myself, to try and figure out how this was possible through blueprints. I didn't find the answer, but had Josh from my team work this problem out. Later down the line, although the wall had been working, the effect stopped, and was replaced the wall falling without any physics, which still gave the illusion of the wall falling apart, but wasn't the effect we really wanted.
Later down the line, I revisited the blueprint and started it again from scratch. Although I had not originally programmed the blueprint, I used it to help me understand what I needed to do and how to get it functioning. I first started by getting the wall piece I had created and using the fracture tab in Unreal broke the element into a Geometry Collection to use inside of the Blueprint. I also included a sphere with a completely transparent material and no collision that effects the player. When the Player then walks over to the wall, and interacts with it, the blueprint makes the sphere move from its original location and through the wall using a timeline, resulting in the wall shattering as the sphere passes through. The effect worked well, but the thousands of pieces created got in the way, so after some time, we'd destroy the actor completely, but it seemed so jarring to see it suddenly disappear.
So finally, I looked into creating materials that could have parameters modified by blueprints and timelines. After looking into different ways to accomplish this, I created a Material Parameter Collection which I can create scalar and vector parameters that can be modified through a blueprint. For the fade material, I created a Scalar parameter since I was using a value rather than the colour value of a Vector Parameter, and named it accordingly. I had to created a separate material without the cel shader to execute the effect, put setting the Material to be Masked, I could input a Dither Temporal to the Mask, and add the Fade Parameter to the Alpha Threshold. Finally, to add the effect, I added another timeline to the actor, and used a Lerp to change the value from 1 - 0 to create the fade effect, which then destroyed the actor selling the illusion of the wall fading into nothing.
Reflection:
This Blueprint is one of my favourite elements of the entire game, it has a real unique flare in comparison to other elements of the game. The feature does have one significant error with it, being that running into the wall can cause it to break itself, which is a huge work around for the player, requiring them to do nothing. Since I'm unfamiliar with the techniques used in this, I'm not certain of the solution, but will look into how I can fix this.
Battering Ram Gate
Technical Summary:
The Battering Ram Gate was one of the later additions to the game. It was documented inside the method description that the lockpick was an essential part of the Break Out Method, but if you followed the method along, the need for it wasn't there. So finally, I created the gate that opens to let the player grab the item instead of having to jump the fence. When developing this, I wanted the gates to open out towards the player, using a similar technique we'd made for other doors. The only roadblock for this was no door frames and it was two doors. In several previous projects, I've utilised the Arrow for getting a specific location, but for this, I used it as a parent for the gates. I used a similar timeline layout for the gates to the Spaceport Wall, but making sure I got the angles correct so the gates open in the correct directions.
Reflection:
I think this gate really enhances the scene and adds a nice change in comparison to other places you can open. I think if anything, this should be the template followed for all other opening doors, such as the ticket office and the spaceport.
Compass Markers
Technical Summary:
One of the key feedbacks we received from Alpha was the different ways we could show the player where to go, one of those ways was through a compass bar and markers to help the player move around the method they wanted. The compass bar was a good addition to the game, working as a great way for the player to get there baring in the level, but adding compass markers, especially combined with following methods, would help the player navigate even further. When we first implemented them, the markers were solely used to mark the location of the method, but we did also test having persistent markers around the level for the home and cantina.
The compass bar went through several periods of development, getting them to work correctly and be in the right places and be removed when they needed to be. This however, presented a whole heap of errors and issues that I couldn't figure out. When developing the Hidden Path Method, I tried to have the markers appear when you were so close to them, but once the actor was destroyed or the player left the area, the game would generate errors. So after much head scratching and bug fixing, we ultimately decided to take them out of the game. As useful as they were, the errors that came with them couldn't be overcome, so we turned our attentions away to other means of guiding the player.
Although the markers were left alone to be revisited another day, I did learn a chunk of new information about them. I experimented with using an actor component that could be triggered through the actors it was attached to, which opened my eyes to how components can provide similar services to actors who would be effected by similar things, for example could be used for a Stamina and Health system that could be utilised for the player, enemies, and NPCs! It also helped me understand having materials that could move with the direction of the player camera, using the same Material Parameter Collection as the Spaceport Wall.
Reflection:
Although we are testing other ways to help the player navigate around the map, it would be a great addition to actually have the markers and have them work with every available method. With the code still being there, I could very easily revisit it in the Gold Standard period to refine and implement it accordingly!
Objective System
Technical Summary:
As mentioned, we looked into having more than one way to help the player move around the level and understand where they are going and what they can see. One of these new additions was the inclusion of the Mini-Map, showing a small area around the player, and having enough detail to make out items. As well as being a live capture of the level allowing for the locations of enemies and moving components, which can really help through both day and night.
To really aid this system, we also created objectives that detailed each method with enough information to help the player, but not to much that it makes it seem you are holding the players hand the whole time. This was a simple scale box with text that would be updated through an actor component as the player completed them. I utilised an actor component to hold all this information and assigned it to the player so they can trigger the objective system at the beginning of play. The objectives are broken down into each method that can be checked through a string. The objectives follow a long line of branches to make sure the player can advance to the next location, which I programmed to ensure that the method can still be followed regardless of what the player chooses. Partnering this with the marker system also really elevates it to the next level and helping the player navigate the world easily.
Reflection:
I think this is definitely a big help for the player, allowing them to follow the method they want easily. There are some issues with the system that have come to my attention, such as the objectives are only something the player becomes aware of when they open up the inventory, which they might not do, so having the default value as a guidance to get the player to see the inventory and set a method would really help the player experience. I also never tested whether the system transitioned properly if the player ends up in the night after running out of time, which doesn't function correctly, so I should consider reworking the system further to fix this small issue.