Dominion Strategy Forum

Please login or register.

Login with username, password and session length
Pages: 1 [2] 3 4 ... 13  All

Author Topic: Dominiate: a Dominion simulator that runs on the Web  (Read 56065 times)

0 Members and 2 Guests are viewing this topic.

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #25 on: September 12, 2011, 12:16:36 pm »
0

I have made some modifications to the sources for Trade Route.

I kept it simple:
- Added a Trade Route "Mat" (array) and Value (int) to the State.
- Whenever a card is gained, it fires and checks to see if TR is in play, the card is a VP card and already on the list and adds the card and sets a new Trade Route Value if the card is not yet on the list

I even sent a Pull Request I believe.

I am new to GitHub, so bear with me.


I wanted to add the event to the VP cards instead of the main gainCard() method, but I could only find an overridable Buy method and not Gain.
I think a Gain method may be needed not only for this, but other cards as well, but my understanding of the source is still very little, so maybe you can do the rest of the work.

I've debugged and merged it -- thanks! I also added it to the default action priority, near the end, but there should actually be some sort of condition there, because there are many situations where you'd prefer not to play Trade Route. SillyAI is playing it with hands full of expensive cards sometimes.

As an event triggered when an entire type of card is gained, the main gainCard() method is a good place for it. I don't think gainEffect() is necessary.
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #26 on: September 12, 2011, 12:19:59 pm »
0

Hello,

  Amazing work! Keep it going :)

  I found one problem with trashing. I was experimenting with fishing villages, and noticed bot wants to leave at least 3 coppers before trashing them. And when counting coppers it does not include fishing willage's +1 coin. So it leads to situations, where it thashes less than it should to. I copy/pasted one example. Here bot has already bought fishing village, so it needs two coppers to keep buying power, but it keeps three of them. I guess trashing algorithm is hard coded, but maybe i am wrong? Here is log:

I'm trying to hard-code as little as possible -- the hardcoded things are things like always revealing a Moat. The trashPriority can be overridden by AIs. You can see the default one in http://rspeer.github.com/dominiate/docs/basicAI.html.
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #27 on: September 12, 2011, 12:26:02 pm »
0

Okay, here's the list of cards that are done and not done:

https://github.com/rspeer/dominiate/blob/master/card_list.txt

We're up to 64 cards (including the 10 base cards and 5 prizes)! There are still some easy ones left to code, too.
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #28 on: September 12, 2011, 12:31:37 pm »
0

Nice.

How hard would it be to make a councilroom feature where you can start from a given turn from an already played game and simulate from strategies from there?  We could make the simplifying assumption that both decks start shuffled.

One sort of hard part would be getting the game state from that turn in that game. I see why you suggest starting by shuffling both decks -- because CouncilRoom already has some JS that counts the number of cards in each deck and the supply.

Then we'd also need some UI for starting Dominiate in a mid-game state.

It sounds cool but kind of fiddly to code, so I probably won't get to that kind of thing for a while.
Logged

Davio

  • 2012 Dutch Champion
  • *
  • Offline Offline
  • Posts: 4733
  • Respect: +3300
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #29 on: September 12, 2011, 01:04:26 pm »
0

Ambassador can be somewhat of an AI challenge, since it can be challenging for humans.

In this hand (let's say after you've been Minioned): Copper-Copper-Estate-Ambassador
What do you reveal/return? 2 Coppers or the 1 Estate. If you're Minioning yourself, then I think the 2 Coppers are better since you need to thin your deck as much as possible. Otherwise, the useless Estate could be better.

And then there's TR and KC. We might want to tell the AI not to return until the 2nd or 3rd time or something, but this also depends very much on the cards in hand.

KC-Ambassador-Curse-Curse-Curse is easy for humans, since you'll just return 1 at a time or 1 times 1 and 1 times 2, but you have to have at least 1 for the third time.


