Jump to content


edwardb

Member Since 30 Jul 2004
Offline Last Active Jul 17 2018 10:03 AM
-----

Topics I've Started

Fruit Machines Inside Out: Manufacturing

10 July 2018 - 03:46 PM

Hi All

 

I thought I'd write some info about the manufacturing process of AWP machines. Obviously, this differed by manufacturer but you might find it interesting to know how machines were made, how some companies different in production methods and some of the cock ups that were made.

 

Cabinets

------------

 

Carcass cabinets used to be made in-house at most companies until the late 1990s/early 2000s. Barcrest, Maygay and Bell Fruit all had "cab shops" where CNC routers would cut cabinet parts from sheets of MDF or chipboard, which were then bolted together to make the bare carcass. Later, companies such as Cabinet Developments ("cabdev") or Postern Cabinet Co started to take over as running a cab shop was a cost that could be done without.

Cabinets and all the tooling that goes into making them is VERY expensive (in the hundreds of thousands), and so changes to cabinets designs were not frequent. Modifications to payout systems to combat fraud were fairly common, and some necessitate a change in cabinet design to amend coin routing, to stop rodding etc.
 

A fun fact is that BFM used to use their CNC routers overnight to make kitchen cabinets for MFI back in the 90s. Might as well earn some money from your machinery when it's not needed.

 

Wiring & Vac Forms

---------------------------

All the big companies made the majority of wiring harnesses in-house until the late 90s. Barcrest and Bell Fruit used to hand-wire lampboards (the plastic vacuum formed panels behind the glass) using a machine that would illuminate a sequence of lamps, and the operators would follow with a wire and insertion tool, and then crimp the wire, put it in the plug and do the next lamp row/column.

 

For complex games with lots of multicoloured lamps this was a pain, and a laborious process, so it eventually got outsourced too.

 

It wasn't uncommon to have mistakes where pins on a plug were misplaced, and so the wrong lamps lit, and you would have to go through and figure out which ones were wrong and change them over.

 

MPUs/PCBs

-----------------

 

With the exception of Barcrest (until MPU5 days) all companies outsourced MPU manufacture. I think Maygay might have done some in house but PCB pick & place machines are very expensive. Far easier to get someone else to do it.

 

A fun fact is that Heber, based near Stroud (Glos) who made MPUs used in many of the smaller & foreign manufacturer's machines, also designed custom hardware for some of the bigger manufacturers. They did a video board for Barcrest. They also make shower and washing machine controllers. Good bunch of guys, always like seeing them.

 

Reels & Buttons

---------------------

 

Reels and buttons were almost exclusively supplied by Gamesman and Starpoint. They would arrive in large boxes, and someone would have the fun job of fitting reel strips and inserting button decals. 

Barcrest (I think) used to make their own reel assemblies in the MPU4 days, before moving to off the shelf reels.

 

Glass

-------

 

I started when screen printing was dying off. The artists would send a file (over an ISDN line, or often a CD sent via post!) to the print company who would produce a test batch of 5 glasses, normally. It wasn't uncommon to see them being "off register" - that is, with one of the 4 colours (CMYK) being slightly off and the art looking smudged as a result. 

 

One of the funniest things I saw was the Hi Lo reel aperture being filled with a solid red - should be clear/transparent - which resulted in all glasses being scrapped. Bang goes a few hundred quid.

 

BFM used to print their own glasses in-house, but they stopped in the mid 90s as digital printing took off. No more 4 colour seps, just a large format inkjet printer, which printed to a film which was then stuck to the glass. A black backing was added to stop light bleeding out.

 

Glasses arrives on pallets and were built up into the finished doors, complete with gas struts and lampboard, ready to be hung on the cabinet.

 

 

Production

--------------

 

Barcrest and Maygay had their "flow line" - akin to a car factory, where a carcass cabinet was put on the line at one end, and operatives would fit parts as it rolled down the line, leaving a finished machine at the end. This was efficient, they could manage 2k/3k machines a month with ease.

 

Bell Fruit used to make everything on "stills" - literally a box on which the machine sat, and then one person would build up an entire machine. Not as efficient but often better quality.

 

