Machine owner/ Manufacturer relationship.

[milk monitor]

I have a question which to which have often wondered about the answer, and would be grateful if anyone could shed any light on the matter.

When an emptier reaches the public domain, a sizeable chunk of the machine owners revenue is lost instantly. Can they recover this from the manufacturer? Or another source.

If not and confidence is reduced the manufacturer would expect a significant drop in future sales. Furthermore as such circumstances don't seem to benefit either party, how have they continued to exist? If a computer can be programmed to the level at which it can beat a Chess master, why can't something as simple as a fruit machine be error free?

[blackmogu]

I have a question which to which have often wondered about the answer, and would be grateful if anyone could shed any light on the matter.

When an emptier reaches the public domain, a sizeable chunk of the machine owners revenue is lost instantly. Can they recover this from the manufacturer? Or another source.

It's a little bit of a complex area. How can you prove that money was removed from the fruit via legal/illegal means ? There is no black-box recorder in machines at the moment that has a history of play (except on S16). If it were via illegal means, then barcrest/bellfruit etc. could not be held liable. If via a software fault, then they would be. The lack of any real method of audit leaves a slim path for claiming against software flaws.

Perhaps all the manufacturers have an agreement between them to have a joint disclaimer that suppliers must sign that waives any liability in the event of a software flaw causing loss of revenue.

If not and confidence is reduced the manufacturer would expect a significant drop in future sales.

A-la maygay. RIP.

Furthermore as such circumstances don't seem to benefit either party, how have they continued to exist?

When you are making millions a day, who cares about the odd glitch here and there. It really wouldn't surprise me if some of these 'bugs' are sanctioned at a high level, and then sold on the market for massive sums. Good way for MDs to supplement their incomes tax-free.

If a computer can be programmed to the level at which it can beat a Chess master, why can't something as simple as a fruit machine be error free?

You know, with proper development practices, and a few competent coders, these things wouldn't happen. It's not rocket science. But, having seen how much they pay for programmers, i'm not surprised they get the problems they have. They are running a big-money business on a shoestring budget. Also, considering my last point, perhaps they have no incentive to buck up their act.

[6502]

