Ever tried Lucid Chart?

16 hours ago, Dante3085 said:

3. Timing(Type: float or int): A time window for a specific Input of a ComboNode.

What do you mean by a window?

What is the problem you're working on? I don't mean the subject of this topic, I'm talking about some general "advice appreciated", doesn't quite describe what you're trying to achieve. If you want to, tell us which graphics engine you are using if any, what specific advice you need, what you're currently working on etc.

You can always, if you'd like, use ComboNode graphs per combo/combo group of a character if the combo structures get really complicated.

2 hours ago, Acosix said:

Ever tried Lucid Chart?

Yes, I have worked with several Diagram software(UML stuff). I often find them a bit annoying to use, so I just like to draw by hand or do it myself another way.

Quote

What do you mean by a window?

Example: I push square and the Character performs a "Left-Jab". After that, for a short amount of time (the time window), I have the opportunity to press square again, so that the Character performs a "Strong-Jab". If I fail to press square again during that short amount of time, the Character returns to his initial state.

Quote

What is the problem you're working on? I don't mean the subject of this topic, I'm talking about some general "advice appreciated", doesn't quite describe what you're trying to achieve.

Do you mean a specific programming problem ? My basic problem is just finding satisfying model that can easily be translated into an implementation (basically high level pseudocode). Other than that, I am not shure what you mean.

Quote

If you want to, tell us which graphics engine you are using if any, what specific advice you need, what you're currently working on etc. 

I am using C++ SFML and my project is not much more than the title says. I am planning to visualize that ComboSystem with an AnimatedSprite implementation. Currently I just have "Translating numeric input from a PS4 Controller to enum form (PS4Input::SQUARE, ...)" implemented. So there is not much Code to show. The only specific problem I had until now is something related to measuring time with SFML. So I am not shure if this is the right place to ask about that.

An edge (an arrow) going outward and inward of the same state is usually named a self-loop (as in, the state loops to itself). The extra rule that you impose ("may only be used once") is gernerally solved by adding a new state, like

That is, from Left-jab1 you can move further to Left-jab2, but not any further using the rectangle button. This avoids the special rule, which means less work to implement.

I also moved states around a bit so lines don't cross, and I left out all the "don't care about timing" intervals.

EDIT: I guess you also have to left go of the rectangle button in-between both jabs. Likely the player isn't fast enough to let go before the first button test cycle in Left-jab1, so you may want to relax the rules somewhat, and insert another state where the player is not pushing the rectangle button?

53 minutes ago, Alberth said:

That is, from Left-jab1 you can move further to Left-jab2, but not any further using the rectangle button. This avoids the special rule, which means less work to implement.

I also moved states around a bit so lines don't cross, and I left out all the "don't care about timing" intervals.

That's a great simplification!

Quote

EDIT: I guess you also have to left go of the rectangle button in-between both jabs. Likely the player isn't fast enough to let go before the first button test cycle in Left-jab1, so you may want to relax the rules somewhat, and insert another state where the player is not pushing the rectangle button?

You mean letting go of the previously pressed button would first lead into a neutral state in which the real check for the next part of the combo would take place ? I guess that would also require the following...

1. Look at how long the button is held for and return to start state if it is held for too long.
2. If button is released in time, go to neutral state and check for next input.

I'd simply test for not having the rectangle button pushed:

(note I left out the jumps to the Right-jab state here!!)

1 hour ago, Alberth said:

I'd simply test for not having the rectangle button pushed:

(note I left out the jumps to the Right-jab state here!!)

But if i only test for the rectangle button not being pushed, you could stall the combo indefinetly, right ? I need to keep track for how long it's pushed. Maybe you actually accomodated for that in the diagram, since you put "0..1.3" beside the crossed rectangle button. I am not shure.

To me, "0...1.3" means you have to detect not pushing the button within 1.3 seconds. I see such time intervals always from the moment you enter a state, but maybe you have other ideas there.

I started seeing problem with the previous solution (without Neutral inbetween) with the idea "wait a moment, if I press the button and then hold it, I will always end up in jab2, since you'd detect the button again in 0.6 seconds". Then it hit me that you also detect too early, so keeping it pressed (or rather not letting go of it fast enough) would detect fail immediately in jab1, since you're not supposed press too early. That in turn lead me to believe you need another state inbetween to detect letting go of the button.

Thinking about it again, my assumption was you detect button state, as in "on" means "it is pressed now" (no matter when in the past you started pressing it). Maybe it's better if you detect the act of pushing it, the change of the button state from off->on only, ie the rising flank. You cannot have 2 rising flanks without letting go of the button first, but the change on->off in button state is further ignored.

If a rising flank means "button pressed" in the state machine, 2 button detections of the same button means the act of pressing that button twice, which means there is no need for the neutral state.

EDIT: if I press the cross button in the Jab2 state what should happen? The reason I am asking is that with flank detection suggested above, you detect a button press for one cycle only. So if that detection leads to going back to the starting state, the next cycle there is not cross button detected, so it stays there rather than (the other option) give the opponent a kick.

I would just reorganize the structure template to improve the wanted algorithm.

I'll try to improve(suggest a better) graphs.

7 hours ago, Dante3085 said:

Example: I push square and the Character performs a "Left-Jab". After that, for a short amount of time (the time window), I have the opportunity to press square again, so that the Character performs a "Strong-Jab". If I fail to press square again during that short amount of time, the Character returns to his initial state.Do you mean a specific programming problem ? My basic problem is just finding satisfying model that can easily be translated into an implementation (basically high level pseudocode). Other than that, I am not shure what you mean.

You are not being specific enough, at least what regards me. I can't give you some advice without knowing what you need advice on.

A problem here means a problematic inside a project - you present to us what are you trying to do currently...

Quote

Fighting Game Combo/Input System (Looking for Feedback)

Impressive: you are making a fighter game. But it's a bit hard to understand if the game is 2D or partly 3D, graphics-level,...
Basically, you're looking for feedback - but towards what? The combo system? Input system? Both(combo/input system)?

And e.g. what would you need to improve/add-to your combo system? Better graphs? Better combos? Better structure? More variety?
Better first graph?

Well my question was basically, if you need advice anyways: Do you keep ComboNode objects per-character? Or just random papers?
This is probably your personal stuff, so I'll try to be more specific.

Why do you keep a ComboStateMachine per each combo? Shouldn't a StateMachine actually represent combo making "machine" instead making one per a specific combo?

I mean you already have a combo tree per each character. But why so many ComboStateMachine-s? 

What I'd suggest would be something like:

class ComboStateMachine
{
	CharacterType char_type_check;
	//check all of the given character type combos
};

This would omit loading entire nodes for each combo.

If I got you correctly, you are doing something like:

class ComboNode
{
	int combo[5];
	//ie. 1= triangle, 2=circle, 3= cross, 4 = rectangle
};

class Character
{
	ComboNode per_character[20];
};

I think there should be no minimum timer (like 600 ms), but none (0 ms) as you can't quite measure exact player reflexes, even a good exemplary average would be just an estimation of a required minimum time.

Also if you're trying to make timed combos, not the player does not the exact numbers and even in your case when you do, it's hard to hit the actual time. As it is not in seconds, but fraction-ed ones.

Quote

I am using C++ SFML...

By the way thumbs up for making a PS 4 game in C++  I didn't know SMFL supports the PS 4 platform.

9 minutes ago, Acosix said:

You are not being specific enough, at least what regards me. I can't give you some advice without knowing what you need advice on.

The problem being discussed afaik is converting controller key input to playing kick and jab animations in the game by the player-controlled character. Ie how do you decide to play a double jab animation?