[WIP] Sideboarding: Considerations, Questions

[Agetian]

OK, here I come, I'm starting to implement Sideboarding as a feature of Forge. I inspected some of the related code I might have to work with (in particular, the deck editor UI building elements, EditorTableView, CCurrentDeck/VCurrentDeck) etc. and I have a plan in mind, but I need some advice because it looks like at every step, I meet an obstacle in the form of inability to get different portions of the deck (e.g. the [main] part or the [sideboard] part of the deck). So:

The current idea is to add sideboarding as a feature of the deck editor (at least for Constructed) and then either fire it up between two duels of a match or use the two-listbox multiple choice window for the purposes of in-game sideboarding (in all modes). As for the deck editor, there are two possible strategies. One possibility is to add a button called "Main/Sideboard" to the current deck catalog on the right. Clicking that button will alternate the view between the main part of the deck and the sideboard. The downside may be the potential difficulty of how to move the card between the main and the sideboard, but that can be remedied with some sort of a shortcut or another button. The other possibility is to add a column to the current deck window on the right which will show if a card is in the main or in the sideboard, and add a button to switch between the two. Not sure which one is better, and not sure if maybe there's also a better idea out there.

Anyhow, for the implementation, there are several blockers mostly because I don't know how to do certain stuff in Forge yet:

1. I don't understand what I need to do if I need to reload a portion of a deck (e.g. the sideboard instead of the main, or vice-versa) into the Current Deck table (CCurrentDeck/VCurrentDeck). There seem to be no easy option to access different portions of the currently loaded deck from inside that method, so if, say, I add a button to VCurrentDeck and then implement something like:

Code: Select all

        ((FLabel) VCurrentDeck.SINGLETON_INSTANCE.getBtnSideboard()).setCommand(new Command() {
            @Override  public void execute() {

                  // ??? How do I reload a part of the deck here?

            } });


then it's not clear how I can actually load another portion of the deck into the current deck table. I checked the various methods of the current editor controller, but nothing seemed to do the trick. There are methods like getSideboard() in the Deck class, but it looks like there's no way to access an instance of a Deck class for the currently loaded deck in the editor, and I failed to find an alternative for that...

2. I may not realize all the rules of sideboarding yet. What I know is (please correct if I'm wrong anywhere):
- In Constructed, the sideboard must consist of either 0 or 15 cards.
- In Draft and Sealed, the entire collection received from the boosters/etc. that did not go into the main is considered to be the sideboard.
- In Constructed, there may be no more than 4 cards of the same kind in the main and the sideboard together.
- In Draft and Sealed, as many cards as necessary may go into both the main and the sideboard.
What I don't fully realize (or at least doubt) is:
- In Sealed and Draft, do the basic lands count as sideboardable items? Can you sideboard in/out basic land?
- What do we do if, upon validation, the sideboard rules (e.g. in Constructed) are found out to be broken? Do we just not let the user save the deck until he corrects the deck?
- Are there any other peculiarities I have to be aware of when implementing sideboarding?

Any tips and tricks related to loading/saving parts of deck, especially from within the context of the deck editor, are highly welcome. The code is spread across several classes containing several dozen methods each, it's definitely not easy to go through it in search of a particular block of code which may potentially not even exist yet...

I'll try to implement this feature as quickly as I can, but I think I'll delay its merge (or at least enabling it for the final user) until after 1.3.3 in case I somehow manage to get it to work before 1.3.3, simply because it's a major enough change.

- Agetian

[friarsol]

What I don't fully realize (or at least doubt) is:
- In Sealed and Draft, do the basic lands count as sideboardable items? Can you sideboard in/out basic land?
- What do we do if, upon validation, the sideboard rules (e.g. in Constructed) are found out to be broken? Do we just not let the user save the deck until he corrects the deck?
- Are there any other peculiarities I have to be aware of when implementing sideboarding?

Yes, you may have basic lands in your sideboard. And you may sideboard them in/out. It's certainly possible (in limited) to Sideboard out your whole deck, and sideboard in a completely different deck. Some constructed decks do this in certain matchups, pulling out 15 useless cards, and sideboarding in completely different win conditions.

I'd imagine instead of a save button, we'd have a "Finish Sideboarding" button, which would check the appropriate rules, and not leave the deck editor if it doesn't match the rules. In general, you shouldn't be able to Sideboard in a way that would fail validation (aside from too low card count), as invalid cards in your sideboard shouldn't be in there to begin with.

The only other things I can think of that interact with the Sideboard are these cards: http://magiccards.info/query?q=o%3A%22o ... rd&s=cname which shouldn't make a huge difference, but just something to keep in mind.

[ArsenalNut]

Here's a couple of thoughts I had about sideboard implementation

1) For the editor, I have seen an implementation in another Open Source Magic app that split the deck editor into two lists in the same gui panel. Choosing cards from the catalog, added them to the main deck. Then there were separate buttons to move highlighted cards back and forth between the main deck and the sideboard. I like the idea of seeing both the main deck and sideboard at the same time so you can see what's in the deck without toggle between views.

2) I like using the dual list box idea better than opening the editor back up for the actual in game sideboarding implementation. I saw this in action when Friarsol accidentally check in some code that partially implemented the sideboard. I thought it worked pretty well.

3) It would be nice if the sideboarding could be toggled on and off from the game area similar to the targeting overlays. From my little experience with Friarsol's code, using the sideboard definitely slowed down my game play. I can definitely see where I would want to turn it off sometimes.

[Agetian]

