[Concept Idea] Global Combo System

[Alblaka]

I've recently considered whether some sort of 'LFE-wide Combo API' would be of rational use.
The idea is to find a common ground, much rather a defined layer, of y-values, which then can be used by any character to request &| accept combos.
You can find a basic (and local) implementation of this concept in my project Ninja Tales, where every of the four Ninjas adresses a special body on y-level f.e. 3900000 (via casual itr:kind8 interaction) and can, regardless of who actually spawned said body, perform his part of the combo, basing his own actions onto a set of y-bdys in the range of 3900000-3920000. Of course this implementation is VERY rudimentary.

However, if we were to take the concept, refine it and then define it as an 'official API', we could essentialle given DCers a base frame to permit their characters to perform combos with other characters that aren't even finished by the time they release their characters.

The main issues I see are
1. creating an API (=a set of y-bdys meant to act as a 'messager' in between characters) that is versatile enough to be useful to any character, but as well 'small enough', so it can actually be implemented in < ~40 frames. This implies that, if we define an API with too many different possibilities, a single character cannot support all of them (defying the use of this global API), but if we define it to limited, the moves will be limited as well (take Ninja Talex as example: All moves consist of one character carrying the second one around and ordering him to perform a semi-airborne attack).
2. getting people to actually use this, which requires the API to be well-explained and easy to use.


An example form of the API content would be something like

y: 7770002000 = Character A ready to carry another character (B) on his back
y: 7770004000 = B confirms he found A, proceed to x6000 and start moving
y: 7770006000 = A aknowledged B's ok, starts to move around, B follows via this body
y: 7770008000 = A requests B to launch the combo attack

I found working in the range of x...y*2 000 area quite useful, as you can define itr's with h:1000 without intersecting with other special bodys (which again means the actual y coordinate of a character is quite irrelevant, in LF2 you barely exceed the 1000er mark.


Are there any suggestions/critique from side of the DC-experienced members of this forum?
Would you, as either 'old' or 'new' DCer use this API if it were to be completed?

[YinYin]

Yes,
however I want to see some improvements over your Ninjas.

First of all find a way to stop opponents from teaming up.
And second: add one or two extra carrying states to be used for the carrying character tilting forward or backward (running/stop running/throwing preparation).

edit: pDCer you still did not state any reason why you wouldn't use it. Thus you didn't express your view at all, you just said no because you can.

edit: Also I just noticed you did not state the exact actions/alignment this new stuff would use.
I kind of like the carrying teammate concept and by the nature of itr kind 8 it also is the best option.
If it doesn't make the whole thing too big I would give the creator of the carrying character two options: either hurling the teammate forward like a boulder/crate (into the enemy crowd)
or less farther but instead higher (maybe just above 45°).
That means the thrown character needs two starting actions which will always perform these direction vectors. After that the creator can decide whether the character will perform the same action on both angles or perform different ones.
So with a different teammate you can get a different action. (this can make some more or less of a good fit)

[Alblaka]

