Overall API design

[Michael-F-Bryan]

After having a quick skim through the StarCraft II protocol I imagine a typical user experience would be like this:

• The user creates a game Engine and configures it (e.g. setting endpoint URL and other game options)
• He then passes in a custom type implementing the Bot trait
  • The main method of the Bot trait is on_tick(), this takes in some representation of the game world then internally creates some ActionSet thing, where you call various methods on it to queue up actions to be executed, then when you return the ActionRecorder the Engine sends it back to the server
• The user then calls some run() function which will tell the game engine to run infinitely until it's told to stop.

---

Alternatively you could create a pull-style interface, where the player continually calls engine.next_frame() to advance the game one tick. Then you again create an ActionSet and have to manually tell the Engine to send it back to the server.

What are your thoughts?

[ttdonovan]

I like what you had done in #3 as a start - I'm going to take some time later this evening to study it more in detail. I believe pysc2 takes a similar approach and s2client-api has the pull-style interface.

[ttdonovan]

@Michael-F-Bryan I've started to update my ping example and made a couple of changes to ActionSet and Action. I've also added a couple of questions in the Engine. Is this inline to how you envisioned the API working? https://github.com/ttdonovan/sc2-api-rs/tree/ttdonovan/ping-bot

[ttdonovan]

I missed your last reply in #3 you can disregard some of my questions above. So basically tick() is meant to only handle one action and the actions will be one of these types?

I'm still trying to wrap my head around the response types and their meaning from the web socket API but from what I can gather GameState will have single Observation for a game loop.

[Michael-F-Bryan]

So basically tick() is meant to only handle one action and the actions will be one of these types?

Pretty much. I was going to use an Action enum which we then translate into a protobuf Request. That way you hide unnecessary implementation details from the end user and make things easier to change in the future.

I'm still trying to wrap my head around the response types and their meaning from the web socket API but from what I can gather GameState will have single Observation for a game loop.

Looking through the C++ API, their Observation is the GameState thing we're letting bots inspect. Although I'd argue my name for it is more intuitive.

My understanding is you'll send some sort of message to the server and update the GameState with the response. I'm assuming each bot will need to have some sort of BotManager thing which manages a single bot because each one needs its own connection and GameState.

Is this inline to how you envisioned the API working?

Yep, looks good to me! Although bots probably won't be sending a Ping message to the server directly, I was thinking an Action should represent the physical things you'd do in a game (e.g. select some units, build something, leave the game) and the underlying game engine should worry about things like pinging the server and connection management.

[ttdonovan]

If Bot's will not being performing actions like Ping or GameInfo would it be useful to create a RemoteController like this: https://github.com/deepmind/pysc2/blob/master/pysc2/lib/remote_controller.py

[Michael-F-Bryan]

Yep, I believe their RemoteController is roughly the same idea as my BotManager. A RemoteController/BotManager acts as an intermediary between a Bot and the raw protobuf connection.

That way the RemoteController manages the connection and game state, and converts Actions which the Bot wants to execute into protobuf messages which can be sent to the server. The RemoteController would also be doing things like an occasional Ping to check the server is alive, and periodic GameInfo calls so it can update its internal representation of the game state... Does that make sense?

[ttdonovan]

@Michael-F-Bryan does the purposed draft above align with your envision of how the various components should interact and work.

[Michael-F-Bryan]

@ttdonovan did you end up figuring out how to communicate to a websocket running on another thread? This is a pretty annoying issue in that how we deal with it will directly affect the crate's API.

[ttdonovan]

I think I have a working solution. Might not be the best code but able to read and write over the socket connection. I put it in another pull request, if it’s a good enough solution I’ll merge it into master.

…

On Sat, Sep 30, 2017 at 00:30 Michael Bryan ***@***.***> wrote: @ttdonovan <https://github.com/ttdonovan> did you end up figuring out how to communicate to a websocket running on another thread? This is a pretty annoying issue in that how we deal with it will directly affect the crate's API. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAo3KLrd5Zu2p8sAE-L3vAxMxqHH5hRks5sne4ogaJpZM4Pdmn8> .