New constructed game screen for N players

[moomarc]

I'd be really happy with that. I considered trying to do it but figured I'd first try get everything else working first. Now I just wish I had a new modem so I could connect to svn and commit some of the small things. Hopefully I'll get it replaced at the weekend.

[drdev]

I've fixed a couple issues, like having played decks be restored again and some layout stuff. I've also made some tweaks to scrollbar and table rendering, including changing ItemManager tables to use the ZEBRA color, which is more distinguishable from the Inactive color for some skins, like Journeyman.

Please look over the skinned appearance in any skins you like and let me know what if anything should be tweaked.

Thanks.
-Dan

[Max mtg]

It looks like our game can feature several types at once.

Then let's consider those as different entities - Game Type that includes { Sealed, Draft, Gauntlet, Quest, Constructed } and applied variants { Archenemy, ArchenemyRumble, Planechase, Vanguard, Commander }
What about creating different enums for them?

For a match one and only value of the first list is always used, and a set of items from the second list can be applied

I also wonder which are valid combinatins for the appliedVariants.

[moomarc]

@Max: I'm not sure whether your comment was posted before or after I committed r24463, but a big part of my plan was to finally be able to allow multivariant matches. I think the biggest problem is going to be Commander with other variants because of the distinction between Commander and regular decks when they are in fact the same, just with the commander section and singleton aspect enforced. The temporary solution would be to make it so that when commander is selected, the main deck selection button is replaced with the commander deck selection rather than adding new buttons below. The other variants should play nicely with it then. The problem is that several calls to start a match work through deckChooser. I'll just leave commander for last. In the game rules I'm considering setting Commander life to currentLife + 20 instead of straight life = 40. Will play better with archenemy classic then, but its not technically correct. How do you guys feel about that?

Then on to things I need some assistence with:
1 - When changing deck section in the main deck, it gives focus to the focus player's avatar in order to refresh the deck panel so that the random generated deck checkboxes can be added or removed appropriately. Ideally populateDeckPanel(GameType.Constructed) should be called, but that causes the issue I mentioned before where player 1's avatar gains focus which causes the deck panel to revert to player 1's deck selection. Any help in getting that to work without having to take focus away from the deck chooser would be so appreciated.
2 - enabling the planechase variant causes the player name and deck lines to be shifted away from the avatar. I assume it's because of the max width specified for the deck selector button. I didn't want to mess around with it though because I know Dan has a better understanding of MigLayout and getting it to do what he wants after panels are added or removed.

[drdev]

I'll look into those two things tonight.

[Max mtg]

Code: Select all

    private final List<PlayerPanel> playerPanelList = new ArrayList<PlayerPanel>(8);
    private final List<FPanel> activePlayerPanelList = new ArrayList<FPanel>(8);
    private final List<FPanel> inactivePlayerPanelList = new ArrayList<FPanel>(6);
    private final List<FTextField> playerNameBtnList = new ArrayList<FTextField>(8);
    private final List<String> playerNames = new ArrayList<String>(8);
    private final List<FLabel> nameRandomisers = new ArrayList<FLabel>(8);
    private final List<FRadioButton> playerTypeRadios = new ArrayList<FRadioButton>(8);
    private final List<FLabel> avatarList = new ArrayList<FLabel>(8);


What do you think about a single control, representing player's frame ... instead of those arrays eight items wide each?

It's like including all those components into an already created PlayerPanel class.

[Max mtg]

And please pay attention to r24515 - I believe this change improves the look and feel of planar deck selection by adding a label next to the 2 buttons aligned in the row below avatar

[moomarc]

Thanks Max. I can't check how it looks right now, but trust it looks great. I'm just a lowly bricklayer when it comes to coding here, so am glad for any improvements the masters can add. You have to remember that until this I'd never done any layout code and never attempted anything this ambitious. I think I've managed to improve one or two things as I've moved the variants across, but I can't do much more. Your idea of a player panel class sounds great, but I wouldn't know how to implement it so that it doesn't break something else. I'm still just a coding noob doing the best I can.

[Max mtg]

Thanks for your trust, yet I am not a master, just a professional programmer.
Ok, I'll gather all those arrays into classes in the next 2 days hours.

Upd: done in 24516

[moomarc]

Thanks for your trust, yet I am not a master, just a professional programmer.
Ok, I'll gather all those arrays into classes in the next 2 days hours.

Upd: done in 24516

Great work. Did a quick test and everything seems to work as before with one exception. When Vanguard is enabled, switching the player type should update thhe avatar list immediately because some avatars are filtered out for the AI. Thanks to you and Dan both for helping realise this new match setup.

If anyone wants to move Archenemy and or vanguard across to the new setup this week, feel free. But if nobody does I'll be free to work on it again from the 8th Feb.

[Max mtg]

exception fixed in 24517

[moomarc]

Hi Max, I'm just trying to learn some of the intricasies here so could you please explain something to me. In the vanguard list selection event listener, it checks whether the selected object is a PaperCard object, then uses an IPaperCard to actually populate the cardDetailPanel. Using a straight PaperCard object works too, so why use IPaperCard. I see PaperCard implements IPaperCard, so assume that has something to do with it. Is IPaperCard just lighterweight and holds all the info necessary for the card detail panel, so use that if possible? But both IPaperCard and PaperCard work for both lines, so why not use the lighter weight one for the instanceof check and the card detail panel population?

[Max mtg]

IPaperCard is not 'lighter weight' than PaperCard is. It's just a different way to point at the same object.

IPaperCard as an interface does not hold anything, it's just an agreement on a number of method, that all descendants have to implement. So when you declare a variable of type IPaperClass, you state like this: "I don't care which concrete class this object has, but it does define all the methods from this interface".

PaperCard is a class and surely holds data, as described in its fields, but again you don't know "how heavy" it is. This time you would declare that "this is an instance of PaperCard class or any of its descendants", so you know that the instance is at least "as heavy" as PaperCard is, because there could exist different descendants with their field sets.

Yet, when it comes to passing parameters, any class instance has the same "weight" - it is the memory address (of the block of data which holds instance's fields) that is passed to the callee - 32-bits or 64-bits wide, depends on your OS architecture.

[moomarc]

So if IPaperCard doesn't hold actual information, then why does it work passing the object cast as one to the card detail panel?

Edit: never mind, I answered that myself. The list object itself holds the info so casting as IPaperCard just tells the method that the object does in fact use that interface (or I suppose actually says it should try to read that object as though it uses that interface). Is that correct?

[Max mtg]

It works because method's signature actually reads: parameter of any class that implements named interface.

so casting as IPaperCard just tells the method that the object does in fact use that interface (or I suppose actually says it should try to read that object as though it uses that interface). Is that correct?

Yes.
When you cast types, a check is made in runtime. If the object's class does not implement that interface, there'll be an exception.