Counterparty’s betting system is essentially that
 player A can place a bet that X happens
 player B can place a bet that X does not happens
 if A and B have matching odds
 then an oracle feed decides who wins
 the protocol takes care of escrowing XCP and paying out winnings
The feed is just a numerical value. The oracle defines what it means, like 1=yes, 2=no; or 1=heads, 2=tails; or the number of goals scores in a match; or a stock price; or a dice roll.
A dice roll oracle may publish a random integer 16 once every day.
Players can every day play on the outcome of this game. E.g. one side wins if the outcome = 6, the other side if the outcome is 1, 2, 3, 4 or 5. One side will always have the probability 1/6 of winning; the other 5/6.
This assumes the oracle is honest.
An automated oracle will be 100% trustworthy. A blockhash is used to determine the dice roll.
Is it relatively easy to add this to the protocol? I wonder if this can work on top of all the code that exists today? The autooracle will be an address (but without a private key, as with burn address) and it broadcasts a random integer 1,2,3,4,5 or 6 at a specified interval. It may be every block or once a day, whatever we decide is optimal.
Beyond being trustworthy, this also saves BTC tx fees frin broadcasting this feed. The autooracle won’t need to take any percentage of the winnings either, so the payout will be 100%.
Why Dice Roll?
An automated oracle will only be able to publish anything derived from the blockchain. It can never publish sports results, election outcomes, stock prices, etc. These must be published manually (as by a human or robot external to the XCP protocol)
From the info inside the blockchain there are lots of interesting numbers that people may be interested in betting on, like number of transactions, average fee, block timestamp, mining difficulty, etc.
However, most of these would requires bets in a largerorsmallerthan fashion. This is not possible with the current betting system. (CFDs are disabled). Bets have to be equalornotequal.
Betting must therefore be limited to an integer within a reasonable range.
Some possibilities

Coin flip (outcome 1 or 2, equally likely)
Two players may be willing to play this at even odds if they both are risk seeking. They will prefer to play (50% chance of doubling their 100 XCP) versus just HODL their 100 XCP. 
Dice Roll (outcomes 16, each with prob 1/6)
Two players, one risk seeking and one risk neutral/averse can play this game. The risk seeker will want to play on the dice landing on 6. He may even accept a slightly negative expectancy. Although everyone know the exact probabilities of each outcome, the odds are set by players interacting. In this game, it’s likely there are more risk seekers, therefore the market will give an edge to those playing on NOT 6. 
One in a Hundred (outcomes 100, each with prob 1/100)
The exact same principle applies here. Some players will want to risk 10 XCP even if the market payoutis just 950 XCP. Others will see it as a good business to take the other side since it has a positive expectancy. At least in theory. I fear there won’t be enough players around in the beginning to form a market here. Some need to risk almost 1000 XCP for a 99% chance of winning 10 XCP.
A dice roll seems like a good balance point to attract both risk seekers and those who want to profit on positive expectancy.
If computationally very cheap to have an autooracle (I don’t know) then maybe better introduce all three mentioned here, and possibly more, and let the users choose.
How Games Form
On any one feed, there can be many games. Players need to agree on a deadline and a specific outcome. The network effects comes into play here. Players will gravitate to the one game with the most players since this will have the most liquid bet “order book”.
The World’s Most Fair Lottery
With an autooracle as outlined, XCP will enable bets/games/lotteries that are provably fair, have 100% payout, and open to anyone without registering. Does any other lottery in the entire world offer this?
If an oracle on top of the protocol, as suggested, isn’t too technically challenging to implement, is there any good reason NOT to do it?