YesNoOk
avatar

Sacchin (for 1.1) (Read 4906 times)

Started by Bannana, July 01, 2022, 06:05:21 am
Share this topic:
Sacchin (for 1.1)
#1  July 01, 2022, 06:05:21 am
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
Slowly been working on this :p
The character and system are designed for a 4:3 environment. Playing in 16:9 may cause issues visually.
I am currently using screenwidth and screenheight controllers so this is 1.1 ONLY, but I will be editing that later to make it 1.0 compatible.
There are bugs in ikemen with the color selection and remappal. Ikemen GO compatibility is intended so I'm looking into it.

Since Gato I've been developing the gameplay for my all Fatal Fury system, trying to unite gameplay mechanics from every game from 3 to Mark of the Wolves, along with some ideas I thought were pretty interesting in Art of Fighting 3. It's still not perfect, we're gonna need tons of different characters to really flesh out the mechanics and find what fits, but alpha tests were pretty promising and I'm happy with the core package so far.

AS ALWAYS my very voluntary, and quite busy, old man testers and I are not gonna find everything, so please tell me if you find any bugs or issues. Oversights are common!

The idea behind the gameplay is very early to mid 90s neutral-ish, taking what is basically a core FF3 gameplay after removing lane sways, though retaining the classic down forward quick sway on D. With this there's the Heat meter from Wild Ambition, Escalation mode as a loose interpretation of the effects of Blue Mary's super from RB2, and everything is rounded out with Just Defend, Feint Cancel, a Break Move, a Pursuit, and a simplified version of everyone's favorite Real Bout mechanic: chain combos.

I'm working on a lot of cosmetic and graphical backends, and there's some FX and some other fluff I still want to add, maybe change the SFX out in the future, but the gameplay is done.
No AI at the moment, I use a modified version of Vans' buffering so she'll just bug out.

Spoiler: Movelist (click to see content)
Spoiler: Cancel Chart (click to see content)
Spoiler: Universal Mechanics (click to see content)
Spoiler: Training Mode (click to see content)

not on the webzone right now
Last Edit: July 09, 2022, 02:02:38 am by Bannana
Re: Sacchin (for 1.1)
#2  July 01, 2022, 02:28:06 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
I know very little about MB and forgot everything about FF, so this was a refreshing character to try out. ;P

Some feedback for you:

- Training menu should be drawn with lower sprpriority. Currently the dodge goes behind it
- I think state 52 should have velset = 0, 0
- Not your fault but the buffer's: you can input buttons before motions during combos and the specials still come out
- Possibly also the buffer: cancelling B into 214A makes the B version always come out
- Can't cancel 5A into 214B
- Can't cancel crouching attacks
- Her idle legs' hurtbox seems exceptionally fat. Are they accurate? Most of her head is also unhittable
- Crouching Clsn shouldn't be thinner than when standing. It also extends way beyond her head. I get why it's like that but the discrepancy is too big in this case, I think. It also makes her standing and crouching Clsn2 almost the same height
- 6B is an overhead that doesn't hit crouchers?
- C misses KFM at point blank
- C has no guard pushback. Intentional?
- I feel that hop dodge and actual hops overlap too much in function
- There's a lot of debug messages about missing helper parents. Also one about "GRD GUY" with invalid palfx mul value
- If you skip the intro fast enough, training mode isn't detected (not a big deal)
- Palette selection could use a time limit
- "6AA - Simplified chain combo" seems like it's actually 6AAA you listed the wrong battery type
- Sacchin Dunk target binds are weird. On frame 1 P2 is bound wrong, and for the rest of the move it looks like he's sliding
- Sacchin Arm has the same frame 1 bug
- I think her get hit hurtboxes should move less while being juggled
- Diagup anim makes her disappear
- Weak "Don't come near me" is punishable on hit. Is there a catch?
- The throw doesn't selfstate P2 at the end
- If you throw P2 into the corner she overlaps with him (needs edge width)
- If P2 holds forward while being thrown he will slide longer
- If P2 holds forward after being thrown he will keep walking forward. Seems intentional up to there, but that means he can't block unless he does something else beforehand
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Re: Sacchin (for 1.1)
#3  July 01, 2022, 10:44:01 pm
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
Quote
- Her idle legs' hurtbox seems exceptionally fat. Are they accurate? Most of her head is also unhittable
- Crouching Clsn shouldn't be thinner than when standing. It also extends way beyond her head. I get why it's like that but the discrepancy is too big in this case, I think. It also makes her standing and crouching Clsn2 almost the same height
I this is an issue with some of the hitbox philosophy not necessarily working in certain sprite contexts. A lot of FF games including Garou have standardized boxes across the cast (kevin's doesn't even move with his idle animation), so I was curious about attempting this, though I'm thinking the way the sprites are drawn it would make more sense to modify them slightly

