gamedev Iiro

Custom damage event One thing I wanted to do for a while was to create a custom event for applying damage to actors. This allows passing more detailed information about the damage than Unreal's default Apply Damage event. The custom event passes a structure of variables. One key variable is the type of incoming damage, which is based on an enumeration that contains all the damage types. Damage info structure is created and sent to the actor receiving the damage. The actor receiving the damage parses through the structure and for example, uses the information to determine what type of defensive stat should be used to reduce the damage. The defensive stat is selected and whether the attack can be avoided is based on the received damage info. The damage info is passed via an interface for combat actors, so any actor not participating in combat can't receive damage. Player respawn Previously, when the player character died it would simply get restarted at a designated location, but...

In January I've mostly worked on the game menu which combines inventory, character sheet and game settings within a single panel. In case I come up with a new tab I want to add, all I have to do is add a new widget to the menu and it'll fill the space below the top row with its contents.  The player's inventory is shown in the first tab, which simply lists all of the items the player has and shows the items info on to right side. Right clicking an item open options to use, discard and assign it to the quick slots at the bottom left of the screen. I also recreated the whole inventory system, which now works better with a list styled menu. Inventory within the menu. The character sheet is also pretty simple. It gets the player's stats and changes the appropriate numbers to reflect their values. The experience bar that shows the progress towards next level is also displayed on the bottom left of the screen when the menu is closed so the player can keep track of their progr...

As the work on Garden 2 slowed down towards the holidays at the end of the year, I figured it would be a good time to tackle some issues I had discovered in  Garden: Urada Chapter . When I released the game, I was surprised at how bug-free the game turned out to be. Aside from some actors in-game not showing up on the screen at all times (which I think is a rendering issue in the engine), I wasn't aware of any other issues. Though later playthroughs did reveal some bugs, most of them were just an annoyance to the player and did not have a huge impact on the play. The most serious issue was related to the secret boss in Part 2. As the player enters the boss' room, an event plays out and then the player can walk to the boss and interact with it to initiate the battle. However if the player chose to exit the room, the event itself would reset since it was not checking if there were any changes to the variable tracking the event's progress. So as the event would no longer repea...

After the first playtest, I decided begin improving the enemy AI in the game. The enemies had a very simple behavior tree and most of their behavor was written in their blueprints. It felt a bit messy so I wanted to move as much as possible into the behavior trees. It took a bit of learning how to properly use the behavior trees and there's still ways to go, but I'm already quite happy how the AI for the regular enemies has turned out. Before the improvements the enemies simply ran to the player and executed attack and if they lost sight of the player the enemy returns back to their original location. The improvements include seperate behavior trees for melee and ranged enemies. In additional to sight, the AI can also react to sounds and damage. After hearing a sound, the enemy moves to investigate the location of the sound. The AI also makes use of different movement speed values for different tasks. After noticing the player, the melee enemy moves to a close range, begins to ...

After a few months of development, it was time for the first playtest. The person testing the game is a good friend of mine who also playtested Garden: Urada Chapter throughout its development. The main part of the test is the boss battle of the level. I have some mixed feelings about the design of the boss, but I didn't make any major changes before the test, since I'll probably end up keeping it pretty similar to what it is and make another boss battle in the level that would represent more traditional action RPG boss. There are also the basic enemies of the level and the prototype of the level itself to play through. The level's intended progression route is complete for testing and populated with the basic enemies with the intention to add a few more unique enemies later on. It also includes the game's save points, and rest stations, at key locations providing resupply of items and checkpoints. Another area I wanted to discuss with my tester was the game's stat ...

The basic enemy Idle sprite of the enemy, crackling. Introducing the first enemy of the game, the crackling. It is a four-legged insect the player encounters while traversing the desert canyons of the planet Unu'qu. The crackling is classified as a fodder-type enemy, meaning it is weak and not particularly threatening, but several of them could overwhelm the player.  The crackling follows a simple enemy AI that begins to chase the player after seeing them or receiving damage, and after a few seconds returns back to their original location if they lose track of the player. Once the crackling is close enough to the player, it begins executing its attack, which is a short-range dash to hit the player with its claws. While preparing, the attack locks onto the player's location, and then the crackling dashes towards that position. If the player moves too far during the preparation, the dash is still executed but falls short. The video clip below shows the crackling in action. During...

Relation of different enemy blueprints . The creation of enemies in Garden 2 begins from a base enemy blueprint that acts as a parent for all enemies in the game, including bosses. The base blueprint includes all components and code that every enemy uses. From the base blueprint, a child blueprint is created for each individual enemy, which includes only what is unique to that specific enemy. The individual enemy blueprint requires setting an animation blueprint, but otherwise is ready for use. Since boss enemies have most of the same functions that normal enemies do, a base boss blueprint is created from the base enemy blueprint that has additional functions that only bosses use. One of the important actor components of the base blueprint is EnemyStats component, which hosts the enemy's stats (health, attack, etc.) and any functions related to them. At the moment of writing, the functions can alter any given stat between its lowest and maximum value, and find and return the value ...