I wasn’t able to do anything with this blog all last week because I was so busy; between school and a little bit of normal-ish-but-kinda-rare family events that I’m not going to go into a lot of detail here, I didn’t have as much free time to work on things as I would have desired. Fortunately, I still made a little progress.
The main thing that I worked on last week is roll functionality. As far as the PHP for this goes, it’s actually largely identical to what most simple activities will do; calling a function and printing a result. However, it does so in a meaningfully nuanced way; you feed it a comma separated value set with three to five inputs (depending on the roll type you want), and then give some player-friendly output.
The most important part of the roll functionality is that it then displays a XMI-parsed file, which is one of the keys to success on the project. It’s still somewhat experimental, but upgrading the XMI parser to utilize functions the other day meant that doing this was a rather easy task. An important thing to remember about the roller is that it doesn’t actually collect the data required for a roll; it’s just a script to collect all the data, put it into a function selected in the XMI file that calls the roll, and then run the data.
This is much more complex than it sounds, at least in my implementation. I’ve been working on more gracefully POST’ing information, since it has both security and performance implications (the latter are more nominal, but that’s okay), and moving more of my variables over to $_SESSION as opposed to $_POST.
I’ll probably go back and update the original XMI (see final paragraph of this post) and action systems to fully utilize sessions, as what I’ve updated my methods to do is simply use $_POST to communicate the ID of the action being taken. This is then used to load up a $_SESSION variable that stores an array with all the information we need, which I then either take from bit-by-bit or turn into a CSV to feed the function. There’s a little inefficiency here since I feed in data as a CSV, append it to an array, push it over to the roller activity, remove the other stuff from the array, and then feed the array into the specified function, but that’s the way that things work because I can’t specify array data within the XML (well, I might be able to, but it’s not the best way). I should also make sure that I’m not storing too much of my $_SESSION data on clients, especially if XMICYOA is to be suitable for commercial use. That said, the database shouldn’t respect bad inputs (and by that I mean that it almost never updates from $_SESSION). I made a slight upgrade to session security; it’s not real security but it should suffice for most uses. I’m not going to go super brutal on security because XMICYOA is a game platform, and I want users to be able to move between networks and still play normally. This leaves us vulnerable to some hijacks, but since I don’t think people are going to go around stealing XMICYOA logins because there’s not a whole lot to gain by doing so I think the added convenience is worth the trade-off. Once I’m more familiar with the security functions, I’ll make this configurable, but right now I’m worried I’d make it really weird. It definitely bloats the sessions a little, too.
Back to rolling, the roller has separate roll function and user output components; the user output does not use a CSV to store information but rather a full-bodied associative array. The reason for this is because a lot of these values will be set in the configuration setting by default, and this way it’s possible to define each in the XML file (for instance, $outputdata[“resultname”], which defaults to “roll” because that’s the normal variable name for a roll, unless you specify otherwise) or in the configuration. Roll outcome files each come from the “/roll” directory by default, as well, because it’s neater. You can specify multiple as a CSV in the appropriate XMI call (I’ll have a full post on the roller once it’s finished). Right now there’s no distinction between success and success margin; I’d likely add a second function to do this as there would be a requirement to feed more XMI in.
Sadly, I still have not implemented normal state requirements. They slipped my mind and I literally just remembered them. I also need to implement attribute requirements, which should be pretty simple as opposed to the more complex state requirements. Or state requirements should still function as desired, though I still need to add proper marginal handling to them.
Other news for today is that since it’s now possible to encounter multiple XMI files at once, I have to revamp saving. Note that there’s an important caveat to saving; right now the setup for saving is a single object, but soon it’ll use a CSV array just like function calls do to support multiple options. This will allow you to determine what exact XMI functions are available if the player resumes (not seeing a roll result again, for instance, but having all the options available). The catch for this is that XMICYOA doesn’t save position and game state updates at the same time. Once I fix the save system to allow for multiple XMI calls, I’ll switch saving around to being opt-out.