deal or no deal

Does anyone know if its possible to do a dvd version of deal or no deal?

Hmmm.. tough job! I would have thought it possible - but only just. The game entails a user selecting a number (a box with a hidden money prize inside) and then eliminating the remaining numbers one by one. Between rounds the user receives a 'call' from the banker who offers money for the box the user has chosen and elects to continue with the game or accept the offer.

You would need to script several things. Firstly, the user selection needs to link to a monetary value, and this *must* be different each time - choosing box 3 in two different games must give you two different amounts in each.

Next you would need to keep track of the remaining boxes and script the user choice, like a jukebox script. Again though, each box needs to hold a different value for each game, and, just like a jukebox, the user needs to see inside those boxes to get the values they hold.

Finally, you'll need to script the way the 'Banker' works. This is probably the toughest maths to do for it to be realistic.

By far the largest amount of work will be creating enough menus to cover the huge number of combinations available from the user selecting one box and the order in which the remaining ones go from the game. You would need to seriously cut down the number to reduce the variables, or come up with a way to get around this issue. If a DVD could be dynamic in the way that a Flash movie is then it would be a lot more straight forward, but there is no way to do that sort of thing (currently) and so you have to ask yourself is it worth doing.

Personally, I don't think it is if you intend to copy the game faithfully - there is a shed load of work to do! I'd be very interested in following your progress if you do take it on, mind you! You might be better off doing a version that looks similar but is somewhat reduced.

Oh - and check here regularly... looks like someone is already working on it:

[www.getreadytowiggle.com]

Thanks for the info Hal.

We are trying to develop the game format for a 'on-road' version (show) for fund raising events.

The banker will be the compere, so this, in theory will solve the banker problem (as we will know beforehand how much is in each box and therefore make sensible/calculated offers).

We would like to stick to a similar format as the current one, but we will have to change things to get round the box choice/probability..

...and ideas will be greatly appreciated.

OK - this is going to be a proprietary kind of game project then, rather than one for a more general release...

You can store the player's box value in a single GPRM, and you can easily store the three chosen boxes in another GPRM and in the order they were chosen. You could then use a short track to playback the opening of the box in the same order they were chosen. This is a standard 'jukebox' kind of operation.

What gets tricky is the sheer number of combinations of menus to build which would need to cover every single eventuality, including the player's box choice! I would probably do this using several collections of menus. The first set would be for the player to choose their own box. A series of 25 menus each with a different 'box' not there should do it (assuming 25 boxes in the game). Presenting the player with a menu that has 25 buttons, you can use a GPRM to store SPRM8 information. You can then go to a menu which shows the remaining boxes from there.

Now the tricky bit... You'll need to create the jukebox system so that the user can choose three boxes at a time (or more, if you prefer). You then play back a short clip for each of those boxes, BUT you need to randomly select the clip to play - the user doesn't need to know that part. If they select box 2, 4 and 9 in a round, then you play back three random clips which show a different value has been chosen for each box, You MUST keep track of the values that were shown to the player by storing them in a GPRM. If you use 25 boxes then your storage space will need to be at least 5 bits long (25 in binary is '11001' which is five bots long). Since we only have 16 bits in a register you will need all 8 registers to store 24 possible values. This is simply no good to you because you'll need some registers to be counters and others to be spaces for calculations... you must therefore use less than 25 boxes in your version of the game, or find a different way to remember which boxes have been 'opened'. I think you *could* possibly partition two registers into 16 bits each and name each partition relevant to a box number. When that box is selected, set a '1' into the relevant partition and this should then be enough to not allow it to be used again in the rounds following. You could use two registers and store up to 32 'boxes' (waaay too many!).

So, you use SPRM8 to track the box selections and create a vast number of menus for the different possible combinations that could be chosen. You use two GPRMs to store the values revealed to the user. You have a live compere being the banker, so you are pretty much set up. If only you could dynamically assign the remaining boxes to place onto a menu once a user choice has been made, life would be so much more simple!

And just to get into the scale of the problem a bit more - if you gave the user 25 possible boxes to select, and you asked them to choose three of them at random, then wanted to show the remaining boxes back to them, you'd need 13,800 different permutations to cover the options. Each permutation would need to be a menu or screen from which three more possible buttons could be chosen...

If you limit it to just ten possible buttons then it gets slightly easier - the user can choose three 'boxes' which means you'd need to create 720 different menus with each showing the possible permutations of the possible choices.

And that's only for the very first selection in round 1.

For the next round you'd have only seven boxes to choose from, but you'd need to add on a further 210 menus or screens to cover that round. For round three you'd need a new set of 24 menus and finally, for the fourth round (in a ten box game) you'd need a paltry 6 menus. This would leave you with a single box unopened... and a total of 960 menus to create.

I'd rather have to do a ten box game than a 25 box game (which would be impossible anyway if you use menus as your selection screens), but neither is particularly simple, even if it could be done!

If I were to show the $$ values on 22 buttons when each box is opened how could I have each box dissapear when selected without using all the menus?

I think the way to do this would be to not have a specific value showing on each box, or to try to keep the positions of the boxes the same between rounds.

If you think about it, each round will reduce the number of boxes by a set amount. If the subsequent menus then just show the correct number of boxes in an arrangement the user can select any three each time. Without numbering the boxes in a persistent manner at all, you can seriously reduce the number of menus you would need each time.

It takes some thinking about, and it is a slight deviation from how the game is presented on TV but I think it will still capture the feel of it.

If I were to have the boxes as props how would I show the $$ value that are left to the contestant through a DVD build in DVDSP 3, eg. open box contains 1c I would then wish to remove the 1c value from the screen and so on. this just a visual aid to keep track of the money left to play for. I'm hoping to have 22 Money Values would this be to much as far as menus go P.S thank Hal