Coin-op game dev

I don't know alot about, one thing I do know is that the StreetFighter IV arcade machines were using a PC set-up with windows XP, it was when it was released anyway.

Designing the hardware will be quite a task and as you said alot of the newer machines are using close to if not PC hardware, so you could go from there.
And for the coin op you will probably just buy the hardware with an SDK.

It depends really on how involved you want to get with the hardware, and what kind of performance you want to get out of it.

If you want a lot of punch without much time spent developing hardware, then you probably want a PC-based solution. They sell 19-inch and 25-inch arcade-style (open frame) monitors that take a VGA signal, and operate up to 800x600 resolution. These are often used in MAME emulation stand-ups, but are also used in actual arcade hardware. Its also not atypical these days that newer arcade games are running on High-Def LCD or plasma screens (for example BlazBlue or some of the other newer fighters and racing titles) which are probably driven off of DVI or HDMI connections.

For a PC-based setup, the smallest, relatively cheap solution would probably be an NVidea ION-based Mini-ITX motherboard, like the ones from Zotac, or a similar AMD-based setup with a 780G or 785G chipset (preferably one with some side-port memory). The ION motherboards typically have single or dual-core Atom processors, which is probably enough for any game you'd want to drive off of that GPU, although you can get options with a more powerful, socketted processor if you like. Any low-power Athlon would work just fine on the AMD side. Pair it with an automotive PC case (the kind that's mounted in the trunk) so it can be mounted to the side panel of your cabinet, and a DC-DC power supply so it can be driven of the 12v lines of an external, arcade-style PSU, and add a USB-based JAMMA interface to tie in your controls and your done.

For a real arcade deployment you then have to worry about reliability of components (smokey bars and spoiled kids beating on the machine is not a good environment for most PC components) -- but generally speaking passively cooled CPUs and solid-state drives ought to solve the environmental hazards. If you have commercial anticipation, then you've got to think about protecting your game from being knocked-off, so you have to worry about hardware dongles, anti-tampering measures, and other things to help prevent people from cloning your disk drive, sticking it into compatible off-the-shelf hardware, and selling your game themselves.

Old school screens (the type you might find in a mid-90s arcade machine) run at the same clock rate and resolution as a television -- the difference being that that they take the R,G,B, Hsync and Vsync signals directly and indipendantly, rather than RF or composite video signals. Some old, low-res PC monitors work the same way (like the Commodore 1080 and 1084 monitors, which also take composite, s-video and an early digital video input -- I have one due to the variety of inputs it accepts).

If you're looking to drive something like that, you could do a lot with a fast Microcontroller and an r2r DAC driving the video signals. This is how Andre's Hydra (and presumably the Chameleons) work in VGA mode. You can also look at the Uzebox -- take away the RGB-to-NTSC encoder (which is probably the single most expensive component anyhow) and you could drive that kind of display off of it. They've been able to drive SNES-like games with nothing more than a ~28Mhz, 8bit microcontroller with 4K of RAM.

I've been toying around with the idea of building a similar system myself, but based around an 80Mhz, 32bit microcontroller (not ARM-based) with 128K of RAM. The only real problem with generating the video signal on the CPU is that it ties up the processor roughly 94% of the time. That still leaves plenty of cycles to do stuff (even though it doesn't sound like it) but its less than optimal. Ideally you'd like to hand video off to a completely separate sub-system, but then you've got to deal with multi-processor systems.

If you're not experienced at all with hardware or embedded systems development, then you probably don't want to go this latter route, but its not actually as unreasonable a project as one might expect.

As far as I know, there aren't any companies which distribute development kits for their arcade hardware, its all pretty much in-house stuff only, and there's little if any homebrew information for existing arcade platforms, although the information could be gotten out of analyzing emulators and such.

Probably the easiest and quickest way to get results is with a PC solution as Ravyne suggested. We have been evaluating the mini-itx boards from zotac and they are pretty good. we have the ion/atom based board and also a socketed intel core2 duo board with nvidia 9300 gpu.

If you wanted to get a little more hardcore then you could try writing a game for existing arcade hardware. There have been a number of people who have done this. The most common project has been to create multi-game roms but pac-man has already been ported to run on world-cup-90 boards and I've heard talk of people working on extra levels for atari star wars. The hardware is fairly well documented in the mame source code and some manuals, particularly atari, document the memory map and provide schematics. You can even use mame to develop the software on.

