Allow a rejection response for /start

[Starwort]

Some bots won't understand all rulesets, and these bots should have a way of opting out of games they don't understand.

As such, I propose handling the response from /start (which currently, according to the docs, is ignored), such that 201 ('created') or 202 ('accepted') is returned on games the bot wishes to play, and 204 ('no content'), 406 ('not acceptable'), 422 ('unprocessable entity'), 501 ('not implemented'), or 503 ('service unavailable') are returned for games the bot does not wish to play (which of these responses to use specifically, I'm not sure - I'd probably choose 201/501, but that's a design decision for after the feature is accepted really).

I can see this being particularly useful for ML snakes, which may not be able to understand e.g. games of sizes differing from that on which they were trained - and as such would not produce useful output for such games - as they could simply opt to not play those games instead.

[coreyja]

I like this idea!

I wonder what should happen if a snake opts out?

The easiest answer is for them to probably be marked as a lose immediately? This would have the least changes to things like matchmaking.

More questions:

• Should snakes receive a snake that opted out on the first turn? If not is it bad the start and first move payload are different?

[bvanvugt]

Just an idea! Another option might be to flag the snake as inoperable and apply default moves until elimination - sort of like the snake still exists in the game, but it's "brain" has checked out? We could indicate that in the UI.

That has the same result as losing immediately (close enough?), but dodges the question of how to represent it in game.

[Starwort]

Whatever solution does end up getting chosen for this, I feel that snakes who opt out should not receive a penalty for doing so (if there are worries of abuse or intentionally dodging certain opponents, perhaps the initial /start call should be anonymised?)

Perhaps as an alternative to rejecting specific games, we could include a field in the response of / or as a separate endpoint where snakes can provide specific ruleset restrictions they'd like to play with?

[bvanvugt]

Agree, and also I'm not super concerned about the penalty situation.

Competitive rankings come from leaderboards only, which are fixed game configurations (fixed size, fixed opponent count, fixed rules, etc). So if you don't want those games, it's easy enough to just not join those leaderboards. But if you're in the leaderboards, it seems reasonable to receive a penalty if you're dodging games, yeah?

Unless there's an aspect to this I'm missing, obv :)

[und3f]

I think it is a must-have feature. I have a few thoughts on possible implementation:

/start response code: 204, any 2xx response should be considered as snake accepts the game. I am totally against treating 204 as a decline response since it is a successful response.

For the first implementation declining game could be treated as a technical loss (with a corresponding message, like snake declined a match, or snake failed to accept match).
For further development, there could be such a thing as "delaying a match" -- like if snake can't handle one more concurrent game it could ask to delay the match (by /start response), and the server may try to hold the match in 5 minutes or so. And like if snake is declining to match for some time it could be considered a technical loss.

[Starwort]

I am totally against treating 204 as a decline response since it is a successful response

I understand your point of view here; however, it's arguably true that the server handled the result successfully (and simply decided it did not want to play) - hence 204 being a reasonable choice for a decline response imo - 400 codes feel wrong (the battlesnake server didn't make an error per se) and 500 codes feel equally wrong to me (nothing went wrong, the server just doesn't want to play); this ambiguity is why I left a selection of suggested statuses 🙃

[und3f]

I am totally against treating 204 as a decline response since it is a successful response

I understand your point of view here; however, it's arguably true that the server handled the result successfully (and simply decided it did not want to play) - hence 204 being a reasonable choice for a decline response imo - 400 codes feel wrong (the battlesnake server didn't make an error per se) and 500 codes feel equally wrong to me (nothing went wrong, the server just doesn't want to play); this ambiguity is why I left a selection of suggested statuses 🙃

We could use any of these responses:

• 503 Service Unavailable The server is not ready to handle the request.
• 429 Too Many Requests The user has sent too many requests in a given amount of time ("rate limiting").

Both are related to option when snake can't handle the game (like if snake server is overloaded with concurrent games).