淡き翼

#pixelart

I'm pushing it a bit, but im keeping it grounded.

fire attacks come from fireworks and flintlocks, toxic attacks from poison and blood. Hence Iruruu can never conjure up elements, and can only catch it from enemies' attacks. Alcohol and iron oil coating allow substances to adhere to the blade.

here's the real reason I added guard counters: element catching (I need a better name)

attacks with elemental/status damage that would otherwise chip and proc can be 'caught' with a guard counter and imbued into your sword, which protects you from further status damage.

guard counter!

unlike a deflect, there's a slight delay before the active frame, so it's a bit harder to pull off.

animation I did a while ago

haha im not as evil as miyazaki

...but don't tempt me

yeeee i really want to add rain, but likely just for a specific fight for extra *drama*

oh right i hid it in the reflection cuz i was gonna make a separate water shader but then gave up on that xD

was gonna make water a bottomless insta-kill pool but this is more fun

splash splash

thankss :3

been spending some time creating drafts of the next area to see what i like

...I say "draft" but they'll probably remain in this state for the next year and a half xD

Monolith Castle
#pixelart

FA

i personally don't like it aesthetically, but yeah that is the best solution (i was thinking something similar to BOTW's stamina circle). might add it as an option

ah, there's already a different sword heating mechanic where your sword heats up and you can use it as a cauter so that might conflict a bit

having something shown on the character is a good idea though, maybe some alternative idle/run/deflect animations

yeah I think I can get by with top/bottom as an option since it's usually a deadzone in a room layout, but middle is tougher because since it'll obscure vertical room connections

maybe a good compromise is to only show centered posture bars for boss rooms that won't have these connections

moving it to the bottom *sometimes* work, but it depends on the room layout whether the player is closer to the top or bottom. I dont want to make it dynamic either since it betrays eye muscle memory

I've already added sound cues when posture is nearly broken, but I feel it's not enough

after lots of playtesting I realize why Sekiro and AC6 put posture in the middle, as high-pressure combat really doesn't let you peel your eyes from the fight for even a second. it's even more important now that I've added the disarm mechanic. BUT a centered UI element looks weird in a 2D game

im a little late but, HAPPY NEW YEAR!!!! xD

since it's the year of the horse I figure I'd draw young Iruruu when she still had her horse and bow back in Xinjiang

yeah it's just a static class with static methods. Since C# went with the Java playbook of everything-must-be-a-class, you'll still need a "class", but it's just a holder for functions.

there's no escaping OOP in most game engines, so using it in select parts as u've mentioned is the best approach

yeah last I checked i think it does support mobile but not fully stable: godotengine.org/article/plat...

if your goal is to ship mobile games with C# then I think Unity is probably the better option.

That said, this approach is only useful for games where combat has many branching paths. If there's no parries or counters, that occur regularly, it's likely overkill.

However, in a deflection-focused game, a single combat event can have like 10+ results, so it helps to have a pure data flow.

The main advantage of this approach is (1) everything related to how combat is done is just a series of reducers and mappers, so debugging is much easier. There's no state I need to keep track of. (2) unit testing is dead simple. I can mock any struct as input and just check the output.

ReduceCombatRequest is static, so it's entirely data-driven. Given the type of attack, position of attack, response of the defender, direction, etc., what would be the resulting reaction of the defender, attacker, effect type, position, etc.

AttackHitbox, DamageHitbox, and DamageHandler are nodes, which are children to Player/Enemy nodes. The contexts/requests/results are structs.

The main FP part here is the ReduceCombatRequest. It's the only function that handles business logic; other methods like Damage() only supply context.

Haha I actually love discussing technical stuff so I'm more than happy to go into details! I'm using Godot 4 with C#.

(I actually had this flowchart a long time ago to help myself visualize the whole flow)

technically inspired by Lies of P but I haven't actually played Lies of P and only learned about a similar mechanic from watching Joseph Anderson's video on it (yeah Im that kind of person xD)

(( I'll buy it during winter sale I swear LoP fans pls don't crucify me ))

it's a bit overtuned for demonstration purposes; I think I'll settle at around 20+ deflects for 1 bar of healing. the idea is to still maintain that sense of desperation once you've depleted your main healing item, but give players a sliver of hope so they keep on fighting