gamedev Iiro

It's been a while since last updates, but that simply means there's more things to talk about. The last level sequence The last level sequence that plays after the boss is defeated is done, including more supporting characters, the Flower's sprite in perspective and new dialogue box art. The overall work on level sequences is not yet finished as they require hiding the gameplay UI and tweaking camera and character positions. The last level sequence. Menu art and updates UI art updates include inventory and character menus as well as progress bars for health, energy and such. The progress bar is a single widget that is re-useable for any purpose that displays a value and maximum value as well as smoothly changes the bar percentage when the value changes. Inventory tab of the menu. The character menu features equipment panel which allows the player to change blade and core mods and displays which stats each of them affect. The drop menu displaying all of the acquired mods of ...

There's not much to show this month, but generally, the sprite work is done, as are most of the level sequences. The sequence introducing the second boss is now in place, though the camera and some character positions require more tweaking, which is something I plan to do for all of the sequences later along with hiding the player HUD. A take from the second boss' sequence. When a cutscene is triggered they're added to the save file, so the game knows not to trigger them again. The sprite of the ship is now fully drawn with more detail. It is still missing perspective and some door animations. Full sprite of the ship.

October went by while working on sprite animations for the characters and implementing them in Unreal. The main character's extra sprite has her picking up the princess and jumping to safety during a level sequence. The rest of the characters got animations for walking in a set direction during sequences. Maia's extra sprite in action during a sequence. The final boss finally got its own sprite and two animations to complement it. The first of the animations is the boss ordering the ship to attack the player and the second one is a backstep that the boss uses to move away from the player. The boss moves by backstepping away from the player. The last piece missing from the final sequence is the main casts' ship. I took the sprite it had in Garden: Urada Chapter and put it in Unreal to get a starting point. The ship sprite from Garden: Urada Chapter in Unreal. To my surprise, the ship was already close to its intended size. I have some small changes in mind along with more de...

Hardpoint sprites in Unreal After importing the hardpoint sprites to Unreal and attaching them to the gunship I noticed that I had programmed the hardpoints to work as 3D objects. Meaning that for example rotation of the hardpoints wouldn't match with the sprite animation. I figured that in the case of rotation, each animated frame would have to be assigned it's own sector which would then be picked depending on the rotation. Wanting to move on instead of getting stuck experimenting, I decided to skip this for now and use a single sprite to represent the hardpoints and have that sprite rotate which looks fine except for the extremes of the rotation. Hardpoint rotated to face the right extreme. In an ideal situation I would probably have the ship and it's hardpoints made as simple 3D meshes with pixel-style textures. Effect sprites & light emissions Before I went to work on remaining character sprites, I did most of the sprites for the effects used in the boss battles. I...

August felt pretty slow in terms of progress probably because of only working on pixel assets. Anyways... The gunship sprite is now finished along with separate sprites for the hard points. The gunship sprite. The hardpoint sprites include a rotating turret and a rocket launcher that rises up opening the launch pods.  I also made sprites for the beams fired by the turret and explosions from the rockets fired from the launcher. Next up is importing the sprites into Unreal and putting them into use. There are also a couple of character sprites to do before I can start working on the remaining level sequences.

  June and July blog posts are combined into one, because of how little progress there's been due to me taking some time off during summer. The remaining level sequences The second boss' introduction sequence was a pretty straightforward process, with the most important thing being to disable the boss AI when the sequence begins and re-enable it with a delay once the sequence ends, so the boss doesn't immediately rush on the player. The sequence leading to the first boss fight. While writing the sequences involving the second boss I wanted to have all the assets involved in the sequence done. So I booted up Aseprite and started working on the pirates' spaceship. Other assets required would be the boss and a couple of characters that show up later on. Pirate gunship assets I spent a good while figuring out how I wanted the gunship to look. My initial thoughts on the shape were something similar to a turtle, a round-shaped middle section with a pair of wings. Before proce...

Sprites I started out May by creating individual NPCs from the existing base class and adding some necessary animations before I could tackle the cutscenes by using level sequences. Finishing up the animations for rest of the characters will be done after I know what each of them are doing during the cutscenes. Princess Unu's walking sprite. Level sequences The level sequences turned out to be pretty straightforward to use for my purposes, though there are lots of options and adjustments to make which take most of the time. The sequences in Garden 2 mostly control camera movement and trigger events from the actors usually for moving or playing dialogue. The sequences play out at the beginning of the level and when the player reaches a certain areas in the level, for example a boss introduction sequence plays when the player reaches the boss room for the first time. A take from the sequence that plays at the beginning of the level. Speaking of bosses, I had to add all of the dialogu...

The second playtest The second playtest took place in early April, it featured all of the playable content that was planned for the game. A separate post about the test can be found here . Character sprites As I began to shift more focus on building the storytelling in the game, I needed characters to tell the story, which meant it was time to create some sprite assets. Most of the characters retained their design from Garden: Urada Chapter, so the design process itself required only a little bit of sketching. The sprites used the main character's sprite as a base, with each character having a unique silhouette and color scheme. Most of the characters have only idle sprites for now, as I'm figuring out which kind of sprites each character requires for the story. The sprites of the main cast. Dialogue Another key feature of storytelling is dialogue during cutscenes and when the player interacts with NPCs (non-player characters). I wanted to try to make a system where the dialogu...

The second playtest included all playable content of the game: the level as a whole, character progression, enemies, treasures, functioning shortcuts, and two bosses.  The test itself went much smoother than the first. It was conducted on the same PC as the first so I could see if the performance had improved. The game's default graphic scalability is now set to epic instead of cinematic and I assume that my custom-made materials are more lightweight than the prototyping materials I used earlier. The graphics card's VRAM ran short once again, but only by around 100 megabytes. The frame rate doubled compared to the first test's and the input lag was gone.  The playthrough of the level went smoothly without any issues or difficulties. Both of the bosses took several attempts, which was within my expectations. I was initially worried that one of the first boss' abilities was unclear. The boss jumps and slams the ground causing an earthquake that damages the player if they...

Enemy respawn when resting at a save point To make enemies respawn when the player rests at a save point, I went back to the enemy spawner and created an event that spawns new enemies in place of defeated ones. It simply goes through an array of killed enemies checking if they should be respawned and then removes the enemy from the array. The event that respawns enemies. To prevent duplicate enemies from spawning when resting after loading the level, I created a second event that clears the respawning enemies from the array when the level is loaded. Clearing respawning enemies from the killed enemies array. I noticed that removing an item from an array that is being looped through caused the next item's index to drop by one and it would not be included in the loop, always "skipping" the next index after an item is removed. So any changes are made in a temporary copy of the array and after the whole loop is finished the original array is updated with the information from t...

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

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