Games Practical Project Development Blog - Week #5

This week involved a lot of adding mechanics and art, alongside changing engine versions and ensuring everything converted properly.

This week, after some careful consideration, I decided I wanted to be working in the latest public build of UE4, which is a slight problem as the majority of my work time is spent in the university labs, and they don't have 4.21 installed. In order to get around this, I downloaded the engine version at home, added the necessary files to my hard drive, and run the engine from this when I am in labs. This means I have to convert the engine build of the project when working on it, as it was started in 4.19. One of the biggest reasons for this change in engine is asset packs. Knowing that my progress report was coming up soon, and I would need a brochure image for Expotees would also be needed, I took the advice of my tutor and swapped in my project plan audio gathering with art gathering, and got to working finding some asset packs I could make use of, and implementing said asset packs into my project, getting a simple art-pass started. Unfortunately most art packs I was interested where only compatible to 4.20 and 4.21. Thankfully so far switching engines has been quite painless

The two asset packs I downloaded are:

"Medieval Dungeon" - https://www.unrealengine.com/marketplace/en-US/item/9adb34ff933e419b8ba18d767c63eb13

"Hand Painted Textures Starter Kit" - https://www.unrealengine.com/marketplace/en-US/item/261e35f135f24b4c9999c2c211933330

The majority of the assets/materials received from two separate asset packs

I also found and downloaded a particle asset pack for use during combat and for further down the line for game feel and polish, which is:

Luo's Particle Toolkit Vol.1" - https://www.unrealengine.com/marketplace/en-US/item/94715dbed7a54ca288c0bfd7f43a0c9a

The particles from the asset pack

With these assets I set about getting an initial art pass set up in the main hub to get out of the whitebox stage, and applied some materials to the procedural generating level sections to keep things visually consistent.

The main overview of the players room/shop

A shot showing the main room of the player, in front of the entrance to the dungeons

The back of the shop area, currently inhabited by a test enemy

A top down example of a randomly generated floor, with materials and meshes spawning in

Now that I had set up some basic art, I was itching to get into the technical side again, especially after last weeks lack of in engine work. I was ready to start implementing some of the work I had researched last week. I decided to start with setting up dynamic lighting, again.

As mentioned in previous blog posts, I have set up some basic dynamic lighting, however it was quite basic in its implementation, and left me with some concerns for more interesting shapes and lighting. While researching fully dynamic lighting in Unreal, I found an incredibly useful talk given by Epic's Zak Parrish. In this video he goes into depth about how Epic lights Fornite in real time, the techniques and tools they use, and tips to keep it running at a good frame rate. Hopefully the effects are apparent in the beauty shots above. The video can be found here: https://www.youtube.com/watch?v=vef_ZPLhjt8&fbclid=IwAR1r3GEnobZ1jduAClG0qpzpxB5-qbTnlLbUPVEbjsmBHuouECIhPbKBnVA

To make sure the minute to minute gameplay worked, I got to work setting up enemy spawning, some very basic AI to chase down the player, and gave the player HP to lose when the enemy successfully lands a blow. With this, I then did the same for the enemies, allowing them to die, and setting up a quick death particle by editing and combining some particles received from an asset pack.

Basic examples of the enemies moving, attacking the player and dying

The function called when the enemy damages the player

After this, I set about getting the players basic health/death set up, so the enemies actually pose a threat. After quickly setting up the health variables and damage taking function I tied it to a simple UI widget to show the player, and made a quick death screen for when the players health hits zero. Because of the style of game mine is, instead of just killing the player and respawning them, I wanted the death of the player to force them back to the base, meaning they lose downward progress, and in the future drop the loot/gold they have on them at the time of death.

The player taking a final hit, the "death" widget and forcing the player back to their base

Checking the players health has been reduced to 0, and creating the widget to take the player back to the hub

While testing this and making sure everything worked, I realised that I didn't keep the players health stored between floors, allowing the player to just go down the ladder and get a completely free heal, which is something I obviously needed to stop. While fixing this I also set up a quick variable to store the players floor they are on, and a widget that appears when first appearing on the floor to let the player know how far down they are. I however did want the player to heal when they return to their base, however I wanted there to be some progress from returning, so that the player would only return when they felt they had done enough, and had to decide for themselves the risk vs reward of forging on and potentially going to far and being punished for it. In order to do this I made it so that returning to base also progresses the date by a day, putting the player closer to the weekly and monthly costs that are yet to be implemented, but will be the driving force for the player to make money and continue playing.

With this in place, I realised I needed to get the loot system prototyped so that the player did in fact have a reason to fight enemies. In this very simplistic version of my planned loot and gold system, when the player defeats an enemy, they drop a random amount of loot, based on how a min and maximum amount of loot that increases the deeper the player goes into the dungeon. To achieve this I set the random amount of loot right before the enemy is destroyed, and they send that number to the player, who adds it to their total.

Checking if the enemy is dead, and passing on the randomised amount of loot when they are

The player obtaining the loot from a defeated enemy and adding it to the memory

When the player returns to the hub, they are able to approach the table beside the stairs and sell their loot for a fluctuating price. While this system is fine for obtaining loot, it's very simplistic, and like with the level generation, is just an initial draft while I research and develop a much more intricate system.

The player selling loot, if they have any

Finally, I decided the player needed some haptic feedback during combat, to make sure they know when they have been hit, so I set up a quick controller vibration system, deciding between three different vibrations of increasing strength depending on how much damage the player just took, with less than a third of their max health, it does the weakest vibration, if its above a third, but below half the players max health it does a medium vibration, and if it's over half the players max health the strongest vibration. The blueprints are shared below.