Quote
- 6B is an overhead that doesn't hit crouchers?
- C misses KFM at point blank
- C has no guard pushback. Intentional?
All intentional but they do seems a bit egregious

Quote
- There's a lot of debug messages about missing helper parents. Also one about "GRD GUY" with invalid palfx mul value
I need to tweak this code, the parent is destroying itself before the child helper is gone.
The palfx debug is a necessary bug in some sense but I can probably fix it.

Quote
- "6AA - Simplified chain combo" seems like it's actually 6AAA you listed the wrong battery type
It should be both, that's sort of a quirk of the 5a in some of the games if you don't have a command normal

Quote
- Sacchin Dunk target binds are weird. On frame 1 P2 is bound wrong, and for the rest of the move it looks like he's sliding
- Sacchin Arm has the same frame 1 bug
I'm not sure I understand how they're bound wrong, unless it's due to an oversight like animelemtime(1)=1 or the bindtime being too short
As for the first, they're bound for 4 animelems and then I released it with some slight vel added hoping for an interesting effect, but maybe it looks a bit weird

Quote
- The throw doesn't selfstate P2 at the end
- If you throw P2 into the corner she overlaps with him (needs edge width)
- If P2 holds forward while being thrown he will slide longer
- If P2 holds forward after being thrown he will keep walking forward. Seems intentional up to there, but that means he can't block unless he does something else beforehand
This thing is driving me insane lol. It's meant to selfstate but they have to input as so
Code:
[State 800, 2]
type = selfState
triggerall = time > 50
trigger1 = command = "a"||command = "b"||command = "c"||command = "x"||command = "y"||command = "z"||command = "start"
trigger2 = command = "holdback"||command = "holdup"||command = "holddown"
value = 0
ctrl = 1

As for some of the jank about it I'm at an impasse with this and might as well just replace it with a real throw


Lots of good stuff, thanks for your time!
Re: Sacchin (for 1.1)
#4  July 02, 2022, 03:15:40 am
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
Quick hotfix that covers a majority of the feedback
Spoiler: 7/1/22 (click to see content)

I can't recreate all of the issues with the canceling, but I'm betting some of this stuff ends up being how I intentionally modified tiny buffering to read inputs as "open," so to speak. With this you OS inputs based on button order or incomplete inputs, like buffering 2/3rds of an input into a command grab, which you can kara off by finishing the last direction of special input, e.g. 626B 3C was an intentional aspect of the system

The issue is this causes special canceling for lows to have issues with 22X having priority because it reads the initial crouch as the first down input, so if you try to go for 214 out of crouch it will parse it as 2214.
Re: Sacchin (for 1.1)
#5  July 02, 2022, 12:39:17 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
I'm not sure I understand how they're bound wrong, unless it's due to an oversight like animelemtime(1)=1 or the bindtime being too short
As for the first, they're bound for 4 animelems and then I released it with some slight vel added hoping for an interesting effect, but maybe it looks a bit weird
The update fixed the first frame thing, which was the most noticeable issue of the two. As for the other, you can see it if you land the throw then pause and use frame stepping. The opponent will slide a bit away from the binding positions. I like to use "animelemtime(x) >= 0 && animelemtime(x + 1) < 0" for this reason.

Quote
This thing is driving me insane lol. It's meant to selfstate but they have to input as so
Code:
[State 800, 2]
type = selfState
triggerall = time > 50
trigger1 = command = "a"||command = "b"||command = "c"||command = "x"||command = "y"||command = "z"||command = "start"
trigger2 = command = "holdback"||command = "holdup"||command = "holddown"
value = 0
ctrl = 1

