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............