During busy periods it was not uncommon to have the factory working 24/7 on three shifts, and sods law you would have a hit machine in the UK at the same time as you had a hit machine in say Holland or Germany, resulting in a high demand for machines. UK normally got priority.

 

Conversely lean periods meant people sat around doing nothing, so a lot of factory staff were temps, which meant that quality could be hit and miss until they were trained up properly.

 

Final Inspection

---------------------

 

At Mazooma, we took delivery of machines to our offices in Newark, where we would inspect each machine and correct faults. I will never forget my first big seller, Sinbad 2000 for Germany, where we had an initial small production run of 300 machines, arranged in two long rows the length of the warehouse, all with their front door open - like a guard of honour. As an 18/19 year old that was pretty cool to see.

 

We would install the software, and then power up each machine in turn (or 8 at a time if you were good!) and just check it fired up. Reel faults and cable snags were common. We checked they spun to the correct position and we would set the real-time clock. You would then run a few coins through it, ensuring the hopper and coin mech worked, and checked the mechanical meters were OK, before doing a RAM reset, switching it off and bagging it up for trucking to site.

 

Machines were loaded on a wagon and off to wherever.

 

Though I was a developer I always liked getting my hands dirty in whatever needed doing - every day was a school day and it set you apart from those who wouldn't get their hands dirty.

 

I think I've covered everything but as always, feel free to ask any questions!

 

 


Fruit Machines Inside Out: Design & Development

11 July 2017 - 03:18 PM

Hi All
 
Next instalment of FMIO, I will be talking about how you design a game and how it gets to production. Ready for a mammoth read?
 
1. Ideas
 
Well, everyone has ideas in this business, but it is usually a game designer (which wasn't an actual job title save for Barcrest's shrouded-in-secrecy MMG team) or developer who came up with the game. Most developers were players, in Mazooma certainly, and this showed in the games and how they played. I always felt this to be a good thing!
 
There is no set process, you have an idea, write it down and then when a new game is needed, out comes the notebook etc. I would always sketch out my ideas and make
sure they worked in my head.
 
What has/hasn't done well recently? What did the other companies release? Why did game X work and a similar game not? What new stuff can we do that won't confuse people?
The best "new" concepts were a 5% move on from another game.
 
So we've got a concept. Let's kick it off!
 
2. Design
 
So you have an idea and need to get it fleshed out. You write a game specification that explains how the game works, the layout of the board or trail, and
anything that might not be obvious. The spec is read by technical and sales people so you need to be sure it has everything you need to get across in plain English.
 
Have you checked your board layout? Can you reach the game over/mystery square within 12 moves of every other board position in case you need to kick the player out?
Are there any dead ends, i.e. can your game get somewhere where you can't boot the player out, and he can manipulate things?
 
List and explain every feature game, layout of the mystery/bonus dapple and what each outcome does. Got a cashpot? How does that work? How do you win it?
 
OK good. So your spec is written, usually 15 pages or so, now let's talk to the other guys and get it rolling.
 
3. Art
 
The game designer, developer and artist will all sit around and talk over how they want the game to look. 
 
The artist generally does a pencil sketch (though nowadays, mostly done on PC) which takes a few days to a week, and has the basic layout and rough character sketches on.
From that, assuming no big changes are needed, the artist will then start on the artwork proper. This can take anywhere from 2 to 8 weeks, depending on what's needed.
Detailed characters add a lot of time.
 
These days, art is done in Photoshop but some still use Freehand.
 
Once art is finished, everyone looks over it and checks for spelling/grammar mistakes and anything that may be wrong.
 
Designing artwork is a technical and mechanical challenge. You have "restrictions" which are areas you cannot place a lamp for mechanical reasons,
such as near a hi-lo reel (I think we left a 10mm gap top and bottom) and also near cut-outs for coin/note acceptors etc.
 
There are areas where reels cannot go for the same reasons, as they would catch on hardware inside the machines. Hence why you cannot have a reel on the
right where your hoppers and coin mech are! Each cabinet would have a restriction drawing made for it, showing where you cannot place lamps or reels. I have one somewhere, I will dig it out.
 
You need to leave a 3mm "land" between each lamp box as that's the minimum tolerance a vac former can do.
 