As for some of the jank about it I'm at an impasse with this and might as well just replace it with a real throw
If you want to keep the throw like that you should add holdfwd to the list and (I think) a 1 or 2 frames NotHitBy so P2 can block when coming out of it.

I can't recreate all of the issues with the canceling
Which ones?
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Re: Sacchin (for 1.1)
#6  July 02, 2022, 09:59:50 pm
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
Quote
- Possibly also the buffer: cancelling B into 214A makes the B version always come out
- Can't cancel 5A into 214B
the issues with 214 canceling don't come up for me at all so I'm curious as to how you found them.
Re: Sacchin (for 1.1)
#7  July 02, 2022, 10:11:20 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
Turns out I'm just an idiot. :derp: I saw that she has a slow and a fast version of that move, but forgot they are tied to the Escalation mechanic rather than button strength. Nevermind that one.

While checking that out I just noticed something else: if you're crouching, then walk forward a bit and try to do 2A (very common scenario in fighting games), she will do the ground pound instead of the low. In other words, I think the input should be "D, D" instead of "~D, D"
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Re: Sacchin (for 1.1)
#8  July 02, 2022, 10:26:04 pm
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
I suspect that's probably the command and buffer in tandem, I'll probably need to make some modifications. That's part of the reason why I ended up working with satsuki, since most of the SNK characters I would have made don't have 22X specials.
Re: Sacchin (for 1.1)
#9  July 05, 2022, 04:04:09 am
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
Spoiler: 7/4/22 (click to see content)

Major/minor update, I have fully removed most of mugen's basic input reading in favor of my own, including specials, which means that certain issues I had with buffer reading can be amended. I did testing on a few controllers and it felt stable (depending on my skill in hitting the correct angles), but this new modified buffer is definitely in BETA territory at the moment. Pretty big difference so here's my log outside of the spoiler above:
Quote
first major buffer modifications, now it will contextually read raw inputs properly, e.g. 25214, crouch returning to neutral to a QCB input would be read by mugen as 22.. and it would result in 22X as opposed to 214X. Now it will attempt to understand these inputs in terms of their intent, based on order and buffer decay, instead of trying to identify mugen's set patterns. This also means that where mugen identifies the first matching input and executes it, my buffer identifies the last matching pattern at a decay rate of 30 ticks per input, meaning that theoretically the buffer will attempt to match the last intentional input in the context of the values of the previous inputs, as opposed to the first matching command pattern, intentional or not. With this more intuitive reading of 22X is also a more realistic reading for charge commands, where the buffer will cache the time spent holding the initial direction and perform a check when the following direction is pressed or if the stick returns to neutral.

Aside from this I made some minor changes based on previous feedback as necessary. Redirect works the same as the initial build where pressing forward won't turn you around simply because this was an aspect in source Wild Ambition, so whether or not that was actually a good decision on SNK's part will be determined in the future :p

Made some changes to some 5XXX boxes, but I ended up looking to Kn and GM as my base sources in terms of compatibility so there might be just inherent issues when mixing characters/gameplay styles. Juggling really isn't a factor in the games I'm building upon outside of CH situations so this is just deciding whether or not we believe in universal standards or following those made by the sources that interest us.
Re: Sacchin (for 1.1)
#10  July 05, 2022, 04:53:54 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
This also means that where mugen identifies the first matching input and executes it, my buffer identifies the last matching pattern at a decay rate of 30 ticks per input, meaning that theoretically the buffer will attempt to match the last intentional input in the context of the values of the previous inputs, as opposed to the first matching command pattern, intentional or not.
My thought reading this was what about doing Shoryuken with F, QCF? In the latest version 421B is extremely hard to pull off.

Quote
Redirect works the same as the initial build where pressing forward won't turn you around simply because this was an aspect in source Wild Ambition, so whether or not that was actually a good decision on SNK's part will be determined in the future :p
I still think it's a bit janky, because in order to block P2 has to do anything but hold the block direction. In Wild Ambition, was it meant to turn P2 on his back or to set up (fake) unblockables?

