Skip to main content
Howarth Games Logo Overlay

Barcrest

Ashton-under-Lyne — fourteen years and nine months of gaming machines

Barcrest

Barcrest made fruit machines. If you drank in a British pub between the seventies and the two-thousands, you have stood in front of one: the reels, the nudge buttons, the hold lights, the feature board round the outside that you worked your way along. The company was in Ashton-under-Lyne, on a site on Margaret Street, and for most of its life it was the biggest name in the business.

I was there from January 1994 to September 2008 — fourteen years and nine months, in five jobs, having arrived from Software Creations and the games industry. It is a longer stretch than everything else on this site put together, and it is where most of what I know about writing software that has to be right was learned.

The company, and what became of it

Barcrest had been going since 1968, and it grew up alongside the machines themselves. It was among the first to put real computing behind the reels: MPU boards that turned a game of pure chance into one with skill stops, holds, nudges and feature rounds. Nearly every wheel bonus and pick-a-box round in the industry since is descended from that idea, and a great deal of it was worked out a few miles east of Manchester.

The site was around five acres, and it did the lot: design, electronics, software, cabinet build, test and approvals, all in the same place. That mattered more than it sounds. When the hardware engineers, the maths people and the software engineers are along the same corridor, a question about why a lamp flickers or why a percentage is drifting gets answered in an afternoon rather than a fortnight.

The ownership changed underneath us more than once, which is why my own record alternates between Barcrest Limited and Barcrest Games Limited depending on the year. Barcrest spent a long stretch as part of the Bass group’s leisure business, was bought by IGT — International Game Technology — at the end of the nineties, and was sold on again to Scientific Games, whose UK operation traded as SG Gaming. Scientific Games itself became Light & Wonder in 2022. The Barcrest name survived all of it: the brand and the back catalogue are still on machines and in online slots today, which is a long innings for a company from a side street in Ashton.

What I did there

Five jobs over fourteen years, all of them on the same site in Ashton-under-Lyne. They run in order, from the test bench to writing the machines.

Test / Approval Engineer

Barcrest · 1994–1997 · Ashton-under-Lyne

Testing gaming machines. The first job, and in hindsight the right one to start on: before you write a machine it is worth spending three years finding out how they fail.

A gaming machine is not signed off the way a game is. It has to behave correctly for every combination of coin in, button press and power cut, it has to pay what it says it pays over the long run, and it has to do that in a pub for years with nobody looking after it. Approval work is where that gets proved — running a machine through its cases, catching the ones that only appear on the ten thousandth spin or when the power drops mid-payout, and not letting it out of the door until it does the right thing every time.

EMC / LVD Engineer

Barcrest Limited · 1997–2001 · Ashton-under-Lyne

Testing gaming machines to British and European safety and emissions standards — EN 55014, EN 55022, and the low voltage directive work that goes with them.

This is the part of the industry nobody outside it thinks about. A cabinet full of switching power supplies, motors, lamps and a processor is an excellent radio transmitter if you let it be, and it is a hazard if the earthing is wrong. So the machine goes in a chamber, the emissions are measured across the band, and the ones that fail come back to be fixed — a cable rerouted, a filter added, a screen bonded properly. It teaches you that a design is not finished when it works on the bench, and that the physical and the logical are not separable: a software fix and a ferrite bead can solve the same problem, and sometimes only one of them is allowed.

The other direction is the interesting one. Emissions testing asks what the machine throws out; immunity testing asks what happens when something is thrown at it — and in an industry where the box holds money, that stopped being a purely academic question quite quickly. People did try it. A mobile phone held against the right part of a cabinet, or a home–made transmitter waved at it, on the hope that enough interference in the right place would confuse a meter, upset a sensor or persuade a hopper to run. So that was tested for deliberately: fields applied across the band, bursts put onto the mains and the signal lines, static discharged into every surface a hand can reach, and then the check that mattered — that the machine either carried on correctly or stopped dead and said so, and under no circumstances paid out.

It was good fun to sit and attack a machine for a living, and it is genuinely the same job as security testing anywhere else. An input nobody designed for is still an input. If the only thing standing between a radio and the cash box is that nobody has thought to try, then it is not a compliance failure that turns up eventually, it is a security hole with a queue forming at it.

Software Engineer

Barcrest Games Limited · 2001–2004 · Ashton-under-Lyne