Another solution, also slightly hardcore, would be to use something like an Altera FPGA development board. The company I work for manufactures electronic display systems and my project for the last couple of years has been an FPGA display card. We use the NIOS 2 soft CPU with a display controller that drives a standard scart tv and thats all embedded within the FPGA (except for a couple of DACs for the analogue video output).

There is also the option of writing some homebrew games for the XBOX1 but that would involve modding the xbox and I wouldn't want to be seen condoning that on a public forum.

Well, I was thinking of going commercial with my arcade machines (if I end up making anything good). I haven't estimated production, shipping and marketing costs yet, but this is mainly an idea set aside for the future. So I'm basically just getting this information straight before just diving in.

Last night as I was sleeping, I was thinking of a more "DOS" (or should I say "Ring 0") style based solution with some older PC hardware to start off with. I don't really want to have a fully PC compatible solution because adding protection for that would sound too difficult. Instead I was thinking of getting some older hardware running a Pentium processor (around the P6 era), use some PC compatible hardware that I know is well documented or already knowledgeable about, store my game on a decent sized HDD and have the game write to the hardware directly for maximum efficiency. This way I have direct access to privelaged hardware registers and CPU instructions.

As for security, I'm not really sure how to implement that. I was thinking of maybe gathering hardware information (such as vendor IDs from each piece of hardware) and using it to form some type of "GUID" similar to a Windows/DirectX COM interface GUID. If the GUID formed by the vendor IDs of the specific hardware don't match, do nothing. If they do match, start the game. That or I should just build a small security daughter board containing a special ROM with various keys that the game must recognize and must be connected in order to play it. Not sure how secure that would be (sounds easy to hack), but it's better than nothing. Or how about a CRC check?

One more question on hardware. What about coin insertions? How does one design the coin system? That's the biggest thing I've been thinking about. Do I have to buy that separately? If I design it myself, how can I tell if an actual quarter has been dropped in?

So I was planning on writing a nice arcade style game similar to BlackHawk Striker for the PC as a first. Nothing too terribly complex. Add some nice high polygon meshes and I'm quite sure that having 64MB of VRam and maybe 128MB of system memory would be more than enough.

Quote:

Original post by acadestuff There is also the option of writing some homebrew games for the XBOX1 but that would involve modding the xbox and I wouldn't want to be seen condoning that on a public forum.

I do own an old debug Xbox that I've experimented with and have been using to practice writing a cross platform engine in my spare time. That helped me learn alot.

EDIT: One more thing. Will I need to apply for a patent on any hardware I design for my machines? I'm quite sure if I have to design some of my own daughter boards, I'll need to get a patent to avoid having my IP stolen/infringed. Also, which ones should I apply for? Thanks.

[Edited by - blueshogun96 on February 24, 2010 3:07:36 PM]

The biggest problem you're going to have with that is that finding a standard hardware base (one that's still in production) is going to be difficult if you ever do get to the commercial phase, and then you're going to have to port to a whole new platform (since you wrote direct to the hardware) to fill orders.

Your only realistic option here would be to get a board through one of the industrial board vendors -- what makes them industrial is that, typically, their motherboards have a guaranteed production life of 5-10 years and support beyond that, but they do cost a premium -- anywhere from 2-4 times equivilent "consumer" hardware.

On the plus side, they usually are well documented, and have plenty of legacy ports (like parallel and serial ports, which are typically easier to interface with)

The lowest-end boards you'll probably find in production today with a reasonable lifetime remaining will probably be a GEODE-based (I think the NXs are the old athlon core) board at around 500Mhz, with maybe 128 MBs onboard. OEM pricing is probably $300 or so, but you can sometimes snag one off ebay for a reasonable ammount.

I don't know if you'd necessarily want to go all the way back to DOS -- Dealling with memory segments and memory extenders are reason enough alone to avoid any 16-bit OS. It'd probably be best to go with a small, customized linux -- I recall seeing one which had the minimal ammount of stuff needed to run OpenGL apps, and it fit on a single floppy disk -- didn't even have a desktop environment. You get the advantage of common APIs and no need to write driver-level code, while also keeping OS overhead to a minimum.