The artist will produce a "PCX" file, basically a technical drawing of where lamps are, and also for printing, other colours of the artwork - called "separations" or just "seps". More below.
 
4. Prototyping, Glass Printing & Vac Forms
 
A prototype machine is then created, which is usually a paper print (done on a poster printer) stuck on a thick bit of MDF.
A punch is used to mark where lamps will go, and then holes drilled out. A bit of plastic is stapled to the other side, and lamps inserted.
 
Remember to remove all burrs and sharp edges!
 
Someone (usually someone in the cab shop, or other tech person, but I did my own) then designs & documents the wiring harnesses and wires the prototype lamp board.
 
Wiring is expensive, so you don't want to use more than you need. You generally follow the shortest path from the connector to the lamp.
Once that is done the machine is given to the developer who starts the code.
 
We now have our bill of materials, we know what it takes and what it costs to make a game, so it can be sent to stores to order parts for production.
 
Meanwhile, we have to get building the real machines, and that means printing glasses, getting vac forms made and wired up.
In the old days, BFG, Barcrest and Maygay had their own print shop and vacuum forming kit. It all got outsourced in the end.
 
As an aside, in the old days, the BFM factory used to make kitchen cabinets for MFI. They had all the gear, so why not use it overnight when the factory was quiet?
 
To print a glass, there are two ways:
 
1. Screenprinting, which you take the artwork and split into 4 colours (cyan, magenta, yellow, black) and print each colour separately. If you look closely at an older glass
you can see the 4 colours. BFG used to print on perspex which never worked as well as glass - the colours looked duller.
 
2. Digital printing, essentially inkjet printing on to an adhesive paper which is stuck to glass. Cheaper, more efficient and more flexible.
 
Spot a mistake on the glass? In the bin they go. Fix and print new ones. Expensive - £40 to £80 a pop for a top glass, £20 for a bottom glass, not to mention staff costs etc.
It did happen. I remember the first Mazooma games hi/lo games had the hi-lo reel window solid red - god knows why. Had to scrap them all. Moving to digital printing saved a lot of cost.
 
Vac forms; if you did in CDT at school the process is the same. You made a wooden jig (done by a CNC router) and then pull heated plastic over it, remove the air, and
there's your vac form. Simple. £15 or so for each unit.
 
Wiring the vacs; a job I hated. We had a rig where you put the last black over a lightbox, and then the vac on top, and a pedal would step through each lamp in sequence
and you followed it with a wire. Tedious but that's how it was done. You then plugged in the loom and checked for bad connections, missed lamps, etc.
 
You now have a glass and wired vacs, and these can go to the factory for a hand-built number of machines for use in dev (later on) and then testing.
 
4. Code
 
The prototype machine is handed over to the developer, who will write the code. Sits next to your desk.
 
All machines start from the the previous game - to ensure the latest versions of the libraries are used, and any bug fixes are also in.
 
The developer normally starts by getting lamps configured; hopefully (though not always) a lot of lamps are the same as a previous game.
Entering upto 256 lamps as #define LP_NUDGE_1 (LP_DATA_1|LP_STROBE7) gets very tedious....
 
Once lamps are defined, we can make tables (arrays) of lamps to make control much easier. Say you had 12 lamps for your nudge pot, you'd create
a table e.g. nudgePotTable[] = { LP_NUDGE_1, LP_NUDGE_2.....} and then with one line of code, AllLampsOff(nudgePotTable), switch them all off.
Easier than doing all lamps individually...
 
Once your inputs and outputs are done, you've entered your reel strip layouts and reel mech types (libraries make this easy), you can then move
to start coding the game properly.
 
As you've started from a previous game, if it's the same style of game (a board game, lets say) then you define your board squares, and call
functions to action the square (e.g. AddToCashPot(100) or AddToNudgePot(1) etc). 
 
Before about 2000, most dev and debugging was done on the machine. We then ported the entire software to PC and have a fast play simulator where
you can use Visual Studio to debug the code before it ever reaches a machine. Logic and visuals are entirely separate for the most part; the visuals
just show (on lamps, alpha or screen) what the logic has already decided what will happen.
 
