Showing posts with label screenshot. Show all posts
Showing posts with label screenshot. Show all posts

Tuesday, May 11, 2010

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:

Sunday, May 9, 2010

Oh hey, detecting and updating user presence is ridiculous. ( = pre-submission goals: update #2)

An annoying behind-the-scenes bug turned out, as I've learned after many hours of struggle today, to be far more frustrating and complicated than I could have imagined.

In my Users table in the database, I simply store a boolean, 'logged_in', by which I intend to record which players are currently using the app.  This does not mean whether they are logged into Facebook, since that status is likely unrelated to my app.  So, I define my logged_in boolean to mean whether the user is on either the index (home) page or the playgame.php page.

It's simple enough to ensure this boolean is marked true when the user loads either of these pages.  Detecting their leaving a page, however -- with the added requirements of updating all contingent information -- is unbelievably far more difficult.

Concerning the latter note, if a user leaves a game while it's in progress...
  • They should be marked 'logged_in' = false, since if they're navigating to one of the app pages, that page will restore that boolean to true.
  • Their 'current_game_id' and 'current_pid' variables must be set to null, to indicate they are no longer in that game.
  • If they were the last remaining player in that game, all turns pertaining to that game as well as the game's entry itself must be cleared from the Turns and Games tables, respectively.
  • If there are any other players left in that game, the 'num_players' value for that game must be set to the new correctly decremented value (and I don't want to just subtract 1, in case of race conditions, so I always want to check with how many players are still marked as involved in the game based on 'current_game_id' in the Users table).
  • The other players in the game should be checking for whether their fellow players have left, and must be informed of such dropouts.
 My original solution to detecting a player leaving the game page was to register the window.onunload event to make an AJAX POST to a php script that would update all appropriate things (see the list above).  This worked well enough in Firefox; I checked the results in the database, and Firebug showed me that the POST was indeed going through, despite the fact that the browser was navigating to another page.  However, I ended up discovering that the window.onunload event, or perhaps the POST, wasn't going through fully in Safari.  This led me to realize I should try an entirely different approach that would not rely on a browser event that may not have solid implementation in all browsers...

Many thanks are due here to John for helping me form new ideas for how to make this work.  Without going into the painful details and resulting unfortunate spaghetti-fication of my code (err..), the basic solution architecture is in three components:
  • The Users table now has a field called 'activity_time'.  Every 30 seconds, whether a user is on the home page or the gameplay page, an AJAX POST calls a php script to set this field to the MySQL CURRENT_TIMESTAMP.  So this is saying "user x is still here".
  • While on the gameplay page, the same script additionally checks for (a) any users marked with that 'current_game_id' but whose 'activity_time' is more than 30 seconds old, and (b) any users with one of the 'fb_id's registered (in a Javascript object stored by the page) as involved in that game, but with 'current_game_id' set to null.  [Note: (a) condition = those who have left the app by going to another page outside of it or closing the browser tab/window, and the cron job has not yet cleared up their data; see next bullet...  (b) condition = those who moved back to the app home page, which clears up their game data immediately, or those who have been cleared up already by the cron job.]  The id's of these "dropout" users are sent back to the page; the display of players in the game is updated to remove the dropouts, and a message is given to the user to advise them to return to the home page and start another game...(see below *).
  • There is now a cron job set up on the server to run every 5 minutes.  It calls another php script which retrieves all users whose activity time is more than 50 seconds old, removes any current game data they have, marks them as logged out, and either decreases the number of players in the game they had been in, or deletes that game entirely if it's now empty of players.
(*) Right now, there is no handling for updating the game state as it's stored in the ActionScript within the Flash app instance, nor does the page stop polling for the dropout players' turns.  As I see it, there are two options for where to go from here, regarding this issue:
  • Don't bother fixing the AS game state.  Just redirect the user automatically back to the home page.  This would make sense anyway for games that only had 2 players to start with, since playing alone is not as much fun.
  • Use the ExternalInterface class in AS to receive a notification from the page (via JS); update the game state accordingly; allow play to continue without the lost player(s).
Given how much trouble logout status has given me for many hours today, I'm inclined to go with the first option (or just let the user figure out that it doesn't work, and that they need to manually go back to the home page or leave the app).  It might turn out to be pretty quick to implement the second option, as long as there is still at least one player in the game, but I would rather turn my attention and remaining time towards a couple of the other goals on my pre-submission list, since I do think they are still important.

Finally, finally:


(I wonder how many Pandora hours I've used, out of my 40 hours given for the month, just from working today...)

Saturday, May 1, 2010

Double fail: another full game played against a friend

Things I learned from this game:
  • I really need to do something about people flying off the edge of the entire grid.
  • I also really need to write an instructions page.  It needs to be really clear about how your acceleration works...
  • I need to double check what's going on when two players are out of bounds at the same time.  The flow of turns seemed to happen properly, but I think at one point my opponent's set of move-option circles didn't appear on my screen when they should have.  (I guess they showed up on his though because he was able to take his move.)
  • Also, Matt exploited his out-of-bounds moves to jump back into the track by just cutting straight through, whereas I basically slowed down to almost zero speed and turned around.  I'd actually never thought of his strategy before.  It's not exactly a bug that he was able to do this, and I'm not sure how to curb it in any simple way in the code, either...
Now for the fun screenshots...

Game 1 (well, the attempt):
(filename: matt_fail.png)



Game 2
(filename: tory_fail.png)

Thursday, April 29, 2010

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!

Tuesday, April 27, 2010

The Facebook API battle/disaster night

I thought it would be fairly simple...


I had worked on a Facebook iframe application once before, and I remembered that the addition of requiring Facebook login and then being able to render XFBML components was not very complicated at all.  It was a matter of pasting in some code in a few different places, and magically, the page would request you to log in and add the application, and then it could show you your Facebook picture and name.  (By the way: FBML = Facebook Markup Language, and XFBML is the version you can use on off-site pages, i.e. your pages in an iframe, or on Connect app pages.)

Well, there I was, just over a year later.  I began delving into the wiki/documentation on authentication etc., and what I began to realize is that everything seemed to be in transition.  There was this new "graph API", and OAuth authentication, and a new Javascript API -- or at least, these all appear to be new, based on the look of the pages and what I could gather from the descriptions.

I really only wanted to be able do 3 things: require login and authentication of the app, pull/display users' names, and pull/display users' profile picture thumbnail.

Many long hours of confusion later, I had gone through stages something like this:
  1. using the wrong new stuff (a PHP API which I now think is supposed to be for Connect apps?);
  2. trying to use the old PHP library, cross-domain receiver file, XFBML, and iframe resizing... I don't even remember what didn't work in this combination, but some piece didn't;
  3. trying to combine the old PHP library and XFBML paste-in code with some of the newer stuff, I think? I don't even remember;
  4. attempting to manually implement the OAuth redirection cycle (things like obtaining a key and this and that), which actually almost worked...;
  5. deciding to give up on making this an iframe application that's actually within the Facebook chrome, and instead, switching it over to a Connect app, using the easy authentication/login via the new Javascript API and all of which is luckily still compatible with XFBML.
...wow.  It was a long, tiring, frustrating struggle.  Much of it was due to over-documentation, if you will, and a lack of clarity in terms of marking pages regarding at which level of API/platform transition the information and code on that page would still be relevant and functional.


And now for the bombardment of a list of links.  Here are some of the many Wiki pages/sections I tried to use to figure this out...

(Note: seems like they are really in transition currently - some of the links may not work or will give a message saying the content is moved/updated)


New (pages are in the theme of the new documentation)

Overview guide to apps (new)

Authentication (new)

Graph API (new)

JavaScript SDK (new)

Old REST API - apparently the precursor to the new Graph API


Old, but seems to still apply / be compatible with new stuff

XFBML (including tag list)


Old, and seems to not apply / not be compatible with new stuff

API (old?)

PHP (old?)

FB_RequireFeatures (old?) - for dynamically loading components of the JS API (via FeatureLoader.js.php)

Authorization and Authentication for Canvas Page Applications on Facebook - matches with the old(?) PHP library

Extended Permissions

Connect/Setting up your site - including XFBML rendering (but uses the FeatureLoader.js.php)

Thursday, April 15, 2010

Non-retangular tracks will work after all

Dear Joe: I don't think I'm capable of writing a short post.

So you know how in the past, the "track" has always been two concentric rectangles?  That's because I was simply drawing it as a Shape object.  To be able to call hitTestPoint on it (to check whether players' pieces were inside the track), I added a fill to the track space, but set alpha = 0 for those pixels so they would be transparent but still register as hits.

Well, no one wants to play this game on a rectangular track all the time.  So it's finally time to make more complex tracks work.  I didn't want to try to draw a curving track by piecing together arcs using the drawing API, so instead I made a new MovieClip object to add to the library.  I called it 'tracks' and am thinking I'll make several tracks, each one on a keyframe.  The user will somehow be able to select one, and then I'll just call gotoAndStop(frame#) on the one instance of the tracks object, and add it to the main scene.

For now I just drew one track using the pen tool and smoothing out the corner joints (vertices) between line segments.  If you go into the menu (Modify -> Shape -> Advanced Smooth...) you find a function that'll create curvature-editing handles for the vertices.  It's not exactly what I was expecting based on experience with Illustrator, but it came out decent enough.  Luckily, I was able to add a transparent fill within the track area (just using the fill tool), just like I'd done programmatically with the rectangle track.  And the bounds testing using hitTestPoint works = one hurdle easily cleared.

[Next steps: multiple tracks to choose from; users drawing their own tracks...!]

Wednesday, March 31, 2010

Successful push of variables in AS =[PHP]=> database, plus AS callback

So the other night I set out to implement the plan I outlined before to figure out how to push data (i.e. each turn's information) from Actionscript variables to the database.  Here are the components I wrote/set up:
  • Database:  set up a test table called TestTurns with 3 fields - p_id (piece's ID number), xpos, and ypos.
  • Actionscript:  added a storeTurn() method to the 'piece' class, which makes use of the URLVariables, URLRequest, and URLLoader classes to structure and send an HTTP POST request, containing a piece's ID number, x-position, and y-position, to the PHP file.  Also wrote a callback function - which gets attached to the Loader's COMPLETE event - that spits the echoed data from the PHP script (provided in name/value query-string format) into a URLVariables object and "logs" some information into a dynamic text box currently sitting in the middle of the race track.  (This is a temporary debugging mechanism, obviously.)
  • PHP:  wrote a small script in a file which grabs the 3 POSTed variables, runs an insert query on the database, and echoes back the information it received and whether the query was successful.
These components seemed straightforward enough, but I did run into some issues along the way.
  • First, I was trying to test the POST to the PHP script by running the Actionscript locally.  It was able to pull the file, but in the AS callback function I was getting these strange strings as supposed value counterparts of the names that the URLVariables constructor was able to parse out.  I rearranged and tested things for some time until the "well duh" moment: I was expecting PHP to run while sitting on my machine.  Oh, wait.  :)  (To test locally, I wrote a simple text file containing a name/value string, directed the HTTP request to that file, and the URLVariables constructor parsed it just fine.)  After this, I uploaded the files so I could test it for real (i.e. with the PHP running).
  • I knew that for an insert query, the mysql_query function would return a true or false based on whether the query was successful or an error occurred.  However, I didn't know the details on the representation of that boolean, and how it would get converted when echoed by the PHP and then parsed by the URLVariables constructor in the Actionscript.  From the output I was getting dumped into the "log" it was appearing as a 1 or 0 instead of the string "true" or "false", so in order that the URLVariables variable for 'success' would actually have a value of true or false (that could then be used in a conditional), I just used the ternary conditional operator (?:) to convert the 1/0 value ahead of time in the PHP echo string.
  • Also from the output log I realized that since I was calling (in the handler PHP file) require_once for the db_connect file, whatever was echoed in that file was showing up amidst what the handler file was echoing.  Naturally this was screwing up the name/value query string I was trying to create so that the URLVariables constructor (in AS) could read it.  I was looking through the PHP documentation for the include/require functions to see if there was a way to suppress the output of the included file, but didn't find anything along those lines.  As an alternative for echoing messages of success or error in db_connect.php, I created a variable to store a boolean for connection success.  Then, when I require db_connect.php in the handler file, I can store that boolean (i.e. $connect_success = require_once "db_connect.php";) to discover and deal with connection errors.
Once I had figured out these problems, though, it actually worked...!  I took screenshots both of the turn data in the test table and the output as it showed up in Flash:

Thursday, February 25, 2010

Hook me up

I'm all done with classes for the week, got some time before the evening activities, sitting in the 34th & Walnut Starbucks... goals for the session are: to connect via PHP with the test database I set up on my server space - at the least to pull info from it and spit it out onto the page, if not to insert new records to the one table - and to get a few calls to the Facebook API working via the Facebook PHP client library.

First I'm checking to make sure PHP works in the first place.  I made my test.html page into test.php and threw in a call to phpinfo().  It works, so it looks like I'm good to go.  Now to figure out database access.  I created a new database user and gave the user access to the app database (which currently only has the one test table).  I'm not sure yet exactly what functionality the app will need to have in accessing the database, so I somewhat arbitrarily gave the following permissions for now: select, insert, update, delete, drop, and lock tables.

In search of a refresher on integrating a MySQL database, I came upon this more general tutorial on building various parts of a Facebook app.  (For now I am only referencing the MySQL example section.)  For organization's sake, I created a file called db_connect.php just to encapsulate the connection code.  Following the example, I inputted "localhost" as the host (following this Support Center answer) along with the user and password I just created.  I also looked up the PHP documentation for the mysql_connect function and based on the example there I added a test for whether the connection attempt was successful.  Since no error message appeared, I assume the connection worked.  The last step is selecting the particular database to use.  I added a call to mysql_select_db and a test for success.  This worked as well.


Redux: So I think I might be documenting my every action a little too carefully, because this took more time than it should for only a bit of code.  I didn't make it to actually pulling from or inserting into the database, and nowhere close to trying out Facebook API calls.  But I figured out the right parameters to connect and it worked, so I did make it that far.

Wednesday, February 24, 2010

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