Encapsulate Quest Opponents in Deck Files

[Sloth]

To get this controversial issue done, I started this topic for a constructive discussion on how to handle this.

Here's how I imagine this:
- The contents of the special quest files (quest1.dck,...) stay as they are (maybe change Deck Type to something else than constructed), but they may get another file type (like .qst).
- Some class in the quest department will read the additional information from the files, the decklist will still be read by the deckManager.

Is this doable doublestrike?

[Doublestrike]

@Sloth - definitely doable, but I'd like to get some confirmation from others before I start.

=======

Another option I was thinking of that may work with Max mtg's vision is to have regular dck files be handled in the quest. These files could have a standard piece of metadata that referred to a "helper" file.

When that piece of metadata is retrieved, it moves to a class that handles the various types of extras that files need (now and in the future, for the fun possibilities).

For example

Code: Select all

[metadata]
foo=bar
Name=detective.dck
DisplayName=Adrian Monk
HelperFile=puzzles/puzzle172.pzl
[main]

========

I'd also like to tentatively suggest a second option: Introduce a new deck type :dodging-rotten-fruit: that could allow departures from the standard MTG rules, into the flexibility of a digital environment. Limiting ourselves to cardboard rules seems...well...then we should play with cardboard.

For example

Code: Select all

[metadata]
foo=bar
Name=kingofplop.dck
DisplayName=Michael Jackson
DeckType=gauntlet
[main]

========

While we're here, you may have noticed I decoupled the file name from the display name using the metadata. Curious to know the opinion on that.

[Sloth]

The second option sounds like the way to go (the first is a little bit too clunky for my taste). Clean decklists will be dck files and those with additional metadata will get another file type.

While we're here, you may have noticed I decoupled the file name from the display name using the metadata. Curious to know the opinion on that.

Don't know if we ever need this, but definitely can't hurt.

[Max mtg]

Another option I was thinking of that may work with Max mtg's vision is to have regular dck files be handled in the quest. These files could have a standard piece of metadata that referred to a "helper" file.

When that piece of metadata is retrieved, it moves to a class that handles the various types of extras that files need (now and in the future, for the fun possibilities).

No need for helper file. The same file can be passed to different parsers, one of which would read the deck into its class and another(s) the quest's difficulty, aiLife, extraCards and so on...

That will keep all data in one file and the classes involved clean and simple.

[Max mtg]

Just commited a fix to Deck class removing metadata, which could contain a lot of data unrelated to deck.

There is a class QuestEvent = it holds the extra data for a battle, not read by DeckManager

In order to complete DoubleStrike's task, he might want to read the extra fields form the quest challenge deckfile into Quest_Assignment class

[Max mtg]

Moreover, given that QuestQuest decks are moved to a separate directory, we'll no longer need files like easy.txt - these lists will be filled just by iterating over every deck in folder, reading its difficulty and then grouping things into a map difficulty -> list<string> or event list of QuestEvents

[Chris H.]

We now have a large number of decks (battle format) that are playable by the AI. Do we want to consider using these decks elsewhere in forge?

People have suggested a gauntlet mode. The AI battle format quest decks could be used here as well.

We also have an option in constructed deck mode where we can select "Random" in the deck selector for ourself and the computer.

Currently, the code randomly selects from among the decks located in the /res/forge/ folder. It might be nice to have an option to have the computer select from among the quest mode battle decks instead.

It might be worthwhile to add a difficulty metadata field to the normal Deck class. Or the difficulty setting could be parsed by looking at the number at the end of the deck name.

Whatever decisions that we make at this time, it would be nice if we could also plan for a system which allows the AI battle format quest decks to be used elsewhere in the game.

[Max mtg]

It might be worthwhile to add a difficulty metadata field to the normal Deck class. Or the difficulty setting could be parsed by looking at the number at the end of the deck name.

Whatever decisions that we make at this time, it would be nice if we could also plan for a system which allows the AI battle format quest decks to be used elsewhere in the game.

Chris, please... stop mixing up deck with predefined challenge or something else.
I've just REMOVED metadata map from decks, replaced it by some fixed fields, because people start adding there (into the deck class I mean) a lot of unrelated to deck fields, such as opponent's starting lives.

Let's define deck as a set of cards that become player's library when the game starts. All other data is not part of deck - well, it may be stored in one file with deck, but it should have no place in the class.

The difficulty field is already in the deck files, but it's stored into QuestEvent class, which is kinda model for the panels representing opponents in quest mode.

[Chris H.]

I am sorry for the confusion.

We have two different types of quest decks. The first is the battle decks and the second type is the special quest decks. My last message is in reference to the battle decks only.

The special quest decks are only useful in the quest mode. These decks all have the file name convention of "quest" + number + ".txt".