So all in all, I can see some challenges here, but maybe Geronimoo is willing to put some of his ideas here, since he has a lot of experience with his own.
Logged

BSG: Cagprezimal Adama
Mage Knight: Arythea

WanderingWinder

  • Adventurer
  • ******
  • Offline Offline
  • Posts: 5275
  • ...doesn't really matter to me
  • Respect: +4334
    • View Profile
    • WanderingWinder YouTube Page
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #30 on: September 12, 2011, 02:03:32 pm »
0

As a general strategy point, you most often want to prefer returning two coppers to one estate. This comes up a lot in early-game amb-cop-cop-cop-est hands.

ackack

  • Explorer
  • *****
  • Offline Offline
  • Posts: 302
  • Respect: +19
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #31 on: September 12, 2011, 02:11:31 pm »
0

As a general strategy point, you most often want to prefer returning two coppers to one estate. This comes up a lot in early-game amb-cop-cop-cop-est hands.

I don't think this is as obvious as a lot of people seem to think it is, and I think it's pretty dependent on what else is out there. Decks that Ambassador 1 Estate exclusively in this spot (which certainly isn't optimal, but as an experiment) end up substantially fatter but also substantially wealthier than decks that Ambassador 2 Coppers exclusively. I suspect a strategy like send an Estate the first time and then 2 Coppers thereafter probably works pretty well. If you have some way of playing 2 Ambassadors at a go, then it might be more worthwhile to winnow down as fast as possible.

added: questions in a similar vein are Remaking Coppers vs. Estates early, or whether a Steward and 4 Coppers should trash or buy Gold. In general I lean towards buying power unless there's some engine I'm building that needs to be trimmed down as fast as possible, or if there's some other specific reason I want to get Copper out of the deck (I'm playing Venture, I'm defending against Pirate Ship, etc.)
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #32 on: September 12, 2011, 02:29:59 pm »
0

Okay, this is making it clear that the next time I can justify coding on this, I should implement Ambassador. And then we can make different bots with the two different Ambassador rules, and actually find out whether it's better to return one estate or two coppers in general.

TWO STRATEGIES ENTER. ONE STRATEGY LEAVES.
Logged

WanderingWinder

  • Adventurer
  • ******
  • Offline Offline
  • Posts: 5275
  • ...doesn't really matter to me
  • Respect: +4334
    • View Profile
    • WanderingWinder YouTube Page
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #33 on: September 12, 2011, 04:15:08 pm »
0

Also note I said 'in general' - I expect this is probably 80% of the time, and it's based on my experience, which I think is pretty good, but not, of course, infallible.

Kirian

  • Adventurer
  • ******
  • Offline Offline
  • Posts: 6759
  • Shuffle iT Username: Kirian
  • An Unbalanced Equation
  • Respect: +8652
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #34 on: September 12, 2011, 04:41:23 pm »
0

Quick feature requests:

A "Stop" button for when pressing "until one strategy dominates" can run for thousands of games.  A "Run until stopped" button would be useful too but less interesting.

A "Reset" button.  When I make a small tweak to one strategy or the other, as far as I can tell, the only way to reset the wins to zero is to F5... which also resets anything else.

Otherwise, a great little app!
Logged
Kirian's Law of f.DS jokes:  Any sufficiently unexplained joke is indistinguishable from serious conversation.

WanderingWinder

  • Adventurer
  • ******
  • Offline Offline
  • Posts: 5275
  • ...doesn't really matter to me
  • Respect: +4334
    • View Profile
    • WanderingWinder YouTube Page
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #35 on: September 12, 2011, 04:54:34 pm »
0

When I click to simulate 100 games, it will go to where there are 100 more games in the current bank of games than there were in the previous, even if I've switched the strategies. i.e. if I simmed 500 games with strategy A vs. strategy B, and then want to sim C vs. D, it starts back at 0 and sims 600 games.

michaeljb

  • Saboteur
  • *****
  • Offline Offline
  • Posts: 1361
  • Shuffle iT Username: michaeljb
  • Respect: +1953
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #36 on: September 12, 2011, 05:50:48 pm »
0

I'm an aspiring programmer (still finishing my undergraduate), with a little experience, and this looks like a fun project to get some experience with and learn some new stuff. Hopefully I'll be able to code some cards while there are still some left  :P
Logged

michaeljb

  • Saboteur
  • *****
  • Offline Offline
  • Posts: 1361
  • Shuffle iT Username: michaeljb
  • Respect: +1953
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #37 on: September 12, 2011, 06:02:51 pm »
0

Ok, how's this look for Tactician?

Code: [Select]
makeCard 'Tactician', duration, {
 cost: 5

 playEffect: (state) ->
  discardCards = no

  if current.hand.length > 0
      discardCards = yes

  state.requireDiscard (current, current.hand.length)

  if discarded
     durationCards: +5
     durationBuys: +1
     durationActions: +1
}

Still learning github, don't have time at the moment to try more cards or figure out how to submit the changes or whatever, but at least I managed to put something together before work.

Edit: cleaned up tabs in code block
Logged

rrenaud

  • Administrator
  • *****
  • Offline Offline
  • Posts: 987
  • Uncivilized Barbarian of Statistics
  • Respect: +1171
    • View Profile
    • CouncilRoom
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #38 on: September 12, 2011, 06:10:28 pm »
0

Github should be paying rspeer for all the new accounts getting created on his behalf ;P
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #39 on: September 12, 2011, 06:26:06 pm »
0

Code: [Select]
makeCard 'Tactician', duration, {
 cost: 5

 playEffect: (state) ->
  discardCards = no

  if current.hand.length > 0
      discardCards = yes

  state.requireDiscard (current, current.hand.length)

  if discarded
     durationCards: +5
     durationBuys: +1
     durationActions: +1
}

That's about the right idea, but the "if discarded" block at the end won't work. It's probably not correct syntax, but more relevantly there's no way to fit in the +5 cards, +1 action, and +1 buy in that part of the code.

When the duration effect is being resolved, it's not running the playEffect code at all, it's running durationEffect. If the effect is constant, it can use the default durationEffect code, which is to look up the card object's durationActions, durationBuys, etc. and apply them. (You can't change these values from the playEffect. Modifying actual values on a card is a bad idea, because there is one Tactician object, it can just show up in a lot of places in the game.)

