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.
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.
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...
I completely understand the need for speed, which is why I'm happy you picked something like Java. It's just with the popularity of Javascript on HN, I was worried that it would be yet another JS project.
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.
If I may, I would suggest thinking about things in a way very similar to how Magic: The Gathering does, which is as a "state-based effect" or "triggered effect". This models very well into programming as event handlers watching state-changes and acting appropriately.
For instance, the most common state-based effect in MTG is death from damage. This is perhaps even easier to model in Hearthstone, as damage is persistent. Simply register event handlers on minions which get called whenever the health of a minion changes; if it's <= 0, trigger death.
Death will then cause any "triggered effects" to fire, such as a deathrattle tigger. This is also easy; just a listener on the death event.
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.
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.
Are you implementing each card by hand? I was going to make something like this and was just going to regex match all of the cards (from HearthPwn). It seemed like there were few enough variations to make something like that possible.
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.
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.