Collectible Card Game Headquarters

Doublestrike has commited a deck class which contains extra AI and human cards:

Code: Select all

public final class Deck implements Comparable<Deck>, Serializable {
    //gameType is from Constant.GameType, like Constant.GameType.Regular

    private Map<String, String> metadata = new HashMap<String, String>();

    private CardPool main;
    private CardPool sideboard;
    private CardPool humanExtraCards;
    private CardPool aiExtraCards;

Who else thinks it is a good idea to store extra cards in a deck?

I'm curious about a few things. What would go in the extra cards, and does it need the set of extraCards need to be different for AI and Human?

friarsol wrote:I'm curious about a few things. What would go in the extra cards, and does it need the set of extraCards need to be different for AI and Human?

Doublestrike added these for the special quest decks.

quest2.dck looks like this now:

| Open

[metadata]
ID=2
Name=quest2
DisplayName=Dungeon Crawling (Blue)
Difficulty=Medium
Description=This realm holds knowledge so vast it can overburden the unwary.
Repeatable=true
NumberWinsRequired=20
CardReward=3 blue rares
CreditsReward=100
Icon=Dungeon Crawling Blue.jpg
AILife=25
Deck Type=constructed
Comment=
[main]
20 Island
4 Wasteland
1 Cognivore
4 Visions of Beyond
1 Bonehoard
1 Conversion Chamber
4 Veil of Birds
1 Veiled Apparition
1 Veiled Serpent
1 Straw Golem
1 Isolation Cell
1 Chimeric Egg
1 Soul Barrier
4 Aven Fogbringer
4 Glowing Anemone
2 Cloud Pirates
2 Cloud Sprite
1 Cosi's Trickster
1 Water Wurm
1 Wandering Ones
1 Slippery Bogle
1 Merfolk of the Pearl Trident
1 Fugitive Wizard
1 Grayscaled Gharial
[sideboard]
[human_extra_cards]
1 Quest for Ancient Secrets
[ai_extra_cards]
1 Forced Fruition

friarsol wrote:I'm curious about a few things. What would go in the extra cards, and does it need the set of extraCards need to be different for AI and Human?

`
I think that the term "extraCards" may be referring to the cards that are in play at the start of a match. If I am correct, then the card list for the AI would be different from the list for the human.

EDIT:

Thank you Sloth for that additional info.

You are right, Chris
It turns out that a deck begins holding not only information on it's user's initial library, but some rules to enfornce on an opponent.

I'm taking this very seriously. If we accept such changes and say "oh, it's okay, let the deck hold opponent's staring life and cards he should start with", then Forge will never come to being something simple and easily managed. Because entities named in one way will behave as if they were something else, methods will do some side calculations besides what they were meant to do.
Let me give you some examples, that I've already met and eliminated: generating cards for sale in shop at Shop UI, calculating rewards for quest both in QuestData and Gui_WinLose, passing the card list N times in order to apply N filters to the same list, copying code over and over...

I am very upset to see that my work on clearing up things, grouping functionality into classes, separating view from game logics, eliminating duplicates and keeping everything in a simple and logical way is being ruined with changes like this one.
Moreover, I strongly dislike that some people consider an acceptable thing to keep code with compile errors in the repository, instead of fixing that ASAP (not in 12-16 hours) or rolling back changes.

Max mtg wrote:You are right, Chris
It turns out that a deck begins holding not only information on it's user's initial library, but some rules to enfornce on an opponent.

I'm taking this very seriously. If we accept such changes and say "oh, it's okay, let the deck hold opponent's staring life and cards he should start with", then Forge will never come to being something simple and easily managed. Because entities named in one way will behave as if they were something else, methods will do some side calculations besides what they were meant to do.
Let me give you some examples, that I've already met and eliminated: generating cards for sale in shop at Shop UI, calculating rewards for quest both in QuestData and Gui_WinLose, passing the card list N times in order to apply N filters to the same list, copying code over and over...

I am very upset to see that my work on clearing up things, grouping functionality into classes, separating view from game logics, eliminating duplicates and keeping everything in a simple and logical way is being ruined with changes like this one.

`
Max, lets calm down and try to look at this from a reasonable and rational position. To be honest, I do not have the perfect solution to the deck issue. All I have is several years of experience gained through discussions on this forum.

Currently, some of the info for the quest opponents (battle opponents and quest opponents) are included in the .dck file. Some of this info is contained in the 4 text files "easy.txt", "medium.txt", "hard.txt" and "veryhard.txt". Some of the info is hard coded. Oh, and some of the data is in the file named "quests.txt".

The past and current systems used for creating/editing/testing these special quest opponent decks was overwhelming for most people. We have people who would like to help with this but the tech needed is holding them back.

I can remember the old days helping Dennis to create/edit/test the special quest opponent decks. I was able to help in this area but I did quickly burn out.

I also can remember when all of the human and the AI decks were contained in a single file. Ugh. This explains the no longer needed import and export commands.

Having all that metadata in a single file could be considered by some people to be confusing. But having that data spread out in so many different areas of our project may not be the best solution either.

Max mtg wrote:I'm taking this very seriously. If we accept such changes and say "oh, it's okay, let the deck hold opponent's staring life and cards he should start with", then Forge will never come to being something simple and easily managed. Because entities named in one way will behave as if they were something else, methods will do some side calculations besides what they were meant to do.
Let me give you some examples, that I've already met and eliminated: generating cards for sale in shop at Shop UI, calculating rewards for quest both in QuestData and Gui_WinLose, passing the card list N times in order to apply N filters to the same list, copying code over and over...

As I said, please go ahead and correct the classes as you see fit. And if you insist, you can also change the file type of the special quests to something else (as long as all information for the quest is stored in one file, i'm ok).

Max mtg wrote:I am very upset to see that my work on clearing up things, grouping functionality into classes, separating view from game logics, eliminating duplicates and keeping everything in a simple and logical way is being ruined with changes like this one.
Moreover, I strongly dislike that some people consider an acceptable thing to keep code with compile errors in the repository, instead of fixing that ASAP (not in 12-16 hours) or rolling back changes.

We all want to make forge a better game. Doublestrike just started out working on the project a few days ago. The code is so lengthy, how could he grasp what direction your changes were going in? And we all make mistakes.