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.


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.

  • 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.

  • 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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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