The obvious exception to this is skill stops, where you watch for a button press and then action that accordingly (sometimes "rolling off" if the player stopped on something
we didn't want them to have!).
 
This is a very simplified version of what is a long process, coding a game could take 12 weeks until it was ready for testing. You have to write any new feature, but
if you want a Money Belt, and you've done one before, you go and take that rather than code from scratch.
 
Most games were just bolting pre-existing bits of code together, in truth.
 
When you want to test your code on the machine, you download via an EPROM emulator. These are boxes of very fast access RAM, connected to the USB (or parallel port!) of a PC
and you use a utility to download your BIN file to the machine. The emulator usually had a hardware reset line, connected to a pin on the processor, which pulled the CPU
into reset whilst the code downloaded. Not doing so resulted in the machine trying to boot every second or so, and failing, and you got this awful clicking noise every time.
 
Then the machine boots up as normal, and you use either the alpha or the serial port to debug what's going on. A lot of times we put pauses in so we can 
check what's going on (such as when calculating the win from nudges) before letting the machine continue.
 
Nudges are interesting, actually, as they (especially for multi line games) need quite a bit of computational power. I remember coding a game on Scorp 4 which had 3x 24 symbols
on the reels, and 5 lines with wild symbols. I got it to calculate the best win with 24 nudges once. It took the poor 16mhz processor a whole 8 minutes :)
Needless to say, we found another way - pre-calculated look up tables of wins from your current reel position.
 
So assuming your game is finished, coded, balanced (i.e it plays right and your payout % is fine) then it's off to test...
 
5. Testing
 
Though you test your code, there is no substitute for a fresh pair of eyes.
 
Game testers (I started as one) will sit and play the game both methodically to a script, and "free play" i.e. playing as a real player would,
to find bugs. Some test scripts are simple, i.e. insert £1, check it registered and meters update, etc, and some are much more complex.
 
Testing takes a good 2 to 3 weeks. Once any bugs are fixed, and the game is ready to go out to the wider world, you "master" a set of EPROMs.
This gives them a part number and also adds security to prevent tampering (checksums tests, etc).
 
During the end of coding and test phases, 25 or 50 machines are built for primary test; these are given (in the old days) free of charge to a pub company
for test. Machines are sited and weekly figures are generated by the Pub Co and fed back.
 
You are looking for your game to beat the previous machine sat on that bit of carpet space. This is known as "indexing". So the last machine averaged
£200 a week - that's a 100% index. Your game goes in and does £400 a week, that's a 200% index. That rarely happens, usually if the game is good you'll see a 120% index.
If the game is good, or the pub's been closed, the index is affected.
 
If the game does a good bit higher than the previous one, the game goes to secondary test with more machines (again, given free..) and the process repeats for another 6/8 weeks.
 
6. Sales?
 
Machine fail test? You get them all back - usually in pieces. Big money up in smoke.
 
Game does well? Time for orders! Big companies would order in lots of 250 or more units. One of my favourite sights was seeing the Mazooma warehouse full
of machines, and a good 100+ with the cab door open looking like a guard of honour, walking down the middle. Awesome stuff.
 
Lots of machines sold, we can keep the lights on and people's mortgages paid and kids fed. Great.
 
Now on to the next game............

Fruit Machines Inside Out: Compensation

06 July 2017 - 01:20 PM

Hi All
 
Decided to write a some articles about how real fruit machines work. In today's lesson, how fruit machines would control themselves, i.e. how decisions are made to pay a prize (or not).
 
BFG/Mazooma called them "compensators", Barcrest "stablisers", Ace/JPM "reflexes", Global "buckets" and 101 other permutations of the name. They all mean the same thing; essentially an amount of virtual money held in memory that the game uses to decide how much money we can give back to the player.
 
As I learned this stuff at the University of Mazooma, I called them "compensators", and that's what I'll use for this post.
 
How they work:
 
A game has a number of compensators, decided by the developer and/or mathematician responsible for the game.
 
Each game, we put the target % of the game into a compensator. So if the game is set to 80% payout, and you're on £1 a game, 80p goes into the compensator, and the other 20p is forgotten about.
 
A compensator is viewed from the player's perspective, that is, if the compensator is negative (hereafter referred to as -ve and positive as +ve) then the machine owes "the player" money - it has "underpaid". If the compensator is positive, the player owes the machine money - it has "overpaid".
 
