What I learned about running a betting market game night contest.
This week I decided to run a betting markets contest - we got a bunch of people together, opened a bunch of betting markets, and competed to see who'd end up with the highest net score[1]. It's a lot of fun, and I recommend more people try it. The basic rules went like this:
The best way I found to set it up was to open a group on Manifold Markets[3]. I set up a game night group, then uploaded the questions one at a time. After a few minutes of betting, I moved on to the next question. I closed them all one at a time in the end.
Each player started out with a set total mana budget for all questions of the night. The budget was freed up as we resolved questions at the end of the night, which allowed for some reinvestment. Aside from that, players had to watch their budgets (since you needed to keep some budget left for later questions).
Manifold markets subsidizes the basic questions - the first player to bet has a significant first mover advantage. To deal with this, we went around in a circle and each person in turn got up to a minute to place the first bet, after which it was a free for all[2]. I then gave a couple of minutes for the free for all before proceeding to the next question (betting on past questions was always allowed).
I had various types of questions. Some were trivia (e.g. "does the NYC subway system have more stations than the London Tube"), some were local (e.g. "how many dice are in this bowl" or "how many people will be in the room when this question is settled"), and some were gameable in various ways (e.g. "in how many T/F questions will the majority be correct", "how many total questions will I ask", or "which question will have the most total points bet on it"). I had the most fun with the gameable ones (I'm not sure if the contestants did). I did want them to all be unambiguously settleable by the end of the night.
I learned a lot from running this. Here's a list of useful conclusions (some of which I was prepared for, most of which I learned the hard way):
This will be chaotic. If you do well, follow all the advice below, and avoid any new issues, it may be slightly less chaotic. But this is a fundamentally messy game.
You may run into a latency issues. It can take a minute or two for a question to show up on the site for other people, and they may not all show up at once. The best solution I found was to start uploading the next question once the first mover's exclusive bet was in, and then let the next player start on it once everyone could see it.
Something in the range of 15-20 questions should be good for a 2-3 hour game night (although you may want to take it slower than I did, in which case adjust accordingly). It's also a lot of fun to not tell the contestants how many questions there are until the end (makes the game more interesting, especially if "how many questions will there be" is itself a question). Have a few questions you can skip if necessary, so that you can tailor the number of questions to the length of the game.
Close the questions before you declare what the right answer is verbally (unless you deliberately want to sow chaos, which you might). Otherwise you'll have people jumping in to bet in the five seconds between your declaration and your hitting the close button.
Try to avoid open-answer questions. (True/False, preset list, and numerical questions should all be good). Open-ended questions can cause race conditions on the site when multiple people try to submit the same answer. (The one open question that worked out well for us was "which answer will get the most points").
Make sure you put all the questions in the group. Make sure your questions start with an index so that you can talk about "question X" coherently. Make sure you have the questions and the answers to the questions written down (for those that have predetermined answers). Make sure you settle the question the right way. It's easy to slip up on any of these under pressure.
Have a clear, loud announcer voice that you use for game declarations (especially whenever you declare a new question and who's up to be the first mover for it). Make sure everyone is paying attention to official announcements.
Have a sample question for people to experiment with the mechanics of betting (up/down, entering a number, and limit orders) before starting the game proper. Make sure everyone playing has had a chance to understand the betting mechanics before you start. (I used "will this coin come up heads" for this).
Especially if you're running something for a large group of people (we had around 20), it may be useful to do a beta run with one other person and iron out bugs. It might also be useful to have a two-person team running the game night (one person handling the technical side, one person handling the players). There isn't that much to do when organizing, but it can still be a lot under pressure (especially if you have to debug anything on the fly).
Keep a timer. Use it to limit the first mover's time to bet to one minute max, and rely on it to keep the game moving in general. Keeping the game moving with more questions is on you - players are easily sidetracked by arguing on existing questions.
The Manifold leaderboards can be a bit buggy. If you want to check who won, you'll have to just ask people how many points they have - the group leaderboards might not be accurate.
[1] As it turned out, it was the guy whose day job is a trader at Jane Street.
[2] I also gave players the option to pass on a question (which runs the risk of us running out of questions before we get back to someone), but no one took me up on it. This may be an unnecessary complication, and I'd drop the pass rule if I run something like this again.
[3] Who are in general pretty nice and endorsed. Someone on their team noticed what we were doing when we started and debugged things for me on the fly, which was thoroughly great of them.