I still say that its probably better to go with a more modern platform -- even if you went with a pure-intel ITX solution like the D510 board (about 80 bucks with CPU and graphics onboard) -- their GPUs aren't great, but you ought to be able to get reasonable results by catering to and optimizing for that specific GPU (IGP 3150 in the newest boards), and their specs are open -- the linux drivers are open-source.

Another option would be something like the beagle-board -- you've got everything you need for a prototype right there, for $150 bucks, and a reference design if you ever commercialize. You get a 600Mhz ARM processor (similar to the one in the Iphone 3Gs) with SIMD, a 420Mhz DSP for audio/video decode or other creative uses, 3D graphics comparable to the Dreamcast, 256MB RAM + 256MB onboard flash, DVI/HDMI, Audio, USB, Ethernet, SD/MMC card, and a few other interfaces. I'm pretty sure there's enough GPIO to interface the controls and some kind of security dongle as well.

Quote:

Original post by Ravyne I don't know if you'd necessarily want to go all the way back to DOS -- Dealling with memory segments and memory extenders are reason enough alone to avoid any 16-bit OS. It'd probably be best to go with a small, customized linux -- I recall seeing one which had the minimal ammount of stuff needed to run OpenGL apps, and it fit on a single floppy disk -- didn't even have a desktop environment. You get the advantage of common APIs and no need to write driver-level code, while also keeping OS overhead to a minimum.

You're thinking of myOS / gameBoxLinux I bet :) Honestly the guys site is a disastrous mess but I agree with your assessment that something like that is a much saner route to go down.

Attempting to bring up hardware and OS is asking for trouble so it makes sense to minimise your pain. You're not out to make the hardware specifically, it's simply a means to an end, that end being that you want your own platform which you can install with games into Arcade venues.

To do that successfully I think you'll want to lower any barriers to entry as far as possible because you'll be competing against larger companies who have already taken this route to slash costs and increase their margins using exactly this approach.

Andy


EDIT: also there are things like this guide which might help. It's probably quicker and easier to build a tiny Linux distro with OpenGL and leverage existing tech to start with even if you later build custom hardware and write custom software. It makes the early steps slightly easier!

[Edited by - NineYearCycle on February 24, 2010 4:32:57 PM]

I used to work for an internet kiosk company some years ago. Obviously we went with the pc setup for the internals, with a custom shell on windows. I can't give you much help on that front.

On the coin-op side we had a custom board with serial communication, because of the need to to have 2 way communication (board telling the computer when money was inserted, or the computer telling the board that it wanted to print X amount of pages so it would add that cost to the board), the board basically controlled everything in that regard.

A few years after that, some friends and I made a cheap kiosk for a local bar in town, we looked through some coin-op solutions and eventually settled on a cheap box that basically acted as a passthrough for the keyboard and mouse and tracked time by the amount of coinage, when the time ran out, it just severed the connection to the keyboard and mouse, making the sytem unusable until more coin was inserted, this was the lowest end solution we found, but was sufficient for its purpose.

Just wanted to drop some personal anecdotes about solutions i've actually used. There's a range of solutions for coin-op, I'm sure you can find something in between the two i've described that will probably fit your needs and come with a shiny sdk (as mentioned earlier).

I had aboslutely nothing to do with the hardware end of things at the kiosk company, other than communicating with the serial port for the control board, so I wouldn't be able to answer any specifics about it.

There are several types of coin acceptors readily available for use in arcade machines.
The earlier machines used mechanical mechs such as the S1 (used a lot in tabletop cabinets) and S10 which has interchangeable coin validators. Most of my arcade machines have these mechs. They have a simple switch that the coin activates.

The older style electronic coin mechs, such as Mars and Sentinel etc, have a number of outputs for the different coin vales. These mechs are usually used with a credit board which takes all of the different coin value switches and convert them to a single switch output. The credit board allows price of play to be set and also bonus credits eg. 3 coins for one credit and 5 coins for 2 credits.

The newer style coin mechs I don't have much experience with. We have just got some to evaluate at work and they seem to use the S10 form factor and use a protocol called CCTalk. I think that the note readers use the same protocol. The board that came with the mech has a USB interface. This would probably be the preferred mech to use as most service engineers will be familiar with them and will carry spares.

I'm currently creating an arcade related website which will contain technical information about arcade hardware but it's a spare time project and I don't know when it will be ready. If you need any technical information about coin mechs, credit boards or anything else then feel free to ask.