But Tactician's effect is infuriatingly non-constant because it needs to remember if you discarded any cards with it, so we can't take the easy route. How can we remember that between the playEffect of one turn and the durationEffect of the next? I'm afraid the answer is: yet another property on the PlayerState!

Here's how I'd outline it:
  • The PlayerState gains a new property called @tacticians. It's initialized to 0 and copied when the PlayerState is copied.
    This will very often be the same as the number of Tacticians in the duration area, but it won't be incremented if you play a Tactician with no hand.
  • The play effect of a Tactician is to determine whether there are any cards in hand, and if so, state.current.tacticians += 1 and discard the hand (exactly like you did, except it should be state.current.hand.length and not current.hand.length).
  • The duration effect of a Tactician is to ensure state.current.tacticians > 0, and if so decrease it by one, draw 5 cards and grant +1 action and +1 buy.

This is also the first card I'd feel the need to specifically write test cases for. So far I've been lazy about testing, and with most cards I just watch how SillyAI plays it over a number of games and make sure it looks right. But the edge cases of Tactician that require all this code are things that I have probably never seen happen in an actual game of Dominion.
« Last Edit: September 12, 2011, 06:31:42 pm by rspeer »
Logged

michaeljb

  • Saboteur
  • *****
  • Offline Offline
  • Posts: 1361
  • Shuffle iT Username: michaeljb
  • Respect: +1953
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #40 on: September 13, 2011, 01:08:06 am »
0

