[Q] How will the API be structured?

[AutomaticCoding]

I haven't programmed for your other bots in quite awhile (Twoish years), but, if memory recalls, it used a tick-based system where you'd have your main logic in one huge function that'd be called every X units, due to Hearthstone's turn based gameplay (Rather than Diablo's or World of Warcraft's real-time), this would obviously be (In my opinion, feel free to correct me) a foolish approach to take for such a game, and, the API would be more event driven.

How I see, it should have multiple events you can register, such as "drawCard", which, notifies you of the card you just drew, "startOfTurn", which, is invoked right after drawCard at the start of your turn, "action", whenever a card activates (Secret, Deathrattle, Enrages, etc...), "hitpointsUpdate", "mulligan", "mana(In/De)crease", etc..., then, all the events return a boolean "self", if true, they were invoked due to something that you did, if false, something your opponent did.

Then, you should also have a bunch of blocking functions for queuing moves, such as something like this which is able to track cards throughout their movement on the board (So, the API can queue playing a card, and, then buffing it, for example)

game.invokeMoves([Hand[0].play(), Hand[1].ApplyBuff(Hand[0])]); //Blocks until both the first index card in hand has been played, and then until the second (now first) index card has been played, and, used it's target move to buff the first index card (Obviously you wouldn't use arrays like this, etc..., but, you get the point, the objects can reference the cards no matter where they are on the field (hand or board)
print(game.getBoard()); //Should now have Hand[0] on board, buffed with Hand[1], as the above function blocks until completion

Etc...

Seems like the logical setup to me, however, I assume the API has the majority already coded, so, I'm just wondering how it'll work.

 

[Apoc]

Well, all of our bots work on a "tick" based system. Mainly, because that simplifies state synchronization between the bot, and the game.

That said, I've been debating how I want to set up the public API. As of right now, we can basically map anything to the game's assemblies, 1:1. (Well, almost 1:1, some stuff is left out)

However, Blizz's own API is... crude... and very difficult to work with. I've been abstracting a bunch of it away to make things slightly easier to work with.

 

[AutomaticCoding]

Well, all of our bots work on a "tick" based system. Mainly, because that simplifies state synchronization between the bot, and the game.

That said, I've been debating how I want to set up the public API. As of right now, we can basically map anything to the game's assemblies, 1:1. (Well, almost 1:1, some stuff is left out)

However, Blizz's own API is... crude... and very difficult to work with. I've been abstracting a bunch of it away to make things slightly easier to work with.

I understand why it's a tick based system on a real-time game, as, obviously, there's no real "events", it's just constant data, but, in a card game, where, there are obvious events occurring (play card, take damage, secret, attack, etc...), I feel that a tick setup doesn't really make sense.

At-least, that's my two cents (/rhyme).

 

[Apoc]

I understand why it's a tick based system on a real-time game, as, obviously, there's no real "events", it's just constant data, but, in a card game, where, there are obvious events occurring (play card, take damage, secret, attack, etc...), I feel that a tick setup doesn't really make sense.

At-least, that's my two cents (/rhyme).

We will still be using a tick-based system, that's never going to change. Synchronizing memory between the game, and our bot, is incredibly difficult to do "whenever we want". So we synchronize with the game, rather than try and fight it to get info "when we want".

However, that doesn't mean that we can't come up with an event-based API.

 

[kelu]

Can't wait to get my hand on that API :> Even if it sucks at the begining.