Sealed Deck development part 2

[RumbleBBU]

Continuing from where I left off...

One of the things I liked in the Microprose version of MtG was the Sealed Deck tournament. In fact, it was probably the best game mode in that game (aside from Shandalar).

Trying to implement something similar in Forge would be a lot of work, due to certain missing important features (like computer-vs-computer duels, as pointed out by someone else). However, I thought of a more-or-less convincing way to emulate the experience, and I've been working on it the past few days.

These are the files I've modified so far:
CSubmenuSealed.java
VSubmenuSealed.java
DeckGroup.java
Deck.java
(note: I have not committed any of these yet - I want to complete the code first, test it, and be fairly confident it works before I commit any of it!)
Here's the basic concept:
When a Sealed Deck game is created, the player can choose the number of elimination rounds, just like in the Micrprose game. If you select 1 round, the Sealed Deck game behaves just like now.

However, if you choose more than one round (in my current code, you can choose 1-5 rounds), the game will generate that many AI decks. Then it will examine the generated decks, and 'rank' them against each other. Rather than actually match them up against each other, the ranking is a simple statistical formula based on draft-ranking values of the cards in each deck. The decks are put in a TreeMap order based on the ranking. While the formula is very primitive, it seems to produce quite logical results: decks that have some very powerful cards like Shivan Dragons, Mythic Rares and such in them are likely to get high scores and make it to round 5.

And I have already coded all that. The 1-5 decks are generated, ranked, ordered and loaded properly when you create and start a (fake) Sealed Deck elimination tournament. The first rounds contain the weaker decks, and they get progressively harder towards round 5.

The only thing missing: I have not yet located the logical place in the code where to check whether the player won the previous match and if he/she did, proceed to a new match with the next aiDecks deck.

[Sloth]

This sounds very nice. Lots of people have requested a tournament mode of some sorts.

The only thing missing: I have not yet located the logical place in the code where to check whether the player won the previous match and if he/she did, proceed to a new match with the next aiDecks deck.

Our UI developer Doublestrike has left the project a few month ago after renewing the whole user interface. I don't think any of the remaining developers can be a lot of help here.

I would approach this by looking how the quest mode is set up (since a tournament is just like a mini quest), but expect this to be a lot of work.

[RumbleBBU]

The only thing missing: I have not yet located the logical place in the code where to check whether the player won the previous match and if he/she did, proceed to a new match with the next aiDecks deck.

Our UI developer Doublestrike has left the project a few month ago after renewing the whole user interface. I don't think any of the remaining developers can be a lot of help here.

...and the fact that GUI design and Java concurrency are not exactly my fortes doesn't really help either.

I'm currently reading up on SwingWorker tutorials to get a grasp on how the Sealed Deck menu and the game object (SwingWorkered) interact.

[RumbleBBU]

Making slow progress here.

So far I've figured out that the menu code (the SwingWorker stuff) really does nothing more than initializes a new game, i.e. the GameNew object. The GameNew object is apparently done when the actual game starts, the and that's where things get hairy, i.e., difficult to follow.

[friarsol]

I think what you are looking for is the WinLoseGame controller. It basically does things after a game ends, which for Quest mode awards boosters and increases your Quest record. I'd imagine if you took a look at the Quest specific WL Controller, it would do things very similar to what you want, you just would need to set the type of game up properly in GameNew, so it has a reference point in WinLose.

[mcrawford620]

It would be sweet to have this for the Draft format too, especially since the decks are already created.

[friarsol]

Yea, this seems like it should be it's own "Gauntlet Mode" Input a Human Deck + 2^n-1 similarly created AI decks, and allow entry for Sealed, Draft, and even constructed. And then have an n-sized bracket.

We can always make it more generic once we get all the basics rolling.

[RumbleBBU]

Thanks for the tip, Sol! It makes a bit more sense now. I'm currently studying ViewWinLose.java, ControlWinLose.java and QuestWinLoseHandler.java and trying to figure out what would be the best way to build a win/lose handler for Sealed Deck mini-"tournaments"/gauntlets. I've also been hacking SealedDeckFormat.java and CardBlock.java some more for extra flexibility in block formation/sealed deck game building (more on that later).

