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.

Database planning - ER diagram and query thoughts

ER Diagram
So, with some refreshing to help out my memory of CIS 330 material, I have constructed a first-draft entity-relationship (ER) diagram for the database.  I'm the slightest bit iffy on whether I've indicated the participation and many-to-one constraints via the correct notation; see the legend (added mainly for my own reference) for my understanding of it.  I also can't remember if foreign keys should be indicated--I seem to recall that they should be given a dashed underline, but I left that out because I'm not sure.  At any rate, I've unconventionally included a bunch of extra notes (including mentions of the foreign keys) to provide further explanation and clarification.

Additional iterations and modifications of this setup are of course likely to occur.  I will try to post updated diagrams as they do.  (Maybe I'll make this into an Illustrator file, but for now, it was easiest for me to work it out in my head and put it directly onto paper.)

Please please click on the image to see it in full size... it's quite difficult to read at the embedded size.

Queries
While I'm thinking about it, here's a very preliminary and unfinished list of SQL queries I'll need to figure out...  (Capitalized terms are entity names; terms in single quotes are attribute names.  I don't know if that's correct syntax, but it's simple notation for myself and readers.)

• Get all Users currently logged in but not playing a game
• Get all default Tracks
• Get all Tracks created by a User
• Get all Tracks... [should I allow access to tracks created by other users?]
• Create a new Track - store the 'filepath', associate with a 'creator' = User.fb_id
• Create a new Game - associate a Track, a User.fb_id as organizer, and 'in_play' = false
• Add Users (unconfirmed) to a game - 'joined' = false
• Confirm a User's participation in a game - set 'joined' = true
• Set (update) a player's position on the game board grid - change 'xpos' and 'ypos' for given User.fb_id
• Get the player whose turn it is now/next
• Delete a Game when it's finished - this will include removal from Game table and all entries with that Game.id in player_group

Long-awaited story boards!

[EDIT: Ah, crap, the images are far too wide for this skinny column.  Click them to see the full image, so that the explanations make sense.]

The aim of these diagrams - which are not necessarily intended to represent proposed visual design - is to show the progression of a sample game at various points.  So here we go:

Initialization
Set up requires choosing a provided closed-loop racetrack (of relatively consistent width) on grid paper, or drawing one yourself.  A start/finish line and direction of travel (see the arrow beside the start line) are decided upon, and each player chooses a symbol and selects a position on the start line.
The possible first moves are shown (for the blue-circle player) as filled blue circles.  Since clearly they have not started moving - a speed of (0,0) - their next move can have a speed of -1, 0, or 1 along each axis.  All possible moves are shown here for completeness, but obviously, you would never move backwards behind the starting line.

Getting going: how to move
At this point, each player has taken 3 moves, and the options for the fourth move are shown for each.  (Dual-color circles indicate that that point is an option for both of those players.)  The basic rule is that for any move, a player can hold constant or change by 1 the number of points to move along each (horizontal and vertical) axis.
For example, if in the prior turn, a player moved (3,2) in (horizontal, vertical) movement, their next move could be any of these options (within bounds): (2,1) (2,2) (2,3) (3,1) (3,2) (3,3) (4,1) (4,2) (4,3)
Note a couple things:

• Players cannot occupy the same grid point at the exact same time.  (BUT, any player can occupy a point that was occupied in a past move by another player.)  Taking a grid point that would be ideal for another player's move could be a strategy.
• Players are not allowed to move to grid points outside the track (obviously).  Clearly, here, the green and blue players have a decreased set of options.  Grid points exactly on the border of the track are considered in-bounds.

Stuck
Now each player has taken 6 moves.  The red player did not think ahead enough and has created a situation in which all possible next moves are located out of bounds.  At this point I have not decided how to handle this situation, but I do not think cutting the player out of the game from then on is ideal.  That's no fun.  I may decide to require some sort of backtracking to a prior position.

The end: finishing/winning
Here, the completion of the game is shown (except the blue-circle player, left out to make the example easier).  Assuming that the red and green players were taking the same turn at the bottom-right of this quadrant of the diagram, notice that 14 moves for each are shown here.  Since the red player reached the start/finish line (and the green player has not yet), the red player wins.
Notice this diagram includes an example of players occupying the same grid point at different times in the game: the green player's 10th move on this diagram is the red player's 8th move.