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:

Discussion with Dad, part 2: Detecting boundaries and out-of-bounds moves

I also spoke in a more high-level sense with my dad about an important issue that I need to solve programmatically via Flash and Actionscript: the program's "awareness" of boundaries.  Here are some methods that I or we came up with:  (Note that I may not have yet researched the feasibility of each.)

• Store a 2D array of booleans.  Each cell corresponds to a grid point (i.e. potential position) and the boolean simply states whether the point is inside (true) or outside (false) the track boundaries.  This takes initial overhead to create but makes detection of out-of-bounds moves a simple array-access call.  I could create such arrays manually for tracks I draw that will be provided as pre-made tracks; the bigger issue is how to compute this array for user-drawn tracks.  My dad's solution to that is to allow users to draw the track only as a series of connected straight line segments; as each segment is created, the its slope (change in x / change in y, in grid-points) can be used to set the booleans for nearby grid points.  [This corresponds to the left-hand part of the scanned diagram below.]
• Check each player move for bounds-crossing.  An idea I had already had is for each time a player selects their next move, a line will be "drawn" (programmatically and hopefully invisibly) from the previous position to the new one.  Then, check if this line intersects with (crosses) a track boundary.  I'm not exactly sure how such an intersection check would be accomplished in Actionscript, though I tried to look around a bit for some methods (see the resource links post)...  [This corresponds to the right-hand side of the diagram below.]
• Use the intrinsic ability of Flash to "know" which area is inside and outside a shape.  This is not as crazy as it sounds.  My dad explained that such data must be stored somehow; the simplest justifying example is that enclosing bounds (i.e. a shape) can be filled with a color.  Since I had no clue how I might access this stored data, I realized maybe I could take the color-filling ability at face value: maybe I can just fill the space outside the outer boundary and inside the inner boundary with a color, and check pixel colors to see if a particular move is in bounds or not.  Again, I figure this can be accomplished with Actionscript; the solution could range from not-so-elegant to rather-hackerish.  Anyway, I'll have to look into it.  [This only corresponds to diagrams in my head, so far.]

Dicussion with Dad, part 1: Handling when a player gets stuck out of bounds

Over lunch with my dad during spring break, I finally remembered to ask him about the one critical point of the game rules that I could not remember: what happens when a player's speed forces them to move out of bounds? -- In other words, all of the 9 possible positions for their current move are located outside the outer edge of the track, or inside the inner edge.  (From playing games with my dad, I definitely remember that this happens sometimes.)

My original idea for handling such a case was to set the player back to their latest prior position (past move) such that subsequent speeds/moves would not force them out of bounds.  As my dad pointed out, this might require backtracking by more than just one previous move, because that might not be enough to allow them to decrease speed within the next move (and stay in bounds).  The process of backtracking and computing at each prior position whether or not the player could stay in bounds from that point would also be a bit of a tedious procedure.  Finally, he maintained that this solution is "unrealistic"; in other words, you don't go backing up your car and slowing down on an actual race track.  Keeping the game realistic isn't especially important to me, but it's kind of a nice feature to attempt to uphold.  (It's kind of like when movies try to stay scientifically accurate.)

My dad's alternative solution is apparently what we always did when we used to play the game (and I just forgot).  It's actually very simple:

1.  When all of a player's options for their current move are out of bounds, the player simply takes the move anyhow.
2.  On their next turn, they lose a turn: their piece/marker stays in place on the grid, but they are considered to hold the same speed in the x and y directions.
3.  On the subsequent turn, they take a move, maintaining the same rules about speed--the x and y speeds may change by 1 unit in either direction.
4.  This alternation between lost turns and normal-movement turns continues for as long as the player is outside of bounds.

Obviously, the point here is to slow the player down while outside bounds, and hence encourage them to get back in bounds as efficiently as possible.

Here's the diagram my dad sketched to show this.  (Ignore the lines on either side of the '2' and the dots they lead to--that was a different idea.)  Suppose a player is forced to move outside the track on the turn indicated by the line next to '1'.  Their next turn, then, is lost; my dad designates this with the circle surrounding the dot.  The circle means they've stayed at that location for a lost turn.  Two more alterations of turn/loss are then depicted, as the player aims to return to the track.

Just to note, I'm not sure yet how I'll indicate visually that the player has stayed in place for the lost turn, since so far in development the game display is not exactly like it would be on paper in some ways.