2 ms·
One option for this is to make the split clear between the backend and the view. If your frontend is asking for the current game state (to render it) and sendi
by IanCal 9y ago
One option for this is to make the split clear between the backend and the view.
If your frontend is asking for the current game state (to render it) and sending control messages to modify it, then you don't need much else to allow people to write bots. All you really need to do then is make sure there's a way they can access the exact same API your frontend uses but with (e.g.) an API key rather than cookies.
It's a reasonable thing to do for the code anyway (and might be how it works now, I don't know). Bots then have the ability and knowledge of any human player, you don't need to run any code your side (which brings up issues with sandboxing) and people can write in whatever language they want.
- Baron_Von_Meats 9y agoYeah that is basically how it works now, and I think I'm gonna do it! (Discussed a little bit in another comment on this thread.) Player's would have to host their own AI but it'd be as simple as sending over the exact same game data that the browser receives and asking for/parsing a response. What's tricky that I forgot to mention in the other comment is that more information is acquired as moves uncover fog-of-war tiles. So I've been sending a new request every unit-move, rather than once per player-turn. This is fine as the data being exchanged is so small and fast, but just something people might need to account for. I suppose I can also quickly whip up a system to grab all sequential moves from an AI service when fog of war is disabled and save some network traffic.