Parallel Project

[danielyule]

Hi!

I'm working on a very similar project to this one, over at https://github.com/danielyule/hearthstone-simulator. Ours is written in Python, but has an almost identical focus. Obviously, there's enough room for two simulators, written in different languages, but I think it makes sense to coordinate, for example in any exporting or importing format.

Java might be really useful, since both HearthStats and Hearthtracker are written in that language. I chose Python because I wanted to use SciPy for my analysis out the other side.

If you're interested in working together, let me know. We've got a mailing list at https://groups.google.com/forum/#!forum/hearthstone-simulator-dev, or you can shoot me an email at daniel.yule@gmail.com.

[oyachai]

Hi! Thanks for letting me know about your project! It looks like a good project and I'd love to collaborate on things going forward.

[Kallin]

One thing we could consider doing is extracting all the card data into a 3rd party project. At one point I was playing with building LUA based cards w/ a reference Java implementation but didn't get too far, https://github.com/Kallin/hearth4j/tree/master/src/main/resources/org/hearth4j/lua. The overheard of keeping up with card changes over time will be challenging, and having both teams contribute to the same codebase for that component would be awesome.

[danielyule]

There's a project called Focus which has a JSON based description of all Hearthstone cards. You can see it at http://fluiddruid.net/forum/viewtopic.php?f=7&t=4808.

The goal of the project I linked above (now called Hearthbreaker) is to be what you mention. It's a now complete implementation of all the cards. I think both HearthSim and Focus are built around a particular modeling ideology (oyachai can correct me if I am wrong), whereas Hearthbreaker was designed from the start to be agnostic, and easily embedded in other systems.

The issue is the same as any, where it's more trouble than it's worth to make applications written in different languages work together directly. I think standards (such as Focus's JSON implementation, or the serialization format being worked on for Hearthbreaker) will allow for interoperability. I plan to support the Focus JSON format, to allow for custom cards.

[Kallin]

That Focus project looks really cool, but I wonder what the JSON schema will have to look like to support every possible card mechanic. You'll end up with a lot of identifiers for which you'll have to re-implement in your logic. If the cards were all written in Lua or Python or something that could be easily digested by any major language it might require a lot less work to integrate.

[jleclanche]

@danielyule Funny that; I just found your project. I knew about HearthSim but not HearthBreaker.

I've been working on a Python HS simulator myself. It is still at a very rough stage though: https://github.com/jleclanche/fireplace

One of my main focus points is reusing the actual game's XML card format and not have to implement too much myself so it's partly a reverse engineering project as well. I am also planning to add a clojure API and/or core to it so that cards can be defined in Clojure files, similarly to @mischanix's soot.

Take a look if you wish, let me know if you have any question. My email is on my profile.

[jleclanche]

@danielyule @Kallin @oyachai

A quick update on fireplace after exchanging some emails as well. I've been looking through the game's internals and am starting to more and more faithfully simulate it.

A very insightful talk is in the GDC Vault about the game's internals. The gist of it is that the game is implemented on two principles: Rules and Tags. Tags are a basic-ish key/value (and param) store, rules declare what happens and how (and cards can break rules). Everything is an Entity and Entities have tags. Turn time, health, frozen, has-attacked-this-turn, all of these are tags.

I am slowly reimplementing some of my mechanics using a similar tag system (example in https://github.com/jleclanche/fireplace/commit/574b50730527603cba5b448b61a79b56564957e8). Incidentally this falls quite nicely into my design reusing the CardXML because it means that, instead of having to set the max health and so on, I can just keep the tags as is when I summon the minion.

[jleclanche]

Cards themselves are very terse and fast to implement once the rules are in place. I even have a few helpers for common actions. For example, "destroy target" is the same action whether it comes from assassinate, big game hunter or shadow word pain. They simply have different play requirements.

A few examples below:

• Neutral commons
• Rogue cards
• Shaman cards

As you can see, for example in backstab, I don't have to implement an erroring logic for damaged minions - Not only is it already implemented in the card's PlayRequirements, but also that would be wrong (eg. execute into spellbender would break).

My next big step is implementing game ticks. Not completely sure on how to architecture them quite yet but I see them as a form of atomic transaction: The contents of a tick are guaranteed to happen when the tick is complete. "Ragnaros hits Gruul for 8 AND Gruul gains 1/1. This happens at the same time so the result is 9/1".

My TODO list is still fairly big, available here