The ‘potential for creepiness’ is exactly why I wanted to seek feedback! I feel like there’s both a technical and a personal side to the requirements. I’ve been trying very hard to lean on the side of being polite, to the point of acknowledging such in my software’s help and documentation even. However, I also feel that that is essentially a paper-thin protection. I’m trying very hard to temper my excitement about the possibilities with a good-faith estimation of what does and does not impact other players’ quality of life in the game, and with an aim towards what solely improves that QoL.
That said, even excluding malicious usage of the API, I can still see cases where an over-enthusiastic user could, through ignorance of socially acceptable uses of automation or simple lack of ability with software engineering, create something which ranges from ‘mildly annoying’ all the way up through ‘inducing unplayability’.
Further, given that my background is explicitly in AI research (and with a lot of specific experience in the medical field) I have been coming to this project with direct considerations related to the etiquette for development-phase work, as well as privacy and informed consent based on HIPAA regulations.
Pursuant to all that, and informed by my basic forays into UX and functionality testing thus far, I’d like to further complicate the discussion by laying out of few of the things I’ve done, and relate some salient experiences related to them that might effect the way we handle these issues going forward. There’s going to be a wall of text here, but I think it’s important.
- With regards to informed consent: my sense of propriety and prior standards of contact for human/robot interaction testing lead me to intuit some necessary points on informing people and communicating:
- A bot tag is definitely important, and I personally felt it was critical to make ‘bot’ the only permissible tag, to reduce the chance that other tag clutter distracted people looking.
- I felt it was important to make it clear in the description who made it and what for, and realized that there should be a clear OOC indication that the bot is not a standard character
- It was immediately apparent that responding to non ‘@’ or ‘msg’ contacts would be difficult, verging on intractable to both implement and monitor, and that a user-made bot should not be able to react to ‘say’ interactions (the potential for error, abuse, and confusion is just too great)
Some observations on this point:
*People seem to struggle with the IC/OOC distinction between the bot, the creator, anyone who happens to be chaperoning the bot at the time, and practical interactions, and there should probably be rules regarding both the play aspects and required presentation.
*People do not seem to internalize an instruction to use the recommended ‘help’ function outlined in the bot’s ‘about’. I realize that lots of people don’t really read a character’s ‘about’, and of course every designer should assume users won’t read the manual. A mechanism for establishing the standards of behavior for identifying, interacting with, and playing alongside bots might be a good cultural expectation.
*I think we need to have a discussion about how a bot may and may not prompt a user- people who try to ‘say give me a drink’ at the bartender bot and get no response would be missing out on the fun not knowing that you’ve got to @ bots. Some options that occur to me are occasional, IC-appropriate announcements (such as ‘Can I get anyone anything to drink ((ooc: @ me with your request))’ on condition that new characters are in the room and at least X seconds have passed since the last announcement has passed) or whispers or messages to new characters encountering the bot (which begs the question of saving a note of “so and so has been informed of the bot” in the bot’s files too much saved data? More on that later.)
*It seems obvious to me, but there should absolutely be a required period of time where the bot must be chaperoned by an active player who is directly monitoring it (and not in the ‘playing, but going back and forth between characters, tabs, or other activities’ way we all do sometimes that leads to 2 minute response times) before it can be left running without supervision
- There are also a suite of technical considerations I’ve been looking at how to balance, which I think inform the discussion on requirements for who can make bots because of the finesse required, and what sorts of behaviors the bot might be required as a result of decency standards.
- I’ve been applying standards of my technical field to the bot’s performance, which not every user who might be interested in playing with the API has. However, restricting that access could stifle creativity and growth. A system similar to how building and linking works would be helpful, without a doubt.
- Testing of very open-ended systems is tough. A lot of modern software engineering relies on unit testing, but even defining the basic test suite for an AI driven model can be intractable. That’s why I think an open-source it, vet it, chaperone period model for acceptance should be necessary
- Because the nuances of the artistic programming required to build stable, but flexible, bots is a fairly high bar, it seems to me like some sort of graduated privileges system for the bots would be ideal- for instance, if bots made by non-bot-maker players would not be allowed to ‘say’, or ‘message’ non-owned characters on the non-test site until approved by a bot-maker.
Based on those observations, I have a few notes as well:
*Rate limiting is important: I’ve been paying close attention to ensuring that the bot performs any visible actions at a speed commensurate with a human players- for instance, in the example above not making the ‘anyone want a drink’ prompt every single time a character enters, or three times in a row when two characters following one other all enter at once. There’s a lot of subtleties there that require skillful execution to be IC-appropriate and improve the game, rather than make it annoying.
*Contact volume is also important: a bot that says too much at a time is going to get ignored. In my basic trials recently, I’ve noticed that people tend to only read a little bit of the help file, for instance, and miss out of bits like whether the bot is currently taking messages or @s, for instance. The same principle applies to a bot that you could talk to, but what if the chat engine produces, as they do sometimes, three paragraphs of text? It’ll look rude and break people out of the spirit.
*Appropriate responses that don’t break suspension of disbelief is absolutely critical. It would be easy for novices to implement bots which, basically, fail to ‘yes-and’ roleplayers. My current draft of the bartender bot is starting off with several hundred lines of kinds of drinks, pattern matching for ordering, and similar IO formatting- entirely because as I got through I keep thinking of other branch possibilities and increasing the size of the system to account for them in a verisimilitudinous way. There certainly needs to be a sort of quality standard rubric, same as there is for builders, for that sort of interaction- not everyone will come to the process with the right programming ethos to enforce that QA them self.
Finally, there’s a couple of prospective points I’d like to raise:
- One of the initial modules I though of was a ‘find so-and-so’ bot that’d go looking for a character. I scrapped that one, and it was half the reason for me to start this discussion because a) it definitely erred on the ‘creepy’ side, and b) it seemed like it violated IC privacy, vis-a-vis the implicit ludonarrative goal imposed by only being able to ‘look’ at characters in the room. I think a sort of operational style guide for how the bot should ‘seem’ IC along with OOC requirements for programming openness and QA would be a strong benefit for the spirit of the game, addressing thematic and RP concerns like this.
- I’d love to bring some more sophisticated operation, namely AI and Machine Learning, into the world. I think it could offer a level of richness you don’t usually see in RP spaces like this, and is uniquely supported by the structure of Wolfery’s story, design, and backend. However- that draws the ‘logging data’ question into sharp focus. Is a classical AI that remembers who it met and what sort of things they’ve talked about too far over the line? Is a machine learning system that doesn’t save explicit data, but does update its model with abstractions too much? Is even the ‘casino’ idea I pitched too much if it keeps a register of a character’s wins and losses? I think there’s an enormous potential benefit, and also an extreme risk associated with this- Wolfery is quite uniquely positioned to benefit from systems like that, but the question of access control, permission, and vetting is really important, to balance risk, free creativity, and richness.
A quick edit to discuss some of @Harcourt’s extremely good points, since that post went up near simultaneously! One of the key issues in regulation of AI is in restricting that sort of persistent logging and analysis that can enable people to discover information that might otherwise be considered in the domain of ‘private knowledge’. The issue is that some of that is entirely the same sort of thing that a stalker can do- just magnified in impact because a robot can do it faster, better, and without resting. A key starting point is that if the code is open-sourced, hiding that sort of behavior will be hard, as a baseline would be that any software that makes calls that record data (or calls to an obfuscated other system) would be automatically rejected. Of course, that requires technical expertise on the part of the vetter, as I alluded to in some of my points above. The construction of a specific approval requirements document is out of the scope of this post, but creating a standard that includes provisions like limitations on what calls can be made, what external libraries can be used, and the like will be essential.