EDIT: I just realized P2 can get around it by holding DB, which is what one would normally do anyway. Then it's not such a big deal.

New thing:
- The custom meters are hidden by stage foreground
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Last Edit: July 05, 2022, 05:18:36 pm by PotS
Re: Sacchin (for 1.1)
#11  July 06, 2022, 12:27:22 am
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
the base form of the reader for DP reads like this
Code:
;0F 1B 2D 3U 4DF 5UF 6UP 7DB
triggerall = (fvar(4) > fvar(2)) && (fvar(4) > fvar(0))
trigger1 = fvar(0) && fvar(2) && fvar(4)
So it wants to check for the DF being active after the first initial inputs and then it will OK it for the buffer to assign the DP as the active command to check for when a button is pressed.

In situations where there is a F HCF or F QCF, the retriggered forward motion would make fvar(4) > fvar(0) return false and cause QCF to return true
Code:
;0F 1B 2D 3U 4DF 5UF 6UP 7DB
triggerall = (fvar(0) > fvar(2)) && (fvar(0) > fvar(4))
trigger1 = fvar(2) && fvar(4) && fvar(0)

The bigger question would be trying to identify inputs like the devs did when they made the game, where they expected that the player would not be totally perfect and they would attempt to correct this like F, DF
Code:
trigger2 = fvar(0) && fvar(4)
So if it's tight I can easily add some more flags that can "correct" inputs, but I think the major issue is the question of how many possible corrections should exist before it begins to override the actual inputs with shortcuts and put out the wrong move

I wasn't having issues on my stick and keyboard but I don't have a pad and that could be an issue with inputs. I think I'll extend the duration beyond 30 ticks for the duration of the active input because it does seem rather strict. The number is essentially arbitrary at the moment.

I'm throwing in a config in the next update for some of the fluff, so I'm going to add in a toggle for the input reader being mugen vs the custom.


As for the meters I do need to double check with some other stages, I tend to not like ones with a lot of foreground in general. Elecbtye should have given us more sprpriority layers to work with :p
Re: Sacchin (for 1.1)
#12  July 08, 2022, 04:51:15 am
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
Spoiler: 7/7/22 (click to see content)

Added a config file which allows for you to skip the color menu and also toggle between the two input parser systems: custom and mugen
Code:
trigger1 = (var(56) := 0 )||e ; color select? 0 = On, 1 = Off
trigger1 = (var(48) := 0 )||e ; Input parser type? 0 = Custom, 1 = Mugen

Buffer length is longer for the custom input reader.
Re: Sacchin (for 1.1)
#13  July 09, 2022, 02:03:31 am
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
Hotfix for some double inputs I was catching today + necessary ontop parameters for most of the bar
Spoiler: 7/8/22 (click to see content)

I think this character is realistically 99-100% done when it comes to character specifics so if there are any other remaining issues I can address those while working on any other character. I'll throw the final when I reorganize everything in a future release on my site so when I make updates all the modular, system stuff can be downloaded for updates instead of the whole character.
Re: Sacchin (for 1.1)
#14  July 09, 2022, 02:41:27 am
  • *****
    • tehwii@gmail.com
I really love the design concept. What sort of plans do you have for the gameplay mechanics? Will it just be a "style" of character or do you hope to do a full game project?
Re: Sacchin (for 1.1)
#15  July 10, 2022, 01:14:31 am
  • ***
  • Non est hoc propter hoc sed propter est hoc
    • USA
    • doubletrend-zeta.neocities.org/
I want it to be a fullgame style project but that's a lot of work, so realistically I'm focusing on characters and gradually it might take form. That and my code doesn't seem compatible with ikemen at the moment, which was going to be where I was planning on moving to at some point.

I think it's hard to see the mechanics in a vacuum, but I want to maintain the certain feeling and momentum found in Real Bout while also putting forth a hypothetical 2000s wonky title that SNK was putting out in the atomiswave/ps2 era, sorta like a Fatal Fury on the dreamcast aesthetic.
Last Edit: July 10, 2022, 01:17:35 am by Bannana