Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got some general questions about modelling a series of betting markets and bets within them. I'm writing in Ruby but it's ultimately agnostic towards which language I want to use.

I have a concept of "games", for example, a soccer league. While the league is running, people can place various types of bets. A bet might be the winner of the league, or it might be the top three winners in any order. Or the top three winners in order. This is called a "market".

Within a game I also have participants. These are the teams that make up the league.

A bet consists of one or multiple participants, the order of these participants is important plus an amount. It is stored against the market.

My question is how should I got about organising this? At the moment I have market types (say Win) inheriting off a base market class.

The base class I'm using looks like this:

class Base
    def self.make(game, market_name)
        puts Kernel.const_get("MatchMaker::Markets::#{market_name}")

The make function is a factory method for generating win classes based on a string passed in with the name off the bet type.

This generation seems a bit clunky at the moment, and I'm somewhat concerned that it might cause me further problems down the track.

I realise this question is somewhat rambling and doesn't have a clear answer. I'm interested more in other peoples ideas in how they would go about putting something like this together.

share|improve this question
up vote 0 down vote accepted

This sounds like a place where it would be useful to treat the game results as events so you have your pool of participants, a schedule of games between them and as the schedule is carried out, I would be using Observers to handle your bets - if the match/game object is Observable then if you are setting up a bet on a series of games you just add that bet as an Observer to those match objects and provide the logic in the bet to handle the consequences of those outcomes.

That way your bet would be handed a list of one or more games, either combined with a statement of logic to make the win conditions clear or with each type of market represented by it's own class descended from a base class that handles the observation side of things. The logic might even be a separate class that is handed to the market along with the list of games - Ruby has some very neat features that give you a lot of different ways to implement this.

share|improve this answer
I've implemented a state machine on the game class as it exists in a few different states (lodged, open and closed) I was planning on triggering the bet results when the game transitions to the closed state. If I understand correctly, when the state transitions to closed the bet will be able to calculate it's win lost state based on the game (provides an array of participants ordered by winner) and a statement of logic from the market its attached to. – Samuel Jul 13 '11 at 9:28
The only difference in what I am describing is that a bet may have multiple games, depending on the logic it has been handed, so each game closed event will notify all observing bets, but only those where this is the last game to close in that particular bet have their logic triggered. This may be divergent from the model you have in mind, however. – glenatron Jul 13 '11 at 9:49
I wasn't planning on handling bets over multiple games, at least not to start with, however it is something that we might eventually add. It might plan to start thinking about it now. – Samuel Jul 13 '11 at 11:01
It certainly seems to be an interesting area when you get to things like accumulators. If you have an event driven model it is very easy to extend in that direction. – glenatron Jul 13 '11 at 11:42

I used to do this about 5 years ago. From memory, we had

  • Event - a sporting event, be it a horse race or a football match
  • Market - anything you can bet on within an event (to win, placed, number of goals)
  • Runner - each possible eventuality you can bet on within a market

If you're doing spread betting, the Market should contain a number of winning Runners, which is used to calculate the "round".

A Bet is more an amount of money placed on a Runner in a Market, and the odds it was placed at.

share|improve this answer
We're planning on using a paramutuel system to start with so recording the odds isn't important as they're calculated once the market has closed. Will roll out a fixed odds system later though. – Samuel Jul 13 '11 at 11:00
Right. I would still probably model it the same though, I'd just have zero be a valid value for "odds" and use that to indicate starting price. Probably. Having two Bet classes seems overkill. – pdr Jul 13 '11 at 11:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.