because fruit machine software engineers (the ones I've come across anyway) are just not on the same planet as everyone else,
they might be very clever to be able to code stuff, but they very easily miss some absolutely glaring errors.
sort of 'can't see the trees for the woods' type of thing.
considering they are coding, they themselves don't seem to think logically

they just seem to have a different mindset to "practical" people.

Oh and some are just down right lazy bastards, and the rest are too busy taking charlie.

[Cardinal Sin]

What was the last program or game which didn't have ANY bugs whatsoever?

A lot of emptiers I've known couldn't have come about simply thru honest mistakes, they must have come from dodgy programmers wanting to make a few extra bob out of hours..

[theoak]

I am highly suspicious of emptiers, though nto complaining. Sometimes you can have a rechip that brings about a NEW empiter, not possible on older software versions, would this suggest it was programmed in on purpose?

[blackmogu]

A lot of emptiers I've known couldn't have come about simply thru honest mistakes, they must have come from dodgy programmers wanting to make a few extra bob out of hours..

Having been a programmer for over a decade in the unix/kernel arena, I can state that if you are semi-competent, then these are not honest mistakes. You know where your boundaries lie within a given set of inputs, and compartment accordingly.

So, they are either incompetent (my best guess, given the old saying if you pay peanuts, expect monkeys) or dishonest, or an intersection of the two sets.

It seems that the programmers have yet to take the simple steps of never trusting inputs after an event outside it's control has occurred.

[Cardinal Sin]

Hmmm....

Casting my mind back: DK, KK, Arcadia, Flashback, JTT, HiLoW, SRR etc I guess could have been the result of an oversight...

But some other ones, such as DOND, LS, Exi-Bar, UnO, SC don't seem (to me anyway, and I could well be talking out my arse here) to be possible just as result of an honest mistake.

It always amazes me how these machines slip through the most elementary of testing.. i.e. the £250 CTL with the Superhold (not that I ever found one).

[bowie]

How do these emptiers reach the public domain in the first place, i refuse to believe some of these things are found out through sheer luck.

[blackmogu]

How do these emptiers reach the public domain in the first place, i refuse to believe some of these things are found out through sheer luck.

most probably theft/leak of their test harness.

[Weyland]

Well, the last game I worked on (for PC) was tested pretty constantly by a dedicated team of five testers throughout its two years development, and still needed patching soon after release!

Bug-free software just doesn't happen these days. Things are too big and complex and you can't really predict how they'll interact unless you try it. And there's just too many combinations to try them all with a small team.

And as for coders being "different"... one of the best quotes I ever heard about my profession was "Coders who work in the games industry do so because they couldn't possibly work anywhere else."

[blackmogu]

Bug-free software just doesn't happen these days. Things are too big and complex and you can't really predict how they'll interact unless you try it. And there's just too many combinations to try them all with a small team.

pedantic I know, but it does happen. And we use mathematics to definitively prove what will happen. An example below:-

http://www.eschertech.com/products/bugfreesoftware.php

The point about fruits is that for what they do, the software is _not_ complicated. They have very little to deal with. And also as important, the games do not have to be bug free in alot of areas. They just have to have proper locking techniques and messagebus serialisation on certain resources. They are sloooowly getting there (cctalk). Race conditions due to parallel messagebus processing on unlocked resources (think credits on slotto for free spins) is sloppy to say the least.

If they got that right, any bug that cropped up would impact the players experience, but not the profits. A win-win for supplier/manufacturer.

[Weyland]

Well, I've used systems like that before. The main effect they had for us was to increase the development time of a project by 50%, and produce code that ran half the speed.

I appreciate that's not a problem for most areas of the software industry, but when you've got a movie license to fit into a PS2, it is.

Of course, this all depends on the error actually being in the bits which talk to the other peripherals. They could just be bugs in the part which decides whether or not to let you win - which must be the majority of the code, surely?

[blackmogu]

Of course, this all depends on the error actually being in the bits which talk to the other peripherals. They could just be bugs in the part which decides whether or not to let you win - which must be the majority of the code, surely?

Say that you had a bug that let you win JP. The machine can pay this out, and recoup percentage from recognising it has drifted massively, and throttle back features/reel wins. Rather like clubbers do when rarely they have a shortcut.

Now, that brings us onto an interesting side-point: Why do clubbers not suffer like AWPs ? Better development process ? Built in defence mechanisms like feature throttle ? I conjecture that due to the comparatively large monetary value held within clubbers, and the likelyhood of client refills, they did a proper job. They know how to make machines already that don't suffer shoddy programming, because if there is a slight flaw in a clubber, then that could easily turn into an empty due to the disparate jumps in prize values.

[Weyland]

I remember when we tried the "Extreme Coding" method as well. We stopped that after the third punch-up erupted in the office. I kid you not.

Say that you had a bug that let you win JP. The machine can pay this out, and recoup percentage from recognising it has drifted massively, and throttle back features/reel wins.

Ah, but what if the bug is one that lets you win a JP, but doesn't record the fact? So even after paying out, it's still just as ready to pay out again. That's a simple error that may not show up in the records of any test harness.

I've always thought clubbers were just reworked S34s with different prize structures.

[blackmogu]

I remember when we tried the "Extreme Coding" method as well. We stopped that after the third punch-up erupted in the office. I kid you not. ]

Unforgivable. There is no excuse why the bank is not treated as a locked variable. Any addition to it should be done by one calling function that also references the floating percentage adjustment function. It's then inescapable. Make it transactional as well to account for powerouts, and there is no problem. It's so simple it's ridiculous.

I have to assume you are playing devils advocate here !

Never tried extreme coding, but I do practice structured development that is scrutinized by hostile parties.

I've always thought clubbers were just reworked S34s with different prize structures.

Correct. Bigger prizes. Also better code (for the supplier!).