Games Practical Project Development Blog - Week #1
After discussing my project plans with my tutor, I got to work developing a basic prototype to present my idea that I will be developing, and help with the discussion of scope.
My first point of action was to develop a comprehensive interaction system, so the player character could interact with many different items and obstacles. To do this I set up a Component to house the interaction, so that it could be reused easily in the future.
The system was set to read for any actors in the "Range" collision box with the tag "Interact". When it found more than one in range, it would cycle through them to find the closest to the player to decide which one to interact with. After this, it would read a secondary, more specific tag and carry out an action based on this tag, afterwards resetting the interact-able item and distance.
This was then all I needed to run in the character blueprint itself, letting the component take care of the actual work, so long as the character has "Interact" as a component. This system worked quite well for finding the closest item to the player, and specifying what action to take, however as the actors in range were stored as "Actor" references and not their specific Blueprint, I could not enter the interacted item to run any events from there, which meant the more interact-able objects I had the longer and more bloated the interact component would become. This worked for my initial prototype for the next meeting with my tutor, however I knew it would have to be updated for future use.
With this interaction system in place, I made a quick "ladder down" blueprint that can be interacted with, to move down to a level that would generate itself on loading.
With that, I started work on the level generation itself, choosing to start with a grid based system to get the initial logic in place. To do this, I set up multiple prefab sections of the level and stored them as blueprints. After this I set up a function to run on Event begin play in the level blueprints to read target points in the level, and select one of the previously created layouts to fill the space, creating an 8 tile grid randomly every time, with the spawn point always being the middle tile.
After this, I needed to make sure that one of the eight tiles would always spawn with the ladder down to a deeper floor, so the player can always progress. To do this I setup a simple Boolean check, which would be set to true if the tile with the ladder is spawned. If this Bool is true, the ladder tile will not be spawned a second time, and if it does not become true by the time the level is loading it's final tile, it will force the final tile to be the ladder down. While this certainly works to ensure a continuous path forward, I'm worried this system will put emphasis on the ladder spawning in the final spot every time, especially when more choices are added for the generation to choose per tile. While not yet implemented, I plan on either randomising the order the tiles are spawned in, removing this final tile bias, or improving the odds of spawning the ladder tile exponentially with each spawn until it is chosen. Both options should ensure the ladder is in an unpredictable position every time, however some testing will be needed in order to decide which option will be better in the long run. The function for generating the level works well and doesn't take long to load, however the script isn't optimised and can be cut down dramatically for my needs for improved performance.
Comments