Week 1

1. What was planned?
- Build familiarity with Unity by completing a tutorial
- Build familiarity with iPhone SDK by completing a tutorial
- Complete IRB Certification

2. What was done?
- Completed IRB
- Completed Unity tutorial, posted finished game on website

3. Problems encountered?
- Steeper learning curve with Unity than expected - the project took considerably more time than originally planned
- As a result of that, I have not started the iPhone SDK tutorial yet

4. What did you learn this week? (esp. computer science, or anything surprising or interesting)
- I learned the basics of Unity and javaScript, and became somewhat comfortable with the Unity API
- I learned about IRB certification

5. What's planned for next week?
- Complete the iPhone SDK tutorial
- Begin work on the Dance Tool and/or the iPhone app

6. Hours worked:
43



Week 2

1. What was planned?
- Submit final IRB paperwork
- Finish iPhone tutorial
- Begin work on either the Dance Tool or the iPhone app

2. What was done?
- Turned in final copy of IRB paperwork
- Worked on iPhone tutorial - created the cube, worked on integrating Views into the project.
- Brainstormed with the team for conference game ideas, we came up with a cool and achievable concept

3. Problems encountered?
- Forgot to turn on the depth buffer for rendering the cube, and then when I did turn it on, I forgot to clear it, so I was looking for non-existant near clipping plane issues.
- VIEWS. Not all Views are created equal, or play nicely together. EAGLViews, which must be used in conjunction with OpenGL code, do not seem to behave the same as UIViews. They inherit from UIViews, but do not interact with the view controller in the same way. I tried many different ways of integrating the ViewController based project with the EAGLView project, and kept hitting walls. However, Evie found a solution that uses multiple .xib files! It hadn't occurred to me to use more than one, but as I'm working through it, it makes sense. Thanks Evie!

4. What did you learn this week? (esp. computer science, or anything surprising or interesting)
- Some OpenGL commands (they have all the man pages on their site, which is really convenient)
- Became somewhat familiarized with Objective C
- Learned a lot about View Controllers and different kinds of Views

5. What's planned for next week?
- Finish the iPhone tutorial
- Build a prototype of the conference game (this week and next week)
- Begin work on the Dance Tool?

6. Hours worked:
~50



Week 3

1. What was planned?
- Finish the iPhone tutorial
- Build a prototype of the conference game (this week and next week)
- Begin work on the Dance Tool?

2. What was done?
- Worked on iPhone tutorial - added 3D transitioning views, multi-touch zooming, and a single tap changes the color of the cube. Also added a light source.
- Developed and pitched an iPhone/iPod Touch game idea for the conference. The working title is Co-op Table Tilt Game. The pitch and screen mockups will be posted soon to the Codendi Game Ideas Wiki.

3. Problems encountered?
- Ran into trouble with registering multiple touches on the iPhone - wasn't sure if it was an error with the simulator or the math. The simulator seems to register the first touch as the origin and then calculates the second touch as a distance ratio based on the first touch's position. This led to wrapping issues near the edges of the window, and unexpected behavior when not zooming on a diagonal from the origin. The math for determining whether to zoom in or out simply takes the two touch points and runs them through the distance formula, and depending on whether the distance between the two points is growing or shrinking, the image is scaled up or down, respectively. However, when we deployed the app to the iPhone, the problem was actually exacerbated, so it probably isn't a problem with the simulator. The math seems sound, so it must have something to do with the registration of the touch positions. Perhaps using the distance formula is the wrong approach, given the way touches are registered?

- I originally planned to have each face of the cube be a different color, and when the user tapped a face, it would change that face's color. Unfortunately, although I could get the screen coordinates of the tap, it is not possible to select a particular pixel and get its color on the iPhone. Unless I cast a ray and intersected it with the face, I wouldn't be able to determine the location of the tap. Since ray casting seemed like overkill, I opted to just make the cube one color, and tap on the cube to change the entire cube's color.