Wow, this thread just keeps getting more and more informative! I think I'm much more equipped to approach this now.

For the commercial projects since I really don't have the budget to get top-of-the-line hardware, I'll take the suggestion of sticking to cheap (but decent) PC hardware and work on a customized version of Linux/Unix to serve as a mini OS to execute the game and load game files from the HDD while still having gcc standard functions. I don't mind writing to the hardware directly, but having an OpenGL implementation would speed up the development process. The only problem is that I know next to nothing about Linux. Yup, I'm a spoiled rotten Windows user. Oh well, I do have some copies of RedHat and Suse Linux laying around.

For fun, I do want to experiment with customized hardware (3Dfx again) and see what I can come up (which will give me a bit more experience).

After looking through all the suggestions and information in this thread, it gives me a good idea of what to expect in this biz. Another thing I forgot to ask, how much should I sell each machine for? I've seen some go for about $4,000 USD, but I'm not sure if I should charge that much. I was thinking maybe $900 USD max, but I do need to cover the expenses of the hardware (not just the PCBs, but the monitor, speakers, wood to build the cabinet if I decide to do that myself, etc.).

Anything else on security? Thanks.

Realistically, you're going to need to charge significantly more than $900. If you go with a Zotac ITX ION board (which is probably the cheapest option with decent graphics) your computer hardware alone (mobo, ram, PSU, board, small SSD, case and some kind of security dongle) is probably going to run around $350 give or take. Those large, arcade-style VGA monitors will run you another $350-$600 (19" vs 25") or probably $600-$900 for a decent 32" LCD. Then there's the cabinet, which is probably $100+ for building materials, probably another $100+ for a decent set of controls, and still another $100+ for the coin mechanism -- finally, there's labor and a job like this is easily a good days work for one person doing them one at a time.

Then you have to think that arcade machines are a low-volume business to begin with, and that the unit is used in a commercial venture to make the operator money, so you need to price the software accordingly.

Now you have to consider that Arcades are dying out left and right, so selling an arcade machine is not exactly moving into an expanding market. If you intend to go at it seriously, you're really going to have an uphill battle on your hands.


About the security dongles, your best bet is probably a USB-based security key -- it basically looks like a thumb drive (they even typically have some protected flash memory on them) but you incorporate their API into your program to challenge the security key for the next authorization periodically throughout your program, not typically during the action -- maybe every time a resource is loaded, every time a coin is inserted, or between rounds. If its not too onerous you could probably do it once per frame.

Its also a good idea to put something critical in the protected flash... maybe the actual executable code itself (in which case you would create a launcher application that could access the flash), decryption keys for the art assets, or any number of creative things.

Its still not perfect, but you have to put something critical in the flash because plain challenge-authenticate security is relatively easy to cut out for an experienced software cracker.

One more thing you might be able to do, if you can read out the BIOS data at runtime is to replace the BIOS boot image with your own graphic, and then verify it before the program will load/run -- Nintendo employed this trick on the original gameboy (remember when you would turn it on without a game, and you'd get a black box instead of the nintendo logo? Its because it was read out of the cartridge, rather than being on the system itself.) In their case, they employed this trick to make the case clear that there was both copyright/trademark infringment of nintendo itself, even for third-party games, as well as an attempt to counterfeit (because the knock-off cartridges wouldn't work without including *exactly* that image.) In your case, it would make the simple act of providing hardware modified to be compatible an infringement of your copyright and trademark, and making the case for counterfeiting, in much the same way.


I was friends with some of the guys behind Stepmania, the DDR emulator, at the time when they were working with ROXOR games to create what would eventually become In The Groove (which was realeased in a couple arcade versions, as well as on the PS2) -- I always pressed for hardware details and tried to sneak peeks when they were updating the prototype machine at our arcade (the developer would literally bring his laptop in, open the cabinet, and jack in to the box, then we'd get new songs or features to play with) but they were always very vauge, probably contractually obligated to be so.

There was some casual discussion about there being a kill-mechanism that would wipe some or all of the important data if the case was tampered with, which may well have been true, though no one would confirm nor deny.

Why would someone want to go down this road in 2010? The arcade business died a little less than 15 years ago, and there are so many better alternatives?

The App store
XNA Indy Games
Steam
Your own web page
etc...