Unfortunately I thought of how it wouldn't quite work in the if discarded block after I was at work and unable to go back and rethink it. I read the documentation last night but apparently not enough of it stuck ::)

Your response was very helpful, I feel I have a better understanding of how to approach cards in general. (if I specifically respond to every useful thing you said my post will be too long :P)

Maybe I'll give Tactician another crack. In any case, thanks for the patience with a relative newbie.

I'm going to keep trying this, and hopefully get some cards right. Don't think I'll try Possession though ;)
Logged

Davio

  • 2012 Dutch Champion
  • *
  • Offline Offline
  • Posts: 4733
  • Respect: +3300
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #41 on: September 13, 2011, 03:45:52 am »
0

May I ask how you handle a required trash?

I simply put "trash: 1" in the card definition, but I don't know if this even works.
And how do you "trash for benefit" like Remake, Apprentice.

I am looking into Apprentice currently.
Logged

BSG: Cagprezimal Adama
Mage Knight: Arythea

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #42 on: September 13, 2011, 05:03:23 am »
0

May I ask how you handle a required trash?

I simply put "trash: 1" in the card definition, but I don't know if this even works.
And how do you "trash for benefit" like Remake, Apprentice.

I am looking into Apprentice currently.

"trash: 1" should work as of recently, for a simple required trash with no further effect. See Trade Route.

Trash for benefit is a doozy. I think we could knock off Remodel, Expand, Upgrade, and Remake all at once, but it'll take a fair amount of new code to get there.

In the playEffect, you could make the actual trashing happen with "state.requireTrash(state.current, 1)". But this will cause AIs to make the wrong decisions -- in trash-for-benefit cards, you often want to trash good cards because the benefit is even better, while these methods will just consult the trashPriority list and probably trash an Estate, a Copper, or a Curse. So there should be a new method ("requireImproveCard"?), which asks the AI for a new kind of decision.

After that, you need to determine what was trashed, to give the benefit -- you could count the cards left in hand, and compare them to the original list, but that's awful. Really this is a sign that requireTrash and allowTrash should return a list of the trashed cards. I'll correct this oversight on my part shortly.

Speaking of cards that require a lot of code, Ambassador is up! That took longer than I thought, so I won't get to nice things like a stop button tonight. I'm particularly interested in tweaks to DoubleAmbassador that make it win more.
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #43 on: September 13, 2011, 05:11:52 am »
0

My cursory look at Ambassador strategies has been interesting. Play two versions of DoubleAmbassador against each other. Change the second one to prefer returning "Copper,2" (with its conditions) over "Estate,1", and call it "DoubleAmbassadorPrime".

DoubleAmbassadorPrime wins about 60% of Colony games against DoubleAmbassador, but only about 40% of non-Colony games.

That's pretty wacky. What causes this difference? I took into account some interactions between returning Copper and buying Silver. Should I also have done this for buying Gold or Platinum?

Logged

rinkworks

  • Saboteur
  • *****
  • Offline Offline
  • Posts: 1316
  • Respect: +906
    • View Profile
    • RinkWorks
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #44 on: September 13, 2011, 10:32:00 am »
0

Trash for benefit is a doozy. I think we could knock off Remodel, Expand, Upgrade, and Remake all at once, but it'll take a fair amount of new code to get there.

I've been working on a Dominion playing game myself, and indeed, I found this to be the case.  All four cards follow the same logic, just different parameters:  (1) How many cards to upgrade, (2) how much higher the cost of the new card may be, and (3) whether the cost of the new card must be exact or "up to."

Quote
in trash-for-benefit cards, you often want to trash good cards because the benefit is even better, while these methods will just consult the trashPriority list and probably trash an Estate, a Copper, or a Curse. So there should be a new method ("requireImproveCard"?), which asks the AI for a new kind of decision.

Possession is the only official card I have yet to touch, but aside from that, the trash-for-benefit cards were indeed the hardest to write A.I. for, and I still have a lot of tweaking to do.  Actually, Remodel/Expand/Upgrade/Remake aren't that bad, because you can hook into your "buy a card" routine for choosing what new card to obtain.

