I finished the backsprite for The Skeleton summon, for when your Party is the one summoning it! I've been working on a lot of UI lately, but that has really been coming around, so I'm getting back to doing more character animations now!

seen from T1
seen from T1
seen from Türkiye
seen from Russia

seen from United States
seen from United States
seen from China
seen from United States
seen from United States

seen from United States
seen from United States
seen from South Korea
seen from Denmark

seen from China

seen from United States
seen from Türkiye
seen from United States

seen from Switzerland

seen from Russia
seen from Russia
I finished the backsprite for The Skeleton summon, for when your Party is the one summoning it! I've been working on a lot of UI lately, but that has really been coming around, so I'm getting back to doing more character animations now!
Devlog #17 - Big UI upgrade & the Anatomy of a Skill + buff timers
Finally got together a new devlog, and I actually think it's pretty meaty this time! A ton of my focus was on untangling the anatomy of what a Skill actually is in my game, and that also went hand-in-hand with UI upgrades, which are very much WIP
Character portraits are now visible in the Pause menu Summary screens - I needed the character sprites associated with the UI for party members for the next step, so I made them visible here as well. Other than that I have not polished the Pause menu at all, but now you can see the character in their stat screen.
In-battle character wheel & plans for UI regarding targeting - So I had this idea of having the party member who is targetted by a single-target attack (or the entire party in case of a party-wide attack) appear at the bottom of the screen, but because of all the information that can be on screen already, I don't want them to always be visible. My solution is a wheel that displays the selected party member, which can be used both when you are selecting them on your turn AND when the enemy selects one of them for a target. This wheel is not finished, but I have a rudimentary version of it in there to see how I like it.
The anatomy of a Skill - I really had to think this through to untangle a lot of the ideas about how to present information clearly while having a lot of interacting and flexible choices for Skill design. I had come up with a lot of passive abilities that sell the feeling of each character/class, but for example, a Poison boosting passive is only as good as your range of active Poison skills, so I needed many active Skills in each category. I also want things like Fire and Ice mages, while having Fire and Ice feel more interesting than different kinds of elemental damage.
What I have so far - Any active attacking Skill (meaning not Passives, Healing, Status, or Buffs/Debuffs) can be, independantly, either Single-Target or Multi-Target, Single-Hit or Multi-Hit, Magic (costs MP and can be silenced, but has more variety and power) or not Magic, Ranged (bypasses time cost of attacking into many summons but loses accuracy) or Melee (the opposite), have an elemental Type (Fire, Ice, Elec, Poison, etc whatever I need) and a melee damage type (Cut, Pierce, Bash, with their own advantages).
Elemental types aren't rock-paper-scissors, they have more bespoke effects. Instead, Fire spells feel like Fire because they inflict the Burning status. Ice spells can slow or freeze enemies, etc. Skills with those tags though, are made more effective by certain passives. As for Melee types, Pierce skills should bypass Defense buffs, Bash attacks scatter summons, and Cut attacks may deal extra damage on crits (maybe, unsure). A Fire Sword attack, for example can be a Single-target Single-hit, Magic Melee Fire Cut attack, and I can balance it all with MP and Time costs.
That's a lot, I know, and the goal is to make it as simple as possible in the battle UI to strategize, but also make the game very flexible and interesting.
Skill tags & properties - Skills in battle display tags that represent the above properties, so we are always clear what we are working with.
Skill and Item description boxes - Now we can read what our Skills and Items actually do in battle! This will also greatly help me to write down the actual current implementation of skills and balance them while playtesting.
Stat buff turn timers - Stat buffs are now applied on individual 3-turn timers (for now this is by default 3 and maxes out at 3, but that could change). Reapplying a buff resets the timer to 3, but while buffs and debuffs counteract each other, buff don't reset the timer unless they are on the positive side, and vice versa for debuffs (ie you can only extend debuffs with debuffs). An alternative approach would be to have a queue of effects with their own timers, where a bunch of buffs and debuffs can be active at once, meaning if the buffs expire, you could be left with a set of active debuffs, but I think using one side to cancel the other works well in concept, I have to think on it some more.
Such a long post, but I've been thinking about this all for like 40 days since the last one!
Devlog #16 - Switching party members mid-battle + more abilities
After several weeks of planning out abilities and enemies/party members, I have more implementation this time, and part of that is introducing the mechanic to Switch party members mid-battle! Normally, switching in will mean that the new party member's turn is used up (possibly using time on the Battle Clock as well), but there will be a passive ability for roguish types to enter without a penalty.
In addition, more abilities have been implemented! All have temporary names in the prototype so I'll just list some effects;
A spell to cure blindness
A spell to cure Poison
A spell which applies some Regen to the entire Party, or counteracts some Poison is they are Poisoned
A skill that acts as a Defense buff
A skill that sacrifices Speed for a larger Defense buff
A skill that sacrifices Defense for a large Strength buff
A passive ability that has a chance to summon minions when casting magic skills
Multiple summoning abilities for minions that still need to be implemented
Those are just a few I've implemented piecemeal while working on the Switch mechanic, next I'll be pushing farther into implementing skills, particularly to complete existing enemy types and their enemy AI (how they choose which skills to use as enemies)!
Devlog #15 - Implementing more abilities/mechanics + Item Loot
Just a quick update this time, largely an extension of the last devlog, but this time going from ideas for classes and abilities to putting them into words and translating that into implementation.
I go over my approach to design more in detail, and mainly I've been knocking off some of the passive abilities, as they are both somehow easier but also force me to get certain underlying mechanics right to implement them.
In addition, enemies now drop items from a loot table, and the poison mechanic has been reworked. Also, summoned minions now provide a protective purpose by hindering enemy attacks against yourself.
Things are going slow, but steady right now I'd say! I feel as though I've been getting bogged down by distractions in my dev time lately. For me personally, the election season is a big culprit of that (and I'm not even American, but can't look away). But, I'm trying not to break the chain, and get that productivity back steadily!
I'm planning out all the classes for recruitable enemies/party members for my game, and I currently have an initial core of 41 ideas and I'm making a big spreadsheet for their stats, skills, and fusions. Then once they're really hammered down I can work on filling out the ranks with classes that conceptually fill in more interesting gaps and niches and mechanics.
I've been pretty offline for a few weeks either slowly doing that or busy with others things during the end of summer, or just catching up on some reading, and lost my flow for a couple of weeks, but hopefully I can get back into gear now!
As a teaser, here's a rough draft of just the names for classes I'm considering for Labyrinth Lesmosyne's core classes;
Alchemist, Assassin, Barbarian, Bard, Battlemage, Cavalier, Charlatan, Chronomancer, Cleric, Cultist, Dark Knight, Druid, Enchanter, General, Hunter, Illusionist, Knight, Lumberjack, Magic Knight, Martial Artist, Medium, Monk, Necromancer, Ninja, Paladin, Pirate, Psychic, Pyromancer, Raider, Rogue, Sailor, Samurai, Scholar, Shepherd, Sorceror, Thief, Valkyrie, Vampire, Viking, Warrior, Witch
While most of this list is me filling the ranks with traditional RPG classes that LL needs (names not final), others, like Lumberjack, Sailor and Shepherd, which I've shown, I've been thinking of as more job-themed proto classes that can be found in the early game, and for example the Lumberjack might be a fusion component for a Barbarian, and Sailor might be one half of a Pirate. I want to add more of these to form a first tier and have a basic set of - for lack of a better term - D&D adjacent classes serve as the second tier.
Then, others on the list already are ideas from a sort of third tier - the Raider being a product of a Hunter and a Thief, or the Valkyrie which arises from certain fusions involving Vikings, maybe Viking + Cavalier. This too is ground where I can generate many new ideas from fusions of the core, and expand the third tier, which should be mostly filled out with conceptual multiclass fusions. The tiers aren;t rigid though, and some fusions might result in an earlier tier class with the opportunity to inherit more powerful skills.
I'm probably going to have enough of the table done to talk about it in detail in a devlog this week, even if not all the details are ironed out.
Finishing up my Cleric animation for the night, could use a few touch-ups, but for now I'll move onto the Knight on the weekend!
Possibly the general shape/rough sketch silhouette for the Paladin enemy type? Maybe it's because I'm doing two suits of armour in a row, but I'm not sure how I feel about this direction yet. TBD.
Messing with having the party's summoned familiars appear on the field alongside the enemy's. Need to draw backsprite animations for each of them and adjust the perspective and scale. Need some distance between the player and enemy field, but also need to make the enemy sprites big enough. Might make an alternate colour scheme for the player's summons too, but for now I'm working on functionality.
Everything depends on the rest of the UI - I'm thinking of making the party stat windows in-battle long and horizontal at the bottom, and sitting the rest of the view above that.
I think I want to redo the animation for the Snake - make sure the frontside design is finalized before I do a back sprite based on it, or I'll have to redo that too - would be lots of rework to keep them consistent - I wonder if that's why early Pokemon back sprites look... like that.