Dance mode overhaul

[Tronic]

Graphics update:

• 3D arrow objects
• Coloring based on note timing (as in other dance games), beat effects
• Better track visualization (instead of the ugly texture)
• BGCHANGE support (background videos)

Gameplay:

• Proper mine support (currently buggy, matches too easily)
• Improved hold note/combo support + roll/lift notes
• 3D mode instead of traditional scrolling? (proof of concept in dance3d branch)

Core:

• 3D object stretching/repeating support for long arrows
• Clean up the dancegraph/instrumentgraph mess

HELP WANTED!

[nieknooijens]

I’ll look into it after abunai (which starts today) I’m trying to get performous being adopted there, but the guy responsible for setting up the karaoke wants to keep using an heavily outdated program :-1:

[nieknooijens]

the dance-3d branch is 490 commits behind master, I think it's better to sync it first before continuing development on this branch, furthermore I think we should add a screen_songs_dance that looks more like a real-dance dance revolution song browser rather than use the original screen_songs, which screen to use should be configurable in the options menu. creating this http://sm-ssc.googlecode.com/hg/_assets/Themes/SMMAX2.0/preview%20screenshots%20in%20png/SMMAX20%20screens%20project%20ver1_1-12.png sort of interface should just be a parabolic formula anchored to the right-side's center. for all the songs, with the cover drawn in the top left. also the current difficulty-selector only shows "beginner, standard, heavy, challenge" and not the "actual" difficulty, for example, I can easily finish a "heavy" with level 7 or 8, but I will fail to clear a "heavy" with 9....

[tapio]

We are not trying to clone other games' interfaces and having multiple browsers is a) pain to maintain and b) would rip Performous of its identity. I think we should be aiming at providing a unique and amazing song browser that works with all types of songs and says "Performous" with a capital P, instead of trying to fight a losing battle of catering every other taste there's in the world through config options. (Of course having our theming system allow creating such a different look through data file editing would be awesome, but unrealistic).

[nieknooijens]

true, I haven thought this over yet, but the dance mode isn't usable as it is at the moment, that you can't see the "real" difficulty (numbers) is a pain in the ass and I'm currently keep using stepmania for it's skins and modifiers, but stepmania lacks a proper search function.... having performous support both karaoke/frets on fire and DDR contradicts with the "do one thing and do it good" principle. and I don't want performous to end up like windows 8 but what should we do with the dance-mode? I really want to improve it but how? ripping it out would also be an option...

[nieknooijens]

OK i looked into it and discovered the following:

IT'S HORRIBLE!! you can't get a single note right with this kind of graph!

[Tronic]

