The reality of tornado-redis is either massively convoluted (if that's what I wanted, I would have gone with twisted) or it just does not work outside of the tornado event loop (hoping this is the case). I'd have probably gotten further tonight if I'd excluded the beer, but hey, it's the weekend!
Still... the tornado-redis client implementation seems to simply not work outside of the tornado event loop, and I can only hope that it does work inside of said process. Testing that isn't massively difficult, but while testing standard redis-py means writing 10 lines of Python, testing redis integration inside of a webservice with tornado-redis involves actually creating and hitting an endpoint. Not the end of the world, but quite a bit more than the thirty seconds of work it should take, in my unfortunately-not-mattering opinion.
It doesn't help that redis-py doesn't bother to expose UNIX socket support for connection pools as a keyword argument. Connections? Sure. But they don't pass that variable through when you initialize a pool, so you actually have to use a separate class to run with a UNIX socket instead of a port via TCP. This would be a lot less irritating if it were documented AT ALL, ANYWHERE, aside from obscure blogs (like mine) by people who have had to figure this out themselves. Thank goodness someone else had managed it before; I'm not sure I'd have figured it out from reading the source. And I still haven't figured it out for the framework I'm actually using. Lovely.
So, unfortunately, my first attempt at building endpoints for the game to hit for unit/item/battle list/detail queries has... pretty much fallen on its face. Next up will be building the endpoints and seeing if tornado-redis can miraculously get its shit together using Undocumented Magic.
Wish me luck.