The last couple months have been devoted to a full refactor of the existing gamecode in Unreal Engine, migrating from full blueprints to C++. I found myself spending alot of time going back and debugging old basic features like UI and camera movement. I figured that the codebase is large enough that I need to add some automated regression testing. I could still do this all in Blueprints but I was also dealing with an annoying issue where packaged builds of the game would error everytime I made a change to my Blueprint Structures. It turns out that this is just a known thing about Unreal Engine, and the lesson learned is create all your base classes and structures in C++ to avoid this problem. (Which sucks) Knowing that I had alot more features that would require more structs, I switched the project to C++. Eventually I just realized doing more in C++ is just going to be easier for writing Unit tests, debugging with breakpoints, Source Control and also it would be nice to have access to Copilot. The one main downside of the switch though has been the IDEs and dev process in C++ (VS IDE or Jetbrains) are quite laggy, crashy and buggy compared to what I’m used to. (Unity and C#). The months in between the refactor and the last post in May have mostly been attempts at more story and character writing.
Cannon Tiles
It’s still in its preliminary stages but I’ve added interactable tiles like a cannon which lets a unit fire an AOE explosion. The hope for this feature is to add it into a larger Ship versus Ship map design. I still have to make the main system itself like Ship health, Movement, Sinking animations.
Attack-Move and End-Turn Shortcuts
I decided to implement a feature from FE NDS games that allowed players to perform an “Attack-Move” where you can select a unit, and as long you move it the selector on top of an enemy, you can skip the action menu entirely and perform an attack. I took it a step further by cutting out the need to move to the adjacent tile before the battle board appears.
Playing the Final Fantasy Tactics Remake really convinced me that this convenience was necessary, as performing a single attack in that game is very cumbersome, both with the number of steps required as well as the controls themselves.
I also added a “Hold To End Turn” Button for additional convenience after playing Metal Slug Tactics. (Although its common in alot of games now). In hindsight, moving a unit to attack and ending turns early are up there as the most common actions a player is trying to perform so they should be made to be quick.
Hotkey Remapping
An obvious inclusion for convenience was adding key remapping which luckily was fairly easy to implement in Unreal with gamepad.
Since the last post, finalizations on character writing while implementing more Unreal engine specific features that I had more trouble doing in Unity. The general visual appearance of the pixel art with light-effected textures is an attempt to create a 2.5D look similar to triangle strategy, without having the same voxel type appearance it has for its environments and textures.
Moving Ships
The clip above shows the 2D animated ships mixed with the water that receives shadow and reflections from Unreals basic lighting system. In the previous Unity Incarnation, all water and environments were Pixel art with transparency which made dynamic use difficult. In addition, the Rain is a simple niagara system with windforce that makes the rain movement seem less 2D.
Storms
The above clip shows a pixel storm that was relatively simple to create using Unreal’s niagara system. Experimenting with the tech has opened up more opportunity with things I can explore narratively which as been nice. A lot of potential gameplay mechanics as well as story has previously been less possible due to having to purpose everything in pixel art or hand-drawn stuff which massively increases the scope of the work.
Lighting and Glow Effects
Switching from using unlit sprites to lit was originally for the purpose of applying shadow so I didn’t have to create an extra pixel art shadow texture for everything. After getting it to work it made sense to create glow effects as an extra way to cast shadows and make better visuals. The above clip shows a unit with a enchant-buffed weapon, and activating spirit to create another outline glow effect. The room light is dimmed on activation to accent the effect.
Weapon Icons
Other work has just been adding other pixel art assets into the UI, and making sure the game always renders the UI at a specific pixel ratio, regardless of the resolution of the window. In general though, moving from 1×1 pixel art to 2×2 pixel art has been way better for dealing with weird pixel rendering.
The last few months have been finalizing the way animations look, programming in base battle mechanics and Enemy AI.
Animations
Years ago the first idle and run animations were done before character writing and visual design were done, so costume and colors were somewhat arbitrarily chosen. After focusing on writing and the game engine switch, it was time to go back and redo the animations with the new costumes and character designs. Since 2021, there have been many fighting game releases by ArcSystemWorks which really elevated how 2.5D games look, giving me alot of great reference and inspiration. In particular, how to get the sweetspot of how many frames to include in each type of animation to create a smoother look.
New | Old
New | Old
Battle Mechanics and Enemy AI
Up until recently, the weapon types that would be in the game were in flux, as I have to figure out what kind of animations I was going to commit to doing. Having characters fight together via the flank/guard system is a major component of the game, and I designed how different weapons would work with that mechanic first. Individually, I wanted to implement something similar to the weapon triangle system in Fire Emblem games, as it’s a nice simple initial layer of how to instructu new players on what to do with their units. Instead of having a RockPaperScissors system between just the melee weapons (sword/axe/lance), I made it so weapons are “countered” by one of the other 5 weapon types. For now the counter effect is 100% hit chance but that will probably change.
Enemy unit AI follows a similar tree to traditional FE games, where they favor available tactics instead of long term strategy, usually at the cost of their lives. With flank/guard being available to enemy units as well, the major adjustments to enemy AI cause them to favor attacking, when they can surround a player unit, and then favor attacking units that they have a weapon counter against. There is a unique exception for Bows, as they have new mechanics compared to FE games, where bows can now attacking at melee range, but do more damage the further way they are from the unit they’re attacking. Enemy Bow units will move as far as possible before attacking.
Next short term goals is to complete the attack, critical attack and death animations for the first character above, and start implementing 2D effects into the main battle animations, to make combat a more cinematic experience.
This last month has been reimplementing some of the old systems from the Unity Game back in Unreal, and it’s allowed some good iterative changes to the systems and UI. In particular, the new counterpart to regular combat called “Dueling”. Some enemy units in the game have the Duel Option which allows the 2 units to fight until one of their HP reaches 0. Units that are duellable have a star hanging over them.
Duel victories result in specific stats being tracked for that unit which ties into the “Title” System that provides passive bonuses for units. The previous iteration of this system, had it so that once titles were “earned” they could be equipped and unequipped from units like items. In the current interation this was overhauled so that once a unit earns a title, that title and its bonuses become “active” and replace the old title.
In the picture above, a unit that “holds” a title will have its sprite visible. If a title is held by a unit in the crew, no other unit can earn that title. This makes it so there’s an extra layer of planning required to maximize the bonuses that titles provide to the crew and to decide which duels should be taken by specific units.
Flanking was also added back into the Unreal build. One change to simplify the UI was to simply have the attacking unit deal damage instead of all flanking units adding an additional damage source and therefore number to the overall outcome. It got complicated in that all the flanking units would have all their own individual calculations, and that took away from the main interaction between the attack instigator and defender. Instead now the flankers provide bonuses to the main attacker, like +DMG, +HIT or +CRIT.
With both titles and flanking both affecting the battle calculations, there is now a tooltip that shows how the end number is affected by the bonuses.
Duels and Flanking/Guarding were 2 of 3 primary new combat features relative to normal FE games. The next major feature is to implement ship attachments, which is to add “useable” attachments like cannons and crows nest to change up how the map interacts with units.
The last couple months have been assets back into the game and building out new maps. In particular, making the pixel art and progamming for the “ship” maps.
The idea with ship maps is to have them dynamic in a number of ways:
Ships versus other ships placements for map layouts
Ship personalization in terms of colors, size, and figurehead
Cannon attachments that affect combat
Ability to move the ship
After placing the pixel art into the game I realized a number of useability features had to be put in, for example above objects “behind” other objects need to have dynamic transparency when interacting in those tiles or if there is a relevant object behind those tiles. Usually the process I go by is to build the art and visual appearance first, and then end up discovering what game rules need to be programmed into to actually leverage the original design of the art assets with regards to perspective and placement.
I realized with building of the ship levels that movement on the ship involves deck elevation levels that affect the pathing, despite two adjacent tiles having no “obstacle” between them. Previously the arrow path would go through the railing, instead of wrapping around the stairs.
How different ships connect to one another is through “Plank” tiles and this turned out tricky to implement. The planks themselves have to create new paths between ships and can be placed/destroyed dynamically creating new paths. This created a number of weird scenarios with how the AI behaviour tries to move closer to enemy units and is still a work in progress.
Having Ship maps have their own design gimmicks is still fairly flawed and there’s a high potential for poor balancing when actually playing maps with alot of choke points and special damage interactions. The plan is now is to get the AI in a good place and play test a number of ship map scenarios.
This week has been mostly reimplementing back the old turn systems from the Unity build like “Spirit” movement, a mechanic from The banner saga that allows units to move further than normal as long as they have spirit points.
In between implementing the “Old” stuff from the unity build, I’ve been trying to take advantage of unreal workflows unique to the engine, in particular VFX. The shader graph from Unity was similar in how it allowed sandboxing of visual effects but the Unreal counterpart has felt way more feature rich. Below is a gif of 2D ocean waves meant to be the background for “Ship Battle” maps. I’m hoping to learning more VFX techniques to possibly make the game transition into 2.5D although there is no practical gameplay reasons to do so, unlike in Triangle Strategy.
The last year and a half started with finally writing the main narrative of the story and characters which basically ended up with alot of art having to be redone. There had been very little actual narrative writing finalized as the hobby thus far had just been to find out if I would be able to build the kind of game I wanted to make. The main point of doing the writing was to be able to come up with a minimum playable demo that I could start designing, as most of the actual gameplay features/system had been completed in Unity.
Unfortunately in September of last year, the unit pricing debacle made me lose confidence in sticking with that platform, specifically because it is my intention of releasing a free downloadable demo at some point. Although the changes were rolled back, it still convinced me that it was worth my time to learn more than one game engine, so I could have more perspective on how to build games in general.
Migration to Unreal Engine from Unity
When looking up tutorials for Unreal, it felt immediately noticeable that the tutorial/youtube community for unreal, but more specifically indie 2D games was underdeveloped compared to Unity. I was VERY lucky to find Alex Quevillon’s Youtube tutorial series that instructs how to build a tactical RPG. Compared to most narrated tutorial series I’ve followed, the depth and format of the tutorials were very thorough, so a big thanks to Alex Quevillon for not only putting out a detailed series from Project Repo Setup all the way to Marketplace setup, but even releasing the entire thing in both English and French.
I mostly used the tutorial as a way to understand Unreal workflow, especially with how it shows how event dispatchers are used. This is a huge departure in programming design from what I had developed in unity, where all player input are processed by a singleton state machine. After completing Quevillon’s 60+ video series, I’m now currently in the process of repurposing this starting point of an Unreal tactics game back into the Fire Emblem style ruleset and game mechanics I had built in Unity.
Although the migration was a lot of steps backwards at the start, many of the features from Quevillon ‘s tutorial series have been massive improvements to the overall design process. Particularly the inclusion of debug tools have been helpful in iterating quicker on how things like AI and movement should work, and in general thinking about how to build features with debugging tools in mind. Below shows the placement of units from the tutorial but with replacing the Visual meshes with Paper sprite assets from the Unity build.
Although most unreal engine features were available in unity too, revisiting stuff like camera functionality and UI through Quevillon’s tutorial has given me more thoughts of having 2.5D features in the game instead of locking it to purely top down. Below is an example of billboarding where the sprites always face the camera. I’m hoping to evolve this with more visual effects like hand-painted normal maps and transition from unlit sprites to a dynamically lit scene. The billboarding does not really have a gameplay purpose in tactics games like Fire emblem where there is only one tile elevation, and camera control is not necessary to observe the game board properly. Most likely just going to use 2.5D cameras for transition effects between unit control and battle animations.
One huge improvement I appreciate from Quevillon’s tutorial series was how he handled the pathfinding algorithm performance. In my unity build I had a much less elegant solution to per frame processing, where I had hardset a number of operations allowed per frame to get rid of frame stutters, but Quevillon’s millisecond delay ended up being more flexible for my needs.
PixelArt Improvements
Another rehaul of the pixel art has been underway the past year due to a few games with really great pixel art that came out: Songs of Conquest, Triangle Strategy and Octopath Traveler 2. Previously the 1×1 single pixel blocks being used were sensitive to rendering artifacts when the camera was not perfectly sized to the monitor resolution. The main “rehaul” was having pixel art in 2×2 size pixels worked better with changes in camera zoom and just looked more appealing in general.
Songs of Conquest in particular has been great to study from for all environmental pixel art and all three games in particular have great 2.5D visual effects. It is also very motivating that TS and OT2 are made in unreal engine.
Adaptations in Portrait Art and 2D battle
As mentioned previously, having character writing done allowed me to finalize things like custom design for a number of the main cast, and also allowed me to progress my art in way that it better serves how I want the game to feel. In previous iterations I had felt that it was an issue that doing character portrait art felt like such a completely separate task than doing battle animations. I realized what I wanted for doing character art in general to feel more cohesive, so I had to embrace a more anime portrait art style that was less heavily painted and rendered. So I spent alot of time redoing the character portrait art based off the new character writing and making sure that it basically didn’t look too different from the battle animations.
My focus now will still be to get the Unreal build back to the equivalent feature set that I had in Unity and using all the assets I had built over the years, particularly all the UI assets and their functionality. I may still switch back to Unity, as I’m still more comfortable with it and coding in Unreal blueprints is still somewhat unintuitive for me, despite already encountering much easier code debugging scenarios in general.
The Battle UI for Group Skirmishes has changed a lot over the years a long with the mechanic itself. The Flank and Guard mechanic is progression of the way Dual strikes and Dual guard worked in FE Awakening and Fates. Flanking allows units that are surrounding an enemy unit in the cardinal directions (Up, Down, Left, Right) to join in an attack. This creates unit interactions of up to 5 concurrent units. Below shows a “3vs2” scenario, where 3 player units will each attack a single enemy unit.
Flanking aims to:
Flank attacks are a way for all participating units to build support EXP with each other.
Replace double attacks. I personally never liked the arbitrary requirements for double attacks (5 speed above defending unit). Double attacks did enhance the game experience by speeding up combat and having 2 chances to Crit, which was a generally satisfying mechanic for players.
One thing that is pending the order of which the attackers begin their attack, and the EXP distribution for each participant, which are things that will affect game balance alot.
Guard/Blocking
For any unit being attacked, any allied units in adjacent squares contribute to an overall chance to Block/guard. This means that for any attack that would hit (not miss), each blocker will calculate a chance to block. What is displayed on the battle UI is the overall chance for any attack to be blocked (19%). Should a block/guard trigger, all damage is negated.
Due to the Rest/Heal mechanic only working when there are no enemy units in attack range, guarding damage is the primary way to conserve your parties HP pool. Taking advantage of guard/block and building support between units becomes extremely important later into the game as high support levels can cause a group of 3 player units standing next to each other to provide very high block rates for one another.
I had a lot of initial reservations with increasingly the complexity of combat interactions as it makes sense that most people don’t want to read through tables and charts of numbers that may seemingly come from nowhere. That seems to be the design trend in FE games as the dual mechanics were removed from future installments, and complexity was added to class systems instead of map interactions. The main trade-off of the more complex design, and that I liked about the dual system was the satisfaction of units blocking for one another, which added an additional layer of fantasy to making support between units meaningful, both mechanically and narratively.
At this point in the design, the hope is to alleviate some of that complexity through simplified UI. For most players and situations, the battle UI should just explain whether the combat will be good or bad for the player. It will mostly likely make sense down the road to purposefully hide combat information that is distracting from helping the player make a decision.
Dueling
A system called dueling is added to the base gameplay loop that is available on “Commander” type enemies. It behaves essentially as an adaptation of the arena system from FE games, where 2 units battle until one is defeated. Unlike an arena battle, there is no ability to forfeit mid battle, so duels are considered high risk/high reward. Winning duels increases a Duels Won counter tied to the specific unit that was used and also provides additional Bounty Silver once the level is complete.
The Dueling System aims to:
High Risk/High reward side objectives
Contributes to overall Unit customization
Additional Narrative Elements
The criteria for a duel to take place is fairly strict. The option to duel an Enemy commander will not appear if they have taken any damage from player units or been attacked. This prevents the player from dealing regular combat damage to a commander and then dueling to easily claim the bounty rewards.
Duel Draws
There exists scenarios where 2 units dueling may have a combination of low hit rate and low damage that may cause the duel to possibly drag on forever. Currently there is a 20 attack max count to create a “Duel Draw” situation.
Enemy Platoons
Duels are against “Commanders” and some of these Commander type units are surrounded by “subordinate” units. Winning a duel provides a route to avoid having to fight every individual unit. Winning a duel against the commander will cause each subordinate unit to surrender afterwards. In addition to granting EXP and WEXP like a normal battle, winning duels will grant Reknown based on the relative bounty of that commander.
Attacking Surrendered Units
When Enemy Units surrender from their commander being defeated, they remain permanently idle until the level is over. These units can still be attacked and will die in a single hit, with a 100% hit chance. Doing so will still grant EXP and WEXP but increase the players Infamy. The design of the infamy mechanic tends to lean towards giving rewards to the player immediately in exchange for disadvantages later on.
Unit Titles
To compliment the dueling mechanic, the “Titles” system is added a reward system around duels which allows passive bonuses to be equipped to Units.
Titles are a progression on equippable passive skills seen in FE games. In FE games, skills that provided passive bonuses (+10 hit and +10 avoid) were usually locked to characters or classes for narrative purposes. These passive bonuses are now obtained by any unit through side objectives.
The Titles system aims to:
Help players feel their characters are unique from one another
Add to player units narratively. (story is unlocked by certain units getting certain titles)
Be a sort of minigame within the game, similar to training a metapod in pokemon,
Additional way to make your units much stronger
Additional incentive to duel strong optional enemies to claim their titles.
The Title List will show all available titles that have been earned as well as the ones yet to be earned. This screen is meant to help players decide what bonuses they want to pursue and how close they are. Units can equip one of the titles from the list that they have earned, and this title is shown on their stat screen.
Unit Stat Screen UI
Character Bounty and Titles
The dueling and titles system are both meant to add to character customization narratively and the Character UI is meant to capture this. In addition to titles, every character has a Silver Bounty associated with them based off the number of duels and regular battles they participate in. In all party-building tactics games, there’s a few characters that end up being the “favorites”. The bounty system aims to highlight this more obviously as well as change both gameplay and narrative events.
Despite being a very simple screen from the perspective of the player, a lot of time is actually spent by players studying the unit stat screen in RPGs and tactics games. This was another screen that got a lot more raw information and functionality added to it from its traditional FE counterparts. Much like one the unit equipment screens, the Stat growths of units are shown and dynamically change to whichever unit is selected.
This post outlined some of the more significant changes to the traditional base gameplay loop. Basic combat now has Flank/Guard and Dueling added problems for players to solve and how to split and group their units down different paths. Next post will showcase the changes to Chapter Start Unit Selection and the Unit Hiring System that was added.
After a 2 year hiatus from posting on this blog, I’ve decided to resume posting to serve it’s original purpose as progress tracking for myself, so that I have old designs to look back on and compare my processes for development and art. It stopped serving that purpose once gif and video editing started to take up too much time every week.
The original idea behind a weekly schedule that was upheld from 2017-2019 was to force myself to get something done regularly. Now programming and art I’ll update it on a topic and completion-basis which has been more productive in the last 2 years working on the game silently.
Gameplay Mechanics and Game Difficulty
This post is mainly focusing on game mechanics that have been added on top of the original fire emblem gameplay loops and systems:
All controlled units are commanded in a single “turn”.
Units that are defeated removes them from use, possibly for the entire playthrough.
Game difficulty in modern fire emblem games has typically been to add different modes, that increase the power and/or amount of enemy units on each map. These modes have never appealed to me personally and do not seem interesting to design level/maps around. Addition/change of existing tactics RPG mechanics aims to deal with.
The main philosophy behind these supplementary mechanics its to incentivize players to complete each level with low turn countsas an alternative to difficulty created by having stronger enemy units.
A secondary goal that these mechanics aim to achieve is:
Have a single difficulty setting while simultaneously removing “unwinnable” states in each level.
Chapter Bounties
In the above picture a list of player rewards for different optional objectives is shown on the right. These rewards provide the player with the games currency Silver, which can used for a number of things, but mainly to make the player’s unit roster stronger through:
Hiring/Recruiting new Units
Buying stronger weapons
The Clear in X turns objectives is a direct push on the player to complete the level quickly, but is balanced with the additional Silver reward of losing no units. This mechanic is geared towards players who wish to min/max their silver output from level to level. Taking advantage of these bounties and having a very strong unit roster is not necessary to being able to complete the game, because of the healing/rest mechanic explained in the section below. Although, having a strong roster that can provide low completion turn counts may affect the story/ending significantly.
Heal/Rest Mechanics
Every controllable unit has the ability to use the “Rest” Command. It heals them for a percentage of their max health and is only available if they are not standing in attack range of any enemy units.
The main idea behind this mechanic is to make the goal of simply being able to clear each level much easier. The player can pull their units back and heal, but at the cost of potentially wasted turns. The heal mechanic is intended to act as a way to recover from mistakes, but the requirement to move a unit back will increase the turn count, making it much harder to get the low turn count bounties.
Spirit Mechanics
Each unit has a resource called Spirit Points (SP) that is used to perform certain movement and combat actions. In the below gif, spirit is used on a selected unit to allow that unit to move further than their movement stat normally allows. The spirit mechanic aims to expand on the willpower mechanic seen in The Banner Saga series.
Spirit can also be used to increase the hit rate and critical chance during battle, providing a choice for players to use it offensively or defensively.
Spirit points are indicated under a units health bar by gold stars. They are replenished at the beginning of every chapter. Just like HP, leveling up increases the maximum spirit capacity of each unit, but as of this post Spirit points will always be sparse, with a maximum of 10 even at the max level (30).
Spirit points aim to be an additional problem solving tool for situations that typically happen in Fire Emblem Games like the ones below:
Defeating boss/Stronger enemies
Allowing weaker units to defeat stronger enemies and level them up
Getting out of bad situations to rest
Reaching side objectives quickly with stronger units to achieve low turn counts
Destructible Bridges
The image below shows the ability to destroy bridges, creating impassable terrain situations. Any units that are on the bridge will instantly die. This can be used as a gimmicky method to potentially to defeat stronger enemies. As of this post, the unit that destroys the bridge will not gain any EXP if an enemy unit should die from it, to keep the mechanic as purely as defensive one. Destroying bridges will eliminate a direct path, that will most likely increase turn count.
Village Raiding
Village raiding allows your units to pillage any friendly NPC/town, to obtain items that are normally sold in that towns shop. This allows players to obtain items without spending any silver. Items in shops are separated into tiers and categories, and there is a Random Roll that picks an item from each tier/category.
This mechanic allows certain units to become powerful early on, serving as an additional artificial difficulty setting, but comes at the cost of player Doing so, results in the infamy stat to go up, which affects a number of things in the game, like story, which units become recruitable and the price of items in other shops.
The inclusion of village raiding is primarily to add extra variability in story, but also for players to min/max playthroughs, because as of this post, items in each shop are static and not randomly generated.
Village raiding is one mechanic in the large Reknown/Infamy system. The other mechanics related to reknown such as dueling are still a work in progress but aims to create a balanced good/evil system, to add replayability to the game, as it changes the story and which characters become available throughout a playthrough.
Quality of Life Changes for FE style games
A number of small changes that have been added for quality of life. Most of these are just things I wish existed in every FE game I’ve played, but in particular the GBA games.
Showing Enemy Attack Squares and threat level
Above shows the attack squares for enemy units. This exists in modern FE games, where I first saw it in FE Awakening, but I’ve taken a step further by actually adding numbers that indicate the threat level of each square. The numbers indicate how many enemy units can move to that square to attack. I felt this has even increased importance when combined with the Flank system used by both the players and enemies for attacking.
Show Support Letters
When a player unit is selected to perform an action, all allied units will display their support rank with that unit. Some of the supplementary game mechanics such as blocking/flanking increases the incentive to group/pair units together and have them develop a rapport throughout the game. Showing the support rank is a much needed addition to know which units should be placed near each other for a significant advantage.
Show Enemy AI
The enemy unit behaviours in FE games have never been super complicated and are pretty much split into 3 main types:
Enemy Unit will remain stationary until a player unit moves within range. (Most common)
Enemy Unit Will not move (usually defending a choke point)
Enemy Unit will move in direction of player units as soon as the level starts
The Icons shown in the picture above denote each of these behaviours. I never saw a point in obfuscating this information from the player. Knowing the specific behaviours of different types of units and on specific maps only provided a reward for players that had already completed those levels at least once. The choice to make the enemy unit behaviour obvious is solely to service new players.
Coming Posts
This post covered some of the more finished additions to the game. By the end of writing this it did actually help me realize changes I want to make in other features, particularly with UI.
Next Post will detail the changes to the battle system and the UI changes, and the post after that will cover some of the new UI screens related to out-of-level gameplay. As stated above, the posts will no longer be weekly as they once were, but as things finish. This is due to the state of the project changing, where there is now enough finalized designs and concepts, and the topics will be covering more how they piece together into something actually playable, whereas before the posts from 2017-2019 were more about process discovery.
Haven’t posted in about 2 months due to a build up of character drafts and combination of life/job stuff. Currently still working on animation drafts for about 5 characters concurrently right now, below is an idle of one of them. The others involve magic casting animations and settling on visual effects for the magic has been a longer process due to having to make sure background environments don’t create an oversaturated color effect. The hope is to finish each of the characters and go back to weekly visual updates.
Also, Some other design include preliminary level designs, and the a first draft of a side objective system within missions and probably another overhaul of the pixel tile graphics. Thanks for reading.
To Reverie 