- Lighting was very problematic, mostly because the iPhone does not allow most of the typical OpenGL methods for drawing. I enabled GL_LIGHTING, a light, and set the shader model to GL_SMOOTH (as opposed to FLAT). I calculated all of the surface normals and set the material properties, but the cube was still in grayscale. After a lot of hunting around, I found that I had not enabled GL_COLOR_MATERIAL! After that was set, lighting worked as expected.

4. What did you learn this week? (esp. computer science, or anything surprising or interesting)
- Learned about the touch interface for the iPhone
- Learned a lot about lighting in OpenGL, and some of the limitations of the iPhone's implementation of OpenGL
- Increased familiarity with Objective C

5. What's planned for next week?
- Learn about the capabilities of the iPhone accelerometer and build a limited prototype of the table tilt game
- Begin work on the Dance Tool

6. Hours worked:
~46



Week 4

1. What was planned?
- Learn about the capabilities of the iPhone accelerometer and build a limited prototype of the table tilt game (by this Friday)

2. What was done?
- Worked on table tilt prototype - got the app working in landscape mode, found an alternate way to draw using the CoreGraphics framework, and got simple ball physics working on one iPhone.

3. Problems encountered?
- Making a multiple-view application in landscape mode is actually not possible. There is a key that can be set in the Info.plist for the project that is supposed to force the orientation to whatever you choose, but it does not seem to have an affect unless each view controller also gets instructions. Even then, only the primary view will change, and not the secondary view. After searching around for a while, I discovered that landscape mode for multiple views and view controllers is not actually possible. Applications that appear to be this way are actually just faked - one or more of the screens is just an image that makes the user think that the screen has rotated. This is different than in-app rotation by the way - it is very possible to take a portrait app and rotate to landscape when the user turns the iPhone. However, this was not what I needed. I ended up creating a landscape splashscreen view and a portrait game view, but the user will assume that it is still in landscape, and so they will still hold it that way.

- Another problem that I had was with drawing, although the fact that the device was not drawing was actually indicative of a larger problem. Basically, the flow of control for the program had entirely disappeared, and the timer that I had created within the main thread of execution was never being called. I discovered that when using .nib files (so basically any time you are using multiple views), all of the objects are archived inside the .nib, and so the initWithFrame method is never called. This method contained all of my timer initialization code, and since it never ran, nothing was happening in the program. The fix for this is to use the awakeFromNib or initWithCoder methods instead.

- DEPLOYMENT. Deploying to an actual device was a nightmare - Apple has a lot of different certificates that you need as a developer before you can deploy your app, and even when you have created all of them, there are lots of little things that can go wrong along the way. Thanks to Evie and Thomas for helping me get that working!

- The accelerometer is also a problem right now. I can access the data from the three axis correctly, but am running into trouble with the math that ties the readings to the physical movement of the ball.

4. What did you learn this week? (esp. computer science, or anything surprising or interesting)
- Learned a lot more about views and .nib files
- Learned an alternative way to draw on the iPhone
- Learned some about the accelerometer on the iPhone
- Learned more about Objective C

5. What's planned for next week?
- Finish the prototype by this Friday
- Go to the AIED conference!

6. Hours worked.
40



Week 5

1. What was planned?
- Go to AIED conference in the UK

2. What was done?
- Went to AIED conference, attended as many workshops and talks as possible.
- Also worked as a student volunteer - loaded conference bags, signed people up for the conference, directed people to the different conference rooms, and ran mics for the keynote QA sessions.

3. Problems encountered?
- None, but there were some near misses at the Chicago O'Hare International Airport. They don't have enough signs.

4. What did you learn this week?
- I learned a lot about the the cutting edge research questions in the area of AI and Education and some of the potential answers to those questions, such as the study of metacognition, empathetic agents, affect detection, and scaffolding.

5. What's planned for next week?
- Return the Dance Tool to a stable state
- Help Evie run a user study on the Dance Tool
- Work on integrating Evie's and my work on Table Tilt

6. Hours worked.
40ish.



Week 6

1. What was planned?
- Return the Dance Tool to a stable state
- Help Evie run a user study on the Dance Tool
- Work on integrating Evie's and my work on Table Tilt

