Collectible Card Game Headquarters

Certain cards are hardcoded simply because they react well specifically with other cards. Thopter Foundry can easily be fixed so it no longer targets, but by doing so the AI loses the "combo" of sacrificing Sword of the Meek if it's in play. I was trying to think of an elegant way of doing this that would move the preference from hardcoded to the data file.

So maybe for the above example of Thopter Foundry + Sword of the Meek, Thopter could have an additional SVar.

Code: Select all

SVar:AIPreference:SacCost$Permanent.namedSword of the Meek


And in ComputerUtil we look for AIPreference at appropriate locations:

Code: Select all

  static public Card getCardPreference(Card activate, String pref, CardList typeList){
     String[] prefValid = activate.getSVar("AIPreference").split("\\$");
     if (prefValid[0].equals(pref)){
        CardList prefList = typeList.getValidCards(prefValid[1].split(","));
        if (prefList.size() != 0){
           prefList.shuffle();
           return prefList.get(0);
        }    
     }
     return null;
  }
 
  static public Card chooseSacrificeType(String type, Card activate, Card target){
      PlayerZone play = AllZone.getZone(Constant.Zone.Play, AllZone.ComputerPlayer);
      CardList typeList = new CardList(play.getCards());
      typeList = typeList.getValidCards(type.split(","));
     if (target != null && target.getController().equals(AllZone.ComputerPlayer) && typeList.contains(target)) // don't sacrifice the card we're pumping
        typeList.remove(target);
    
     if (typeList.size() == 0)
        return null;
    
     Card prefCard = getCardPreference(activate, "SacCost", typeList);
     if (prefCard != null)
        return prefCard;

      CardListUtil.sortAttackLowFirst(typeList);
     return typeList.get(0);
  }


I added the above code, plus changed Foundry to use abCost and the AI was sacrificing only the Sword.

Thoughts?

I agree. Using SVars for combos is much better than hardcoding stuff.

Actually I thought about adding the SVars to the sacrificed cards.

Cards that could use them: Hatching Plans, and Academy Rector.

Or for discard costs: Squee, Goblin Nabob.

Good.

We could probably have it work both ways. I would think if the card has a specific card it likes being combo'd with that would happen first. Then we would check for just anything that likes being paid in a certain manner.

We probably need two different functions for this. One for cards that like paying costs with certain valid cards, and one for cards that like being used to pay for costs.

friarsol wrote:We could probably have it work both ways. I would think if the card has a specific card it likes being combo'd with that would happen first. Then we would check for just anything that likes being paid in a certain manner.

We probably need two different functions for this. One for cards that like paying costs with certain valid cards, and one for cards that like being used to pay for costs.

This would be optimal!

Maybe we should make a sticky topic with all AI specific SVars we use?

You can start an SVar topic with a listing of SVars and I will make it a sticky.

I really think these should be in a separate file rather than on the cards. That way, the AI would look down a list for cards it has, and then select the first one available.

zerker2000 wrote:I really think these should be in a separate file rather than on the cards. That way, the AI would look down a list for cards it has, and then select the first one available.

I don't see how that's better. Instead of looking at what the AI has available in play, it loads up a completely separate list that he might not have any of? Now we have to keep up to date with yet another text file, instead of the one for the cards that are already loaded?

Maybe if all our data was stored in a database that could be better, but since we don't use that format, I don't think it makes as much sense.

The static list would be filtered down to the cards in the AI deck each game. And it's better because the cards are checked in order, so any Basking Rootwalla would be discarded before Squee, Goblin Nabob.

But it's still another list we have to keep track of and update. I think this is a huge negative that we've been slowly moving away from, and isn't necessary here.

Your second point is the true goal here. We could create a basic scoring system out of the cards that like being paid with certain costs, instead of having a linear list.

Madness cards would have a higher score than Squee (although they should be removed if the AI can't afford the madness cost). etc.

Madness is already a property the AI Discard code can look for.

Take Squee for example... he would need many AI hints as he's
good for discard costs, good for sac costs, good for attacking and good for blocking....

I've added support for the SacMe Svar to getCardPreference. The code is still too specific for my taste but works (I tested with Crop Rotation).

The SVar is an integer, so we can give a priority order.

Examples:

Priority 5: Cards that have no other use than to be sacrificed:
Hatching Plans has SVar:SacMe:5

Priority 4: Cards that have not much other use than to be sacrificed:
Academy Rector has SVar:SacMe:4

Priority 3: Sacrificing these cards makes no big difference:
Flagstones of Trokair has SVar:SacMe:3

Priority 2: Sacrificing these cards won't cause card disadvantage:
Squee, Goblin Nabob has SVar:SacMe:2

Priority 1: Sacrificing these cards has a bonus:
Gods' Eye, Gate to the Reikai has SVar:SacMe:1

Priority 0: Sacrificing these cards has a small bonus:
???

Any wishes for changes?

Yea I think we should hold off on adding too much to any of these until we can create a better structure for it. I had those fixes for the Foundry in my code base and was causing some issues with merges. Maybe we can figure out a way to make it more streamlined for anything.