Writing reel and video based gaming machines, in Forth and C++.

Forth surprises people. It is a stack language with almost nothing to it, it compiles to something very small, and on hardware where memory is measured in kilobytes and the processor has other things to do, that is exactly what you want. You define words, and the words define more words, until the top of the program reads like a description of the game rather than of the machine. Written badly it is unreadable; written well it is the tersest correct thing in the building.

The game itself is only half the job. The other half is everything around it: the credit and payout logic, the meters that have to survive a power cut mid-spin, the door switches, the recovery when the machine comes back up in the middle of a feature and has to work out where it was.

Production Software Engineer

Barcrest Limited · 2004–2005 · Ashton-under-Lyne

Writing the embedded hardware libraries the reel machines were built on, in Forth, C and C++.

Below the game there is a layer that talks to the actual metal: stepper reels and their optics, hoppers and note acceptors, lamps, buttons, the display, the meters, the security switches. Getting that layer right is what lets everybody upstairs write games instead of drivers. It is also unforgiving work, because a fault in a shared library is a fault in every machine on the line rather than in one game.

Video Software Engineer

Barcrest Games Limited · 2005–2008 · Ashton-under-Lyne

Writing video based gaming machines, in C++ and Forth.

Video is where the industry went, and it changes what the job is. The reels stop being a mechanism and become a picture of one, which frees the game up enormously — the reels can do things no motor would allow, the feature can be anything you can draw — and takes away the thing that made a mechanical machine honest to look at. The maths does not change. It still has to be provable, and it still has to hold its percentage over a life of millions of spins rather than over an evening.

One game, then several, then one that changed overnight

The shape of the machines changed underneath me while I was writing them, and the change is the most interesting thing about the period.

At the start a cabinet was a game. The glass was screen–printed for that game, the ROMs were programmed for it, the button legends were its own, and the approval had been granted against that exact combination. Changing the game meant an engineer in the pub with a screwdriver, a new set of chips and a new glass — and the paperwork that goes with swapping the part the approval was written about. A game had to earn its keep for a long time, because replacing it was a physical visit to every site it stood in.

Then one cabinet started holding several. A menu on the screen, the player picks, and underneath it a platform: one hardware layer, one set of drivers, one credit and payout mechanism, with the games sitting on top as content. That sounds like a simplification and is the opposite of one. Each game has to keep its own books — its own meters, its own percentage, its own idea of what it owes — and the machine has to know whose money it is holding when the power goes at the wrong moment. Memory did not grow to meet any of it: the same kilobytes now had to hold several games and the thing arbitrating between them.

The last step is the one nobody outside the industry expects. The content stopped needing a person. A machine could be given a different game down a line — between sessions, overnight, in principle while the pub was still open — so the floor could be changed to suit a Friday rather than a Tuesday. Every hard problem in that sentence is a trust problem. The machine has to be certain that what arrived is exactly what was meant to arrive and has not been altered on the way. It must not be halfway through a game, or a payout, when it takes it. The meters have to survive the change, because the money in them is real and somebody is accountable for it. And an update that half–lands has to leave a machine that refuses to play and says why, never one that plays and is quietly wrong. Doing it safely is most of the work; the download is the easy part.

Three generations of gaming machine cabinet Three schematic cabinets side by side. The first holds a single game, its glass printed for that game and its ROMs programmed for it. The second holds several games behind a menu — Neptune’s Treasure, Monty Python, Ooh Aah Dracula — sharing one platform while each game keeps its own accounts. The third is the same multi-game cabinet with new content arriving down a line overnight, adding a title that was not on the machine at six o’clock, which has to prove itself before it is allowed to run. One game printed for this game The glass, the ROMs and the approval are all one machine Several games printed for the cabinet Neptune’s Treasure Monty Python Ooh Aah Dracula One platform underneath, each game keeping its own books A game that changes printed for the cabinet Neptune’s Treasure Monty Python Ooh Aah Dracula not here at 6pm overnight New content arrives, proves itself, and takes the meters with it
The same corner of the same pub, ten years apart. What changed was not the buttons but what was allowed to be behind them.

