Monday, May 15, 2017

Planning for Computerized Characters

The project I am currently planning can be broken down into several iterations on the same theme. I'll try and break it down here, noting that this is not a finalized roadmap, just my current headspace. There's bound to be some overlap and messiness as I sort these concepts out.

Digital Representation


Player characters are represented in a digital format. I do generate character background with a program which takes the six ability scores, sex, and character class as input; however, the generated info is then printed onto paper and used as a supplement to the character sheet, so it doesn't remain digital. Note that for this stage I am only talking about a computational object which represents the character.

The tough parts here include inventory and currently-equipped items. I'll circle back to these.

All-Digital Generation


All of character generation save for the initial 6 dice rolls, rolling for HP (class and mass), and probably something else I'm forgetting, are handled digitally. While, again, the combination of character background traits is already generated digitally, this stage would at minimum require me to program the computer-logic versions of ability score lookup tables  like these. At the most basic, these computerized versions would allow for the generator to automatically include ability bonuses (e.g. +1 melee attack for a high Str) for easy reference.

Live Updating


So I upgrade the character generator to create a complete character, not just their background, and that includes looking up ability-score bonuses, as above. So what? Here's what: suppose a character gets hit by a spell which lowers their Strength. Using a "communication mechanism", I will discuss shortly, the character record is updated to move their Strength from 15 to 11.

Now what we want is for the bonus on the character sheet to change to reflect that drop (using my tables, that would mean going from a +2/+1 melee attack/melee damage to +0 on both.) That means writing code to monitor the ability score, and when it changes (through said mechanism), making the appropriate values drop. This in turn would require dropping the character's current total attack bonus, no? There's a cascade of effects.

And of course we'd have to be careful not to write the code such lowering one's Constitution into a different bonus-HP bracket wiped out the bonus HP earned for HD from previous levels! Oh no!

"Communication Mechanism"


When I say "communication mechanism" above, I am referring to some way of reading and writing  the data in the character record.

The end goal looks a little like this: I send the message "Arvak, thirty foot fall, soft ground, 45 degree angle, jump was not intentional" to a controller program which can read in data for my players' characters. The controller fetches Arvak's data, and then fetches the computer-logic form of the falling algorithm. It tests the appropriate conditions, it rolls the appropriate dice, it accesses Arvak's Dexterity if necessary. It outputs the damage to Arvak and writes the change in his HP to his record, and therefore to his computer screen.

All of the above is possible to construct. I am describing here a domain-specific language (DSL) in which game actions can be expressed and their results applied to the computer records which represent game entities.

Suppose I code the message "decrease HP." This message (function) requires someone who will have their HP decreased and an amount to decrease it by. It returns the modified record. No checking is done to see if this kills them. That is the province of  part of the update system, which sends the "die" message to entities whose HP drops below -10 (or -4 if they're unleveled -- see, we have to track these things.)

Consider where we can go from here. We can write a more advanced message, "decrease HP with respect to damage reduction", which internally uses "decrease HP", but checks to see if the person who is to lose HP has any DR, and if so what type it protects against -- and then all of a sudden we need to know what type of damage is being dealt ...

You see that there is a shitload of complexity here, no? That's why I have to start very very simple and build big stuff out of small stuff. Start with a "decrease HP" primitive message that doesn't give a flying fuck about the rules for death, or DR, or temporary health, or whatever. Now, we DON'T want to use the basic "decrease HP" message for real: we'll build more sophisticated structures on top of it, like "decrease HP as a result of some-damage-type with respect to DR" and then we can build "deal fire damage" as a specialized version of that, and then we can build "deal variable fire damage" as a specialized version of that ...

And then things start getting really interesting, because we want to start thinking about locations. Areas. Zones. That's going to require the next huge shift, the one I've been trying to get started for years but haven't found an entry point: representing THE GAME WORLD digitally, the places and locations and the positions of the characters too. (That's beyond the scope of this post, though.)

Once locations exist -- and we're talking maybe 5 years from now -- then we can express the message "deal variable fire damage as a function of the mage level of Entity A to all entities in the area encompassed by the circle starting at the given point and having a 40 foot diameter."

Perhaps you know that one as "Fireball."

A Note on Intentionality


My philosophical goal while considering and while building these systems is as follows:

I decide whether a rule applies, and if it does, the computer calculates its effect.


Consider the example above, with dealing damage to Arvak because of a fall. Don't you, reader, think that whether or not Feather Fall has been cast on Arvak, should affect the algorithm's decision?

Well, yes, that's the ideal, but the concept of reifying spell effects as messages is, as I've alluded to above, many years off.

Luckily I'm a DM and I can just say, "You've got Feather Fall so you can fall that distance no problem, it'll take this long to drift down gently, no damage is suffered."

No need to run the falling damage algorithm and see if anything happens, because as a DM I know when certain rules override each other.

At the end of the day, all I am really trying to do here is codify, in a programmatic way, the rules that run my game, so that I can give myself the option of shifting the execution of rules to the computer when convenient. As the system grows more sophisticated, I allow it to do more of the "decisions" (i.e. checking rules interactions) so that I am not above the law.

Wrapup


Well, that all turned into a bit of a whirlwind tour of where my head is at, no? Vlad, you left the comment last time that sparked this post. What do you think?

All of this starts with digitalized characters. Once characters are digital, once entities are digital, then I can write a system that manipulates them, that codifies game actions into algorithmic form, along the lines of the "message" metaphor I've been using here.

And one day, one day, one day, I will have a spell list that works on the message system, too. And I have BIG PLANS for that.

But those are beyond the scope of this post.

Friday, May 5, 2017

Whew

After a year of work, I am happy to say that this week I successfully defended my thesis. In my research I was primarily concerned with gathering empirical data regarding a particular question construction in Mandarin Chinese, and the results of my collections show the necessity of expanding current syntactic theories regarding this type of question.

My big thoughts about human-computer hybrid D&D have not left my head, but I've done plenty of talking the talk, so it's time to start walking the walk. I don't want to promise anything, but I know that if I don't work on this stuff it's going to drive me nuts. It's just a huge problem, you know? Figuring out where to start has been tricky, but I think the way in which I can improve my current game (has been on hiatus more or less since April, but starting up again after graduation) is to begin with data models of the player character, and with the "21st century character sheet", i.e. a webpage user interface which (a) displays character information in real time [although without any concept of rounds or turns yet], and (b) can be sent commands by me (and later by the server) in order to add stuff to inventory, represent spell effects, etc. This allows me to concentrate only on stuff will immediately provide value to my players while still working on a fundamental piece of the world-model, and while still getting me to dip my toes in such topics as dynamic website design, databases, user authorization ... though of course the bulk of the work will be encoding many of the game rules regarding player characters into code constructs.

Plenty to do just on this topic.