Dead Stop Page

[codestryke]

Way back when I started my first PHP game I had come across a problem of how to produce a dead stop page. A dead stop page is one where an error has occurred OR you do not want a page to be refreshed by the user and thus re-submit the form data.

As time progressed I've seen other code to do this but it just didn't seem as "tidy" as mine (either that or I just have a big head LOL). One way I've seen is to have a page with huge if/else statements, this works but produces code that is hard to read. The other way I've seen is to use a die or exit statement to stop execution. This works, too, but then you have the problem of die or exit not showing the full layout of the page.

What I came up with is what I call the report function/pages. In my common library file I have a function called report which I can pass a message. The message is then stored to a table called player_reports. The player_reports table is a one to one relationship with the main player table, keyed off playerid. The reason for this is the message can be quite large if I need it, say a result for a an attack, so I use a TEXT field for the player_report table.
player_reports:
playerid [int] [pk]
report [text]

Once the function stores the data in the table it then redirects the user to a report.php page. The report.php page then fetches said message and displays it to the player. Because of the redirection to another page if a player was to hit F5 it won't submit the data back to the calling page (EDIT: I'll say mostly, some whacked out installs of IE have been known to) because they are now on report.php, so that solved one of the problems. In my code you'll see something like:
report('You have already visited the healer today');
Which, to me, was much easier to understand at a glance and no huge if/else statemnts

I've used this method for quite a long time now but it wasn't until recently that I ended up changing the storage method based on Delfisk's massive hatred towards the database Right now I'm basking in the glow of a really good and fast server, couple hundred new players and that could quickly change so I started thinking now of ways to improve my code. Now instead of storing the message in the database I now store it in the user's session. I'm not a big fan of putting a lot of information in session. Actually right now all my games just store a hashed key and now the report message so, in my mind, that is a manageable.

--// example game code:
if( $player->visitedhealer == 1 )
  report ('You already visited the healer today');


--// report function in a common library
function report($message) {
  global $db, $pid;

  $db->Execute('REPLACE player_reports (pid, report) VALUES (?,?)',
    array($message, $pid));

  header('location: report.php');
  exit;
}

--// report.php page
$message = $db->GetOne('SELECT report FROM player_reports WHERE playerid = ?', array($pid));
$message = stripslashes($message);

include 'header.php';
echo $message;
include 'footer.php';


The above shows the database method, to use the session method change the report function to save the information to the session and the report.php page to read from the session.

Hope that helps, or at least gives someone a jumping off point

[JGadrow]

Nice write-up. Obviously, the standard exception always applies: Know your system! If there's a chance that the redirect could toss the user onto another application server (in case you've got this kind of scaling setup) you may not want to use the session depending upon how they're stored for your application.

Am I remembering correctly that you use memory tables for your sessions? I can't think of how else you're getting a performance upgrade out of using the session.

[pavansss91]

hey r u sure that the header work ??
i mean, i remember that header needs a full length url.

Except for that, it's great article.

[karnedge]

hey r u sure that the header work ??
i mean, i remember that header needs a full length url.

They don't need a full length URL but will act funny outside of the root if the directories are not used.

The above shows the database method, to use the session method change the report function to save the information to the session and the report.php page to read from the session.

I was going to point out that the example you gave doesn't seem to use the session at all until I reread that sentence again. haha

[codestryke]

I actually haven't tested the performance of using session vs database. I use just the standard session (not getting stored to the db) I'm just assuming two less database calls will be faster then storing the information in the standard text file session handler.

I've never had a problem with redirecting to the report page, even with it being in a sub-directory off the root. My standard directory structure is:
<wwwroot>
   <images>
   <includes>
   <main>

Once the player signs in they are redirected to the main sub dir which contains the actual game. If I ever need to shut the site down I just add an .htaccess file to the main directory which leaves the front end still open so I can post news or why it's down etc

[travo]

Ive found staying in the currect directory or going entering a directory never to be a problem, only traversing back up through directories... If you use a site root variale and go from there, you know youll be right.

For shutting down, I have that as part of my config. From the admin panel, I can easily switch it on and off, and users get a nice message inside the game template.

As for the dead stop page, I havent tested or anything, but I plan to save a form key in the user's session, along with the form id to make sure we process the right form, not data which has somehow ended up on the wrong page. We then process everything and then delete the session variables and show the message. If they refresh, they will only see the response.

I do like your method though, Im now thinking about using that instead. Only I would prefer to have the url stay the same, rather than response.php...

[JGadrow]

I nearly always use database session storage. But it's just because I'm OCD and I hate that PHP junks up my session directory with a bunch of empty files on my Windows Dev box! lol

[Dasein Fiasco]

I'm proclaiming allegiance to database session storage; MySQL MyISAM is plenty fast, and you can use memcache for another boost if you honestly find it too slow somehow. More importantly for me, though, is that database sessions will scale across servers and into cloud architectures much easier, a fact I'd consider important for a game planning on growth.

As far as a "dead stop" page, I'd think about the two problems separately. For preventing game issues caused by endless refreshing, I'd say that's a problem to be handled by the game's logic engine instead of being made an artifact of design for the stateless web. You'd want to prevent such things as far upstream as possible, so to speak. For errors and reporting, I think codestryke's approach is good. I'd throw an exception as appropriate (for a 500 error, custom exception for game logic violation or flood detection), handle that globally, and then either render the required template, redirect, or just display a given message.

[Chris]

Code: [Select]

function safeexit()
{
display_rest_of_the_page();
exit();
}
or

register_shutdown_function()

[Harkins]

MyISAM is plenty fast until you have to recover after a crash. Then it takes several geological ages to get it back.

So: important game data in InnoDB, stuff you could lose and not worry about, MyISAM.

[codestryke]

MyISAM is plenty fast until you have to recover after a crash. Then it takes several geological ages to get it back.

So: important game data in InnoDB, stuff you could lose and not worry about, MyISAM.

I always go with
Table needs a lot of updating/inserting InnoDB
Table pretty static or, at least, only updated/inserted occasionally MyISAM

MyISAM uses table locking. If the table changes a lot then the request queue is going to grow pretty quickly.


After some pondering and wanting to explore more I think for my next project I might go with a db session handler using a heap/memory table

[Slashmore]

As I'm starting my game again, I'm gonna use this.