Yes, I believe the same concept could be adapted to Draft and Constructed formats. I'll try to keep that in mind, even though my primary focus will be on Sealed Deck (my favorite format).

Here's my overall plan:
Stage 1: Just build a handler that works like the current win/lose handler except that it also allows you to proceed to the next round if there is a next round and you won the previous round. (Plus include everything that I've already coded, see the first post in this thread.)
Stage 2: Once Stage 1 is coded and works, add a 'Save' feature and a Deck editor button (for sideboarding between games).
Stage 3: Adapt the same concept to other formats (Draft, Constructed).

But all that will take some more time. I'm hoping to get Stage 1 completed in time for the next beta (1.2.13), but I'm not sure if that's realistic due to real-life commitments.

Addendum:
What I'm unsure of is when I should start committing parts of this. The wiki guide suggests you commit often (and it's a good idea) but I'm slightly hesitant to commit something that doesn't really work yet. (It gives you the option to choose rounds but then you will get to play only one round anyway.) Oh well, at least the new beta is out now so I wouldn't be messing that...

I will be committing SealedDeckFormat.java and CardBlock.java right away, since the rest of the code doesn't really depend on them nor they on the rest. (Done.)

[Hellfish]

What I'm unsure of is when I should start committing parts of this. The wiki guide suggests you commit often (and it's a good idea) but I'm slightly hesitant to commit something that doesn't really work yet. (It gives you the option to choose rounds but then you will get to play only one round anyway.) Oh well, at least the new beta is out now so I wouldn't be messing that...

I will be committing SealedDeckFormat.java and CardBlock.java right away, since the rest of the code doesn't really depend on them nor they on the rest. (Done.)

A branch would probably be a good idea. I'm no expert but there's a section on the wiki about it.

[ArsenalNut]

What I'm unsure of is when I should start committing parts of this. The wiki guide suggests you commit often (and it's a good idea) but I'm slightly hesitant to commit something that doesn't really work yet. (It gives you the option to choose rounds but then you will get to play only one round anyway.) Oh well, at least the new beta is out now so I wouldn't be messing that...

I will be committing SealedDeckFormat.java and CardBlock.java right away, since the rest of the code doesn't really depend on them nor they on the rest. (Done.)

A branch would probably be a good idea. I'm no expert but there's a section on the wiki about it.

For major updates like this I also recommend using a branch. This allows the developer to check in incremental changes without breaking the trunk. If you want/need help setting up a branch, let me know.

[RumbleBBU]

Yes, branching would seem to make sense.

Unfortunately , I do seem to have a technical problem. This traces back to when I originally configured my Eclipse as per the http://www.slightlymagic.net/wiki/Forge ... ping_Forge instructions. There was one specific step in the instructions that I could not follow:

m2e Plugin Connectors

The m2e plugin must have a connector installed to work with various SCM repositories. Connectors can be found as follows.
SVN Connector

Navigate to File -> Import...
Expand the Maven folder
Select Check Out Maven Projects from SCM and click Next.
In the dialog window that opens, click Find more SCM connectors in the m2e Marketplace
It's on the lower right side of the window.
Search for m2e-svn and select. Click Finish.
Continue with the standard install procedure and restart Eclipse.

The problem is in the bolded step. There is nothing such available! (See the enclosed image.)

Consequently, my Team submenu choice lacks the Branch... menu option. (It only shows "Apply Patch..." and a greyed-out "Share Project...")

So what are my options?
Try to get the m2e-svn plugin from somewhere else?
Use the command-line svn to create the branch? (How?)

[moomarc]

I know I also didn't see the m2v-svn plugin, but I do have the branching option. No idea what I did though (although I'm fairly sure I didn't download it from somewhere else).

[RumbleBBU]

I found and did install m2e Subversive and Subclipse plugins, though, which resulted in some weirdness, like two separate SVN checkout entries in the Import menu (one for each). So, in case one of them was interfering with the other, I tried uninstalling all Subversive related plugins.

Well, that didn't help.

[moomarc]

Are you using the 64-bit version of Eclipse? I think I got the double checkout when I tried installing that when I first switched my OS.

[RumbleBBU]

No, plain 32-bit.