Open JOELwindows7 opened 8 years ago
This shall not be disagreed. I want the closure is when they agree!
They're way ahead of you, pal – see #740.
Reading + thorough searches are your friends – get to know 'em!
This is covered by #740, but I'm going to leave this issue open since that's an omnibus-type planning issue and this is specific.
I want game types to be broken up and scattered. All stepstypes are selectable if the player has a noteskin and wants to select them. Scoring rules move to their own files.
Here's what I've had kicking around in my head for the last couple months.
Keys get broken up into menu and gameplay groups. Menu keys are used for menus, and there is only one set of menu keys per player.
Gameplay keys have a different set for each stepstype. If no mapping is set for a stepstype, that stepstype is not selectable for gameplay.
Gameplay keys need to be per-stepstype because someone could want to play solo (L, LU, D, U, RU, R) as w, e, r, u, i, o, and dance (L, D, U, R) as e, r, u, i.
The engine should allow selecting any stepstype for gameplay, as long as there is a noteskin for displaying it and the player has keys mapped for using it.
Themes can then decide to filter out stepstype based on conditions, and allow the player to decide what is filtered out.
A scoring config should contain a version number, per-column flag, basic info for the size of the timing windows, a dance point value for each judgment, combo values, and life bar values.
A simple number or string to use to decide whether a condensed score actually matches the scoring rules in use, or needs to be regenerated from the full score.
Whether notes in different columns at the same time are judged separately.
TimingWindowScale goes away.
Any number of timing windows are allowed, up to +-2 seconds. (it's not really a music game if you can be a second off, but I'll be generous)
Timing windows can be specified either as a width, or as separate positive and negative offsets. (Someone claimed Pump has asymmetric windows because it's designed to allow the player to fall behind the steps)
An amount for each judgment to add to the combo/life. A negative combo value breaks the combo.
To allow converting between different scoring rules, scores will be saved in more detail. Three major variants of saved score data: Replay, Full, Condensed
Timing data in a score is quantized to the nearest millisecond to save space. Quantizing to a millisecond means we only need two bytes to store a timing number that is relative to a step, and allow faster conversion from Full to Condensed when applying a different scoring config.
Contains full data for playing back a playthrough of a song.
For taps, the number of milliseconds off it was hit is saved, with a special value reserved for a complete miss.
For holds, each press and release between the beginning and end of the hold is saved, quantized to a millisecond. Two bytes means 65 second holds are supported. A flag value could be used to switch to four byte mode, allowing longer holds.
A normal replay only stores one tap entry for each row. If the perkele flag is set, then each column is handled separately.
The tap data from a Replay is compressed. Notes are grouped by how far off they were hit. (like the graph at the top of this score screen: http://i.imgur.com/v9znofZ.jpg)
This means that saving tap score info only requires 50 to 100 {offset, count} pairs. Multiply by the number of columns when in per-column mode.
A condensed score is what we have now. The count for each judgment, a percentage, and a dance point total.
A condensed score can be generated from a full or replay score by applying a scoring config. This means that a full or replay score can be converted to any scoring config, which makes is possible to compare playthroughs that were performed with different scoring rules. (except for combo/life bar data, which hardly matters)
The player picks what mode they want scores saved in by default, and after playing a song, can choose the mode to save that particular playthrough in. When a score file or song entry is too full, they can choose to condense or delete some scores.
Current score files can be loaded as condensed scores, and marked with a flag to indicate that they cannot be converted to other scoring configs.
This all looks like top-shelf awesome sauce to me. Being able to switch between different scoring/timing configs would be especially nice.
The only thing that I'd say is missing altogether is some kind of provision for vector scoring; i.e scoring that isn't in judgement based chunks but increases the closer you get to spot on the note. Of course, it won't really be vector scoring since it will be per-millisecond, but that's close enough. I think this is preferable for competitive applications, because it means a higher score means better play, period. It also makes draws highly unlikely. ReRave has this kind of scoring, and while it still does have judgement categories, they're really just window dressing. Of course, having judgement categories could still be useful, because even if you're using Pro Judge messages, you might want to have different timing ranges light up in different colors, for instance.
The possibility to actually pull this off though, I don't know. It seems like it has to be a different mode than regular scoring (although still compatible/convertible, since it'll also be per-millisecond.) Obviously, one could manually specify a score value for each ±ms value, but that's poopy. There could be a tool to draw lines/curves on a "score graph" (something like this, only less fugly: http://puu.sh/oZ65d/623c321700.png) and then the program could just calculate a suitable score value for each. But that'd be a ton of work.
Just throwing the idea out there before I disappear into the life-hole for a bit.
Vector scoring has a problem. Observe this graph: http://i.imgur.com/DHUfte5.png
It's not a smooth distribution, there's a very visible spikiness in the line. The offset numbers at the bottom are how far from perfect zero that point is, and how many steps were hit that far off.
Additionally, if you compare the early/late great numbers in the score section to the graph, you can see that one of my early excellents was more than 44.5ms off, so it rounded to 45ms and became a great. Same for two of my late excellents.
(side note: that graph is just from me using data I was already gathering in my theme, quantizing it, and making a graph. The other ground work of actually having a better scoring system isn't there)
Oh, I get it...even with smooth input and scoring, vector scores would never save/replay correctly because everything would get herded to the nearest millisecond, thus changing its score. That's not a trivial issue, especially in the example I give where there's a sharp drop to zero; a tap getting pushed to the wrong end of that will render the saved score highly inaccurate.
D'oh. Well, I'll turn my attention to some more productive things like the new sim format thing, and perhaps helping more with NewSkin ideas/development since everyone seems to be leaving you high and dry in the forums.
@kyzentun By "any number of timing windows are allowed" does that mean there can be up to 7, or even 8 or more timings?
Since 5.1 still has a lot of progress/builds to be made, I think it could be implemented in a beta, RC, or preview of 5.1. There would be a new game folder "custom" for all the custom game types stored, or to store groups of certain custom game types, it could be renamed.
By default, to demonstrate the new user custom game mode system, there would be a 9 panel "example" game mode (techno 8 with center). It should support up to 26 tracks (that way, it would be possible to create a game mode like this: https://www.youtube.com/watch?v=qZAljlnOA9M). Actually, 27 if counting the space bar.
I have an idea about aditional gamemode along dance, pump, ez2, kb7, popn, beat, maniac, ds3dx, guitar, karaoke, etc.
I would like to have users be creative to make their own gametype using created shapes for the receptors, notes, etc. They can make their rule to that game mode. each has differenct styles and how many each player can come in:
This methods seems replaces NoteSkins folder as they specify the gametype will be enabled as the folder was there, since it makes no sense for it suppose to have the image load not to depend the enability of a game modes. thx to NewSkins system, which it won't stick to a gametype so you save more space and destroy the hasle.
Oh yeah, don't forget, the menu there will be changed! from
Select Game
, we change it into `Select/Manage Game' There you can choose the game you want and have a menu to create your own rhythm game.In Stomp, the menu will be just
Manage Game
since the selection of game type and style will be done in difficulty selection upon selecting a song in the music wheel (see my concept later) Relevant issue: #1049However, not all derivatives interface will be as same as in Stomp. older game require you to load it first in main menu so keep the procedure
Select/Manage Game
there.And editor, we will discuss it later. in short, you decide how many keys will be, assign the buttons, fill the sprite of the receptors, notes, judgement, etc. and then make the rule either by setup wizard, switch on, or fully Lua coded manually if users wishes to.
in conclusion, the game mode selection should not be hard coded. I see that part is still hard coded. So I will be proud to you all by making the creativity realizing become easier and more available.