The first thing to do is to clean up the dancegraph/guitargraph code in master branch because it is too complex to be modifiable. It also has buggy mine handling and there could be other gameplay improvements especially with hold note or combination handling (e.g. don't accept a combination unless all arrows that belong to it are pressed).

The dance3d branch was just a concept test and it is not supposed to be used. However, I do think that a 3d visualization like that for the arrows would be the way to go. It just has to be designed well so that the timing becomes more obvious.

[nieknooijens]

ok, I digged through the code and it's truely a mess, I'll propose the following adjustments: 1: display difficulty value (e.g. you can have an "easy" level but this can be an easy 1, 2 or 3) 2: remove the coloured arrows instead colour should identify the note's type 3: music shouldn't pause when a player joins, this ruins it for the other players. 4: speedmods (there's nothing worse then being unable to read the arrows because the screen is full of arrows, instead you should be able to increase the speed thereby creating more space between arrows, the amount of arrows does NOT change) 5: split the arrows into 8 seperate .svg's this should clean up alot of code. 6: implement game modes other than dance-single. 7: simplify the difficulty selection screen (e.g. it's pretty weird you have to start dancing by going to the top entry and press left/right, most dancepads have a start button) 8: timeout delay should be customizable (currently a player fall's out of the game when he/she misses everything for 5 seconds, this delay should be customizable)

I'll wait your response for approval :-)

[Tronic]

1, 2, 3, 6: Yes.

No. 4. Can we find a way to do this without configuration? I'll remind you once again that we are not trying to imitate those dance games and we have no plans to make it so that it would interest "serious" dance players (who absolutely must have identical gameplay, config options, visualization and scoring to StepMania or whatnot).

No. 5. Actually, split them into separate 3d objects (different types at least). Flashing and coloring can be done in code (e.g. by using the emission texture).

No. 7. Doesn't this work already? In any case, it is related to instrument menu and/or the controller subsystem, not dance. Support for selections with four arrows only must be preserved because not all dance pads have Start, Select or diagonal arrows.

No. 8. No. We avoid customization in an effort to keep things simple and to improve usability (the Gnome way, if you will). Autodetection, good defaults and smart logic are the approaches that we prefer.

The drop-out delay (for guitar at least and I suppose that the same logic should be used for dance as well) is based on the number of notes skipped. This value might need to be larger than it currently is.

The song start delay depends on song type and beginners often do miss it, but if the instrument menu at the beginning pauses the song (as it currently does), this is rarely a problem, and in any case it is easy to restart when it happens. If you have a better solution that doesn't make starting the song slower but that makes it easier for beginners to join, feel free to share.

P.S. The markup used by Github is brain-dead. It re-numbers my entries (1, 2, 3, 4...) unless I prefix them with "No.". Who the fuck designed this shit? It should use some non-numbered prefix (e.g. #) for automatically numbered lists. And also # followed by a number shouldn't automatically reference other issues because there are a number of other reasons why something might be #-number. Pff.

[nieknooijens]

regarding nr 4. i'm not talking about spinning arrows and other mods, just the speedmod, and it should be done without configuration, it should be in the player menu when the player joins and it's only remembered for that session.

regarding no 5, should we use .svg's or .obj files for 3d objects? because if we use .obj files we could make 1 arrow and just rotate it in code.

[tapio]

regarding nr 4. i'm not talking about spinning arrows and other mods, just the speedmod, and it should be done without configuration, it should be in the player menu when the player joins and it's only remembered for that session.

Couldn't we automatically adjust the speed based on how rapidly notes follow each others thus being able to avoid polluting the menu? Either dynamically based on e.g. next 10 notes or if changing speed is confusing, analyze the whole song beforehand.

regarding no 5, should we use .svg's or .obj files for 3d objects? because if we use .obj files we could make 1 arrow and just rotate it in code.

SVGs don't store 3d objects, so .obj it is. I think rotating one model is good.

[Tronic]

Regular notes, holds and mines at least will require different models. Hold notes are particularly tricky because they need to be stretched or repeated as long as they last. Different rotations and different colors don't require separate note objects.

[nieknooijens]

@tapio we're not polluting the menu, it'll become like this: http://img821.imageshack.us/img821/6535/7yf8.png automatically adjusting the speed would ruin the dance experience since a lot of songs (especially medley's) change bpm/speed throughout the song. you know in stepmania when you double-press start, you get 2 menu's full op options, but the only one we really use is the top one: the speed settings: we adjust it to the bpm of the song, if the bpm is ~200 we usually put it between 1,5x and 2,5x when the bpm is 300 or higher we set it to 3x or in rare cases to 3,5x. it's the only real modifier we use, and I know we don't want performous to end up like this: http://www.youtube.com/watch?v=yuJIzsrx3IE but I want the dance mode to be usable and alot of peaple need the speedmod for that. but most votes count, if it's still no then I won't add it until all the other stuff is done first. we should make a nice roadmap and decide what will be modified first and what next,

I already created a 3d model for the mine, I can possibly create the other 3d-models too, here's the file: http://ubuntuone.com/2izIeWI5U31fJ2RgzyBPIb

so where should we start?

[nieknooijens]

here's the new 3d-model pack, it contains 2 mine-types an arrow and an arrow-outline http://ubuntuone.com/38n1U6Anw0LOBMhalq9jTQ

let me know what you think of it.

[nieknooijens]

here are the new UV-mapped models :-) http://ubuntuone.com/38n1U6Anw0LOBMhalq9jTQ

[nieknooijens]

Ok I tried to load the arrow obj into performous using the same method as the fret obj works, so loading it in the constructor of the dancegraph, the program crashed with telling me only triangle faces are allowed, a quick ctrl+t in blender made all quads triangular and when trying to load it once again this happened:

Program received signal SIGSEGV, Segmentation fault. 0x0000000000562a35 in Normal (v=..., this=0x1125838) at /home/niek/Projects/performous-dance/game/glshader.hh:125 125 m_vert.normal = v; (gdb) bt

0 0x0000000000562a35 in Normal (v=..., this=0x1125838)

at /home/niek/Projects/performous-dance/game/glshader.hh:125

1 Object3d::loadWavefrontObj (this=this@entry=0x1125838, filepath=...,

scale=1, scale@entry=0)
at /home/niek/Projects/performous-dance/game/3dobject.cc:93

2 0x000000000056481f in Object3d::load (this=this@entry=0x1125838,

filepath=..., texturepath=..., scale=0, scale@entry=1)
at /home/niek/Projects/performous-dance/game/3dobject.cc:103

3 0x00000000004ace21 in DanceGraph::DanceGraph (this=0x1124e90, audio=...,

song=..., dev=...)
at /home/niek/Projects/performous-dance/game/dancegraph.cc:96

4 0x00000000005b1f6e in ScreenSing::prepare (this=0x10f8380)

at /home/niek/Projects/performous-dance/game/screen_sing.cc:405

5 0x000000000055616d in mainLoop (songlist=...)

at /home/niek/Projects/performous-dance/game/main.cc:204

6 0x000000000055e8b4 in main (argc=1, argv=0x7fffffffe558)

at /home/niek/Projects/performous-dance/game/main.cc:379

what the heck??? @Tronic please assist me :-1:

[tapio]

You need to also export normals (check the option in the Blender exporter). The reader should be able to read objs without normals too but apparently there is a flaw. In any case, normals are needed for lighting to work.

[nieknooijens]

ok it does render now but....

something's wrong with the shading, and the texture isn't rendered either

[tapio]

It seems like half of the triangles have their normals facing the wrong direction.

Regarding texturing, Performous does not use .mtl files. The texture path is given as an additional parameter to the Object3d constructor.

[Tronic]

I suppose we should implement proper texturing support via .mtl files. Different channels such as diffuse, specularity and emission will be requiring their own textures, which I gather is currently not supported.

[nieknooijens]

yeah we should implement proper mtl texture support, cause even with the following code:

//load 3d object files
m_arrow_obj.load(findFile("arrow.obj"),findFile("arrowUv-image.png"),0.9);
m_arrow_outline_obj.load(findFile("arrowoutline.obj"));

and re-calculating all the normals... it still doesn' t draw correctly :-( :-1: also there's no way to rotate it in code :-1:

[nieknooijens]

I assume the drawarrow function in dancegraph only draws the "outline" on wich you have to aim right? also about the rotation, should I just make seperate objects each rotated, or should we overhaul the object3d class too? cause in that case we've got alot of work to do (and I need to do a lot of research into sdl/openGL/wavefront 3d etc)

[tapio]

Rotating a 3d object (or anything) happens by creating a Transform instance with an appropriate rotation matrix generated by rotate(float rad, vec3 axis) function.

[nieknooijens]

I had some time off at my student society so i was thinking: how can I push performous to the limits? so i decided to do a little experiment, we've got around 30 DDR-pads lying around here, what if I connect as much as possible?

(with 1 usb-hub it turns out to be 7 + keyboard = 8 players)

as it turned out, if I plugged in the futuremax v3 pads first, then only the futuremax v3's would work, if I plugged in the older pads first then the v3 won't, so I discovered I had to use the SAME pads in order for them to work.

5 players is perfectly doable! however....

8 becomes completely unreadable!!! according to performous' coude I can connect up to 10, but I doubt this will be usable .....

[tapio]

Heh, awesome! :D

[nieknooijens]

for the holds it would probably be best to create a "middle" and "tail" texture and just repeat the middle section until we run out of note and then add the tail texture, this looks moch cleaner and makes creating noteskins alot easier since the holds don't "stretch" the texture continiously. about the speedmods, we had some conversation about that a while ago and i now implemented them in the way I intented it to work, are you happy with them?

oh and sorry for being absent lately, I have to do the webserver-branch work again for school but this time with clementine, in 5 weeks I've got holidays again which means more spare time for performous :-)

[nieknooijens]

I came across another bug while experimenting with the phase colors. it appears mines are count as normal notes, which means that if you miss 30 mines, the player will drop out! (you're supposed to miss the mines). it's best to make some dropout counter that increases with every "normal" note you misssed, and it's reset to 0 with every note you hit. (or every time you press one of the arrows on the pad) when the variable reaches 30 the player should drop out.