As I've said, the Ninja's are nothing but a prototype of that technique. The API could contain multiple different combo variants, f.e.
-carrying a teammate
-having a teammare run behind you
-turning the teammate into an invisible object (hammer space, magic, blargh) or into a projectile (Imagine Firen combos with Freeze by turning freeze into a burning ice projectile, lobs him into the enemy and upon contact there's a Firzen-style Explosion with Freeze reappearing within)

Regarding a way to prevent enemies from comboing up... Are itr kind:8s affected by rest values? One could add a itr kind 0 with the special body, dealing no real damage, but sending the 'enemy combo partner' to the injured frames, as well as containing an arest: xy to prevent the kind 8 from launching in the same frame.

edit:
Btw, do we actually know the limit, y-wise, LF2 can handle?

[YinYin]

Running behind would need a reasonable x offset which really isn't that practical with itr kind 8. Also it would feel weird seeing your character still run around without being able to control him - the carrying makes more sense there without control. Also it would allow the transformation into another object too - that really depends on how the carried character is coded.

Regarding a way to prevent enemies from comboing up... Are itr kind:8s affected by rest values? One could add a itr kind 0 with the special body, dealing no real damage, but sending the 'enemy combo partner' to the injured frames, as well as containing an arest: xy to prevent the kind 8 from launching in the same frame.

I don't know whether it can use the characters attack rest. I think it won't because it doesn't make much sense for this one. Alternatively for normal multiple itrs only the first one inside a frame acts if it overlaps. So we could have two with the same area; the first one hitting opponents without any effect (not even injured) and the second one is the kind 8 start, which might not act in case the first one does.
I will try this right away on your Ninjas and edit this post.

edit: okay I did get it working, but the results on this can be a little weird.
Because of the offset that the moves can be started with it wasn't enough to put an enemy itr check to the first frames of the active side. This did work when the passive side started and the active one followed because only the first itr hit. If the active side started and the passive followed however the kind 8 still acts sometimes because the first itr check may have already run while the passive has not performed the move yet. So I also added this check on the second itr kind 8 instance of the active combo. This now results in the character getting picked up, but (next: 180) falling down again due to the itr check.
All this takes a little too long and looks ridiculous. So after all it can be done that way, though we need to condense it a lot.

Btw, do we actually know the limit, y-wise, LF2 can handle?

I suppose it's 31^2 aswell (positive and negative direction).

[Alblaka]

It's not hard to create an x-offset by a generalized amount (f.e. 100), it's pretty much the same with using an y-offset for carrying ^^
Though your point about 'it's strange to have your character running without control' is valid.
What do you think about the idea of turning the character into a 'hand-launched' (gesture, summoning, but not exactly the 'throw' of an heavy object) projectile?

Regarding the problem of not picking up enemies, we could add another layer of ready-ok requests, which means the characters won't get 'picked up'in the first round of itr8 interaction, but only in the second. Downside is another delay of 2 or 4 ticks (not sure how fast kind 8 can act) and the characters will be moved to the same xz coordinate (which may or may not be very noticeable).


Btw, as of now, the 'combo's merely consist of one character performing an attack based upon a second's movement abilities.
With a few proper protocols, we could refine this into some 'real' comboing. Example:
Character A starts a Combo with Character B as backup.
A runs towards the enemy, B auto-follows.
Upon contact, A starts a basic melee combo and hits the enemy upwards. A then uses a ybdy to order 'Fire AoE Sidewards' to B.
B does some AoE move, whilst A teleports into the enemy (ensuring, regardless of what B does, the combo will continue) and perform a uppercut.
A orders B to 'fire AoE upwards' as a finishing move.

The implementation of the combo is obviously all done in Character A, whilst the implementation of the generalized 'Fire AoE xwards' would be part of the API and would depend upon how it was implemented in B. (F.e. Firen would use explosions / fireballs, freeze would use ice stuff, davis may perform strafing combos).

Trivially, not all characters can support any sort of order and the API would need to deal with that, f.e. by a layer of confirmation:
-A checks order XY from B.
-B confirms the order.
-A starts doing something and/or orders XY to B
or
-A checks order XY from B.
-B doesn't react (order and according ybdy not implemented)
-A waits for ~3 frames and then realizes B doesn't support order, combo must be altered or aborted.
>>> The downside of this is, that some characters wouldn't be able to combo at all, f.e. if there is a Davis always requiring an assistance uppercut, he couldn't do proper combos with characters not supporting said move. But one could claim this would be an issue of a lazy DCer not implementin said move to his character (or a lazy DCer not giving Davis a set of alternative combo's).

[Silverthorn]

Btw, do we actually know the limit, y-wise, LF2 can handle?

I suppose it's 31^2 aswell (positive and negative direction).

Not the other way round?
Pretty sure that all coords are stored as signed 32bits.

I personally am quite fond of that idea. What I am most afraid of, though, is a potential clash of layers. What if two people claim y: 70707000 as theirs? Therefore, reservations?

Also, I guess, one wouldn't want to offer too many combo-possibilities, considering that LF2 gets highly unstable with a multitude of tags (and, once again, I forgot the exact limitations on itr's and bdy's).

Anyways, assuming this works just as intended, this could be really awesome. Yes from me

[Alblaka]

Oh right, wanted to mention the 2^31 part as well, but got carried away by actually writing about content :P

The 'clash of layers' is a problem 'right now' as it could happen any time. Even two of my own characters clash (though I don't entirely remember who, one was of Trio Mortale (=OLD)). By using this well-defined API, we merely reserve a few chosen layers for the combo system.
But je, even if you go with my 'wasteful' way of using 2000er ranges, you can still have 1250 layers... And those are only the ones with POSITIVE Y values.

Afaik it was about 10 bdys & itrs in a single frame. It won't be an issue to write a protocol that does not permit to ask 20 questions at once, though... F.e. there would be only 1 layer (1 itr and bdy) which is used to determine whether there is a combo partner at all. In the next frame there will be a couple more etc etc, branching out and determining what can be done where by whom (depending on the API's complexity). I doubt we will run into an overload of tags :P


edit: I stand corrected: 5 itr's or the exe will crash upon loading the dat file.

[YinYin]

It's not hard to create an x-offset by a generalized amount (f.e. 100), it's pretty much the same with using an y-offset for carrying ^^

but the shadow D: I wouldn't want to simulate it

What do you think about the idea of turning the character into a 'hand-launched' (gesture, summoning, but not exactly the 'throw' of an heavy object) projectile?

I don't exactly understand.

Regarding the problem of not picking up enemies, we could add another layer of ready-ok requests, which means the characters won't get 'picked up'in the first round of itr8 interaction, but only in the second. Downside is another delay of 2 or 4 ticks (not sure how fast kind 8 can act) and the characters will be moved to the same xz coordinate (which may or may not be very noticeable).

nah, I prefer the itr prevention I already got as it runs in parallel and can circumvent the alignment.

Btw, as of now, the 'combo's merely consist of one character performing an attack based upon a second's movement abilities.
With a few proper protocols, we could refine this into some 'real' comboing. Example:
Character A starts a Combo with Character B as backup.
A runs towards the enemy, B auto-follows.
Upon contact, A starts a basic melee combo and hits the enemy upwards. A then uses a ybdy to order 'Fire AoE Sidewards' to B.
B does some AoE move, whilst A teleports into the enemy (ensuring, regardless of what B does, the combo will continue) and perform a uppercut.
A orders B to 'fire AoE upwards' as a finishing move.

Well, usually good players are capable of doing these things with the given moves. Sometimes with combinations you as the creator would have never even thought of and/or possible.
My point against this is that it sounds too much like an all pre scripted combo thing that's more fun to watch than play. But we are not directing a movie here.

Btw, do we actually know the limit, y-wise, LF2 can handle?

I suppose it's 31^2 aswell (positive and negative direction).

Not the other way round?
Pretty sure that all coords are stored as signed 32bits.

That's what I meant. Even tho we are able to use the negatives above ground I prefer keeping such things below ground.

What I am most afraid of, though, is a potential clash of layers. What if two people claim y: 70707000 as theirs? Therefore, reservations?

that's the point of this thread.


Okay, in conclusion I would like to go with this:

• Teammates can pick each other up upon performing certain special moves on the same spot.
  
• The carrier will transport the carried in some kind of a heavy object cycle. (the exact controls will depend on the character, using directional keys and/or D/J)
  
• The carried will be displayed in one of three frames. (straight or tilted forward/backward)
  
• The carried may perform quick actions with D/J/A while carried. (maybe even dismounting - jumping away from the other could bring the carrier into broken defense frames as a result)
  
• The carrier can throw the carried at two different angles: normally forward or holding back to throw him higher.
  
• At the start of the two throwing actions (angles) the carried can decide to fly up or down on z-axis.
  
• The actual action performed by the thrown character may differ depending on the angle.
  

edit: By quick actions for the carried character I mean stuff like healing the partner, creating a shield, charging up, dropping bombs, shooting projectiles.
Really anything that won't require a long animation or no animation at all. Because we can only animate via itr kind 8 cycles to not have the character drag behind.

Another reason why I would opt against anything more complex or different from that is that this will already take quite a few frames and time to perfect. Also it's the most general approach that any character can work with because all you need to get started is heavy object actions, which every character has anyway.

[Alblaka]

Let's see which sort of protocol messages I can figure out out of my head...

- I offer to be the carrier in a combo move.
- I accepted the carry offer and are on your position, ready to combo.
- I'm standing/moving somewhere in a carry-pose. This bdy is displayed behind my back, if you detect it in front of you, you need to turn around.
- I'm standing/moving somewhere in a carry-pose, stand straight, 80 px above ground.
- I'm standing/moving somewhere in a carry-pose, tilt forward, 80 px above ground.
- I'm standing/moving somewhere in a carry-pose, tilt backward, 80 px above ground.
- I'm in a carry-pose and teleporting in 1 tick, perform state 400.
- I'm in a carry-pose and teleporting in 1 tick, perform state 401.
- I dismounted from the carrier.
- I throw the carried at a shallow angle, perform attack.
- I throw the carried at a high angle, perform attack.
- I aborted the combo, jump/fall down.

I've marked the few messages that could be sent by the carried' character, everything else are orders/instructions/informations from the carrier.
Those are pretty much the cases you mentioned + the necessary additional ones (f.e. turning) and two messages for teleports (though we may can scrap the ally teleport), as this is a legit way of 'moving'.

Did I forget/mistake anything?

What do you think about the idea of turning the character into a 'hand-launched' (gesture, summoning, but not exactly the 'throw' of an heavy object) projectile?

I don't exactly understand.

Both characters take a pose, character B turns into an fuzzy energy thingy animation and disappears, giving A a signal. A performs a flashy charge up animation and then points his hands forward (or performs a casual gesture like Firen's D>A, Freeze's D>A, etc). B now performs some sort of projectile attack (maybe, but not necessaryly) ending with him reappearing in the midst of the impact location (in a cloud, in an explosion, or maybe the projectile turns into the character right upon impact and instead of dealing direct damage, the character starts a melee combo).

Aka, A converts B into a projectile and launches him at the enemy.
One could even add protocol bdys to permit A to influence B's attack. F.e. A could spawn a few invisible T3's, which can react to orders along the lines of "need explosion here", which can be dropped by B at positions designated by B.

Example: A is Firen, B is Davis.
Davis turns into a blue energy animation and disappears, Firen performs a launch animation and spawn a hidden T3. Davis flies forward as a blue projectile. Upon hitting an enemy, he turns back, gives the hit target a beating, then spawns a T0 bdy behinjd the enemy, causing Firen's hidden T3 to create an explosion at that spot.
Just to realize the hit target was a stone... but je, combo successfull.

[YinYin]

I don't know whether you are missing something - I would have to try and make it step by step myself to check that ...
You sure can keep the teleports in.

About the alternative launching method:
It's much more specific and may work with less characters or require more careful sprite work. Also I'm not a big fan of turning characters into energy.
But I like how the launched character is charged with an attack from the launcher. (The explosion in that example)
This could be added to the normal crarry/throw thing too.

edit: I would like it to be visible during the throw already though. Not just appear out of nowhere at the end.