But Salvager, Bishop, and Apprentice (probably in that order) are monsters.  In case it helps, here's how I got something that probably isn't ideal but at least isn't embarrasing.

Common To All Three Cards

When playing any of these three cards, I look at each card in my hand and evaluate it as a trash target.  Doing this evaluation involves looking at three separate things:

(1) The benefit.  How much extra buying power will I get if I trash this card.  More importantly, what does that extra buying power allow me to get in return?  More on this when I talk about the individual cards.

(2) The loss of the card in terms of the power of my deck.  I have an "evaluate this deck" function that looks at your whole deck and tries to evaluate its power.  This is a complicated analysis and (at present) very flawed, but basically it looks at what your average hand size is likely to be, which in turn helps it figure out what your average buying power, attacking power, etc., you're liable to have is, how many VPs you have, and so on.  All those factors are weighted and averaged based on how far progressed the game is (for example, # of VPs is the overriding consideration in the end-game but barely at all in the early game).

(3) The "play value" of the card.  This is an estimation of how useful the card is to actually play.  I use the card's cost as a starting point, adjusting as necessary.  For example, the play value of a Sea Hag is 4 normally but drops to -1 when the Curses run out.  Cards with VPs (e.g., Island, Nobles, etc) are penalized, and "pure VP" cards have a -1 play value.

Salvager

Salvager is the easiest of the three because unless you trash a card whose supply pile is depleted, you can't make too bad a mistake.  Worst case, you re-buy the card you trash.  But you obviously want to improve upon no effect.

In calculating the benefit, I first look at how much money I anticipate having if I *don't* play the Salvager, then comapre that to how much I'll have if I *do* play the Salvager.  Then I compare those two values to see if I will cross any particular critical threshold.

