You are here

Rebooting predicition market for Drupal 7: a simple Parimutuel system

Submitted by greggles on Fri, 11/04/2011 - 08:01

So, I read the wikipedia page on parimutuel betting and felt like that presents a similarly predictive market without the complexities of trying to build a markets concept with trading and all the fun that comes from matching trades. I really got stuck last time on two elements:

  • The trading concept requires a lot of extra calculations and overhead, those lead to a complex system which leveraged a lot of contributed modules...
  • Relying on too many contributed modules, which made the stack of technology just too frail when one of those changed

So, I'm hoping that a simpler pariumutuel system (doesn't require matching trades, therefore doesn't require an automated market maker) will allow me a simpler architecture which will reduce the desire to rely on other contributed modules. The biggest drawback to a pariumutuel system is in long term events. If you are betting on something that won't be determined for years your money is tied up until the event passes. If you want to back out of a position you get back exactly your same initial wager and the odds shift. This is a clear drawback, but I feel it could be worth it just to get a working system going sooner.

I'm thinking now about how to build the system on Drupal 7, which opens up several new technology choices in addition to old models:

  • VotingAPI
  • Nodes and fields
  • Fields and entities (a module can create it's own entities...we could do that)
  • Userpoints

I spent a little bit of time (in bed as I woke up it was the first thing on my mind...I must be getting excited again) trying to think about the model. Nodes, Fields and Entities are all powerful tools. But I'm not sure if they provide the right kind of scalable framework for this.

Userpoints would be the form of currency again, most likely. I can't think of much that would change my mind on this unless the module just got horrible in the last 2 years instead of getting better.


  • I can create a Question node with a flag for whether it is open or closed and another field for a close date (if it's known) and a text field with unlimited number of options for the outcomes
  • I can create a node for a wager, which will require an amount (can be updated, revisions enabled of course) which would refer to a specific Question and a field that refers to a specific outcome from the Question (that seems like a new field type: the field_input_reference or something)
  • When a question is closed no more wagers would be allowed, the total would be calculated and proceeds distributed back to users as points

VotingAPI basis:

  • Again there would be a question node with similar metadata fields, but the option fields would become voting api tags (nid-delta?)

Still debating on this. I've been going back and forth on which one to use this morning, but at least it's getting closer.