[Trigger] Slotmachine - Win recognize problem

[Donnerkoettel]

Hi guys. I have 2 problems with my slotmachine. A map i have worked on for long time now. First i will explane, how i made it, since not everyone nows how a slotmachine works.
-Me too. So i've come up with this idea:

I wanted to create a slotmachine with 5 wheels and 3 symbols (units). I wanted a scatter and an increasing jackpot. More than just 5 winning lines and some day maybe a bonus game when something special happens.

So i created a unity-type variable with an array of 33 to create a wheel. When you write it on a paper and put the ends together you know what i mean.

When the player does a spin, 5 random-numbers for each wheel 1, will be created and the units spawn. That was quit much if/then/else stuff, since i had to check wich unit comes before and after. To increase the thrill, i let 'em spawn backwards to crush all hopes when the last unit is spawned. (Not when 3 wheels have stoped. Thats kind of dumb from the originals)

So far so good. I made trigger to check if a there is a win, by unit-type comparison of the units building the winning lines. Then i added specialeffect triggers using blitz effects.

I have also managed to save and load the jackpot via gamecache!

The problems i have is, that not each time the win is recognized and the slot runs just through. I have this problem also by manual spinn. When that happens, the special effects does not accour. (What is right so far, but not when ther IS a win -.-)

The second problem is the defense value of my dummy unit. I have tried everithing to clean the Interface from unused stuff, but this stupid zero (also tried 9999999999) does not disappear. I cant overlap it with an bigger blp in black for the Armor type eather. That tiny little zero realy sucks!

Hope someone can help me with this 2 problems. Please download it, check it out and tell me where i am wrong.

 

[Dr Super Good]

I suggest you read documentation on how to create slot machines. It is a well known industrial process so nothing to reinvent.

The basics are that the slots themselves are not coupled to the outcome. The outcome is already pre-determined the moment they pull the handle, with a single RNG roll. This allows one to manage risk, chance and reward in a way that you, the casino, always end up the winner in the long run while still conforming to gambling regulations. The slots then behave in a way to show this outcome, including rigging it so that even with perfect stop precision it will not be possible to get anything but the pre-computed outcome.

There are a few exceptions to this. I believe Sonic the Hedgehog purposely disabled this rigging mechanic with its slot machines in various console games to improve fun factor and hence outcome was entirely skill based, when you pull the leaver to stop individual wheels. Final Fantasy 6 used a hybrid approach between rigging and skill where by it was rigged against certain over powered outcomes (instant death to all enemies, even final boss) but not rigged against lesser outcomes (healing, summon, instant loss, etc). These are cases when the standard approach was purposely not used so as to make a game more fun/skill orientated than real machines.

I suggest reading Wikipedia...
Slot machine - Wikipedia

You basically select an outcome at the start and manipulate the wheels such that it will happen. The sum of all outcomes times their probability defines the player returns. In the case of a Warcraft III map with virtual currency you might want to set this at 100%, or even over to encourage people to play it more. If you want the feature to exist but discourage its use then a value of 80% might be more appropriate.

 

[Donnerkoettel]

Wow, thanks for the reply. I've read plenty much of how Slotmachines work. The computer-slots and the very old only-mechanic. The biggest difference between them is, that computerslots from casinos nowdays actually havent real wheels. They just create symbols by chance and by doing so, they betray the gamblers with so called "nearly" win pictures. I dislike this concept, since it is not fair. Making an algorithm wich does nothing to avoid wins till the random number hits the lowest win is nothing anybody wants to play. But thats how it is today. Instead i wanted it more mechanically. Of course i use random numbers BUT i use wheels, wich are made of an unit-type-variable with an array of 33.

I know very well wat i want it to be and in my eyes it is very near to a slotmachine.

Anyway, this is more a Triggerproblem than a "how to make it from the start". I know there is a problem in my triggers, but i cant say what it is. Is it inballanced? Are there memory leaks? Or something else. My head is smoking. I am sure that each trigger runs only after another. Everything should work, but sometimes the wins just dont work. Than they work fine. Its not a specific win-line, i really dont know what to do...

Edit:
Im making this Slotmachine only for privat use, i havent planned to bring it out as something big. So the funfactor is not in question. But thanks anyway. A little feedback is always welcome.

 

[Dr Super Good]

Making an algorithm wich does nothing to avoid wins till the random number hits the lowest win is nothing anybody wants to play.

