Showing posts with label planning. Show all posts
Showing posts with label planning. Show all posts

Sunday, May 2, 2010

Goals prior to final submission

So after my first full night ever in the SIG lab, I managed to pull off my presentation pretty well, I think.  I even ran a live demo, playing against John, and nothing broke. (!!)

Post-presentation, I've still got about a week to wrap this project up.  Here's what I'm hoping to get done in that time:
  • (bug) Fix/rework the way user logout is recorded in the database... right now I keep finding that users are still marked logged-in when I don't think they are.  (At least login is working right, I think!)
  • (bug) Make sure the "player __ won!" popup works for all players.  I seem to remember a couple of test runs in which only one out of two players saw it when someone had won.
  • (feature) Show each player's current x- and y-velocity somewhere next to their picture.  This should be really easy to do and would be helpful to see.
  • ("feature") Write the About and Help pages (including gameplay instructions)
  • (enhancement) Spruce up the (logged-out) intro page and the main page with a short intro to the gameplay.
  • (enhancement) I kind of forgot to implement preventing players from occupying the same grid point at the same time.  This also should be extremely easy to implement.
  • (bug?) I just today played the game against a friend and we ran into the case in which both of us were out of bounds at the same time.  I think there might have briefly been a mix-up regarding displaying the move options for one of us.  (Gameplay still proceeded properly though, I think.)  So I should test this again and fix if needed.
  • (bug) I nearly forgot this one... but I really should do something about the case of players running off the edge of the entire grid.  Apparently this happens more easily in my online version than on grid paper with a pencil, haha.  (See previous blog post.)
  • (enhancement) Show more clearly when another player takes their move.  I'm thinking I should highlight the position circle they've chosen for about a second prior to turning off those circles and showing their piece in the new position.
  • ("enhancement") Write some back-logged blog posts.
I don't think any of these changes are too major, and none of them significantly change the gameplay, which was certainly functional by presentation time.

Will update this list if I think of anything else.

Thursday, April 29, 2010

Considerations extracted from first (real-..)game chat

...with additional thoughts spurred from which...

Interface
  • show players (names, pics, association to colored piece)
  • display whose turn it is (and note "your turn" or "waiting for player __")
  • display your current speed (and others' speeds?)
  • and re: current speed - show a little compass of -x/+x and -y/+y directions

Instructions

How to interact with the interface:
  • click on circle to select move
  • gameplay is turn-based so you must wait for other players' moves
  • other players' circles are NOT clickable to you when it's not your turn

Gameplay:
  • goal is to be first around the track
  • how your speed is allowed to change for each turn, and that the game calculates this for you and shows you your available moves
  • when you go out of bounds, you lose every other turn for the duration of turns you are out of bounds
  • boundaries of track (both inner and outer) are considered in-bounds
  • cannot occupy same gridpoint as another player at the same time, but can occupy another player's previous gridpoint

Implementation stuff
  • handle out-of-bounds (lose every other turn)
  • handle off-the-grid
  • detect when a player crosses the start line again (i.e. the winner!)
  • don't let players be on the same point at the same time
  • display something differently about the optpos when it's out of bounds

First game played against another real person!!

My wonderful friend volunteered to test-play my game!  I happily report that everything worked as it should, and we were able to play the game as fully as possible given the state of the code.  (Some things are missing, including: losing a turn when you're out of bounds, detection of a player winning the game, detection of a player going off the edge of the grid entirely -- this last issue did not come up in our game, but it's rather important to make sure I can handle that somehow.)

First I'll post a screenshot of our finished game.  I'm the blue player and my friend is the red.

Following the screenshot, I'm including a transcript of our chat conversation during the game (with my friend's permission, and mildly edited for relevance).  It's very helpful to know his thoughts during gameplay, particularly in the areas of: the rules of play, interaction with the interface, and information to be displayed during gameplay.

Our game:



Chat transcript:

