stepmania / stepmania

Advanced rhythm game for Windows, Linux and OS X. Designed for both home and arcade use.
https://www.stepmania.com/
1.83k stars 446 forks source link

User custom game mode/type #1030

Open JOELwindows7 opened 8 years ago

JOELwindows7 commented 8 years ago

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:

/stepmania <-- Root folder
   /GameModes <-- selectable gametypes
      /dance -|
      /pump  -|-- Preinstalled rhythm games
      /ez2   -|
      ....
      /my_gametype <-- your own rhythm game
         /gamemodes.lua <-- consist the rules of the gameplay, sprite loadings for receptors, notes, etc.
         /[????] <-- I think this shall be just one files...

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: #1049

However, 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.

JOELwindows7 commented 8 years ago

This shall not be disagreed. I want the closure is when they agree!

Kaiveran commented 8 years ago

They're way ahead of you, pal – see #740.

Reading + thorough searches are your friends – get to know 'em!

shakesoda commented 8 years ago

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.

kyzentun commented 8 years ago

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.

Stepstypes

Keymapping

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.

Selecting

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.

Scoring rules

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.

Version number

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.

Per-column flag

Whether notes in different columns at the same time are judged separately.

Timing Windows

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)

Combo / Life values

An amount for each judgment to add to the combo/life. A negative combo value breaks the combo.

Score saving

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.

Replay

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.

Per-Column Mode

A normal replay only stores one tap entry for each row. If the perkele flag is set, then each column is handled separately.

Full

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.

Condensed

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)

Choices

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.

Compatibility

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.

Kaiveran commented 8 years ago

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.

kyzentun commented 8 years ago

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)

Kaiveran commented 8 years ago

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.

1033Forest commented 8 years ago

@kyzentun By "any number of timing windows are allowed" does that mean there can be up to 7, or even 8 or more timings?

1033Forest commented 7 years ago

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.