Billions of dollars a year are made from such machines... So "nothing anybody wants to play" does not hold true.

I assume 3 wheels of 11 each? If that is the case you would want to map your unit array as a 2D array. You would have a separate integer array with the same mapping to track the type state of each wheel for internal calculation. Wheel offset would be a real which gets converted to an index representing the symbol the wheel is currently on. The unit array is used only for graphics, trying to approximate the actual type state used internally with some interpolation to make rotation smooth. Stopping a wheel saves the index of a wheel in another array. When all wheels are stopped then the wheel indexes are dereferenced with the type state of the wheel to get the final wheel result. The final wheel result is then resolved into an outcome, potentially resulting in graphical effects.

 

[Donnerkoettel]

I have tried to avoid that way, since unit-type comparison is faster to trigger than making a full list of each possible integer-/real-win list. To get those values i could give out text messages ingame and check if the units are right for each line. That could be months of documentary for me. But the question is, are integer-/real-comparisons faster than Unit-type-comparisons? If i make a trigger with each possible win-value, it could turn out to one of the hugest triggers ever made. For me it defenetly would the biggest. But is it worth the effort? I cannot believe this could work...

 

[Pyrogasm]

Unit-types are integers (in base-36). There is likely no reason to worry about performance here; much more complicated and resource-intensive things have been done in GUI.

 

[Donnerkoettel]

Is that so? Then why do i have wins, wich arent recognized by my triggers? Shall i try something with Trigger-Queue? Never used them before. And the checking triggers come one after another, till the Boolean wich alows the next spin to run cames at the very end. Why are there sometimes functions missing and sometimes not?

Edit:
Just recognized that i am using waits in the unit spawn triggers. If it's not an memory leak to the unit variables i dont know what the problem could be. I'll replace the waits with expiring timers, wich should work better. I'll report if it solves my problem.

 

[Dr Super Good]

are integer-/real-comparisons faster than Unit-type-comparisons?

Due to JASS overhead all of them should be equally as fast. What GUI calls unit type (not unit) is just an integer.

If i make a trigger with each possible win-value, it could turn out to one of the hugest triggers ever made. For me it defenetly would the biggest. But is it worth the effort? I cannot believe this could work...

I do not understand why such trigger would be large. If you do not want to rig the system in a professional way as described by Wikipedia, you would simply test the symbol type currently selected for each real and perform the appropriate action, eg if all the wheels have the same symbol then look up the reward amount for the symbol and pay it out, else person was a loser. The simple professional approach is to decide the outcome as the lever is pulled using probability theory, eg a selection of numeric range tests on a random integer or real, and then configure the wheel logic so that the outcome becomes reality.

I would not recommend testing unit types or units at all. In my opinion a better approach to implement the wheels would be to make them entirely virtual inside variables. The unit positioning could then be another system which translates the virtual wheel state into physically placed special effects or units. Each symbol type could be given a sequential numeric number. Wheels can be defined as a list of symbol numbers. Current wheel angle can be defined as an offset into the wheel symbol list, with possibly an additional interpolation value used only for visual interpolation or deciding lever outcomes. Resolving the outcome would be comparing the symbol types of the current wheel position for each wheel. Results could be implemented as a set of arrays mapping symbol type to various pieces of data such as payout, extra credit, etc. Multiple play directions would be implemented by repeating the same test but applying offsets to the current wheel position of each wheel based on the positions played. Play positions could be sequential numeric values that are mapped to a list of wheel position offsets, with there being a list of play positions the player has chosen to activate.

 

[Donnerkoettel]

@Pyrogasm
Thanks for pushing me into the right direction. It was indeed a leak problem. The Slot runs pretty fine now, no more wins wich not get recognized by the comparison triggers.

@Dr Super Good
Im very sorry, i missunderstood you from the very start. Please excuse my bad english. This is such a complex theme to me. Using reals or integers is a bit more effort than comparing unit-types, but not that much. I also miss-understood that. The values are already there from the randomnumbers i use for the wheels. So i dont need to check ingame if the number is a win. Pretty stupid from me. ^^

Maybe i will do it this way to make the units changeable. So if i want to play other than undead theme, activate channel and change units to orc ect. But that is another story. Now the system is running fine, so i can make the units move from the top of screen to its place, instead of just spawn it there.

Anyway the problem is solved and i can make this work fancier. Thank you 2 for helping me forward and specially your for ideas Dr Super Good. ;-)