Collectible Card Game Headquarters

I've been refactoring deckmanager, and found out that sealed and draft decks are technically the same thing. Both represent a set of decks which were build up from a limited cardpool and are supposed to play against each other. The number of decks in a set does not really play any role. We got used that draft is made for 8 players and sealed is played by two, but this can be changed with ease.

So I came up to a conclusion that we don't need the PlayerType, GameType and isCustomCube fields in deckfiles anymore.
A deck is a deck, no matter how it was created or which player should play it. To distinguish them, we'll use different folders for decks.
As for cubes, a decksection can be added into the very limited setup file.

So, I'm about to develop a branch that eliminates deckmanager, allows deckeditor to edit any collections (decks, decksets, limitedSetup)

I would tread carefully here. Sealed and Draft Decks have "Sideboards" which are all the extra cards not currently in the "Main" deck. A Constructed deck can't have a sideboard (yet). The deck editor needs to know that it's editing a draft or sealed deck in order to populate the Available Cards grid. A constructed deck would populate the grid with the entire card list.

I think max mistyped constructed for draft, and if that's it, unifying those two as "decks with a non infinite card pool" seems a good idea. in theory, at least

silly freak wrote:I think max mistyped constructed for draft, and if that's it, unifying those two as "decks with a non infinite card pool" seems a good idea. in theory, at least

Yea that's how I took it as well, since I was reading it and constructed didn't make sense, but draft would have made sense.

Sure, I'll proceed with care.

No, there was no mistype. Both draft and sealed are just a set of decks built from a limited cardpool. They are technica,lly the same entity - a few decks (2 or 8 for now, but these constants that can be changed with some effort), each deck contains a cardpool for chosen cards and another one (sideboard, yes) for the rest. Draft of sealed - are just different ways how the cards are chosen. You have to pick them one by one or just get the assorted cards, and the the paths are the same. We don't have to restrict sealed to 2 players, there may be 15 ai players for instance, assuming they recieve different boosters thier decks will we interesting to duel against (I wish they could compete each other to make a little tournament, but the AI, hardcoded to play against human, does not allow us to do so yet).
Anyway, after cards are distributed, sealed and drated decks are just the same thing. That's what I would love to implement.

Some people thanked me for the original post, I'm not sure it's a right time. Because that was just an announce to highlight the direction and ask other developers not to tough deck editors for a couple of weeks.

I believe the mistype that we are referring to is the following

I've been refactoring deckmanager, and found out that sealed and constructed decks are technically the same thing

whereas the title of the post says Draft and Sealed. And you just stated Draft and Sealed again right now.

friarsol wrote:I believe the mistype that we are referring to is the following

I've been refactoring deckmanager, and found out that sealed and constructed decks are technically the same thing

whereas the title of the post says Draft and Sealed. And you just stated Draft and Sealed again right now.

Right, there was one - will fix right now in original post.


Add: DeckEditors ... I guess they should be divided too. Constructed will have unlimited cardpool to take cards from, and limited might provide some tools to edit/view ai-picked decks from sealed/draft mode.

Building up a new constructed deck and re-arranging sealed mode deck are quite different paths and they might be found in different places of menu, so it seems to me, they don't have to be together.

I am still working on it.
There was made a huge refactoring of deck-editor, its menus and even limited game ui was affected

I merge every day and hope it will work the day of commit.

Should we go ahead and update the SVN by adding the four new subdirectories to the deck folder?

constructed
cube
draft
sealed

What about the three files that are located inside of the decks folder?

JuzamjediCube.dck
SkieraCube-cards_not_supported_yet.txt
SkieraCube.dck

Should we move these three files into the cube folder on the SVN?

I just upgraded the constructed submenu. Hopefully it will mesh neatly with Max's changes. I'll update as needed once this final folder structure is decided. Quest events will be available soon, after I examine the pre-game inits and whatnot (today).

FYI I'm getting an NPE in OldDeckParser. I've fixed it locally on my machine using a hack around line 126 (below).

Code: Select all

List<String> fileLines = FileUtil.readFile(f);
           Map<String, List<String>> sections = SectionUtil.parseSections(fileLines);
           DeckFileHeader dh = DeckSerializer.readDeckMetadata(sections);
           //////////////////TEMPORARY BUGFIX
           if (dh == null) {
               continue;
           }
           /////////////////
           String name = dh.getName();
           if (dh.isCustomPool()) {
               continue;
           }

Chris,

Yes, feel free to commit the folders to SVN. Forge will create them anyway if they are missing.

I have to write the conversion code for cubes, their serializer and a dialog with some options in their personal deck editor. Don't move the three files that remain, they will be converted automatically when the code is ready. I'll merge cube into individual files (1-per-cube) from that 2 .dck files and options actually stored in /res/draft and/or /res/sealed folders.

Doublestrike,
There is a deck file that causes the exception, please send it to me.

The folder structure with deck/(gametype) is final. But that is not significant, because a developer who works with decks can use the FolderMap<T> collections to access all decks formerly managed by DeckManager. The collections that are returned from AllZone.getDecks().get(GameType) are instantly syncrhonized to disk. Once you add an item, it gets saved right away, so your code doesn't need to care about the path where they are saved.

Max mtg wrote:Chris,

Yes, feel free to commit the folders to SVN. Forge will create them anyway if they are missing.

`
When I added the four subdirectories to the decks folder on the SVN all four of these folders are given a hidden file named ".svn". The Mac OS will also give these folders a hidden file named ".DS_Store".

It appears that these hidden files are being read in and handled as a deck file and this may be causing the crash reports.

Chris H. wrote:When I added the four subdirectories to the decks folder on the SVN all four of these folders are given a hidden file named ".svn". The Mac OS will also give these folders a hidden file named ".DS_Store".

It appears that these hidden files are being read in and handled as a deck file and this may be causing the crash reports.

This .svn directory might be the case for draft/sealed decks.
I'll improve the filter to accept only non-hidden directories as potential decksets

Thank you.

Ok, looks like I'm done with deck management.

What was done:
- Eliminated DeckManager class which was a container for all kinds of decks. Now decks are stored in their individual folders arranaged by type. Each folder is read by appropriate deserializer
- Created serializer classes which are to support the FolderMap class that makes changes to disk as items are added/removed to the collection it represents.
- DeckController class is the interface between deckeditors' menus and objects being edited collection. Editors and menus no longer interact with DeckManager directly and do their job (of presenting user an interface to interact with) only
- Refactored DeckEditors' menus, derived a base class and removed duplicate code.
- FileSection utility will help in parses of key-value sections, such as deck metadata or quest challenge options. It reads all K-V pairs to a map with case insensitive keys and allows us to retrieve thier values as strings, boolean or integers.
- There is also a convertor class that will arrange unsorted decks from /res/decks folder to a right folder.

It's time to catch bugs now. I'll keep an eye on this topic and nighty-bugs one.
If you report a crash, the deck-file that caused the problem will be highly appreciated.