Mayan Shadows
Mayan shadows is a third person action adventure game where you play as Anika, a infamous bounty hunter in an ancient mayan magical world who is chasing a ruthless skeleton Lieutenant for taking everything from her. In order to finally take revenge from him, help Anika traverse through this world, fighting the Lieutenant's army and solving mysteries of the relics of this world.
Content Breakdown
Mayan Shadows is a project developed during my time studying at VFS under the name of Quest For Valor it’s given as an assignment with a 3-month timespan and focuses on implementing encounters, moments and missions with pre-made assets, following a similar methodology used in the industry and, despite it not being necessary to include more features, I decided to prototype and implement new ones to both learn Unreal as much as possible and provide mechanics that made the experience more enjoyable and unique.
Platforming
This is the first part of the project where the idea was to create a course for players to enjoy some platforming. The course was sketched on paper and iterated over time with some feedback on progress in engine polishing the moment as much as possible.
From the get-go the player mechanics given to us did not focus specifically on movement, it had a limited range of possibilities for us to use, so when designing this section, it came down to portraying an interesting path to follow that allowed players to use the environment cleverly, being engaging despite being limited to basic movement.
The requirements of this project capped the amount of world space available, so every section had to take the most of what was available, so with that in mind, I limited the platforming section to a specific chunk of the space available and followed these steps:
Sketch a path confined to the bounds set.
Measure jumps along the path, guiding the player into the right path.
Eventually, I had a course that was, on paper unskippable given the measures that I’ve taken from the project, and then through feedback and iteration, I slightly modified it for it to be both accurate, meaning the player would follow the same path constantly, and open to a wide range of skills.
As mentioned before, the use of the environment marked the solution to the platforming challenge, using the statues or ledges around led to the goal and so it was key that a good amount of world-building was done to hide the path enough for it not to be obvious, so I included some objects that blended with the actual path components, which through playtesting, demonstrated to be sufficient.
Specifically for this part of the game, no new features were developed, since it was ideal to maximize what was already there for this kind of moment, given the scope and timeframe of the development process.
PuZZLe
The second moment of this project was meant to be a puzzle, options were infinite, the project already provided some assets that allowed for so many clever problems to be resolved, and so a decision had to be made on which was the one that players will experience.
I went back to a little looney toons series of games released for the very first Play Station that I hold very close to my heart and that, fortunately, belonged to the puzzle platformer genre. Among the many memorable challenges these games provided, I loved the ones that involved pattern recognition, they allowed me to explore and experiment until every piece of the puzzle fall into place in a surprisingly rewarding manner. That was the kind of satisfaction I wanted to harness for this puzzle and, for this to be achieved, some assets had to be made alongside the existing ones. This was by far the moment of the project that taught the most about Unreal, thanks to the following custom components:
GEM MONUMENT
This is a fully custom system built with the 3D and VFX assets provided, it was designed to be the foundation of the puzzle communicating what it’s the objective of the challenge and giving feedback that signified progress made by the player.
The functionality came down to two components:
The monument: The blueprint that housed the gems collected and indicated when the puzzle was complete, providing stages of feedback through VFX every time a gem was placed.
Gem Collectibles: This was a blueprint that marked the objectives for the player, it was interactable and it communicated with the monument to let it know progress has been done. Feedback and aesthetic choices were modular in this system, being exposed to designers in order for them to decide the best-fitting models and VFX to be used.
FENCES
This is a single blueprint built from scratch using only the 3D assets given to the project. Despite it being simple, it was extremely useful along the game itself, not only being a key component of the puzzle but extending into other moments of the experience helping to guide and contain the player when needed. As mentioned before it was really simple but modular as well with features like the speed of movement, initial state (being closed or open) or the fact that it could be triggered by any other mechanic in the world when needed.
In the puzzle, they served as the challenge itself by both obstructing the pushable blocks and, thanks to the pressure plate component which activated a group of fences simultaneously, representing the pattern that players had figured out, moving the pushable blocks in the order sketched on paper and tested to make sure that no edge cases took away the reward of solving the puzzle.
CUSTOM PLATFORMS
Once again, this is focused on simple but modular systems that actively ease the development process on the go. The platforms were two blueprints I built both focused on making a zone accessible when activated and providing verticality into whatever scenario they were included, including features and tools on their state (being activated or not), and one of them on initial height and max altitude to reach and as much as the fences, the possibility of being hooked up to any trigger when necessary.
Thanks to their usability these were used all over the project, but in terms of the puzzle, they acted as part of the challenge, where players needed to activate both a pair of platforms using the pressure plates to get a gem and eventually complete the puzzle.
ADDITIONAL ASSETS
These are assets originally built into the project that, combined with the custom components that I created, the puzzle was brought from an idea written on paper to a fully fleshed-out prototype that harnessed the idea of pattern recognition proposed from the beginning. The assets used to complement the new systems were:
Pushable blocks: With an implementation based on physics detection that limited movement depending on its surroundings and that allowed the possibility of being dragged along any surface.
Tracks: A modular system that constructed a grid in whatever order it was desired, where the limits of each piece are represented by borders that had a physical presence in the world.
Pressure Plates: Components that served as triggers with the possibility of being pushed by any object in the world, even the player, which in this case was disabled for the proper functionality to be as intended by design.
Levers: Another form of trigger that only the player could activate whenever it was considered necessary.
Boss Fight
Lastly, the task focused on designing an epic showdown with a final boss battle. This moment was about prototyping new AI behaviour, that made the boss unique from any other enemy behaviour, we had free will to create whatever we wanted using Visual Scripting to achieve the goal. Here is a breakdown of my approach to the boss battle:
My objective for this battle from the beginning was to harness the sensation of portraying a character that possesses epic abilities and convinces the player that they want to get rid of them bringing all they have to the table, and given the included combat mechanics on the project, I went to the God Of War series to gather some reference, more specifically the epic boss battles that the release of 2018 came with. Analyzing their combat, I realized that enemies challenged the player’s reflexes since, dodging attacks of any kind precisely, exposed opportunities for players to attack and deal as much damage as they could.
I wanted to provide a similar challenge to players, where having good reflexes and avoiding attacks, translated to rewards of dealing good damage, and for this project, that came down to two components:
SPECIAL ATTACKS
Enemy AI is already capable of attacking, defending and in some cases throwing projectiles and running away when necessary, it was a foundation that allowed for different combat encounters to be created and resembled in a more simplified manner to combat on my reference. So to convey a good unique battle, two special attacks were prototyped, making sure they focused on the principle of challenging and rewarding good reflexes, here is the way they worked:
Stomp: This was a launch and charge from the air, that targeted the player’s position in a specific moment and provided a timeframe for players to get away, if they were fast enough, the area of damage wouldn’t affect them and a chance to attack would be presented as a reward.
Settings like the timeframe or the area of damage were modular, it was possible to modify them to tweak the difficulty of the attack as desired.
Fire blasts: These were brief moments on which the player had to avoid fire blasts that the boss would throw their way, once again, if they were fast enough constantly, no damage would be taken and a chance to attack was provided at the end for players to enjoy.
This attack was composed of two components, the AI handling which moved the boss around the area, and the fire blasts where their blueprint component instructed to attach the player.
This is one example of the usage of fences as well, providing a little challenge in the scenario players ran too much to the side while avoiding attacks
REWARD SYSTEM
The tools given to us were able to provide information on the progress of the fight, and when it came to enemy health, I was able to know when it received damage and how far along it was before it died, thanks to this information and to prove satisfaction to the player for being fast and develop good reflexes, I prototyped a system that allowed players to hit the boss more frequently, since based just on the tools provided, I would only be triggering the attacks every single time the boss got damaged, and given the feeling I wanted to harness this would become tedious very quickly. Here is a breakdown of the solution:
The enemy would not use special attacks if its health was high, starting the battle smoothly.
When health was low enough, special attacks were enabled, but they would only be triggered if the player attacked the enemy a certain amount of times, determined by a small random system that worked between modular ranges.
This system was the one that harnessed the satisfaction of the battle and made progression very enjoyable, according to multiple playtesters I had during development. Of all moments within this game, this battle was my absolute favourite to develop, because it allowed me to prototype and experiment with a system that came slightly close to one of my favourite game series, dissecting a part of its essence and adapting it to a project were it made sense to have it.
