Chapter 3: Tacos!

My poker game was more or less done by now, so I had to start thinking about setting things up for an actual experiment! The experiment needs to be run in-lab, as opposed to online, because the participants will need to use their webcams correctly; random online people might point their webcam at the wall or at other undesirable places. To motivate people to come, we would need to pay them, so the ICT will need to grant us some funds to do so. To be allowed to run experiments on human subjects, I needed to submit a summary of my experiment for a thorough review to a certain organization, and finally, I would need to extensively test my program with enough people, which would serve as a general test for the experiment, but also as a stress test for the server, since it will be sending and receiving a lot of camera images.

Luckily, there is a bunch of very helpful people at ICT who were willing to guide me in all these areas. The Facilities department was able to get a classroom with 12 computers for me, called the TACL-lab. I have no idea what the abbreviation stands for exactly, but for easier reference, people call it the 'taco'-lab. Facilities was also able to provide a bunch of webcams and give me access to the taco-lab, so that was covered in a few days.

Taco-lab in action

Applying for money to pay study participants is not a big deal either, although it can take up to four weeks to come through. Writing a summary for review was a lot of work, but most of this work was done by a more experienced ICT member, I only needed to supply the basic information, so I am very grateful to her! Finally, with access to the taco-lab, I could grab some other interns and start testing my poker game!

Even though we initially only tested with 6 out of 12 available computers, we managed to crash the server after a couple of minutes of playing. The Tomcat function that I wrote to send video frames to the other player was synchronized, but only for each session. Synchronization means that only a single 'thing' is able to use this function at any time, any other use of this function by 'thing' will need to wait until the original user is done with it, this makes sure that only one 'thing' uses the WebSocket channel. However, the 'thing' in my case was a session, which essentially means a single computer. In a scenario where only 2 people are playing each other, I wouldn't have noticed this, because the images are sent very quickly. During the stress test, 6 sessions are using this method simultaneously, so at some point two different sessions would access this function at exactly the same time, (virtually) exploding their connections.

Some people had some significant feedback about the workings of the game as well, such as the fact that they didn't really have time to look at their opponent's facial expressions, on which they are partly supposed to make their betting decisions, because of the strict timer that only gives you 7 seconds to place your bet. They were also not quite sure how the game worked before they played a couple of rounds, so they suggested making a tutorial system, and one of the participants never played any kind of poker so she didn't understand the basic explanation that I had given before starting the game. All around, the presentation of information was lacking, so I set out to fix just that...