Printable View
I am looking into developing a pachinko game. This will be a gambling game in essence, you pay to play and you win by the amount off balls you get in the relevant pockets or holes. Does anyone have experience of developing or even playing these games. They're massive in Asia and Japan apparently but I have found nothing in the UK market.
Would you play a pachinko style game (for all those gamblers amongst you)?
i think this will help.
http://www.flashkit.com/movies/Scrip...6147/index.php
i think anyone who likes the pokies will be into it and yeah they are more than massive in japan i remember walkin by parlor after parlor which contained nothin but packinko machines.
nice work BlinkOk, cheers for this. It will be a third party developing it but I'm interested to know peoples opinions on them in general.
your major problem is cause of the physics and lots of dynamic actions you won't be able to drive it from the back end. that's gotta be a major problem where hacking is concerned.
You could drive it from the backend but you'd use a different approach.Quote:
Originally posted by BlinkOk
your major problem is cause of the physics and lots of dynamic actions you won't be able to drive it from the back end. that's gotta be a major problem where hacking is concerned.
Lets say you launch 5 balls, the RNG will decide that 3 of the balls are going to 'score'. All you do then is add a bounce routine to the pocket making sure the other 2 balls, if hitting on the scoring pocket (or whatever its called), hit the side slightly and bounce out.
Hmmm, just a thought.
yeah i woz thinkin something like that. you'd have to make sure that the math woz calculated in EXACTLY the same way (i think flash has some rounding issues that other languages don't). you could mabey work back from the pocket the ball is intended to land in.
If you think like that though, you're pracctically mapping the path of the balls, this would make it seem a bit rigid, the ball animation and physics wouldn't be fluid enough for the professional gambler, they'd need a sense of realism, a perception of randomness and the achievable. I would only get involved to ensure x number of balls is scored or less than depending on the RNG.Quote:
Originally posted by BlinkOk
yeah i woz thinkin something like that. you'd have to make sure that the math woz calculated in EXACTLY the same way (i think flash has some rounding issues that other languages don't). you could mabey work back from the pocket the ball is intended to land in.
We plan to use stakes up to and including £1000 per ball so the risk management on this has to be perfect, theres absolutely no room for error.
Nice one Blink, you've been a great help.
wow! 1000 punds per ball. if i remember correctly the players would have 15 or 20 balls in play at any one time
Up to 50 we hope. I work for a large online gambling company, this is one of our future developments for the asian and japanese market. You'd be amazed how much people can drop online playing roulette, blackjack etc but you'd be even more amazed at how many thousands of people spend fortunes on scratchcards, lotteries and soft play games.Quote:
Originally posted by BlinkOk
wow! 1000 punds per ball. if i remember correctly the players would have 15 or 20 balls in play at any one time
madness.
I sometimes look at the talent in this forum and think that some of the people here could make a lot of money by adapting the style of games, I might start a thread about it actually.
good idea. just emphasize the pre determined outcomes and the reasons why, otherwise you'll prolly be inundated with all kinds of stuff.
hey,
i don't know a lot about pachinko, but if there's _any_ amount of player interaction then i don't think people will like having the outcome determined "arbitrarily" instead of by some type of simulation. at the same time, the point about cheating is valid.
as far as i can tell from google, players release balls via a pinball-type spring.. (i may have misunderstood though). assuming this is the case, the only variable which might affect the outcome is a single number per ball-in-play describing how "compressed" the spring was before the player releases it.
here's one idea for how to make sure that cheating's impossible:
-use a fixed-rate simulation. there are lots of resources on the internet for this, but basically updating the simulation at a constant rate (i.e 30 fps) makes it a LOT easier to get your simulation behaving completely deterministically. (the graphics can be updated at different rates depending on the speed of the client's machine, but the simulation itself MUST be run at a fixed rate).
-have the client run the simulation, BUT also transmit info to a secure server: for each ball launched, send the time it was launched and the "spring-compressed-ness" selected by the player.
-assuming your simulation is deterministic, the final state of a simulation driven by these inputs from the client should be identical no matter where it's run. if you set things up right, you can have a server version which uses the exact same simulation code without any graphics/sound/etc. -- so that it will run at a much faster rate. you can then compare the securely-simulated version with the client-simulated version to make sure no cheating occurred.
this may seem like a lot of complicated work, but it's the only way i can see to make it 100% secure without removing the essence of pachinko, which is about things bouncing and interacting in a dynamic physics-driven manner. it's also definitely possible to implement; we've made a game which uses a deterministic physics simulation and we're able to generate "replays" of player's games using only recorded keyboard input. this is great for making sure it's impossible to hack the online scores -- each highscore record contains the playe's input, so if we simulate that game ourselves and find that the final score doesn't match the submitted score, we've found a cheater ;)
you have to trust the client a BIT, or else the outcome is totally arbitrary from the user's point of view -- they need some amount of control over the outcome of the game. BUT, you shouldn't trust the client to simulate correctly since this will leave you open to players with hacked clients. so, instead you trust the player's INPUT (which is the bare minimum you need to trust) and let your secure servers handle the rest.
anyway.. sorry for the length of this ramble, i just wanted to let you know that it's definitely possible to NOT have to resort to some cheap "canned" ball movement and still have a secure pachinko system.
raigan
p.s - the "rounding issues" aren't flash specific, they're just the normal floating-point stuff you'd find anywhere else. as long as your code is well-written (see http://www.cbloom.com/3d/techdocs/epsilons.txt for a great paper on how to make sure your collision math is robust) you should even be able to run the simulation on a totally different platform (i.e java, etc.) and have the same results as the flash-driven simulation. this would take a bit of extra effort but it would let your server run the sim a LOT faster.
i agree with ya metanet but this is money we're talkin about. the company needs to guarantee it's returns. poka machines are the prime example; a guaranteed return for the owner, can't get much more pre-determined than that?
ps: that math stuff is cool, thanks for the link:)
i don't know anything about pachinko, but how to the "real life" pachinko operators get a guaranteed return? whatever they do should be reproduceable -- for instance, setting up the tacks and then running it a bunch to get statistics on how frequently each goal is hit, and adjusting the tack positions as necessary..
raigan
We looked at these several years ago when I was working for a poker machine manufacturer. There is a whole lot of legislation to do with electronic gambling machines here in Australia, I think we have some of the strictest regulations anywhere. As such, games of *skill* are not legal, which is to say the user input can have absolutely no bearing on the outcome of the game. In a pachinko appplication, the user input decides only the pin on which the first bounce occurs, and the game takes over from there. It's fairly easy to set up scripted 'bounce' animaton parameters that look dynamic. Once you pre-determine the series of pins that the ball will traverse, you reverse engineer parabolas that force the point of impact on each pin to one side or the other to provide a natural looking bounce towards the next pin.
Sadly, I left the company while those machines were still in development, and haven't seen them in general release, so I can't really comment on their commercial success or otherwise. But as you said Razor, they're for the Japanese market.
On another note, if you've ever played on of the physical pachinko machines... you'd be pretty hard pressed to make anything so loud and garish in flash.
thanks for your comments.
metanet, on off line pachinko (it has varied spellings) machines, players win more balls, not cash. We are doing pretty much the same but offering users the ability to cash in these balls for hard cash. Obviously to do this, we could not use a normal physics engine as undoubtedly, someone would find a way to constantly win and we would lose millions in the space of hours.
To get round this, we'd use an RNG to randomly generate numbers for us telling us exactly how much the user would win. This would inevitably make the game predetermined as soon as the spring is pulled but that is how most online gambling works. The RNG would be externally audited ensuring it was fair etc but this is the only way to safely do it. The maths route is too 'risky' for the gambling profession, we prefer fixed odds and a high payout such as 98% thus returning us a small but welcomed profit.
Slight, our servers are based in curaceo (as with most online gambling companies because of legislation at home). Other countries with lax gambling laws are Gibraltar, Cyprus, Estonia and the Isle of Man (but they're a nightmare to work with).