New constructed game screen for N players

[Marek14]

Marc: I think that an option to set some variables for individual players (at least starting life and poison limit) would be nice, in an "Advanced" menu. Would help finding the best solution.

[moomarc]

I'm considering trying to learn some swing to try implement these starting screens seeing as no one else seems to be interested at this time. Will depend on free time, but hopefully I can get somewhere.

[moomarc]

I'm startingto get somewhere with the layout, but still a lot to do and work out. I'll probably need help with implementing some of the final bits once the layout is done, and it might need some refactoring to split view and control. I'm trying my best though. I'll try post some screen caps over the weekend some time.

[moomarc]

Progress report:

How it looks so far: New game setup alpha v1

Implemented:
So far I've got it to the point where it does what the previous layout did in that a multiplayer game can be started (up to 8 players) and each player can be set as human or AI. Deck selections will also be remembered as before. In addition, changing player 1's name sets the player name preference and carries through to the match. Players can be added and removed, although one slightly quirky bit of behaviour is that if player 3 is removed, the next player added will be player 4, then 5 - 8 as expected, then player 3 as the last player, but in its old slot. This is because the panels are just hidden when closed and added to the end of a list of inactive players.

Unimplemented:
- Other player names can be changed, but are not yet hooked up to the match. I also want to implement the name randomization here at the initial setup rather than when the match starts so that the names can be changed.
- Variants setup has listeners set up, and ready to be fed to match, but nothing is actually hooked up as some changes are necessary to allow multi-variant games. At the moment the checkboxes build an array of GameTypes (including the new GameType.ArchenemyRumble). I plan to feed these to the match initialization where the applicaple modifiers can then be applied.
- Deck selection buttons on player panels not in yet, but giving a player focus by clicking the name box or player type radios changes the deck chooser to the relevant player.
- Visual indication of current focus player.
- Avatar selection not yet possible from this screen. It does use the preferred avatar for player 1 and 2, although they don't update when the avatar is changed via the preferences' avatar screen (which this won't replace due to the preference being used in other formats too). Clicking on or otherwise giving focus to the avatar also doesn't update player focus yet and thus doesn't update deck panel.
- Adding a player does not yet give that player panel focus.
- The random deck checkboxes (singleton etc) are still visible all the time next to the start button. They must be moved into the deck chooser construction code.
- Teams setup not laid out or implemented yet.

---------------

If anyone wants to have a look at the current code or try it out, a patch is attached. It is a project patch, but only changes VSubmenuConstructed, and adds the new gameType to the enum in forge-gui/src/main/java/forge/game.

Feedback welcome, but its still quite far from done.

[Max mtg]

I like the picture, it's way better than what we have now.
If a match can be started from this screen, commit it... the release seems to be quite far ahead.

[Agetian]

I agree with Max on this - since we're in the very early stages of the next beta it may be worth committing the code and working on it in trunk (unless it's completely unworkable and doesn't let you start the game) because otherwise it may be difficult to merge / keep the patch updated later on...

- Agetian

[moomarc]

Thanks guys. I'll commit shortly. Just making sure that nothing is missing from the current implementation. Also fixed a minor bug related to the player panel ordering where if you added player 3 and player four, then removed player 3, the third player in the match would use player 3's deck instead of player 4's, who it is actually meant to refer to.

[Agetian]

Thanks for your effort, Marc, the new screen looks great!

- Agetian

[moomarc]

The first implementation has been committed. Selecting a deck doesn't yet update the label in the player panel. It does use the correct decks for the match though, and save the deckChooser prefs at that point as it did before.

I've also come across an issue where if preferences aren't available yet, player 1's name will be blank and updating the name causes a crash.

[Agetian]

A great beginning, Marc! Over time this will become an amazing Constructed game interface, it's already shaping up to be an awesome replacement for the previous version!

- Agetian

[moomarc]

r24278 - Fixed bugs related to no preferences being available, and implemented avatar randomization (players 3 - 8, or via right mouse click).

[moomarc]

r24280: Names and avatars are now used for the match, except for additional human players (I think this was the behaviour before though, due to the way human lobby players are built). Avatar randomization also ensures duplicate avatars aren't chosen.

Next on the list: populate the name fields with random names and add button to randomise player name.

[drdev]

moomarc, do you mind if I swap out the list box control in the FDeckChooser for a DeckManager when I get the chance?

Also, do you mind if I tweak some padding in the player list so you can see more players at once?

[moomarc]

moomarc, do you mind if I swap out the list box control in the FDeckChooser for a DeckManager when I get the chance?

Also, do you mind if I tweak some padding in the player list so you can see more players at once?

No problem on both counts. And while you're doing the decks, would you please implement the listeners or whatever is needed so that when a deck is selected, the current deck button in the player panel is updated. There is already an updateDeckLabel method, so just update that method as needed. Thanks.

Edit: just remember that there's still more elements to add to the player panels, so don't squeeze them too tightly. Tomorrow I'm going to get the name randomizer working and implement it. It will be an upgrade to the current one in lobby player so I'll call it from there too for the other formats. I guess the most important thing after that is to get the avatar selection working, rather than just the randomizer.

Edit2: sorry if it sounded like I was trying to force you into handling the deck change updates. But it's one thing I hadn't been able to work out yet, so any help is greatly appreciated

[Max mtg]

Speaking on the first count, take care of good list visibility, so that the deckmanager prooves more useful than fdeckchooser.

I suspect (though it could be a wrong assumption) that you'll have to implement an adapter class to populate deckmanager with its instances, because currently fdeckchoooser gives player a list of different types of decks (backed by different classes) and even just colors, that are not decks at all!

As for deck list updates... Events sent by deckeditor and listened to by views with fdckchooser and/or its replacement (those views are singletons afaik) could handle those updates
Misunderstood the problem