The first order of business for alpha was establishing some of the core (and highly reuseable) assets so that I have a base to work upon when developing the more RPG-specific mechanics. This included, to begin with, the puzzle UI and interactable console to trigger the puzzle, alongside scene transitions for loading and deloading levels. I also did a few revisions of the UI and interaction system following their creation.
Before working on anything else, I spent some time 'cleaning up' some of the unnecessary features that the first person preset brings with it on Unreal Engine. This included removing the gun, arms, and related programming functionality. This helped to make the project content browser feel a little less cluttered and will also likely help with reducing performance issues as the game won't be running any redundant code. Once I did this, I first started by making a blueprint for the test console. This console has a block to roughly showcase how big the actual console will be, a text label that rotates when visible, and a sphere collision that detects when the player has entered or exited. When the player enters, the text label is unhidden, reading 'interact (e)'. The player can press the interact key to bring up a test puzzle (simply a button they can press). When they press the puzzle button, it brings them to the next scene (at the moment a simple fade to black), which will be the combat / battle with the train conductor.
To do all of this, I did the following:
Set up an interact event using the Input system that links the interact function to a keybindable action within the player's IMC (input mapping context).
Lock and unlock the mouse when opening and closing the puzzle.
Set up a flipflop for the player detection to save on some processing power by only having to cast to BP_FirstPersonCharacter once for both events, along with them sharing most of their code.
Set up the scene transitions to trigger upon both FirstPersonCharacter load and RPGCameraSystem load (latter will be discussed further in a different portfolio page).
Set up the text label to rotate whenever it is visible using an event tick that uses the same 'text visible' variable that the player detection flipflop checks and sets.
Open images in a new tab in order to view the full image
The first and foremost issue with this set of systems is that it has a few singleton references. For example, the fade in / out function within UI_Transition refers to the FirstPersonCharacter blueprint through a cast, which is an issue as the player pawn is swapped out for an RPG camera system when they load into the combat scene. For now, this has been remeded by not using the function and setting up the transition manually within the new pawn, but I will have to address this later down the line or face potential setbacks and a buildup of technical debt. I also plan to rethink the UI of the interaction system. Rather than a spinning text label, I may create a UI layer that hide and unhides an interact label on the player's screen (so that it is more flexible and could be used with further puzzles down the line). For what I did well, I quite like the transition code as a whole. Despite its current issues, it is very flexible and interchangable, allowing me to reuse the UI and code for multiple parts of the game and saving on some development time and labour. Additionally, I programmed the text label's spinning to only actually spin when visible, which helps to save on some processing power as the only way I've found to do this without accidentally creating an infinite while loop is to use the tick event, so if it were to spin all the time (whether visible or not), it would cost some performance.