Template talk:MoveData

Discussion page of Template:MoveData
Revision as of 23:26, 3 February 2021 by Hating Mirror (talk | contribs) (→‎Alternate design)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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)

Although

That's a lot of info to expect a person to fill up for every single move, Lei has 174 individual moves, with a lot of them being strings, can you imagine how many entrties that is. That's a full time job to just do it, and then there might be secret balance changes specifically to those +25a (+36a) that you just can't keep track of. And it doesn't seem to be a database, like RBNorway's FrameBot is, just text on a page, unconnected to any other page

It took me about a week to fill in Lee movelist, but most of that time was the notes section (particularly all the delay timings), range, and tracking values. Just getting the frame data takes less than a minute per move. It would take someone more time to decide "is this KND or CS or Launch... do we write DMG if there's guaranteed damage?" for knockdowns (e.g. figure out what you would write for Lee's ws2,3 on hit) than to just copy the frame data straight from the game. In any case, it's not expected that one person fill in everything, nor that they do it all at once. You can leave stuff blank if you don't have time to measure it. And technically speaking it is a database, just not a strongly typed one. (RBNorway's is not strongly typed either.) RogerDodger (talk) 04:54, 24 January 2021 (UTC)

Alternate design

I made an alternate design for the movelist format.

  • Having signifiers next to each metric removes the need for the reader to familiarize themselves with the formatting.
  • Having each metric lined up also improves readability.

Would be perfect if it were possible to change the background color for the next 2 rows, every 3 rows to a lighter shade of black/dark grey; to visually distinguish individual moves, especially to split up one move's notes from the next.

Not sure about the order of:

Damage Crush Range Tracking

What do yall think? User:Oldmanwang

Not sure how this is an improvement over the current layout. It's still a multi-row layout, except without any of the visual cues and graceful degradation (try viewing the layout with empty values or on mobile). Comparison:
# Name Level Damage Crush Range Tracking Notes
Input Startup Block Hit CH Recovery
1 Jab h 7d 2.03 5L 7R Recovery is very slightly off-axis to the right, changing the tracking of follow up moves
1 i10 +1 +8 r17
4 Left Right Combo to Revolution Zwei h,h,m,h 7,9,14,23d
  • 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
1,2,2,3 ,i21~23 -3 +17a (+8a) r31
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 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
(Only 2 entries cause putting the data in with the table is a real pain.) If you want to continue experimenting with new designs, you should do it as a template. There's no way we're going to have people writing tables out manually. If it uses the same parameters (which it probably should) then you get test cases for free. (Just copy the Lee movelist to another page and find+replace “MoveData” → “MoveData/sandbox”.) RogerDodger (talk) 10:02, 28 January 2021 (UTC)
Oldmanwang: Ahh, now I see the problem to be solved. Still not sold on the current design, will look into making a better one.
Moved your design to Template:MoveData/testcases. See Template_talk:MoveData/testcases for discussion. RogerDodger (talk) 15:32, 1 February 2021 (UTC)


What's the purpose of the id parameter? Is it so we can make links that go directly to that move's data? If so, how do you make a link like that? Oldmanwang

It would be nice if we could link directly to a move's data, not sure how possible it would be though.--Psylence (talk) 22:13, 3 February 2021 (UTC)

Afaik the functionality doesn't yet exist, but it might come as the full database for the whole website maybe at some point Hating Mirror (talk) 23:26, 3 February 2021 (UTC)