Template talk:MoveData

Discussion page of Template:MoveData

Why isn't this just a normal table?

A lot of people's reaction to—

Name
Alt

Input

Hit level
Damage
Range
Left Tracking
Right Tracking
Block
Hit
CH
Startup
States
Recovery
Notes
Jab

1

h
7
2.03
5
7
+1
+8
i10
r17
Recovery is very slightly off-axis to the right, changing the tracking of follow up moves
Left Right Combo

1,2

h,​h
7,​9
2.83
-1
+5
i10
,i12
r20
  • Move can be delayed 4f
  • Jail from 1st attack
  • Transition to r21 MS with f~n
  • Transition input can be delayed 6f

1,​2,2

h,​h,​m
7,​9,​14
-13
-2
i10
,i20~21
r31
  • Move can be delayed 5f
  • Input can be delayed 7f
  • Combo from 2nd CH with 5f delay
Left Right Combo to Revolution Zwei

1,​2,​2,3

h,​h,​m,​h
7,​9,​14,​23
-3
+17a (+8a)
i10
,i21~23
r31
  • Tailspin
  • Input can be delayed 17f
  • Move can be delayed 13f
  • Combo from 3rd hit with 8f delay
  • Transition to r37 HMS with 4
  • Transition input can be delayed 29f

—is that this is a big mess, and why isn't this just a good ol' fashioned table? So to start with, here's what this data would look like as an ordinary table:

Input Name Hit level Damage Range Startup Crush Recovery Block Hit CH Left Tracking Right Tracking Notes
1 Jab h 7 2.03 i10 r17 +1 +8 5 7 Recovery is very slightly off-axis to the right, changing the tracking of follow up moves
1,​2 h,​h 7,​9 2.83 ,i12 r20 -1 +5
  • Move can be delayed 4f
  • Jail from 1st attack
  • Transition to r21 MS with f~n
  • Transition input can be delayed 6f
1,​2,​2 h,​h,​m 7,​9,​14 ,i20~21 r31 -13 -2
  • Move can be delayed 5f
  • Input can be delayed 7f
  • Combo from 2nd CH with 5f delay
1,​2,​2,​3 Left Right Combo to Revolution Zwei h,​h,​m,​h 7,​9,​14,​23 ,i21~23 r31 -3 +17a (+8a)
  • Tailspin
  • Input can be delayed 17f
  • Move can be delayed 13f
  • Combo from 3rd hit with 8f delay
  • Transition to r37 HMS with 4
  • Transition input can be delayed 29f

Now, personally, I think that alone answers the question. But if not...

If you're viewing this on a monitor, then this might not actually look that bad to you. For the first time using it, it's almost surely easier to scan, because single-row tables are far simpler and you've read plenty of them before.

Of course, the simple table is actually bigger and has tonnes of dead space and even with all that dead space our poor name, input, hit level, and damage fields are wrapping.

The culprit is that pesky notes section.

“Just cut down those notes then! Why don't you just write NCC, NC, S!, KND, HC, SH, RC, OCh etc. like my pappy did back at the TZ farms?” Well, because they just aren't good enough.

  • You're forcing readers to remember even more notation.
  • You're forcing everyone to decide on what notation to use for every little thing (this is a huge headache).
  • How are you describing half of what's there in any kind of meaningful notation?
  • What happens when someone wants to write something in the notes that you didn't think of some notation for? They just leave it out?

The whole point of the notes is to be a free form field. It needs some space. There's a lot of weird stuff in Tekken, and sometimes you need to use words to describe that stuff. Notation isn't good for handling edge cases.

So our notes are gonna be taking up a decent amount of space anyway.

Once that's accepted, it's just a matter of filling up the remaining space effectively. Instead of the data being all in one row, it can span across multiple rows. We can use various visual cues to create a visual language that when learned, makes it easier to scan the table for what you're looking for:

  • Input is extremely large and with a line coming out of it, making it the focal point, since this is the main thing you're scanning for
  • Name is paired with input but is much smaller, since it's more common for people to identify moves by the input
  • Hit level and damage, being the two other fields that can get very long, are paired together
  • For strings, we emphasize the input, damage, and hit level that this move actually represents
  • The fields that are specifically about frames are grouped together and subgrouped by whether it's frame advantage or the attacker's frames
  • Tracking scores are visualized into a line that gets longer the more tracking there is

And it has the really, really big upside that you can read it all on your phone. The distinct visual presentation for each field lets it be reorganized and still read the same way.

But it does take some getting used to.

Now, this specific design is far from perfect, and anyone capable of improving on it is welcome to try. But its problems are not that it's not just a simple, 1-row table, because that just... doesn't work.

Why all this +17a (+8a) crap?

Most frame data just lists any kind of knockdown as KND, Launch, JGL, CS, or something similar. This is pretty weird to do, because shouldn't the frame data have the, you know, frame data, not visual information? Nobody needs to lookup what kind of knockdown a move does. It's pretty obvious.

On top of that, doing that doesn't tell readers:

  • Whether the knockdown can be teched or not
  • How much oki there is
  • How much time there is to connect with a pickup
  • What combo can be done

By being specific about the frames, and linking to the combo page when a combo exists, we answer all the relevant questions without having to define 20 different acronyms for every type of knockdown in the game.

The reason people didn't do this before was probably that getting this data was really hard. But you can get it all from the builtin frame data display now, so, you know, maybe we should use it?

14 columns? Just show the startup, block, and hit frames!

—and put the crush frames into notes, and don't bother with tracking scores or range or...

Okay, well that's just giving up. There's tonnes of places out there that already list all this rudimentary frame data. We're aiming for a bit more than that. RogerDodger (talk) 17:39, 22 January 2021 (UTC)