The battle decks do not have cards that start in play. These decks start with 20 life and there are no extra reward for beating them. The battle decks all have the file name convention of opponent name + number(1 through 4) + ".txt".

The battle decks are basically a normal deck that contains cards that the computer can use to good effect and therefore provides a good challenge. I am suggesting that we may be able to re-use the battle decks elsewhere in the game.

The special quest decks would be treated differently and they would not be used in a gauntlet mode or as a random deck in constructed mode.

[Sloth]

The question is, if we also want to convert the "battle" quest decks to the new file type, because they have some metadata stored in them (like diffifculty) that's only used in quest mode.

I think it would be a good idea. Then all files in the quest\decks folder will have the same file type.

I've just REMOVED metadata map from decks, replaced it by some fixed fields, because people start adding there (into the deck class I mean) a lot of unrelated to deck fields, such as opponent's starting lives.

Let's define deck as a set of cards that become player's library when the game starts. All other data is not part of deck - well, it may be stored in one file with deck, but it should have no place in the class.

Maybe we should leave the Description in the normal deck files too. Maybe we can show it when selcting a deck in the future (some users tend to have hundrets of decks in their folder and I doubt they can remember what deck they were).

[Max mtg]

we may just put those into different folders and neither convention will be needed nor easy.txt hard.txt medium.txt veryhard.txt files.

Yes, that would be nice if these decks were offered for playing in constructed mode.

Then all files in the quest\decks folder will have the same file type.

Really all?

Maybe we should leave the Description in the normal deck files too. Maybe we can show it when selcting a deck in the future (some users tend to have hundrets of decks in their folder and I doubt they can remember what deck they were).

Comment is still there - well, it can be renamed to description if you'd like to.
Or that separate description field may be added - no matter, the main thing that deck class (not file) should not contain any data affecting match rules.

[friarsol]

It sounds like this discussion is suggesting how I originally pictured this feature request in my head.

The Quest Files itself will be one file (including removal of easy.txt, etc). This file will Be parsed by the Quest object that contains a Deck object, which will parse out the deck from that same file. This Deck object will work as Max set it up to work currently. The Quest Object will hold specific metadata about where it can be used.

It might be worth allowing each file to have metadata for all of the non-standard forms of play. That way these Quest files will be available in more than one play-mode at different difficulty levels.

Considering that a Gauntlet mode is for loading a Constructed deck and playing against increasingly difficult opponents, the starting deck is going to be much much better than the starting Quest deck. Some of the Easy Quest Battle decks aren't even appropriate for Gauntlet Mode (such as the Leprechaun deck).

Example:

Code: Select all

[metadata]
Decktype=quest,gauntlet
QuestDifficulty=hard
GauntletDifficulty=medium
[/metadata]


[Doublestrike]

Let's define deck as a set of cards that become player's library when the game starts. All other data is not part of deck - well, it may be stored in one file with deck, but it should have no place in the class.

the main thing that deck class (not file) should not contain any data affecting match rules.

This sounds like something everyone agrees on, and is a good idea, and should be included in the class documentation somewhere.

So, to further define what we're talking about, it sounds like the metadata can hold any information. Of course, the deck class has a "new" format that can retrieve any meta attribute, instead of the "old" which had specified metadata.

It might be worth allowing each file to have metadata for all of the non-standard forms of play.

Comment is still there - well, it can be renamed to description if you'd like to. Or that separate description field may be added

=========

OK, so we've got:

Code: Select all

[metadata] //parsed and returned by deck class but never used by deck class
can=put
anything=relevant
to=the
match=parameters
or=display
[main]
1 only
1 legal
1 cards
4 here
[sideboard]
1 usually
1 strangely
1 empty
1 but
1 has
1 potential


=======

The remaining two questions, for me, are:

1) What to do about starting cards for AI(s) and Human?

2) Where to store tokens?

[Max mtg]

You may add new sections for them, deckmanager will read only the data it needs (name, main & side). Your parser will grab the rest

You are really free to add anything to metadata, yet I'd suggest storing challenge-related data in its own section.

Also, be sure you have updated your codebase to 10249 at least, where Deck has fixed fields instead of too flexible metadata map.

[Doublestrike]

OK, so the structure

Code: Select all

[metadata]
[main]
[sideboard]
[ai_extra_cards]
[human_extra_cards]

is now acceptable?

And, those fields are retrieved by the deck manager class?

And, may "illegal" tokens be stored there with the pattern I described? (as long as they are processed by a non-deck class, like QuestUtil)

Also, be sure you have updated your codebase to 10249 at least

Won't be making that mistake again.

where Deck has fixed fields instead of too flexible metadata map

Not sure what you mean by this? It was sounding like the flexible meta was a positive thing?