me: alright let me instruct you what to do
friend: ok
me: you're still on the page?
friend: absolutely
me: ok refresh it
me: and you should see "game #20" on available games to start
friend: yeah click it?
me: i mean to join
me: yes
me: ok i can see tha tyou joined lol
friend: i'm in baby
me: now does the track show up?
friend: yes
me: alright it's my turn lol
me: i'm blue and your'e red
friend: how do i move it?
me: you have to wait for me to go first
me: i'm player 0
friend: ok
me: you're player 1
me: cuz i started this particular game
friend: ok
me: do you see my move?
friend: you moved up one space
friend: yeah
me: yes
me: now you can click any of the red circles to move there
me: we're trying to go around the track. lol
friend: i gotcha
me: so that's all... lol
friend: can we occupy the same space?
me: not at the same time
friend: ooh
friend: intersting
me: but you can only select from the circles to move to
friend: can i go right on top of the inner black line?
me: they show you where you can move based on the rules
me: yeah that should work
friend: ok
friend: your move
me: yes i know
me: i'm trying to explain lol
friend: hehe
me: cu zi realized you don't know the rules
me: but yeah it's pretty simple
friend: i gotcha
friend: oh now we can move two spaces up
me: the rule is
me: on each turn, you can change your x speed by -1, 0, or 1
me: and same for y speed
me: make sense?
me: so try not to go out of bounds
friend: so how do i change the speed?
me: you are changing it by selecting one of the option circles
friend: ahhh i see
me: middle circle = no change
friend: i getcha
friend: like a turn-based game
me: all the others are a change of some kind, in one or both directions
me: it is turn based yes lol
friend: i dont see why it's letting you take the inside route
friend: and why the spaces closest to the edge wasnt available to me
me: you always have an x/y speed.
me: like i said
me: in each turn you can change one or both of those by: -1, 0, 2 for each
me: but the game is doing the work of tracking your speed and available changes by showing you the options for your move
me: that's all haha
friend: ok fine
me: do you understand it?
friend: for now
me: you manage your acceleration
me: so you should start slowing down in the x-direction
friend: so what's the advantage of a slowing down
me: lol....
me: if you keep going so fast in x-direction
me: you won't be able to stay inside
friend: i getcha
me: b/c you can only slow down by 1 each turn
friend: ahhh ook ok
friend: play on
me: oh shit
me: lol i'm out of bounds hahha
me: right now i don't actually have any implementation for handling that case.
friend: so what does that mean, game over for you/i win?
me: no
me: i haven't coded this part yet
friend: oh ok
friend: so it's stuck
me: but when yor'e out of bounds you lose every other turn
me: so you get slowed down a lot in comparison to the other players
me: no it's not stuck i can just move normally haha
me: see the upper right, the game knows i'm out of bounds
friend: oh ok
me: but it's not going to do anything about it
me: sorry haha i'm technically cheating right now
friend: ahh i see
friend: ok i'm trying to go more down and less righgt
me: mhm
friend: so was that the right move to make
me: yeah that's the right strategy for the moment
me: but don't go flying downwards too fast
me: cuz you will have to slow down again
friend: cause i gotta make the turn
me: it's acutally harder than it looks lol
friend: i go tit,
me: yay
friend: lets see if i can do it
friend: haha
me: dude, you have no idea, i'm so excited right now
friend: ok so one thing
friend: i gotta start goign left
friend: how do i tell it to do that
me: you can't "tell" it to do anything
friend: right
me: you can just choose from the options
me: you'll see
friend: well how do i change my velocity
friend: to go -x
me: it'll just do it for you
friend: based on what
me: as long as you are selecting one of the left-hand-column circles to move to, you're changing your horizontal speed by -1 each time
friend: ah haa
me: just keep clicking lol
friend: ok
me: now your'e out
me: of bounds
me: but you can keep playing like i did lol
friend: yeah
friend: didnt have much of an option
me: see you are going -x now
friend: yeah i see
me: but now watch the inside bound
friend: it's just
friend: reactive
me: haha
me: it's like driving
friend: how do i know what my current "x" is
me: right now you have to count it, sorry
me: i'll make a display for that
friend: haha ok
friend: that's the only thing
friend: keeping track
me: yeahh sorry!
friend: shoulda slowed my Y a bit sooner
me: lol, yeah
me: oh and please try not to go off the board
me: i don't have anything to deal with that right now in the code lol
friend: i'm working on it
friend: but i kidna dont remember how much -Y i put in
me: you can count from your previous dot to your X now
friend: oh forget that
me: okay...
me: crap i might go out
friend: hee
me: i didn't slow x early enough
friend: you nooob
me: right sure.
me: yeah shit
me: haha i'm flyyying off the track there.
friend: hahah
me: you should aslo slow x now
me: by the way it's not goign to detect the winner..
friend: yeah i finally see the x slowing
me: ok i'm gonna stop there ok?
friend: ok so you won then
me: well i was out of bounds so
me: who knows haha
me: hey
me: can i ask you a huge favor
friend:
so it's supposed to skip yoru turn
friend: but it seem like it didnt
me: i know, i told you i didn't code the turn-losing yet
friend: oh ok
me: yeah..
friend: sorry osrry
me: lol it's ok
friend: just trying to get it striaght
friend: ok huge favor
friend: go ahead
me: yeah def.
me: so would you mind if i posted (most of) this conversation with you on my project blog?
friend: sure
me: this is the first time i've played wiht someone else on another computer.
me: i won't put your name
friend: just, know that i'm not educated
friend: haha
me: lol,
me: i like our conversation b/c you pointed out stuff that would be confusing to someone who's never played before
me: which are things i should consider when i write the instructions, etc
friend: ah i see

me: thank you soo much!

Friday, April 23, 2010

Features to implement by presentation day

A rough list for the moment; probably to be updated as I go...

