gamedev Iiro

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 ...

In Garden 2 any action the player takes is supposed to feel meaningful and have consequences. This means certain actions lock the player character into an animation until it has finished playing. For example, a sword swing has to be finished until any other action can be taken. Initially, this was done by using boolean variables "IsAbleToAct", "IsMovementLocked", "IsJumping" etc. However, the code started to get cluttered when the action required several of these booleans to be checked before the action could be performed. Actions also had to set certain booleans to true at the beginning and back to false at the end of the action. It works, but is messy and it's easy to miss a boolean which creates extra work for later on. In the picture below are the booleans that had to be checked to allow movement. Input event for moving, a few booleans have to meet conditions for the player to be able to move. To make it simpler, I created a list of player states a...

Attack animations The basic attack animation for two swings, three frames per swing. I noticed that the animation does not look very smooth so I looked at some free assets I've used in the past and noticed that they have much more frames per swing compared to the three I have. Adding a few more frames in each swing should make it look better, especially since I had this idea of an effect in the game that quickens or slows the speed of the player's attacks. Attack combos Attack combos use an enumeration list of different attacks to determine which attack to play next. The animation blueprint plays the first attack and if the attack input is pressed again during the animation, the enumeration is set to attack number two, which is played after the first attack finishes. If there is no attack input, the first animation transitions to walk and idle, and the combo is finished while the state of enumeration is reset. The attack event called by attack input. switch event changes the en...

Dodge animation and distance Sprite for dodging towards the east. After creating sprite animations for dodging, it was time to implement the action in the engine. The direction, speed, and distance of the dodge are handled by a timeline event that applies velocity to the player pawn to the direction they're facing based on the directionality variable (which's main use is to determine the direction the sprite should be facing). However, since the values of the variable can only be 0 or 1, dodging in an intercardinal direction would make the dodge distance longer (shown with yellow lines in the picture below). The fix was to use the forward vector of the directional arrow component I talked about in one of my earlier posts . When facing an intercardinal direction, the forward vector would give values of 0,77... for both the x and y axes which would then translate to the same distance as dodging in cardinal directions (shown in red in the picture below). Dodge distances while usin...