Project Update: Pardon My Mess

Sorry about how patchy blog posts have been recently. I’ve been having a lot more schoolwork and a lot of minor irritating problems with the XMICYOA system that preclude having anything good to talk about. Fortunately, as of about five minutes ago, I have stuff worth talking about again. I mentioned that I was going back to make the XMI parser more efficient and flexible, and a large part of that was cutting it into two discrete parts; one to call the parser and one to actually parse the files.This, in and of itself, was not particularly problematic. Re-writing some of the shoddy code I wrote earlier to function nicely is not particularly difficult. However, I had a desire to go in and secure some of the prompts and codes differently; now the only client-side data that will go to the end-user with any of my methodology is an ID to be called; either ActionID or XMIPromptID right now, though adding more is not difficult. To do this, I have delved into object-oriented PHP, something which I was painfully incapable of at the beginning of my work on XMICYOA and now is still not my forte but which I can at least make do with.

What this means is that I’ve started using objects in PHP for the storage of ID values so that a single string can be sent back and forth to and from the client. In the day of broadband and quad-core phones, this isn’t so much for performance concerns as the simplicity and superiority of the method. It’s also likely how I will work on the inventory system and the like, as these items can actually hold multiple values, so it would be possible to send “sword, dagger, and staff” to the inventory manager and get it to give the player a sword, dagger, and staff. This isn’t to imply falsely that my inventory system is being worked on actively, though I’m comfortable with the concept it’s a lower priority than getting the game going.

Now, we have objects that contain all our data that look something like this* (for XMI requests):

“xmlPrompt Object ( [location] => potential [file] => d [id] => 1 )”

There’s only one real downside to doing things this way, which is that we do need to include our object definitions in each page, but in the long run this makes XMICYOA extension a lot more friendly; the amount of code we can theoretically cut is enormous, and that includes a variety of different formats.

This is what the old XMI parser loading code looked like:

//This checks to see if we got XMI directions from an action link or from a file that interfaces with XMI.
//echo ($_SESSION[‘currfile’]);
//echo (‘”‘.$_POST[‘xmifile’].'”‘);
//Debugging tools for stuff.
include “xmishuttle.php”;
$xmifile= safeinput(‘xmifile’);
$xmidir= safeinput(‘xmidir’);
//We sanitize our input before it hits the file system.
//These two echo functions are for debugging. If everything’s fine, leave them commented out. Note that we have a horrible sketchy work-around for handling this.
if (in_array(‘”‘.$xmifile.'”‘, $valifile)){
//If our server-side value equals what the browser sent. This is cheat protection.
//Load up this file.
//Clear our $_SESSION[‘currfile’] variable.
$currdir = safeinput(‘xmidir’);
//Note that we only sanitize input for the SQL database. It’s possible to break saves this way, but you should *NEVER* encounter a situation where this could happen.
$currfile = safeinput(‘xmifile’);
//Save $currdir, $currfile in our SQL database called location. Note the ` and not ‘, there’s a difference.
//This script runs our additional information from actions.
echo “We couldn’t complete that request. Please load your game again.”;
//Note that we leave $_SESSION[‘currfile’] initialized. This is to deal with refreshing pages and the like.
}  else {
echo “<center>XMI does not initialize properly when accessed from a URL.</center>”;
//Note the importance of the else here. This is used when there is no request detected (i.e. the user visits XMI.php directly).
//This simply loads either a “destination” xml from a folder of “type”. (e.g. Potential/Village.xml), or the like.

Compared to the new XMI parser, which will look something like:

$xmiQueryCSV= safeinput($_SESSION[‘xmiQueryID’]);
$xmiQueryArray= str_getcsv($xmiQueryCSV);
foreach($xmiQueryArray as $xmiQuery){
${“xmiQueryObject”.$xmiQuery}= unserialize(${“xmlPrompt”.$xmiQuery});
${“currXMIFile”.$xmiQuery}= ${“xmiQueryObject”.$xmiQuery}->getFilePath()
include_once “xmishuttle.php”;
echo “Error, we couldn’t start XMI up.”;

Note that this is still just pseudocode that’s actually written in WordPress instead of my IDE, so please exclude any typos. I’m also going to add session persistence for each of the serialized XMI objects, which will allow users to leave the page and come back without missing out on things. I’ll need to add some more graceful error detection in here, such as making sure that my $doc finds a file, but that’s been the case for a while.

Also, the line length isn’t the efficiency here so much as the fact that I’m not assembling strings piecewise in the XMI parser; we might see a few more lines here but this code lets us send in data more usefully.

* Pedantically, they do look like this, because this is just the print_r output of an object.

2 thoughts on “Project Update: Pardon My Mess”

  1. Noteworthy omission in this post: Where I have the $doc->load function in the sample upgraded code, it should include “xmiinclude.php” directly afterward.

    1. The final code looks a lot different because of changes to the XMI query; each query can support an arbitrary number of files, so we no longer have to ever send multiple queries. As a result, the loading code is much simpler.

Leave a Reply

Your email address will not be published. Required fields are marked *