I just read this interesting article in Gamasutra. In it, Tom Buscaglia makes the case that if you are using Scrum to develop games, signing a contract with a publisher that takes Scrum into account is difficult. He raises a concern that many developers adopting Scrum have raised.
I agree that contract solutions for iterative development are different, but there is no reason that existing models can't be applied. In fact, Tom wrote an article about flexible milestone deliverables. He does point this out, but says that Scrum is incompatible with "hard-set objective-predetermined milestone deliverables", but this is not what the flexible milestone deliverables article is saying. In that article he says that the publisher and the developer define each milestone (past the first two) based on the the last milestone. This is an iterative contract approach! This is not incompatible with Scrum. In fact flexible milestones, used by many publishers, are a acknowledgment of the iterative nature of game development.
Scrum is a framework. For example, it doesn't define technical practices or how to handle "milestones". Practices can be added to support both. For example, many teams add XP practices like Test Driven Development to create code that can better support iterative development. Another set of practices are those defined by Mike Cohn in his book Agile Estimating and Planning. There is nothing against with defining milestones the same way you would define releases. Your product owner should pay attention to the amount of change that is introduced during the release so that the release backlog matches the milestone definition agreed to. If this is too hard to do over three months, work with the publisher to have shorter milestone intervals. I don't think many publishers would argue with receiving more regular builds.
If anything this iterative milestone approach encourages communication about the product between publisher and developer. Contracts with fixed milestone deliverables/payments discourage change and therefore communication. Both parties may agree that the game is not as fun as the original design document and contract anticipated halfway through development, but for the sake of those payments, no change is allowed (and I have never seen a contract rewritten during development).