Next up on the drawing table: Noteskin parameters, and theme layers in the notefield.
I haven't yet implemented these ideas at all, so they might change a lot.
Notskin parameters will be a standardized way for noteskins to have options that the player can set. For example, I've got a noteskin with little explosion particles when notes are hit (
http://i.imgur.com/XGSbx8w.png). A noteskin parameter could be used to allow the player to use the options menu in a theme to turn those on or off.
To use parameters, a noteskin would have this in noteskin.lua, inside the table that is returned:
skin_parameters= {
frames= 2,
tap_graphic= "Love",
rots= {Left= 90, Down= 0, Up= 180, Right= 270},
},
skin_parameter_info= {
frames= {type= "int", min= 1, max= 4},
tap_graphic= {"3_9", "Chromatic", "Emoticon", "Grammar", "GrooveNights", "ITG2", "Love", "Tactics"},
rots= {
Left= {min= 0, max= 360},
Down= {min= 0, max= 360},
Up= {min= 0, max= 360},
Right= {min= 0, max= 360},
},
},
And notes.lua would have something like this:
return function(button_list, stepstype, skin_parameters)
local tap_graphic= skin_parameters.tap_graphic
local tap_frames_per_quantization= skin_parameters.frames
local rots= skin_parameters.rots
(then the other stuff that normally occurs in notes.lua, using tap_graphic and such)
skin_parameters is a lua table that can contain whatever the noteskin author wants to be modifiable. This is one of those places where I can't give much guidance beyond "Think about the choices you want the player to have". It can contain tables in a nested structure, so you can organize and build whatever data structure you want.
skin_parameter_info contains some basic information on the fields, so that the theme can build a menu for the player to pick from. The info for each field is stored in a table. For numerical fields, if the type field is not set to "int", then the theme can use a menu for a float number, and allow the player to set values like 1.5. (this example marks frames as an int, because 1.5 frames of animation in a sprite doesn't make sense). The min and max values are so the theme can know what range to limit choices to. Imagine a noteskin with 4 frames available for each note, but with the option to use only 1 frame to make notes unanimated.
Boolean values in skin_parameters are assumed to allow both true and false values. There does not have to be an entry in skin_parameter_info for boolean values.
String parameters need to supply a list of valid strings for the player to pick from.
So the system would work like this:
1. The player picks a noteskin.
2. The player goes to a noteskin config menu and sets some parameters.
3. The engine takes those choices, does some sanity checking, then passes them to the noteskin, as an argument to the loading functions.
4. The loading functions look at the parameters and adjust behavior appropriately.
Theme layers in the notefield:
Some themes may wish to do things that are convenient only in the notefield, like judgment flashes or hold judgments. So the idea here is to allow the theme to specify some layers above and below the notes, identical to the layers in the noteskin, for containing those things. I have no idea how I'll do this yet, I'm just thinking it could be useful to someone.
Problems:
Constructing a dynamic menu that can handle any table data structure of floats, ints, bools, and strings in the OptionRow system will be challenging. Making it work out nicely in Consensual is going to be a fair bit of work, and Consensual has tools for arbitrary configured numbers.
Translation will also be difficult. The theme will only have the name of the option to go off of. It can't have entries in the standard language files for every noteskin, because that info belongs with the noteskin. So there will have to be some way to embed translated field names in the noteskin for the theme to display for each language. Maybe add a translations section with entries for each language to the type info for the skin parameter.