Hmm, i don't think these changes to ApiSpec work --- you're allowing arguments of types "alnum" and "button" to be empty in *all* cases, not just the one you have in mind.  So e.g. now ApiSpec will allow createUser with an empty username, etc.  Obviously, some of those errors will be caught other places, but IMO it's a bad idea to weaken the checks in ApiSpec across the board.  So, you could make a new type "alnum_optional", but OTOH one reason most things *aren't* optional in ApiSpec right now is that i believe our common pattern is for the argument to the API function to be optional.

Oh, wait, i answered my own question --- it's because of the mysterious "games with some number of players other than two" idea, isn't it?  Bleah, okay.

Well, anyway, my argument stands: we shouldn't make alnum and button optional across the board, so either:
A. Add alnum_optional and button_optional types to ApiSpec
B. Add a numPlayers argument to createGame, ideally which defaults to 2, so that whenever the length of the arrays is smaller than the number of players, you can assume the remaining seats to be unspecified (and thus that whenever the arguments *are* specified, they need to be non-empty)
C. Refactor the API further so it passes an array of game participants, each of which is an array which can be empty, or can contain either or both of the keys "player" and "button"

I don't feel strongly --- in general, i think passing around empty strings is a pain and likely to cause trouble, so i somewhat prefer B or C.  I'm pretty happy with arrays of arrays as a concept, so maybe C, but i know that might be a pain.