2. What was done?
- Helped eliminate some critical bugs - the Dance Tool was stable in time for the study.
- Helped Evie run the user study.
- Worked on the state machine for Table Tilt.

3. Problems encountered?
- Did not really have time to do much integration on Evie's and my work on Table Tilt, due to the crunch on Dance Tool.

4. What did you learn this week?
- The iPhone does not have a state machine system that I can build on, so I will have to write one from scratch.

5. What's planned for next week?
- Finish state machine and all game mechanics for Table Tilt (hole detection, scoring, timer)
- Integrate my code with Evie's

6. Hours worked.
40



Week 7

1. What was planned?
- Finish state machine and all game mechanics for Table Tilt (hole detection, scoring, timer)
- Integrate my code with Evie's

2. What was done?
- Finished most of the state machine - level loading is still waiting on the packet information from the server.
- Finished hole detection, scoring, and timer.
- Reworked the physics system, did some code cleanup and added more comments.
- Added some of Christie's art assets.
- Wrote rough draft of final presentation.
- Wrote rough draft of user study.

3. Problems encountered?
- The networking is still not quite to the point of integrating with the level loading and ball transfer, but it is very close.
- Some of the art assets need to be tweaked.

4. What did you learn this week?
- Learned about some different containers and array structures in Objective C.

5. What's planned for next week?
- Finish networking, polish game.
- Finish user study and conduct a pilot study.
- Finish research poster and write research paper.

6. Hours worked.
45



Week 8

1. What was planned?
- Finish networking, polish game.
- Finish user study and conduct a pilot study.
- Finish research poster and write research paper.
- Give presentation

2. What was done?
- Made poster
- Finished and gave presentation
- Finished user study
- Networking correctly sends level information, devices correctly receive it (reworked array passing)
- Holes display correctly - the positions are correctly randomly generated
- Reworked some of the enumerations to make things easier

3. Problems encountered?
- Art was never finished for the game. :( We had to make some rough substitutes instead.
- Mutable arrays are just pointers, so passing them across devices is a minor disaster, because the memory addresses don't line up. To fix this, we had to encode each object in the array separately, instead of the whole array.

4. What did you learn this week?
- Learned more about the way that mutable arrays actually work.

5. What's planned for next week?
- Finish the game
- Write paper
- Make real poster for STARS

6. Hours worked.
~70



Week 9

1. What was planned?
- Finish the game
- Write paper
- Make real poster for STARS

2. What was done?
- Made real poster for STARS
- Fixed vector network passing
- Multi-threaded the networking so that the accelerometer could run too

3. Problems encountered?
- The networking code was actually preventing the accelerometer updates from running, because they were both in the same thread. Moving the networking stuff to a separate thread fixed this issue. Unfortunately, the accelerometer is currently not giving us real values.

4. What did you learn this week?
- Learned how to do multi-threading for the iPhone.

5. What's planned for next week?
- Fix accelerometer data, finish code for passing the ball between screens.
- Test game
- Write paper

6. Hours worked.
~47



Week 10

1. What was planned?
- Fix accelerometer data, finish code for passing the ball between screens.
- Test game
- Write paper

2. What was done?
- Fixed accelerometer
- Finished ball-passing code
- Everything is finished for the game! At least for our first release... yay!
- Finished final paper

3. Problems encountered?
- Sometimes the ball can be lost when it is moving between screens if the vector is reversed while it is traveling. It doesn't happen very often, but when it does, the packet is lost for good, because none of the devices think that it is in their coordinates.
- Also, occasionally scenarios can be generated that are impossible. To counteract this, Evie added a swipe gesture to reset to a new scenario. Eventually, we want to change the level generation to better prevent extremely difficult or impossible scenarios.

4. What did you learn this week?
- This summer has been a very positive experience for me, and I learned a great deal about research methods, new programming languages, and design. I also had the opportunity to network with others in the research community both at UNCC and at the two conferences I attended. Because of this research experience, I am now seriously considering a Ph.D. Thanks to everyone at the Game2Learn lab for a great summer!!

6. Hours worked.
~48

Image courtesy of Google images (2009)