As a side note, Barcrest worked the opposite way (from the machine's point of view - +ve being underpaid, -ve as overpaid).
 
We divide the compensator into "levels". The size of each level depends on various factors, again usually determined by the developer/maths person.
 
Let's see an example:
                                      |
          0------1------2------3------4------5------6 Compensator Level
                                      |
+2500  +1000  +500     0    -500   -1000  -2500
 
So Level 3 is our midpoint - the compensator has ZERO money in it. But that doesn't mean you won't win. Quite the opposite.
 
Now we play some games, we stick £10 in and we win nothing. Now our compensator is -£8 (we took 80% of our stake, remember, the other £2 has evaporated!), we are there now in level 4 (between -£5 and £10). 
 
But how do we decide if we're going to win? Easy. We use a chance table! 
 
Let's see those same levels, but this time we're going to assign a % chance of something happening:
 
£2 nudge win chance:
                                      |
          0------1------2------3------4------5------6 Compensator Level
                                      |
            1      3      8      15     35     60     80 (% chance of winning)
 
As you can see, the chance of getting a win (or maybe of getting the feature) is adjusted depending on the level of the compensator.
 
Chance tables controlled almost every aspect of the game; the likelihood of getting nudges (losing or otherwise), the likelihood of holds, features, even to the point of choosing which music to play (the more money we have, maybe we play a more "intense" bit of music?).
 
When a win is given, assuming the player collects the win, we remove that money - £2 in this case - from the compensator (after which is still in level 4, now) and carry on. If they didn't collect the win (gambled, and lost) then we don't do anything - the machine still needs to get rid of that money at some point. When a compensator is at zero, the machine should be bang on payout %.
 
The money in a compensator has no relevence to the physical amount of money present in a machine - so if the hopper is full or empty makes zero difference to how likely you are to win (or not). So those urban legends about "the machine is backing" (i.e. coins going to cashbox) and therefore due to payout are nonsense, but we all had a good laugh about it!
 
Most AWPs, certainly ones we did, had 1 main compensator for general gameplay, and 1 for big wins. We would then divide the 80% into the two compensators, maybe 80% of 80% (are you following?) to main, and 20% to reserve. Once reserve compen had reached our target value, transfer the whole lot to main comp (which then shoots up to level 6 - super generous!) and get rid of it. Maybe set a flag to say "big win time" and force a red mode or jackpot repeater.
 
Believe it or not, often, the more simple the game (lo-tech/Bar-X) the more compensators there were. From memory, some of our lo-techs had 20+ compensators, all receiving a small % of the stake each game, and then use to pay for things happening in the game (multiple streaks, hopper-emptying wins, etc).
 
Hope that's useful to some - let me know of any questions!
 
:)
 
What would you like to know about next?
 

Flyers, flyers and more flyers

04 July 2017 - 04:08 PM

Hi All

 

I have started uploading small versions of the zillions of flyers I have from 20 years in the industry. There are a lot of crap ones and loads of foreign AWP machines (since that's what I used to code, mainly).

 

I started a gallery (edwardb machine flyers) but not sure if this is the right place? If anyone wants a high res scan of a flyer then let me know.

 

Some right classics in there....and some games that flopped miserably!


Foreign EPOCH games, anyone?

26 January 2017 - 09:39 AM

Hi Folks

I haven't been on these forums for years, but some of the old timers might remember me.

I was a programmer at Mazooma and latterly Global Games before heading off on my own, and doing various things. Still very much in the industry but in the online side now.

 

I coded pretty much every foreign AWP game they did. Since all these machines are long outlawed and probably rusting in a shed somewhere in eastern Europe, would anyone like to have a go at making an emulation of some?

I found the ROMs and original source code on a CD whilst cleaning out my house recently, and can probably get a decent scan of the original artwork.

 

Also, for reference, I am working (very slowly!!) on writing a book about my time in the industry, stories about some of the characters, the games, how they're developed, how compensation/control of the games work. Hopefully accessible and understandable to everyone who's ever played a fruit machine, and full of funny stories. It's titled "Give It A Spin: Tales from the UK fruit machine industry 1996 - 2010". Will probably self-publish but it's only half finished.

 

Cheers

Ed