Thesis Update #16

Enough time has passed that I feel like I can look at this project again haha. I finally made a video that describes how the game works and the technology behind it. Check it out!

To see photos from the exhibition and some screenshots from the game itself, you can head over to the KORE project page.

Learnings:

To answer the thesis question of can you build immersion in VR asymmetrical games, our answer is yes. As long as we got people talking to each other, they were engaged in the game (and things often got loud!). We noticed that kids who played the game (not young kids, but like 8-12 range) generally solved more challenges than adults or at least solved one challenge faster.

We can only hypothesize as to why. Do kids just feel less self-conscious about shouting out information? Adults tended to be quiet and tended to overthink things, however there was a notable exception. When we got people who knew each other to play together, they performed the best. I suppose the degree of comfort they share with one another allowed them to effectively communicate. They were able to understand what the others players were referring to faster than groups which consisted of strangers. 

We noticed that our balance between the three players wasn't quite perfect. The Manual Master and Laboratory Leader were constantly talking and engaged with each other, exchanging information back and forth. The Sensor Strategist was kind of the oddball out; they had quick flurries of action (like when lights were needed or the oxygen was almost empty), but they talked a lot less and engaged with the other players a lot less. We think this is because they did not have to relay any information, only receive. While their role was constant button pushing, it didn't really achieve the sort of engagement we hoped for. However, the players who were kids usually enjoyed the role anyway because it was physical. 

We would definitely simplify the game the next time around and we would redesign some elements to give the sensor strategist information to give back to the Laboratory Leader. However, we've realized that this game is more like a board game. It's not really something you just pick up and play, but something you learn and get better at over the course of an hour. Groups that played longer, and groups that switched roles, generally got faster at the game. If we had time to give it a good polish and redesign how we give out panel information, I think it would be a fun party game or icebreaker game. 

(all that really matters is that Ken Perlin liked it okay.)

Thesis Update#15 - Science Gallery Exhibition

And finally, here we are full circle. My first post in this blog was about the previous IDM class's projects. Now here I am showcasing my own. It's essentially the end of my degree, the end of my time here in Ireland, and finally the end of this bloody project. I'm not even sure what happened this weekend.

We were open to the public on Saturday and Sunday at the Science Gallery, a supremely nice venue that is very close to my heart after spending so much time in there during the hackathon. Then on Monday morning we were graded by the professors and gave our final presentation. On Tuesday, we had one last showcase, this time a smaller one just for all the graduating computer science students (we brought our projects, the rest of the students brought their super smart sounding poster boards...so basically ours were cooler). 

I did a lot of programming on the fly, including providing more feedback on the buttons. I was able to make them change color when pressed, and back again on Clear Input and on the start of a new challenge. It didn't work the first time and it was embarrassing, but I got it to work in the end. I admit I wasn't in top form - stressed and ill (yay mono!) and a little annoyed at everyone. 

But we did it. We finished. And I met Ken Perlin. My idol who worked on Tron and created that sexy algorithm. He was our external examiner. Naturally, our project kept breaking when he tried to use it (3 bluetooth connections didn't always like to connect). Embarrassing, but at the end it was all worth it. We went out to a pub and I sat right next to him and talked to him for like three or more hours. He said he thought our project was the most interesting because we broke the most rules; we didn't do anything safe, nothing guaranteed to work, nothing standard like a website. 

So that felt real good. And then we shared a pint and I was satisfied with life. 

I'd completely redo the way I handled the project if I had a choice, but damn did I learn a lot! And really, that makes me a smarter leader and developer for the next project. I made a lot of mistakes, but I learned a ton. That certified unity developer certificate is well earned. I'll probably make a separate post for pictures and videos, but most of it on the KORE main project page on my website. I'm not sure I have it in me to look at this project again any time soon, even if it's just to post pictures and videos haha. Talk about burnout! But I accomplished what I wanted. I wanted to do Unity and VR, and for three glorious months my only job was to learn that (and more! hello unexpected bluetooth and arduino). 

Thesis Update #10

To quote Karl: "However, at the moment we’re having a bit of a noodle-scratcher getting the Bluetooth to connect when we push the game to a Android. Everything works in the desktop version of Unity, but we’ve spent all of yesterday trying to get it to work in mobile to no avail. So frustrating!"

Well, we figured it out. We needed to get rid of device.setEndByte(10). ONE LINE. SEVEN HOURS OF MY LIFE GONE.

When you use .read() to read bytes from a bluetooth connection, and you don't want packetization, remember to get rid of the setEndByte. Obviously, that's only required when you set up packetization code in your arduino script. If you want all of the precious bytes to come as they are, and don't do any packetization in your arduino script, be sure to delete the setEndByte piece of code, otherwise the C# script will not receive the message from the arduino through the blue tooth.

Karl was correct. There were tears. So many. But we got it working today. And Alberto was a gem and helped us finagle the delay in the ardunio script to ensure that we got a steady, repeated message when we desired it.

Therefore, we can now turn on lights with a button press through our convoluted arduino+blue tooth+unity+android system. Additionally, we also figured out how to call lights by tag. We have several lights associated with each sin. Through tags and arrays, a button press will be able to turn on the array of lights associated with each sin. Of course we still need to get the NFC tags working for the lights to function as desired(Karl explained their purpose in the last post).

So next week Karl and I will implement the NFC tags and also get started on networking to include the tablet, which will hopefully display information/feedback for player 2 and 3.

Thesis Update #9

Over the past two days Karl and I have been working on the bluetooth connection. We are using the HC-06 bluetooth module to connect the arduino to an android phone. We managed to pair the bluetooth to the phone and also to the PC.

Our next step was sending information from the ardunio to Unity via the bluetooth connection. We hooked up a button to the ardunio and had a bit of challenge with the delay and eventually found a solution by using millis(). There is an important difference between delay and millis. Millis can tell you how much time has passed, while delay waits for the time to pass. Using millis means the entire code is not locked up, waiting for something to happen. Millis provided us with an ideal way to ensure that information from the button press is sent to the Unity program only when we are ready for that to happen.

Photo: Set up of the button, ardunio, and bluetooth module.