Thanks for your input, guys!
My current implementation is going to be like this: the creation of initial sideboard is done via a deck editor mode. In-game sideboarding is done with a two-pane dialog box. Sideboarding can be turned on and off akin to targeting overlays.

The first phase is very close to ready and will be committed to SVN after v1.3.3 is released (it's kinda raw so I don't want to introduce more bugs before the release time).

EDIT: Found a rather elegant fix for the issue posted previously, so currently everything seems to work fine.

- Agetian

[friarsol]

However, this introduces a nasty crash when coming back from the sideboard mode to the main deck editor mode - selecting any card in the card catalog crashes Forge with an editor in EditorTableView, particularly in showSelectedCard when it tries to visualize the card. Looking at the code for "setup" I can clearly see that it was not intended for dynamically altering the number of columns in tables.

Maybe instead of adding/removing column you can just have it treated as an invisible filter (that is, one that doesn't show up as a checkbox in the filter tab). When you need it, you show the column, and when you don't need it, you hide it.

I generally hide Power, Toughness, and CMC columns, but occassionally they are useful (like say in draft), so I manually reactivate them.

[Agetian]

That sounds like an interesting idea, Sol, though I currently fixed it by implementing an extra lightweight method for adding/removing columns... do you know what function can be used to apply a filter though? I might look into it and see if it's going to be more efficient.

- Agetian

[friarsol]

do you know what function can be used to apply a filter though? I might look into it and see if it's going to be more efficient.

No idea, I'd just try to find the filter checkboxes and see how they work. I'd imagine hiding/showing is more efficient than removing/adding.

[Agetian]

Ok I'll look around. Thanks for the tips, Sol.

P.S. I committed the phase 1-related code to SVN just so there are no compatibility issues in the future. The code is currently DISABLED and will not affect anything, it will be updated and enabled after the v1.3.3 release.

- Agetian

[Agetian]

OK, a little question: is there anything in Quest mode (e.g. Fantasy mode) that can affect the number of cards of the same kind that can go into the deck+sideboard or is it always 4 like in pure Constructed?

- Agetian

[Sloth]

OK, a little question: is there anything in Quest mode (e.g. Fantasy mode) that can affect the number of cards of the same kind that can go into the deck+sideboard or is it always 4 like in pure Constructed?

No. The limit should always be 4 (with the exception of basics and Relentless Rats).

[Agetian]

Nice, thanks! I'm very close to implementing full sideboarding btw, I'll make some major commits soon after v1.3.3 is released.

- Agetian

[Agetian]

Ok, done and done, the initial implementation of Sideboarding is complete and, according to preliminary testing, works as desired. This will be committed ASAP after 1.3.3 is out, I hope no one ninja's me with some other super major commit that breaks it though (I mean, the implementation affects 10+ files in a rather major fashion, so...)

Highlights of the upcoming sideboarding release:
- A full-featured sideboard editor for Constructed and Quest modes (Limited doesn't really need it because the sideboard there is everything that's not in the main deck).
- Full deck validation upon entering the game including sideboard rules.
- In-game sideboarding using a two-panel window which is modified for convenience and shows the count of cards in the main deck and the sideboard and updates it dynamically and allows to move cards between the main deck and the sideboard. Unnecessary buttons which don't make sense for sideboarding (remove all/add all and "Auto ordering") are turned off for the ingame sideboard editor. Full validation is also done, so illegal decks are not accepted until both the main deck and the sideboard are valid from the point of view of the game format.
- Constructed/Quest can have sideboards with 15 cards or no sideboard at all (0 cards). If you don't have a sideboard, the game doesn't bug you with the question if you'd like to sideboard.

Coming soon after the initial release:
- An option to turn sideboarding off (not sure how necessary this is, I mean, the question to sideboard is just another question like "do you want to mulligan?", if you don't need to make any changes you can just click OK).

Current caveats:
- There is no AI support yet, but hopefully someone will be able to write some (I'm not good at AI coding, at least not yet...). There is a comment in the code telling where to hook up the AI sideboarding code.
- After the match, the deck is set back to its original form. Not sure if this is actually the desired behavior or not, but 1) saving the deck from inside the game seems like a rather major hassle, 2) not sure if you'd actually want to keep the modifications to your main deck after sideboarding anyway. So I'll leave it the way it is, at least for the time being.
- There is some minor code duplication in one spot of the code, I'll try to take care of it and I'd welcome your suggestions for code improvements in general.

- Agetian

[moomarc]

Thanks Agetian! Looking forward to trying it out!

[friarsol]

- After the match, the deck is set back to its original form. Not sure if this is actually the desired behavior or not, but 1) saving the deck from inside the game seems like a rather major hassle, 2) not sure if you'd actually want to keep the modifications to your main deck after sideboarding anyway. So I'll leave it the way it is, at least for the time being.

Very Nice.

This was also one of my major concerns when I was first looking at Sideboarding. In general, it would be nice if the "Main Deck" taken in between Games 2 and 3 was the most recent Main Deck used, as opposed to the Main Deck on file. (If you sideboarded something in for a reason, you probably want to leave it in for the same opponent). However, there didn't seem to be a good place to actually access this information when you are sideboarding.

But you definitely wouldn't want your changes to affect your next match down the line (which overwriting your deck on file would do), so it may be something we have to live with for now.

[Agetian]

Breakthrough report: The sideboard is now persistent across duels in a match, so, for instance, in game 3 you start with the same main/sideboard configuration as in game 2. However, after the match is over, your deck is reset to its original state. The implementation is a tiny bit on the convoluted side, but I think it's fairly acceptable, and I'll see if I can simplify over time, too.

- Agetian