Should Shmeppy take a stance for or against bots?

Features, Bugs, and Questions
1

Some developers use Shmeppy, and while Shmeppy will certainly never have the extensibility of a tool like Foundry Tabletop which was built from the ground-up to be great for that, there’s certainly some neat things you could do with Shmeppy with even a basic API.

Indeed, I’m starting this thread because TWebberX on Discord has made Shmeppy’s (probably) first bot by reverse engineering Shmeppy’s client-server protocol.

Can bots be stopped? (Can judgement day be stopped?)

Stopping bots from being built like this by making it technically impossible is… very hard, and is the same difficult goal that DRM attempts to achieve. I’d have to rely on heuristics most likely, and though it’s maybe possible to use DRM-supportive-hardware on users’ computers to do it in a more-sure-fire way I don’t want to go down any of these roads really.

So… let’s just say no: bots can’t be stopped.

What’s the question then?

There’s still a question even if I’m not trying to make bots impossible to make.

Should Shmeppy support an API that allows developers to create bots? Should Shmeppy say “we’re not going to stop you from making bots, but we won’t help either: use at your own risk?” Shmeppy could even say “bots aren’t allowed, they’re against our Terms of Service, and we may throw pie at you if we notice you’re using one.”

In essence: should Shmeppy take a stance for or against bots?

The main concern I have is that allowing random developers to essentially add features (and therefore UI) to Shmeppy seems dangerous. These bots will become part of the “Shmeppy experience” to whoever uses them, and they’re likely to be pretty bad experiences (even with an official API keeping them somewhat stable at least).

And I definitely don’t want to start seeing people say to new users “oh well you’ve gotta use bots X and Y to really get the full Shmeppy experience.” That is not going to be a good experience for new users, and I fear it could be very bad for Shmeppy’s future.

A quick plea…

Since I know developers are the most likely ones to respond here… A quick plea: let’s not talk about the technical details of what an API might look like, it’s not relevant to the question at hand and would be better off happening in another thread.

2

This sort of thing is my main concern. I would not want useful functionality to be gated behind a bot that a 3rd party developer made and is not able to properly support. My suspicion is that the primary user base for Shmeppy will be relatively non-tech savvy DMs who aren’t going to be able to easily utilize a bot, and I would personally prefer development time and resources to go toward features that make Shmeppy easier and more useful for the majority. Roll20 suffers from this a bit already, though I’m not sure it’s really bots. But you need to find someone who developed a character sheet for inputting all your stuff and write custom macros and scripts to effectively use any advanced dice rolling functionality. It’s too much work and I think most people don’t want that level of complexity from their VTT experience. You should not need a programming background to use a tool like this, in my opinion.

1 Like
3

As introduction, I am TWebberX on Discord so sort of the cause of this post. As author of the first shmeppy bot, I think I have a few things to note.

If we take that banning all bots is impossible as a given, which I think is wise given the significant development cost it would take to do so, then my conclusions are as follows. If we put user experience central, bots that rely on an official API are always going to function better than bots that use shmeppy via the normal user interactions. You are obviously worried about the new-user experience, making sure that their first use shows how easy it is to work with Shmeppy. If an official place for bots exists, with a rating system, place to put comments and maybe even a ‘official endorsement’ thing on the shmeppy site itself you keep control of the bot ecosystem. When new users visit the bot ‘marketplace’ for the first time you can have a prompt that notifies the user that bots are not part of the core user experience and you don’t guarantee the correct working of said bots.

I see this as a way better solution then some kind of separate forum with a bunch of janky bots. This is kind of the old Minecraft scenario, where mod makers have to dig into the code and there are thousands upon thousands of questions related to deleting META-INF from your minecraft.jar. The official way allows you to track down malfunctioning bots easily, since you know which bots are in a game if a user reports an issue and can pass a report on to a bot author and let the user know which bot caused his/her issue. You also remain in control of revoking that bots access easily, by revoking their access token and delisting from the ‘marketplace’.

1 Like
4

Bots using an official API with great support from Shmeppy will absolutely provide a better experience to the users who choose to use bots. And many people will find it easy to use them if there’s an official listing of them.

But there are a lot more options besides this “fully support bots” strategy and “fight bots with technology” counter strategy.

It seems like it could be possible to dissuade the vast majority of users from using bots in the first place. And if it’s a difficult, scrappy experience that only developers could possibly find palatable… that’s ok if it’s just a handful of developers using them :woman_shrugging:.

5

There’s an extra dimension here: Time. I think Shmeppy should discourage bots now, and should create a bot API and bot market sometime in the far future.

Today, and probably for quite a while going forward, Shmeppy is in “early development flux” and there are very obvious very valuable features that can be added, and actively supporting bots would (in my opinion) be a large distraction, and “strongly tolerating” bots would lead to people using them and possibly avoiding the core Shmeppy experience being great (because feature needs would be pushed over onto the bots.)

By discouraging bots and keeping a close eye on what they end up used for and what they do UI-wise, it is then possible to create a bot API some time in the future (and likely relatively far future) to support that really well.

That’s all based on a “generic discussion”. If I were in your (@johncs) shoes, I would be a bit more concrete around bot support. As long as we are talking about only a very small number of bots, it is probably worthwhile to evaluate each bot individually, and if it makes sense, support particular bots on an individual basis, which discouraging all other bots. Ie, if you see a bot that you think provide value that is sufficient that it makes sense to you, do a specific API agreement with that bot developer, and feature that bot in some gallery of “officially supported bots”, while not providing a generic bot API.

2 Likes
6

Speaking in full accordance with Eivind_Eklund above: working to expose an API this early on just gives you that much more to maintain, which will be subject to change, as opposed to later allowing you to choose what to expose from a completed feature set.

Stating that creating bots is discouraged for the course of this early development phase will save you myriad headaches in the form of support. Allowing for bots early means design choices being made to support existing, early-functionality bots that may not be willing to update to your tune, and add the weight on you to either accept breaking their bot (and upsetting its users) or bending over backward for the creator.

In projects I’ve worked on, I personally take the stance that third party support comes post-MVP, once the project is refined enough to provide the core experience I intend to put forth.

7

Makes total sense. Indeed if I decided a bot marketplace and such would be a good idea for Shmeppy, it would be a long time before it came into existence for much the same reasons.

I think I have a decent handle on the maintenance and effort required to support bots.

I have less of a handle on the implications to the user experience (both benefits for users and costs to users) though. I’d especially love to hear from folks who want to see particular bots for example.