barcode cards

Barcodes are just numbers, written in a machine-readable form. Once the barcode is read and decoded, it is just a number and you can do with that number whatever you want. So your cards would have a different barcode each, which is read and used to let the program know which card it is, just like a person would by reading a number written on the card; what the software will do once it knows which card you scanned is up to you, I guess.

This page explains the four different methods currently used to read barcodes and retrive the corresponding values:
http://www.taltech.com/TALtech_web/resources/intro_to_bc/bcpwork.htm

And bc Tester and bcWebCam are some nice free applications that might be useful for barcode testing. They will let you use a webcam, digital camera or scanner to read the barcodes if you don't have a barcode scanner handy. I'm sure there are some free or cheap SDKs for codebar recognition, but I'll leave that to the programmers.

HTH

Nando,

You're actually confusing UPC (Universal Product Codes) with barcodes. Barcodes are, as Ariel stated, just a graphic representation of a number. UPCs are numbers purchased from whatever the organization is called that sells them, that retailers can use to database their products. Typically UPCes have a barcode for easier/faster access, but it's not truly necessary.

-Darke

Aside from the other notes of how a barcode actually works, there are numerous examples of various toys and games that effectively use a barcode, just mechanically (as opposed to optically scanned).

From a game standpoint, I present...The Generals:
http://www.boardgamegeek.com/boardgame/2728

(I am lead to believe that the 1970 date should be 1980, but that is besides the point).

Anyway, each piece on the bottom had a molded "barcode" line of, I think, a combination of 8 nubs or lack of nubs. Much like a standard barcode where a black line or white space defines a specific product, this combination of nubs/no nubs defined the piece. Since they were on the bottom, players could not see the nubs.

When the pieces are placed in the "battle slot," the nubs would press down (or in the case of no nubs, not press down) eight little switches. This switch combinations would tell the electronics what kind of piece was being played by each player, and resolve the battle with lights. Ultimately, it was Stratego, except that you never knew exactly what pieces your opponents beat you with, just that they had a a higher value.

Anyway, this little nubs/no nubs trick has been used on many infant toys, I've seen.

As an app developer, I've had quite a few turns with barcodes. They're not too difficult to work with, but unless you want to deal with 3D barcodes (that look like a square instead of a traditional barcode) you're going to be fairly limited to what you actually put into the barcode. Generally you would include some sort of object ID that is intended to be looked up in a database to reveal more details. There is no rule as to how long your barcode can be (the more text data you want to include in your barcode the longer the barcode will physically be). But in order to reduce scanning errors and potential for destruction, you're best keeping the data inside the barcode to a minimum.

For a beginner, you should be looking at the 3of9 barcode format. There are many free fonts that you can download to get this barcode into your Photoshop or word processing apps.

Hardware to scan barcodes can also be had for relatively cheap. I've always used hardware that was read from the serial port (using the COM32 library for Windows to detect activity on the scanner). I'm sure there are cost-effective USB alternatives that you can be using. With a solid library to read from the barcode scanner, it can be made as easy to use as reading a click from the mouse.