Pre-submission goals, update #3: So, what happens when I fly off the grid?

There is one significant issue I have found (via user testing) that occurs in my Flash version of this game that I do not recall ever occurring when I played this game on paper with my dad.  This would be the possibility of players going so fast that not only do they go out of the track boundaries, but they end up in the position in which all options for their next move are off the playing grid entirely.  I wonder if my discovery of this is a result of my throwing my friends into playing my game without their really having a clue what they had to do, and thus having pretty much no clue (initially) of how to strategize the management of velocity.  But either way, I thought that it would be fairly bad in terms of user experience to force everyone to restart the game if a player went off the grid, so I decided to handle that case.

I consulted with my dad, and he helped me come up with a reasonable solution.  I decided that if a player comes to their turn and all their options are off the grid, that move will be taken for the player as follows:

1. They will move to the "middle" option (i.e. the gridpoint that would maintain both their x- and y-velocities), wherever it may be, off the grid.
2. Then, they will "slide" back onto the edge of the grid.  In other words, if they are off past the top or bottom edge, their y-coordinate will be adjusted, and if they are off past the left or right edge, their x-coordinate will be adjusted.
3. As a "punishment" for going off the grid, their velocity will be reset to (0, 0).

Since the player has no control of this move that's bringing them back onto the grid, they are informed of it, like so:

And on your next turn, you start off at the edge with (0, 0) velocity:

Meeting with Dr. Nimeroff: Database structure and linking multiple players

I met with my adviser, Dr. Nimeroff, for a bit the other day and we mainly discussed two related points.  Since it's been awhile since I've tried to design a database, we first talked over my ER diagram.  He didn't see any major potential issues with it right off the bat, so that was a good start.  We focused on the 'player_group' relation between the 'games' and 'users' entities.  I had not been sure whether it would be necessary to store player state information, like the x- and y-position, for a running game--in my newness to Flash/Actionscript, I'd been thinking something like that could be stored in Actionscript variables.  Dr. Nimeroff explained, though, that the Flash swf and associated Actionscript are run locally on each user's browser, so when values and visual elements change for one player, they aren't automatically updated for other players.  The key here is that whatever information is needed to update players' states on each others' "copies" of the swf and of variable values in the code must be saved into the database (since that, of course, is stored on the server) and then retrieved by calls from the other players' browsers to receive the new state.  Thus, it was a good thing I included such state information in my ER design.

Along these lines, I then asked about an issue that has been a "hole" in my mental plan of implementation since the beginning: how do other players' local machines find out that an update has been made to the database and take appropriate action to update their own copy of the game state in the code and swf?  I do want the game to be real-time, though it is turn-based, which makes it far easier than having to support multiple players doing things at the same time.  The only thing I could think of was polling; the Actionscript would just ping the database every fixed interval of time to look for a change and pull the new info if necessary.  I had also wondered whether the reverse idea would be feasible: could the database notify the game instances when an update was ready?  Dr. Nimeroff said that the former (games-poll-database) method was definitely the way to go about it.  Since the game is turn-based, it's not creating a constant stream of updates that need to be passed around; thus, a polling request every couple of seconds or so would not be a strain on the server.  Plus, the amount of data to be transferred per request is very little.  Finally, this is much simpler than the database trying to keep track of which instance to notify, where to send the notification, and the like.  This conclusion was very exciting for me, as I am no longer in the dark about a doable and sensible approach the implementation of multiplayer support.  And I think I might even know at a high level how to go about it.  Yay!

Setting up the Facebook application

Luckily this task does not seem nearly as daunting to me as it might, since I have worked through the process before when I took the User Interfaces and the Web course (which was CIS 399.006 prior to the renaming of all the 399s) and my partner and I were creating a Facebook app for our project.  However, since things may have changed since then, I've decided to figure out the process again with the help of instructions and documentation, and consult my code from the prior app only if I get stuck.

Some of the basic information was easy: what to name the app (Trace Race), an email address for Facebook to use to contact me, and an email address for app users to contact the developer (which I set to the email I created while setting up my web hosting service).  There are also spaces to fill in a few callback URLs, but as I haven't created any of the pages yet, I'm leaving those blank for a moment.

The first major choice to be made was whether to build the app as an iframe or with FBML.  I found an article on the developers' wiki explaining the differences and pros/cons of both structures.  After reading this over, I decided to go with the iframe-based structure for a few reasons: it reduces the overhead for AJAX calls (which I do expect to use), it avoids the slowdown caused by reloading Facebook Chat (this happens in FBML apps because page reloads must reload the whole page, whereas iframe reloads only reload the frame), and XFBML provides a faster way to use Facebook elements or access Facebook data than making individual API calls (and I don't expect to be making many of those anyhow).

The next question was whether to use the resizable iframe option.  This allows some control over the size of the iframe as opposed to having to fit the app into a fixed-size frame.  Although I am not sure yet how large the Flash gameboard area will be, I imagine that the pages without the gameboard and the pages with the board will probably have a different-sized content area, so I will try out turning on the resizing option.  Maybe I will turn it off later once I see how the pages are coming together.

Finally (though the app isn't totally set up--have to connect the database and hook in Facebook API code), I ran the simplest of tests.  On my web hosting space I created a directory for the pages for this app and entered it as the canvas callback URL in the app settings.  I chose a canvas URL, which is the direct link to the app in the form of "http://apps.facebook.com/[name]": http://apps.facebook.com/tracerace/.  So now if you access the canvas URL, you'll see the directory index (being pulled via an iframe from my server space) and can click to the test.html page.  Sweet!

p.s. I have added a screenshot showing the test page on my server space being pulled into the app's iframe, BUT, since the app is indeed live and publicly accessible--albeit in a primitive bare-bones fashion--you can actually go to the URL and see it yourself.  (At least, I believe so--a Facebook account may be required.  I haven't tested that.)