For example, if I anticipate having $7 without playing the Salvager and $9 if I do, that allows me to buy a Province, and so I consider that a good Salvager play.  However, if I anticipate having $8 without playing the Salvager and $10 if I do, I consider that a poor Salvager play.  Especially since Salvager allows multiple buys, I also look at thresholds such as $13 (Province + Duchy) and $16 (Province + Province) and other combinations.  (Of course it's important not to look at actual fixed values, like $8 and $16, but at "the current cost of Province" and "the current cost of two Provinces," since Bridge and Princess can muck with those amounts.)

Anyway, the upshot is that I come out of this calculation not with a $ amount but a +VP amount.  Ultimately I don't care if I'm getting +$2, I care what +VP change that causes.  To make this more accurate, I then need to adjust this number by subtracting the # of VP that the trashed card would have given me.

I now balance this +/- VP consideration with the change to my "deck evaluation" and the "play value" of the card to trash.  For the "play value," I'm particularly interested in seeing the difference between the play value and the card's base cost.  That way dead Sea Hags (for example) really stand-out as strong Salvager candidates.

Then I assign at weight to all these heuristics (again valuing +/- VP high in the late game, low in the early game), and ultimately wind up with a number that is quite useless except when compared with the results of these same calculations for the other cards in my hand.

Whichever card results in the highest calculation gets trashed.  If the numbers for all the cards in my hand are negative, I don't play the Salvager at all.

Obviously this is a HIGHLY fuzzy and error-prone calculation.  But as my goal is to build something that approximates good play, rather than a provably optimal strategy, it suits my purposes fine.

Apprentice

Essentially the same calculation as Salvager, IF you are able to write a function that, given some number of +cards, will tell you how much extra spending power your deck is liable to produce with them.  My such function tries to take into account what actions I'm liable to draw with those cards too, but it still ultimately tries to boil that consideration down into an estimate of increased buying power.

One complication is that you have to consider how many buys you have.  With Salvager, if your expected buying power goes from $15 to $16, you don't have to worry about having the extra buy to afford the second Province, because it gives you that extra buy.  With Apprentice, the crossing the $15 -> $16 threshold is only useful if you have an extra buy from somewhere else, or anticipate drawing a card that will give you +buy.

Bishop

Actually this is probably the easiest of the three to code unless you want to take into account the benefit to the other players.  I didn't, so I just look at the same three values:  (1) +/- VP, (2) change in deck power, (3) play value of the card to trash.

(2) and (3) are calculated in the exact same way as for Salvager and Apprentice.  Calculating (1) is a whole lot easier, because you don't have to look at cost thresholds or anything.  You just look at the the number of VP chips you get and subtract any VPs attached to the card you're trashing.

In Summary

I hope the above helps.  Even if you don't go to the lengths I did, maybe this rambling will help you think about an approach you do or do not wish to take to solving the problem.  If you do decide to do something like what I did, recognize that it's a lot of work, and the results are fuzzy and imperfect.  Probably what you want in a sim is something simpler anyhow.  But for me, I'm kind of interested in seeing how far I can take this.
« Last Edit: September 13, 2011, 10:34:31 am by rinkworks »
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #45 on: September 13, 2011, 11:52:10 am »
0

If people are looking for easy cards to start with, here are ones that can be done with existing code and require no new decisions:

  • Familiar
  • Farming Village
  • Hunting Party
  • Navigator (don't treat the province-revealing as a decision)
  • Sea Hag
  • Treasure Map
  • Tribute
  • Venture
  • Vineyard
Logged

michaeljb

  • Saboteur
  • *****
  • Offline Offline
  • Posts: 1361
  • Shuffle iT Username: michaeljb
  • Respect: +1953
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #46 on: September 13, 2011, 12:30:09 pm »
0

I coded Familiar, Ironworks and Moneylender last night but must have not done everything correctly on GitHub, but when I look at the master dominiate page it is showing I have one pull request, so I'm not quite sure where I went wrong.

I also just realized that Ironworks probably won't be optimal at the moment; I just copied the Workshop code and added to the end for the bonuses, so I don't think it will properly handle situations like multiple Ironworks in hand when the highest priority to gain is Gardens but it would be better to gain action cards first and Gardens with the last Ironworks played.

I also noticed that the Workshop cost was set at 4, rather than 3, and that's another change I included in my pull request.
« Last Edit: September 13, 2011, 12:34:10 pm by michaeljb »
Logged

rspeer

  • Witch
  • *****
  • Offline Offline
  • Posts: 469
  • Respect: +869
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #47 on: September 13, 2011, 01:47:09 pm »
0

You did it right, and I pulled in your changes. And thanks for catching my Workshop thinko.

While you're at it, could you add Familiar, Ironworks, and Moneylender to the default actionPriority in basicAI.coffee, in reasonable places?
Logged

michaeljb

  • Saboteur
  • *****
  • Offline Offline
  • Posts: 1361
  • Shuffle iT Username: michaeljb
  • Respect: +1953
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #48 on: September 13, 2011, 01:57:05 pm »
0

Will do, and I'll be sure to do the same for other cards as I add them.
Logged

danshep

  • Navigator
  • ****
  • Offline Offline
  • Posts: 70
  • Respect: +13
    • View Profile
Re: Dominiate: a Dominion simulator that runs on the Web
« Reply #49 on: September 13, 2011, 08:38:50 pm »
0

To write rules for the Salvager/Apprentice/Bishop trashings, just changing the existing trash rules so that it has knowledge of WHY it is trashing should work, so you can do:

Code: [Select]
trashPriority: (state, trasher) -> [
  "Apprentice" if trasher == "Apprentice"
  ... rest of priorities ...
]

Not sure where that trasher variable belongs - whether it should be a parameter or on the method or something on the state, or is there a state already for the current card being played?
Logged
Pages: 1 [2] 3 4 ... 13  All
 

Page created in 2.13 seconds with 20 queries.