Definitely:
  • Select from 4 different provided tracks to play on
  • Communication between Actionscript and Javascript on the page, so that various information about the game state (whose turn it is, players going out of bounds, etc.) can be displayed on the page... This will replace the "log" text box I currently have sitting in the middle of the track.
  • Players should lose every other turn while they are outside the track bounds -- see this discussion.
  • Displaying lines (options thereof?) connecting the dots of players' previous moves (maybe just the last move, to highlight it; probably all moves once the game is over, to show the overall trajectory)
  • Finish the database setup for real... because so far I've just been adding fields and tables along with adding corresponding features to the game.  I should probably redraw/re-post a new ER diagram too.
  • Facebook login required to get to the app (because right now I'm pretty sure you can just go to the page and see it); and consequent storage of app users in the database, including whether they are currently online.
  • Display on the main (index) page of your Facebook friends who are currently logged in to the app
  • [maybe] primitive inviting of your friends to join games
  • Obviously, the entire interface needs a nice layout and lots of CSS...
  • Some sort of about/help page(s)
Optimally would be nice to have these, but no guarantees:
  • AI opponent so you can play single-player
  • allow players to draw their own tracks
  • ...and save them for subsequent use?
  • public/private games or allowing the game organizer to moderate (real-time) other players' joining

Tuesday, March 23, 2010

Storing a Turn: From Actionscript to the Database (Plan)

After deciding last night might be a good time to do something useful for my project, I chose to tackle an important feature component of my game that I had yet to really look into: making it multiplayer across client machines.  In other words, I needed to figure out how to:
  • take the occurrence of one player's turn (which happens on the Flash movie on one player's browser), 
  • send the critical information (which player and their new position on the grid) to the database on the server, 
  • and update the display of that player on all of the other players' Flash movies.
Since PHP is my avenue to the database, I set out to learn how to send information between Actionscript and PHP.  I stumbled on a forum thread that includes enough code to seemingly walk me through the necessary steps for packaging up Actionscript variables and sending an HTTP POST request to a PHP script (which can then insert values into the database).

In addition, the thread mentions that you can attach a callback function which will handle the event of the completion of the request--i.e. once the data has been loaded from the requested URL, that function is called and you can access the returned data.  So in the PHP I'll check on the success of the database insertion and send that result back (which I believe is just via 'echo' in PHP... wow I'm rusty on PHP).

I intended to draw a higher-level diagram of how this would all work, but I ended up writing in what is almost entirely correct code (as opposed to pseudocode or less).  I have some explanatory side notes written in, and arrows to show the overall informational flow.


*Important note*  I realized that this plan encompasses only the communication between one instance of the Flash game (on one client browser) and the database.  It does not cover the implementation of updating multiple players' instances of the same game on different clients, but it is the first step towards that.


Anyway here's the diagram.  (As usual, click to see in full size.)  I have a propensity for hand-drawing/writing stuff these days, it seems.

Tuesday, March 16, 2010

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.]

Tuesday, February 23, 2010

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

Sunday, February 21, 2010

Implementation Breakdown...

Pardon the rambling nature I expect this post will assume...  I just want to try to really break this grand plan in my head down into rather small, manageable chunks so that I can actually get them done.  Some brainstorming ideas will also be here.  Post is subject to later editing. :)

Note: items listed within brackets, [ ], are things I am considering but not sure whether I will ultimately implement.

Database
What it needs to include:
  • all currently logged-in users (so you can see who's available to start a game with)
  • [all users ever? - only if I want to include saved information on a user's past activity]
  •  [location pointers to stored screenshots of past games]
  • location pointers to stored game board (track) files - both the default/provided ones and the user-created ones
  • games currently in progress: the group of users who are playing together; whose turn it is; locations on the board of each player.  note: include some kind of tag for games not yet started, players invited vs. accepted, and user who started game (becomes 'organizer')
Steps:
  • draw out the schema
  • create db, add tables and relationships
  • add some test data
  • write out the queries for the above functionality
  • code queries in PHP, test
Interface
Elements/pages:
  • navigation...
  • introduction, maybe combined with help/about page
  • list of users currently online (split to show your friends and non-friends)
  • list of games not yet started and open to players joining (as opposed to closed/invite-only games)
  • sequence of pages or steps on a page to set up a new game: selecting a premade track or [a saved track of yours] or design a new track, decide whether to open your game to any users or invite certain users, choose symbol markers
  • main gameplay page - the Flash gameboard, list of the players, their symbols, whose turn it is
  • post-game display... [stats? save this game screenshot?]
 Steps:
  • diagram of navigational flow through pages / solidify pages
  • and similarly, decide what to put in main navigation
  • sketches of interfaces
  • mockups of interfaces (html etc.)
Flash game board area
Functionality:
  • display pre-made static image (blank grid on which to draw a new track; pre-made tracks on grid)
  • user drawing a new track [check for invalid tracks - e.g. unclosed loops or lack of inside and outside boundary...?]
  • detect user clicks and localize them onto gridpoints (for players to take their turns)
  • display new overlaid graphics (player symbols on gridpoints, showing possible locations for next move)
  • determine whether a move would be out of bounds - for each potential new position, I'm thinking of drawing a line (possibly invisibly within the code?) from current player position to new position, and seeing if that line intersects with the track boundary; perhaps store some key information regarding the track boundaries when it's created, and use start and endpoints of these lines to compare...
  • output/save entire game board as a static image (for saving new tracks and/or completed games)
Facebook integration
Steps:
  • Set up a new Facebook application
  • Connect outside hosting/database
  • Run some tests to make sure FB API hooks up
  • After or as mockups are being built, convert into FBML, FBJS, etc.

    Saturday, February 6, 2010

    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.