Programming
Marker System
Technical Summary:
After our Beta Playtests, navigating the map was still an area of concern, people were still unsure about what they were doing, where they were going and what the ultimate goal of the method they'd chosen was. After previously scrapping the Marker system, it was super apparent that we should revisit and rework the system into the Gold Standard versions to help the player follow a more direct path and not get completely lost inside our level.
The original system that the markers followed wasn't a very optimal system, using event ticks and a large string of branches to check where the marker would need to move to. Not only did this very clearly affect the overall performance of our game, but it was simply a huge mess of strings that we could very easily clean up. I tried several iterations of this system, attempting to use an Actor Component so that I could attach the same system to different actors in the level to get a good level of accuracy in where the markers should be, but this would run into several issues where the markers would try to remove themselves and create several errors, which I couldn't really find a suitable solution for, and ultimately abandoned.
By this point, I was so invested into getting this small addition to function, that I would stop at nothing to see it completed. Having taken onboard what my previous attempts had taught me, I chose to return to the teleporting marker, especially since it could be a persistent asset outside the two levels I would be streaming. What also helped with this process was that although I had completely reworked the objectives by this point, I'd kept the objective phase variable through each stage, which meant I could use that to help with all the branches I would have to go through to get the marker in the right place. One of the error with the previous versions was that the Markers would constantly be created through an event tick, so when it was eventually destroyed, it would result in several errors. To overcome this error, at the start of the game, the Marker UI is created and set as a variable so that I can remove and add it to the viewport whenever I need to. So, inside the Marker Blueprint, the loop starts by removing the marker from the viewport and figuring out which objective phase they are at, before adding the marker to the viewport and setting the target actor to itself, so the marker will correctly move along the compass bar depending on the rotation of the player's camera. Since I knew I needed to move the marker depending on each objective, I was checking each objective as their own individual marker, but after realising that I could use the same location for a bunch of objectives, I began reusing the same Objective Phase Number to help with this process.
The markers were typically situated around one specific point that the objective made out to be a clear target, such as the Market, so I could move the marker to that location and copy the coordinates to make that process easier. I did question how I should tackle the marker for when it covered a large area of the map, like searching for a specific item, which with the whole factor of being random, couldn't have their locations pinpointed as accurately as others. My solution to this, at first, was to not include the marker since it wasn't going to serve much of a purpose, but I felt like that was going to confuse people into wondering where the markers had gone, and instead chose to have them appear at the town centre, since the items would be found in a large radius around that location.
Reflection:
I am so glad that we decided to revisit the Marker System, as painful as it was to implement. It is a great compliment to helping the player navigate the level, especially with the recently improved level map inside the Inventory UI. This is also a perfect example of focusing on the experience the player has throughout the game, which is a huge focus of this period, rather than pushing to include more and more features and methods that add more elements we need to develop for a better player experience. I think if there is definitely one area that this can improve on, is having a different style for when the marker is showing that an objective spans the whole map rather than confusing the player as to what the marker is trying to tell you.
Objective System
Technical Summary:
The objective system is something I was super proud of getting to function, since the origins of the system is rooted all the way back in my Role Application, back in December 2024. I was really happy with the original system, having thought about the different ways people could end up following the method they chose, but after playtesting in Beta, it was one of the most overlooked features of the whole game, and also didn't function correctly if the player didn't complete the objectives set during the day, or if they chose to start an objective when already inside the night map, underlining just how important playtesting really is.
So to work out every single possibility for each method, I laid out a simple map of objectives the player would need to complete, making sure I knew every possible outcome. The new system starts by checking whether the player is in the night period through a Boolean, which then leads to several branches that are built up to check the final objective first, before going down the list to the previous ones. This system worked a lot better and much easier to look at rather than the long line of code we previously had. We also made the default objective text to actually tell the player to select an escape method, to let them clearly know that objectives are something included inside the game.
With the recent changes to the Compass Markers, the new objectives helped compliment that system even more, helping us really benefit the player experience, a large focus of this period. Having the player to visibly read the objective they need to do works well, but we can't fill the onscreen objectives with loads of information to guide the player, but with the Markers, we can actually give a visual indication as to where they need to travel to helping the player get used to the map and key areas the player can explore through both day and night.
Reflection:
The Objective System is one of my favourite pieces of programming and my favourite way we've helped the player navigate the world. This is also the best way we've helped the player experience, allowing for the player to comfortably move around this large level and not feel confused or lost when exploring. I think some of the objective descriptions could be written better, and even adding a different tab in the escape methods to add a more detailed explanation to the current objective could also be a decent inclusion for the player to help them more.
First Person Perspective
Technical Summary:
During the last couple of days working on the game, I asked my team how they would feel about having a first-person perspective in the game, which we were all unsure about how that would look, but super interested in seeing how this would look and feel in the game. Having recently looked into switching from third to first person, this was a super simple addition, but provided more trouble with attaching the new camera to a skeletal bone. Since we had an idle animation that had the player move their head, this caused the camera to either show the inside of the player's head, or be moved around with the head, which was really jarring, so we had to attach it to the root of the player so that we could position it in the correct place. I also made it so that the player would rotate correctly rotate with the camera by setting the Yaw Rotation and stopped the player from using their animation blueprint when in first person. Another issue I discovered along the way was that the night map exposed the fact that the player wasn't using any animations, so I stopped the player from casting any shadows when in first person. To allow for us to switch between the two cameras, we could set the different characters to be active or inactive through a simple Boolean inside the cameras.
A small detail added later to the First-Person Perspective was the ability to see which items we were holding in our hands, which you could easily look down to see, but to better improve on this, I added a unique UI element that uses the image renders of the items the player can hold to let the player know they are definitely holding the item they picked up. I also thought it would be beneficial to add one for when the player goes invisible, so you could clearly see that you had pressed the CTRL Key and didn't have to just watch the invisibility bar go down.
Reflection:
The First-Person Perspective is one of my favourite final additions. It was something we never truly intended to include, but an addition that I think adds a new charm to the game, putting you in the shoes of the Martian, reducing the view you have of the overall level, and my favourite element, adding a level of fear to the game. Being at the same height as the Redcoats and being unable to always know what's around the corner, so running into a Redcoat or being chased by one, is a truly adrenaline inducing experience, which definitely helps to fit with the original intention of our game, adding this pressure onto the player to make them move and make decisions faster.