// Physical Computing Project 3: Blackjack Table
12/7/2004
Final Testing
Powerpoint Presentation of ITP Blackjack
Here's some user feedback on our final tests:
- Confusion over the value of X
- LCD screen was hard to see - needed to be set at an angle
- People pressed HIT and STAY - QProx was not extremely intuitive, but was recognizable
- Overall, users really liked the interface
- Bidding was fairly intuitive
- Multiple pushes tried for bidding over single chip value
- Button Sensitivity - needed a firm press
- New players needed explanation of game, but found the experience easy
Unforunately, the wire mesh that we used in conjunction with the QProx to register moisture would at times trigger itself, causing the player or dealer to hit automatically. Ultimately, the game was very fragile.
UPDATE: We determined that the noisy gameplay was coming from the power source, not the QProx. When the game was powered by a 9V battery, the game would occassionally hiccup and reset. However, when we used an AC adapter and plugged it in, the game played fine.
12/6/2004
We completed the table as best as we could in order to begin user testing and documentation. We visited a number of fabric stores but were unable to find a dark felt, so we stuck with the original fabric. We covered the top portion of the board to better match the bottom.
Originally, we had planned to use acrylic paint to create the letters on the fabric, but later went with white stickers. Fortunately, someone on the floor found black fabric stickers from a nearby fabric store. We went with these instead, as they looked much nicer.
After much discussion, we used painted cards with the words "HIT" and "STAY." We were going to use card combinations, but didn't want to confuse the user. We added the King-Ace combo in the center to illustrate blackjack and recreate the feeling of cards on a card table.
I ordered some poker chips online to better recreate the bidding effect. We sanded down one side of each chip and super glued them to digital buttons.
Here's the final code. Due to time constraints, we were only able to include the push feature. We were never able to correct the display of the 10 card, either.
12/5/2004
Tonight, we tried implementing the bidding portion of the game. Unfortunately, a subroutine's while loop is breaking. The loop is to wait for a bidding button to be pushed before it deals the cards. When I use a 10K Ohm resistor on the button the button doesn't work. When I use no button it automatically triggers. When I use no resistor it works occasionally. Still trying to figure this one out...
12/5/2004
I took some time to solder an old Samsung Yepp MP3 player. We're going to wait until we get the rest of the project working before we begin implementing this. The Yepp has a 64MB hard drive and would be perfect for MP3 recordings that call plays. The Yepp has four buttons - play/pause, forward, back, and stop. Should we get to this point, we would wire both ends of the simple switches to relays. When we want the code to fire off a button, we send some voltage to the relay.
The Yepp works on two AA batteries, so we'll probably have to wire it to the breadboard to share the same power source as the chip.
12/4/2004
The LCDs came in. One double-line LCD (with backlight) appeared to not work. We wired it, but once we turned on the PIC it only flashed black and deteriorated. Wiring was the same as the LCD-76 (diagrammed below). We solded a second LCD and this one worked.
According to the PIC Basic Pro manual, using LCDOUT $FE, $C0, message takes the cursor to the second line of the LCD.
12/3/2004
Since we are still waiting for the LCD we ordered to arrive, we decided to test the bidding portion of the game by outputting the results via serial to the laptop. Once the serial was wired we checked it with the simple "Hello World" code from Tom's site. No problem. Once we combined the code with the game, it suddenly started skipping portions of the game. Suddenly, the game was playing by itself--the player would bust and the dealer would receive no cards. After troubleshooting, we decided to just wait until the LCD came in, as we're not using serial in the final project anyway.
11/28/2004
We ran into some problems passing a variable from PIC#1 > PIC#2 > second LCD, but realized that there were no initialization statements for our second LCD. Then we realized that PicBasic Pro doesn't support a string variable datatype. Only BIT, BYTE, and WORD are supported, all of which are numerically based (the BX-24 has a string type, however that would require us to rewrite all of the code). This helps to explain why we were unable to contain a string of more than 2 characters within a variable. Unfortunately, this also means that the only successful way to transfer a string serially within a variable is to spell out the letters of a string in an array, send the array one piece at a time, and then reassemble the string. Because this is so overly-complicated and due to the tight deadline, we have decided to use only one 40 character LCD. This will allow us time to refine the bidding process and focus on the packaging of the project.
11/23/2004
The ace value has been corrected, and we have set up the display to show player cards rather than one total value. Some of the verbiage during gameplay has been modified as well. Instead of "Player Hits, Dealer Hits" throughout the game, the game starts out with "Dealing to Player, Dealing to Dealer."
Based on the advice from a number of sources, we will try to communicate to a second LCD through Pic to Pic rather than a multiplexer. The PIC18F452 will display to an LCD and communicate to the PIC18F252. This 252 chip will then control the second LCD. Once we have this working, we will add an additional 252 and LCD for the third screen. We also purchased some casino chips to work as buttons. During user testing, someone suggested a button over an analog control, as a button feels more 'dangerous.'
11/22/2004
I spent a portion of the weekend soldering LCD displays. We're using an LCD-76 display (diagram shows wiring as specified in the accompanying datasheet). We used colored wires as illustrated in the diagram. The LCD itself labels the 1,2, and 14 pins. Pins are as follows:
- VSS Ground
- VDD Power
- VO LCD Voltage Control
- RS Register Select
- R/W Read/Write
- E Enable Signal
- D0 to D7 Data Lines
Using a potentiometer, we wired it onto the same line of the breadboard as VO. This allowed us to set the contrast of the screen. Once we were satisfied with the contrast, VO goes into ground.
So far, we haface card functionality working. The display now shows card face values and does the math behind the scenes. This is accomplished with 2 arrays, one for the face value and one for the numeric value. The random value from the stripped wire is used to choose values from the same place in both arrays. An X represents the dealer's down card until the game is over (photo right, just as the player is busting with 22). The only problem We're experiencing is with the number 10. We've tried placing it as a string and a numeric value in our array, but the LCD refuses to display a 2 character number. We've tried checking for the value and rewriting,
We're going to search for a multiplexer to control multiple displays, as we've found it difficult to find documentation on using the graphic LCD display we ordered.
11/17/2004
We have completed testing of the original Blackjack table. Below are some of the results. Besides addressing some of the issues mentioned by students, I noticed that the game chooses a 1 or 11 value from an array. These values are to represent the ace, yet aren't accurate to the actual game. We will therefore be modifying the logic to both display the ace and face cards and determine their values behind the scenes.
GAME PLAY SPEED ISSUE:
Most users seemed to think that the game sequence was to slow, often users would see the text stating that it was dealing to player/dealer or hitting player/dealer and the user would be attempting to perform an action.
DESIRE FOR CLEAR USER FEEDBACK:
Users seemed to want more visual details. People stated that they would prefer to know how many cards they had rather than just having the value amount of the cards. Furthermore, multiple users stated that they would prefer to see a graphic representation of the cards.
QPROX v. DIGITAL BUTTON INTERFACE:
Some users felt that the qprox buttons were just as effective as actual buttons; however, others felt that they should be able to feel something to capture the natural impulsive nature of gambling. Also, all users agreed that consistency issues need to be addressed with the current button functionality.
THE UNFAMILIAR PARTY:
Users that were unfamiliar with game felt that some sort of instructions should be available.
BIDDING:
One users stated that they would prefer to have a range of digital buttons for bidding. Hitting buttons made a user think more of the consequences of their actions.
OVERALL:
Most users agreed that a strong audio and/or visual guide would help to make the user interface more intuitive. Also, users stated that performance issues need to be addressed for consistency.
11/14/2004
Based on Tom Igoe's feedback via the ITP student list-serve, we have decided not to use QProx sliders for the bidding aspect of the board. Apparently, the sliders are very sensitive. Tom also mentioned that he's had them since August and still not been able to get them to work properly.
11/14/2004
I have joined David Yates and Lamar Hines and will spend the remainder of the semester working on a Blackjack table. The details of their original project can be found on Lamar's PComp page. This is the original code for the game.
As a group, we discussed the addition of bidding, more advanced gameplay (push, split, double down) and the possibility of creating a two player version. Lamar's very much interested in trying out a QProx slider for the bidding aspect of the game. One of the challenges to this project will be to better recreate a blackjack table environment.