Most definitely... not. Well, since Harvest Golem is not yet implemented, the subtle nuances are beyond the scope anyways. It's something I will have to go through to get it right in due course.
Having said that, the focus (of my curiosity) is in AI modeling at a broader (higher?) level, so I think will be concentrating on that aspect for now.
I think it's not a problem... This is not a playable clone of the game. It's purely for deck analysis, kind of like how SimulationCraft is a DPS simulation and analysis tool for World of Warcraft.
HearthSim is designed purely as a AI vs AI game simulation tool. It's not a "playable" Hearthstone clone. In the examples on my blog, I usually run 40,000 simulated games per data point, and each set of 40,000 games usually takes a few hours to run on a relatively modern PC.
I have informally looked at what the AI does. Turns out, as far as I can see, the AI does a pretty good job... with a BIG CAVEAT. The decks that I have used so far consist solely of minions and one other special card, so there really isn't any "mistakes" the AI can make. The decks are just so simplistic at this point. As more interesting cards are implemented, I'm sure there will be situations where the AI will make interesting mistakes that we can learn from. It is something I'm really looking forward to exploring.
The event/listener paradigm is an interesting way of going about this, and I considered doing it that way at the beginning. But, after some thinking and experimenting, I found the "card use -> modify BoardState" way more straight forward, especially since it leads to a nice recursive tree structure for the game AI engine. The primary goal of this simulator is to do statistical analysis on deck performance, so I think it's a decent way of going about it. On the other hand, if my goal were to create an actual playable game clone, I probably would have taken the event/listener approach.
A lot of the cards are more or less automatically generated in the sense that they don't actually extend any functionality of the parent class. Variations in the special effects ("text" effects) are big enough that for those, I find implementing them one by one much easier.
Simulation speed is of primary concern here (though javascript isn't too shabby)! I actually have a C++ version too, but I thought Java might be more accessible to more people...
That might be true. The advantage that The Coin gives you is highly dependent on the deck that you have. In that particular deck that I used in the simulations, the advantage is rather large. For a deck consisting of stronger (higher mana) cards, the advantage is much smaller. I think it's basically due to the fact that a 2-mana drop vs 1-mana drop is much stronger than a 7-mana drop vs a 6-mana drop.
Yep, I'm up to about 100 cards at this time, working on the basic cards first. Besides the cards, there needs to be more work on the AI modeling... currently, it won't handle any card with elements of randomness to it. I think I have an idea on how to treat it (without the AI cheating), so that implementation is coming up... soon.
Having said that, the focus (of my curiosity) is in AI modeling at a broader (higher?) level, so I think will be concentrating on that aspect for now.