Thread: [Essentials script] Pokémon TCG mod
View Single Post
  #162    
Old April 18th, 2013 (05:44 AM).
TheDarkShark
Metal Headed Hacker
 
Join Date: May 2010
Location: Germany
Gender: Male
Nature: Calm
*blows away dust*
Sorry for reviving this thread (I'll assume these rules apply in this subforum, too, because no limit to thread revival is mentioned in the specific rules), just found it again.
Since you already said, you'd finish this definetly, I'll gladly state that I still have interest in this project. In fact, I think I might be able to help you with the AI, though I still haven't looked into Ruby. I'm probably the only one who recently read the entire thread, so I'm going to quote the particular part I'm talking about:

Quote:
Originally Posted by Maruno View Post
I really don't think such strategies need to be separated. It all boils down to "use the best cards", and what constitutes a "best card" depends on the environment (i.e. what other cards are in play, etc.). This can certainly become convoluted very quickly as the AI develops, as there'll be all sorts of checks and evaluations. This is especially true when you start thinking of combos.

Of course, the AI is going to cheat. That is, it'll make its choices while knowing about cards it shouldn't be able to know about (e.g. cards in the player's hand, which prize card is best to take, whether it'll draw something good because of Professor Oak). However, it won't influence the outcomes of coin flips or whatever, so it'll be fair that way. I think making the AI omniscient is the only way it can be made to stand a chance against players.

As for how the AI will actually work, I have a vague idea. At the start of its turn, it looks around the duel and lists everything it is able to do (play a card from the hand, use an in-play effect such as a Pokémon Power, retreat, etc.), and then assign a desirability value to it. Calculating this value for each action depends a lot on the environment, and is the convoluted part. Once all the values are calculated, it will do the most desirable action and repeat (recalculating the values for what's left). Once there's nothing left to do, it will attack if possible and desirable - the good thing is that an attack is always the last thing in a turn (and there's always just 1 attack per turn), which makes it a bit simpler.

It sounds simple when I write it in just one paragraph, and some actions will always be desirable (e.g. play Bill) and some will never be worth using (e.g. Mankey's Pokémon Power, as the AI will know all those cards via cheating anyway). However, when is the best time to play Energy Removal, and which Pokémon/energy should be hit by it? How about Super Energy Removal, which involves a cost to the user and may not be worth it (and if so, which card should the AI pay)? There's a huge amount of thought that needs to go into the AI for even a single effect, and I think that such thought needs to be done in order to make the AI worthwhile.

Tuning can come much later, e.g. deciding the threshold desirability value below which an action shouldn't be done, and how much randomness to involve in the choices.

As you can see, any emergent "strategy" will depend entirely on the make-up of the deck. It can only depend on the cards you've got available ("work with what you've got"), and it's up to the AI calculations for each card to decide how useful (and therefore desirable) it is. The overall behaviour of the AI will simply look like what it does the most, which depends on what it's got (e.g. an energy-controlling strategy will appear if there are a lot of energy-controlling effects in the deck). I don't think there's any need to include deck-specific AI profiles (particularly as it would tend to rail-road and hurt decks which could sometimes benefit from profiles they don't have), and instead throw every situational calculation into the one AI used for everything.
This reminds me a lot of Dragon Age's threat system, which basically makes each individual enemy attack the character that poses the greatest threat to them. If you're interested in it, as some kind of reference, a better explanation can be found here.
Why do I think this is relevant? Well, depending on the game's difficulty settings, the equipped armor and weapons increase the threat, making enemies on lower difficulties more likely to attack your tank. Let's think this idea through a little bit:

Let's say there's a number of variables that scale the desirability of each action. This could be used to individualize the playstyle of characters and adjust the AI to the deck. Assume, for instance, the previously discussed evolution-/base-decks, where evolving pokémon and getting energy on base-pokémon should have different priorities. If there's two floats named evolution and baseEnergy, respectively, these could be set in the PBS-entries. In the evolution themed deck, you'd set evolution=1.1 and baseEnergy=0.8. The desire to play an energy on a base pokémon would be multiplied by 0.8, and the desire to evolve a pokémon by 1.1.
Of course, you'd need more variables (and better names), but I'm pretty sure this would pay off, since you'd have to do a lot less fine tuning (except for standard values, when the user doesn't set them for the deck).

To simplify the decision on what trainer card to play, you could also categorize them and apply values. Let's say both Bill and Professor Oak are in the category deckspeed (that's what this kind of cards are used for in YGO, anyways), Bill would have the value 20 and Professor Oak would have the value 40 (arbitrary example, don't count on me for the exact balancing). If you assume a float deckspeedPriority, similar to the previous evolution and baseEnergy variables, the cards would get assigned the proper desire. If deckspeedPriority=1.5, playing Bill would stand at 30 desire, and Professor Oak would stand at 60.
I'll admit though, that this is not optimal, since Professor Oak makes you toss all cards in your hand, so the desire should be decreased depending on what cards the CPU player currently has. Applying multiple properties to a card might help. To keep the example going, assume Professor Oak had the properties deckspeed 70 and toss 0, where 0 basically means all. The desire to play Professor Oak would then be 70 * 1.5 = 105, reduced by an appropriate amount of desire, depending on the number of cards.

If you want actual strategy, as in playing combos of cards that work well together, consider having the user specify them for the deck. If none are specified you're fine. However, if the AI's supposed to wait for this card in the deck before playing that card, the desire to play that card would be drastically reduced, maybe by the priority of the combo.

All of these are ideas I came up with while brainstorming, haven't really done much more thinking, though. I know, they look like a lot of extra work, but please consider them at least.
__________________
There are two things every Rom-Hacker should learn:
1. Don't give away everything you know!