The AI wall

So.. I ‘ve kind of hit a wall with the AI. I just realized that the paradigm shift I talked about in the last posts is incompatible with my elegant solution for spell effects. Currently, I use the .Net IEnumerable type with the yield keyword so that I can very briefly write the code for a spell. See my post on Shock for an example of this. But, to construct the minmax tree, one has to try all the possible answers whenever there is a choice involved. Which happens a lot during a spell is played (targeting, paying costs, etc…). But with IEnumerables, I can’t “go back” and try to “play the cost” differently. So I’m stuck with destroying my beautiful scheme 😦 but I can’t resolve myself to do it. There must be a way around it 🙂

I have this hunch that there is something wrong with my basic hypothesis and that there is a better way to handle the game flow.

For those implementing minmax, how did you resolve this problem? How do you describe the flow of the game in your engine? How do you code card rules?


About fparadis2

Lead Game programmer
This entry was posted in Mox. Bookmark the permalink.

5 Responses to The AI wall

  1. mtgrares says:

    Yes everybody hits walls and you aren’t sure what to do. Hopefully something comes together in your head, (thats how I get through walls.)

    I laughed at your min-max AI tic-tac-toe stuff that when the board was like:

    X X _
    _ O _
    _ _ _

    and the AI wouldn’t block the 2 Xs. I guess the evaluate board function was the same no matter where the AI put the X so the AI puts the X in the first place that it searched. (This is just a guess since I haven’t used min-max yet but I want no.)

    I want to use min-max for the AI on future versions of MTG Forge. Even a very shallow search tree would improve MTG Forge’s AI.

    I also view the creature combat min-max is separate from the “play a card” min-max, although I know that Magic entangles both parts making everything more complex but harder to code.

    Keep up the good work and thanks for the link to my blog,

  2. Snacko says:

    Most likely you thought about it yourself, but you could switch from the IEnumerable to some collection type and iterate back and forth on it, however depending on you code this might be a suboptimal solution.

  3. fparadis2 says:

    Hehe, that’s exactly what happened with the tic tac toe AI. I don’t see why you would separate the combat AI from the normal AI. They are intertwined. What if combat might kill a creature that has a static effect out of combat? The AI needs to make decisions that are consistent across the game. Anyway, I think if the system is well designed, the min-max implementation should be transparent across the board.

    The problem with lists is that I lose the elegance of the my solution. My solution allows the result of a cost to influence the actions to do next. For example, a target cost might influence what to do next whether it’s a creature or a player that’s been targeted. This is possible in my current model because costs are evaluated *as they are yielded*. The first cost can influence what costs come next.

    Thinking about it, I might be able to cheat and use a list and then have conditions for my costs so that they are only used when needed based on the result of previous costs. I don’t think it’s such a common case anyway in the MTG rule domain. I’ll continue thinking about it…

  4. Snacko says:

    Thinking about it now it might be better to create a wrapper that will store the already evaluated possibilities and actions that lead to it. This way you can explore all the possibilities and keep track of it.
    I don’t know your code but it looks possible with your current design as you can keep the game state / rewind it (you’re using the command pattern which allows to keep as many possible game states as you want) and replay the events with IEnumerables while choosing different options.

  5. fparadis2 says:

    Yeah, I think that’s what I’ll do.. instead of enforcing that only one “fork” per “game flow element”, I’m gonna change the system so that it can “remember” the choices as they are made so that the *whole* spell can be “replayed”. Less performant, because you have to rewind all the way to the beginning of the spell and play it all again for all combinations of choices during the spell (instead of just rewinding to the last choice), but it allows me to keep the spell code simple for “card coders”.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s