XMICYOA is built on the ABACUS core, but I want to provide a robust number of features for people to use in their own work, as well as allow myself a certain degree of flexibility as far as game mechanics go. As such, I’ve been hard at work creating a working dice emulator that provides meaningful and robust results without a whole lot of difficulty. I also fixed a couple bugs this week.
As far as busywork goes, I fixed an error in how I handled the cheat protection that didn’t come up with the single-option testing I’d done last week. Now acceptable outcome variables are pushed into an array, making it possible to move more quickly. I don’t store the directory of the file (just the name), so end-users may want to make sure to implement smart cheat countermeasures for one-of-a-kind fights and locations (naming important xml’s with a “c” prefix for combat, for instance), but usually if you don’t double up in places where players will want to cheat you should be fine. I also commented out some unused functions, which should provide a moderate degree of improvement in speed.
Now onto the new stuff. ABACUS requires just one dice system for everything, its 2d20 curves, but I’m implementing more dice rollers both for random elements (3d6+20 coins, anyone?), and to ease compatibility concerns when working with other systems (I hope to include enough functions to implement classic Shadowrun “inward exploding” dice, d20, modern Shadowrun “outward exploding” dice, and d100 systems). Right now I have a working d6 count as well as the ABACUS system, and it’ll always be possible to roll loose dice separately.
From a technical aspect, the dice rolling functions are built to give nice variables to wherever they are needed. Rolls are standard PHP functions that can be fed variables in a normal way, and they export a global (by default $roll) when they are completed. This means, for instance, that I have a line of code that looks like:
d6rollsum(3, 5, 1, attack);
which outputs $attack which is equal to 3d6+5 + 3 (1 for every die). I don’t know of any systems that use per die modifiers, but I figure it’s an easy enough feature to implement that it *has* to come in handy. As variables are not required, I can do stuff easily. For instance, were I to want to implement a d20-styled attack roll, all I would have to do is use the following (not yet fully implemented, though it should only take four lines of code and is waiting for me to finish this post for its implementation) command:
d20roll(5, tohit);
Which will roll d20+5 and mark the result as $tohit. If I wanted to, I could actually import other variables there, so I could have $dex+$bab = $modifier earlier and then make my call be:
d20roll($modifier, tohit);
For those curious, my code for the d6 function is as follows:
function d6rollsum($countdice, $totalmodifier = 0, $diemodifier = 0, $resultname=”roll”){
$result= $diemodifier*$countdice;
//We want to make sure that we give our per-die modifier first.
while($countdice > 0){
//Only roll while there are still dice to roll.
$result = $result+rand(1,6);
//Increase our result by d6
$countdice = $countdice-1;
//Remove that last die from the rolling process.
}
$GLOBALS[$resultname] = $result+$totalmodifier;
}
This isn’t really functionality that XMICYOA desperately needed, but it’s part of the game elements that I’m working on putting in right now.
My roadmap for the next couple weeks is delving back into MySQL to save location and stats across sessions (which requires, for testing’s sake, that I incorporate a rudimentary advancement/levelup system), and then it’ll be back to the XMI parsing system and requirements (I want to test this authentically rather than modifying values on SQL’s end and seeing if it caused a change). At some point I should also go back and neaten up my code so that XMICYOA loads from a central file, rather than loose files, for neatness’s sake (i.e. you’ll have a page that includes x.php instead of going to x.php directly), but that’s low priority.