The games themselves were a mix of both worlds, which is why the job spanned reels and video at the same time. Neptune’s Treasure was reel–based and built for the German market, which has never done things the way Britain does — different rules on stake, prize and how long a play is allowed to take, and a machine written to them behaves differently in the hand as well as on paper. Monty Python and the Holy Grail and Ooh Aah Dracula were video, where the reels are a picture of a mechanism rather than a mechanism, and the feature can be anything that can be drawn. There were a good many others, most of whose names have gone the way of the cabinets they lived in.

What sits behind the glass on a reel machine and on a video machine Two schematics. On the left, a reel machine seen from the side: three drums printed with symbols, each on a stepper motor, each with an optical sensor watching a slot in the rim so the machine can prove which symbol is actually in the window. On the right, a video machine: one screen, one processor, and the same three symbols drawn rather than turned, with nothing mechanical to read back. Reels the window stepper motors An optic reads a slot in each rim, so the machine can prove what is in the window rather than assume it Video CPU The same three symbols, drawn rather than turned. Nothing mechanical to read back, and the maths carries the whole load
Neptune’s Treasure on the left, Monty Python and Ooh Aah Dracula on the right. The freedom on the right is real, and so is what it costs: a reel you can watch is a reel that argues for itself.

What the job actually is

People assume writing a gaming machine is writing a game. It overlaps, but the constraints are from a different world. The machine is a regulated product. The maths has to be provable to somebody outside the company, and it has to keep being true across millions of plays rather than feeling right. Every state has to survive the power being pulled — and it will be pulled, mid-payout, by a cleaner at half past eleven — so the machine has to come back up knowing exactly what it owed and to whom.

And it runs unattended. A game gets played for a fortnight and put down. A machine sits in the corner of a pub for years, being kicked, having drinks spilled on it and being played by people actively looking for a way to make it pay more than it should. That does concentrate the mind on edge cases.

The habits that come out of it transfer better than you might think: tight code, small memory, defensive about state, and no cleverness for its own sake. Some of it came back round much later when I wrote 5 Reel Spinner for the iPhone — holds, nudges and all — and a good deal of it is still in the way I write the apps on this site.

Before and after

Before Barcrest was Software Creations in Manchester, and the Commodore 64 games on this site came out of that — the C64 was my machine, and the studio’s Nintendo work was other people’s. After Barcrest came OneFile in Manchester, where I still am, and the iPhone and Android work that the apps came out of.

The dates and job titles here are my own record. The company history around them — the ownership changes and what the name is attached to now — is from the public record, and if I have any of it out of order, tell me and I will put it right.

Before Barcrest: my games on the C64

Strike! – 1987
A bowling game published by MAD / Mastertronic. Players compete in a ten-pin bowling tournament, aiming for strikes and spares while mastering the timing and accuracy needed to send the ball down the lane.

Raw Recruit – 1988
A multi-event sports game in which players take control of a new army recruit undergoing military training. Events include obstacle courses, shooting practice and fitness challenges, all designed to test speed and skill.

Scumball – 1988
A quirky multi-screen platform game where the player controls a bouncing ball-like character through a series of dangerous rooms filled with enemies, ladders and traps. The goal is to collect items and survive long enough to reach the next stage.

Sky Shark (US Version) – 1988
A vertically scrolling shoot-'em-up based on the arcade game by Taito. Players pilot a fighter plane through enemy territory, avoiding heavy fire while destroying tanks, ships and aircraft across increasingly difficult levels.

War Cars Construction Kit – 1988
Part action game and part creation tool, this title allows players to design their own arenas and then battle computer-controlled opponents using armed vehicles. It offered a surprising amount of freedom for a Commodore 64 game of the era.

Baby Blues – 1990
A fast-paced crosshair shooter in which the player must defend against waves of cartoon-style enemies. The game combines quick reflexes with colourful graphics and a light-hearted sense of humour.

Gunslinger – 1990
A Wild West themed shooting game where the player takes on the role of a lone gunslinger facing enemies in a series of quick-draw shootouts. Success depends on fast reactions and accurate aim.

Puzznic – 1990
A conversion of the popular arcade puzzle game. Players must slide matching blocks together to make them disappear, solving increasingly complex puzzles using logic and careful planning.

Gauntlet III: The Final Quest – 1991
An action game inspired by the Gauntlet series, featuring dungeon exploration, monsters and treasure. Players guide their hero through maze-like levels, battling enemies and searching for the exit while collecting power-ups along the way. :contentReference[oaicite:7]{index=7}