Category: Development

Haptics Rerouting for Fun and No Profit

Kyle Machulis

At this point, it’s fair to say that I’ve built at least some of my career on the back of a single trick: Haptics Rerouting, or more appropriately, Rumble Rerouting. This involves taking a video game on PC or Console, catching specific game state or else rumble signals from the game to the gamepad, and pointing them at other things.

Rumble rerouting has become popular on TikTok/Twitch/Youtube/etc too, with people hooking up all sorts of large haptics to desks and basically liquefying furniture (or themselves) with games.

However, in my case, the other things are usually sex toys.

Some examples of my projects include:

These projects are built on more general platforms:

While these projects are fun to post to social media and show off at conferences, I’ve never really written up the technical background of what this requires. With the Elden Ring project done and dusted I figured now’s the time to put together an overview of how these various stunt hacks have come together, including where they sit in the technology stack, how they access the parts of a game or the surrounding system that they need to do what it is they do, and the impact they’ve had around making for good shitposts.

Why Haptics Rerouting?

Why keep doing what amounts to the same project over and over?

Because it still works today just as well as it did in 2005 and before, so why not.

Haptics rerouting uses the tried and true digital/electronic art method of:

  • Take a signal of some kind
  • Remove it from its original context
  • Apply it to a different (hopefully but not necessarily) meaningful context
  • Call it art

In the case of the haptics rerouting I personally do, this means taking the notification system of rumble in gamepads as triggered by video games, and re-contextualizing it to intimacy (for various definitions of the word) via the use of sex toys.

For instance, an early version of my hardware haptics rerouting projects used the game Burnout, a car racing game with a robust system for simulating vehicle collisions and crashes. Taking the rumble from collisions in the game and rerouting them to sex toys takes the context from over-the-top racing game to over-the-top simulation of JG Ballard’s Crash.

With social media the way it is now, though, the act of removing notification context and applying sex toys is enough. Even if initial re-contextualization is given, posting a video showing a game’s rumble events driving a vibrator will elicit different reaction posts in different communities, each making it their own, some positive, some negative. The loss of focused attention on a detail by the project author is traded for near infinite variation as media becomes meme.

Or in other words: It’s a shitpost that keeps on giving.

One thing I won’t be covering in this post is the use of haptics rerouting in multiplayer games and MMOs, as I’d mostly like to cover the technical side here. There’s a lot of ethical issues to unpack when using these tools in multiplayer games, and I usually add warnings to my utilities about playing games in a manner that is private and/or with consent of all players involved. That said, that’s not a whole solution, and it’s a complex issue. I’ll try to do another write-up about how I handle this at some point in the future.

The Stack

Before diving into how haptics rerouting projects work, let’s get familiar with the stack of technology that they run on. In this case, I’ll be using a simplified example with 4 levels.

For all levels outside of Hardware, I’m also assuming that the game is running on a computer with user access to the processes and operating system.

  • Game Process
    • The game itself. This is where all of the game state and code live. This is where game mods
      happen.
  • Userspace
    • The abstract space including/around the game process, that the user can still interact with. Instead of knowing exactly what game we’re dealing with, in this realm all we know is that there’s a process and, depending on the libraries it uses (which we can usually get a list of), it may use a gamepad.
  • Operating System and Drivers
    • Access to things in and around the operating system kernel, including all data flowing between the gamepad and the computer, before it gets to the game process.
  • Hardware
    • At this point, we’ve left the machine that the game is running on, and are now working on either the interconnect between the machine and the controller, or on the controller itself, or in extreme cases, just building our own controller.

I’ll be covering each of these layers in this article, starting from the top, as that’s what most people will be familiar with, and moving down from there.

Haptics Routing in the Game Process

To start, we’ll visit the area that I actually work in the least.

Haptics routing (not rerouting yet, as we’re assuming here that the developer of the mod creates the events, versus tapping haptics events the game puts out) in the game process is a fancy way of saying “game mods”. This refers to code that modifies or augments a game in such a way that haptics can be triggered by something happening in the game itself.

Game mods can use either APIs provided by the game itself (i.e. capabilities the developer allows access to via something like Steam Workshop), or outside frameworks such as Melonloader or IPA, which provide generic utilities for accessing game state in certain engines like Unity. These tools allow developers to change assets or trigger devices based on actual game context (state and events), like a player losing or regaining health in combat, hitting a note in a music/rhythm game, etc…

However, this is also the level where anti-cheat systems like Valve Anticheat or Easy Anticheat live (we’ll get to kernel level anti-cheat later in this post). If a developer does not want game state exposed and editable, especially in multiplayer games, they’ll use anti-cheat to remove the ability to check and edit game state from outside the game itself. This means that mods may not have the visibility required to do what the user wants, and finding ways around this that still interacts with the process may end up with the user banned or even the developer arrested.

Mods for games like Minecraft, STALKER, Osu!, and others have been built using Buttplug, and are listed in the Awesome Buttplug Applications Repository. Specifically for haptics routing for intimate devices, mods are the method of choice for communities like healsluts, who are looking for events triggered based on game state (i.e. who healed whom, when, for how much, etc…) in real time.

Pros, Cons, and Impact

Games with mods tend to have communities dedicated to their upkeep. The size of these communities can vary, from a small group of dedicated users (Many indie games end up with these) to multiple gigantic communities, all with their own tools and communication hubs (Skyrim is a good example of this).

I personally avoid game modding for haptics routing because of the upkeep and maintenance cost of being involved. If I’m not working specifically with a game developer, external game mod upkeep means keeping track of when a game updates, what changes were made, how that affects the API, and a raft of other possible issues.

That said, while it’s not my area of choice, games with modding communities usually have developers dedicated to building utilities for updates, as well as keeping track of what changes when and how to update accordingly. It’s a little too niche for me to dedicate myself, but I work with developers from many different mod communities in order to help them access hardware for their chosen game or platform.

Haptics Rerouting in Userspace

Haptics rerouting in userspace takes the game modding idea and abstracts it to look at the process and what it accesses, versus the specific game state. While game mods are a scalpel, this approach is more like a shotgun. A really, really large, blind shotgun. Or a Game Genie, if you remember those.

To explain this with a concrete example, it helps to be familiar with the Intiface Game Haptics Router and its workflow. Here’s the tutorial video for that software:

To quickly summarize the workflow:

  • The GHR Application scans the list of all running processes
  • Any time it sees a process that uses a library the GHR can hook (I’ll get to this in a second), it
    adds it to its list of usable processes.
  • The list is presented to the user, so they can select the game process they’re interested in using
    the GHR with (assuming that process shows up on the list).

Once the user has selected the process, they hit an “Attach To Process” button, and this is where the GHR does its thing. The GHR adds “hooks” to the running game process, which in simplified terms means it finds the code for a certain function of the program, and then redirects it to call another function. In our case, it finds the function that is run whenever the game wants to set a rumble speed in a gamepad, takes the values from that, and sends them elsewhere (in our case, to the controls of another vibrator selected by the user). The user of the GHR can also decide whether the values still to go the gamepad to set its rumble, too.

The GHR supports two different types of processes: games that use XInput (an API for accessing Xbox Compatible Gamepads), and VR games that use the Unity Game Engine. For XInput, hooking happens using the EasyHook library, which allows .Net executables to hook native code. For Unity, we use the Harmony library, which is specifically for hooking for .Net applications (and is also used by some of the frameworks mentioned in the mod section).

The difference between mods and this type of hooking is that we do not have any game state to work from. We are just taking the rumble commands the game sends and rerouting them with no knowledge of the events that caused the game to send them.

Pros, Cons, and Impact

This is personally my favorite layer to work in, because it has the biggest potential for chaos.

Instead of building mods for a specific game, you can hand users a utility that they can try on their whole PC game libraries (this doesn’t work on consoles because we don’t have access to processes easily there). Users then can come back and say what works and what doesn’t. It gives them a way to explore and find emergent patterns and mechanics, experiencing games in new ways.

For instance, I tried the GHR with a twin-stick shooter called Crimsonland. I found all sorts of interesting patterns based on weapons, even though running a sex toy using a game about shooting bugs/zombies/bug-zombies isn’t exactly what most would be into.

Going slightly into the multiplayer realm for a second, I’ve also helped cam models use the GHR to connect with their fan base in more interactive ways than the video/text chat they normally have access to.

Unfortunately, this is also where my work normally gets knocked out by anti-cheat utilities. While the GHR and other hooking programs may not specifically be looking for game state to do malicious things with, anti-cheat (and even a lot of general antivirus programs) consider hooking to be a malicious act and will stop most naive attempts. This is why the GHR doesn’t work with games like Overwatch. There’s ways around that which I’ll get to in the next sections, but that way lies danger.

Haptics Rerouting in the OS and Drivers

If we can’t hook a process, then the next layer down will have to do. We’ll watch things from the kernel.

This is how the Elden Ring project and Buttpcap works.

Instead of hooking a process, I install a filter driver in the kernel, that watches the USB bus and relays all messages going over it out to Administrator Level Userspace (in Windows terms). In the case of the Elden Ring project, I’m using USBPcap, a utility normally used for debugging USB device development.

This allows me to find the data going between the game process and the USB manager of the operating system (which then talks to the gamepad hardware itself), possibly without the game process ever knowing I’m doing it. This is how I work around things like EAC. At the level I’m working at and for the goals of my projects, I don’t mind that I’ve lost all game context, I just want the rumble signal to make another device do something.

Pros, Cons, and Impact

While it works and makes for a good video, using filter drivers has many, many issues.

Installing a filter driver is wildly dangerous, as it means that any program running with administrator privileges can see what’s going over the USB bus. While there’s controller information flying over it, keystrokes from keyboards are also going over USB. This is basically a voluntary keylogger sitting on the system. While I can run this on an air-gapped machine to build projects, recommending anyone else do it would be inadvisable, to put it lightly.

That means that, while I can make a video showing things like Elden Ring, I can’t really share with users the same way that I can with userspace solutions like the GHR. It’s fine for a one-off, and it’ll get attention, but it’s the last resort.

This method may also be on the way out as we start to see kernel level anti-cheat become popular. While I build mostly for silly projects, kernel level snooping is used by commercial cheat manufacturers, so game vendors are fighting back by putting defenses in the kernel. While USB and other I/O may be considered innocuous for games for now, this method may not work forever.

Haptics Rerouting at the Hardware Level

Finally, there’s tapping the physical line between the controller and computer/console, or event building your own damn controller. This is the method I’ve used a few times, but only when required (because either I had no choice or I didn’t know better).

For the SeXBox, all I did was remove the rumble motors from a Xbox controller, and solder the wires to the battery leads of a vibrator. This is about a rudimentary as you can get, and it worked maybe half the time at best. I didn’t do any tests on load to the motors I connected, so many times they’d either overdraw or just not run at all. I wasn’t the first to do this by far, as projects like the G4 TV Xshok happened in 2003.

For the Console Game Haptics Router and Animal Crossing, things were far more complicated. Since I didn’t want to reverse engineer the Switch or jailbreak the system, I had to run a Man-In-The-Middle attack over bluetooth (specifically L2CAP). This meant making a Raspberry Pi identify as a Switch Joycon, then having it relay packets to/from the actual Switch Joycon. While this did work, it was incredibly slow, mostly due to the radio timing.

Pros, Cons, and Impact

No matter how simple they may be, hardware hacks always look neat. Having a physical device, especially with wires and exposed circuitry, has a hacker aesthetic like little else. Even if things aren’t doing much, it makes for much, much better visuals than software projects.

That said, it’s also time consuming and usually very difficult to put the hardware together, and it’s a very high bar for anyone else to replicate the project.

In terms of projects like this being shut down, it mostly depends on the platform. For computers, as long as gamepads identify as certain standard (HID, XInput, etc…), it’s fairly easy to work with. For consoles however, there may be signing/encryption between the gamepads and the consoles that is either not possible to work around, or else requires extra hardware to accommodate. For instance on playstation, the GIMX project allows users to hook up new controls that can identify and operate as Playstation controllers.

Conclusion

Between things like speed-running, alternative controllers, and mods, games are being pulled in all sorts of direction they may not have been originally designed for. My projects are just a small part of this overall trend to take interactive media and repurpose it in sometimes useful, sometimes silly ways. It’s great fun to watch people take utilities like the GHR and use them to find new ways to enjoy games they love, and the new projects coming up on social media for either better immersion or just pure shitposting are always entertaining to watch.

I hope this post was helpful in showing the multiple ways to get this kind of data out to games so you can throw it at whatever you want.

Now go build something dumb.

When Buttplug Won’t Buttplug, Part 1: Oh No

Kyle Machulis

There comes a time in every software poorly planned open source software project where you have to sit back and say “Wait, am I completely off the mark? Did I totally fuck this up?”.

(Image via https://webcomicname.com)

Of course, these times really shouldn’t happen at a frequency of once a month, but here we are. Unlike prior fuckups, this time I have a blog, so instead of fixing things, I can write about them!

But to be fair, a bit of self reflection is good before starting on the fixings.

Buttplugging So Far

Buttplug is itself an experiment with a general goal but no real focused direction to get there. The idea is to hand developers a way to easily access sex toys (this will come back to haunt us very soon) and then see what they do with this newfound raunchy power.

Thanks to the glorious lack of direction on how to achieve that goal of easy access, it’s also ended up as an exploration of technical niches like hardware drivers, implementation languages, and platform features. Its how we’ve gone from being a single library written in C# to two libraries written in C# and Javascript back to one library written in Rust with C# and Javascript/WASM layers on top of it, while also ending up maintaining a cross-platform Bluetooth LE library along the way. Buttplug at this point is balanced between being a useful sex toy library and a shitpost made of bleeding-edge development technologies, and I wouldn’t have it any other way.

One of the core philosophies of the library is that it should only maintain direct access with the hardware it works with. Currently, it uses only local communications systems like Bluetooth, Serial, or USB to talk to hardware. This means that, even if a company’s services go away, I can still provide users with a way to access their toy across software that works with our library. The library already supports out-of-production toys like the Real Touch, and many toys it can connect to now will suffer this same fate of obsolescence in the future, and we will be there, make sure they vibrate until the heat death of the sun or the usable lifetime of their $0.43 motor. This work has even gotten us to the point where sex toy manufacturers like The Handy actively engage with library development to provide support for their hardware. This strategy also helps preserve the privacy of the user, letting them choose hardware while being free of having to live on whatever ecosystem is provided by that hardware’s manufacturer.

During this time, Buttplug has stayed mostly desktop focused. While there have been web apps that work on Android and some via some alternative iOS web browsers, mobile offerings have been sparse at best, mostly due to lack of development resources. This happened while pretty much every sex toy manufacturer focused solely on mobile.

While all of this has been a mostly successful endeavor, it also assumes a usage model that may not always work for users of certain kinds of toys or in certain situations. Ironically, this includes many situations involving the type of toy from which I took the project name.

Buttplug, Buttplugs, and Social VR Worlds

Up until 2020, most applications for Buttplug assumed that a user was near their computer. Be it media players, single player game interaction, or other interactive applications, I mostly assumed that the user would stay still and near whatever computer was controlling the toy while using it. Even in teledildonics situations or mobile applications, there hadn’t really been any applications built where the device user and the controlling computer were assumed to be all that far away from each other.

Every so often I’d hear about random hardware disconnection issues in Buttplug (my library, not the toy), mostly with insertable toys, and in that niche, mostly with buttplugs (the toy, not my library). These toys use Bluetooth LE, a system that was not really made for fast updates, or butts, or updating things in butts in a fast, reliable way. Bluetooth LE is fine when you have line of sight or not much distance between radios and their hosts, and just need to throw data around in a leisurely way. Since Bluetooth is radio, it also would very much like to not be impeded by things like water. Overall, this means Bluetooth LE is great for things like mobile phones and small IoT devices that will stay near each other, not so much for desktops or gaming laptops, and definitely not for desktops/laptops talking to devices is in one of the deeper, harder to reach parts of a (mostly water based) human body. The past few years have been a lesson in doing this the hard way, as developing cross-platform bluetooth applications for desktop operating systems for body-immersed hardware has been nothing short of an absolute nightmare.

This user is fine and normal and good.

Unfortunately, I just don’t have many options to offer otherwise. No one seems to want a USB cable coming out of their butt (the luddites), and most people want their toy to be able to talk to their phone (as those are considered the most “private”/”intimate” technology accessing device), and phones either need WiFi (which is power hungry and complex to configure and implement) or Bluetooth to talk to the devices.

Doesn’t stop me from yelling into the void though. I’ve groused in the media for years about Bluetooth LE being bad for sex toys, though people that actually manufacture products and are better at this than I am have said otherwise.

“The antennas aren’t good enough!”

“There’s not enough transmit power in the toy!”

“Sex toy manufacturers don’t have the experience to build what’s needed!”

Up until 2020, it wasn’t much of an issue though. A few reports here and there, some recommendations on dongles and buying USB extension cables, and we’d be on our way.

Then Buttplug integration with VR social worlds like Neos and VRChat happened, and suddenly disconnection reports spiked. Thanks to COVID-19, these worlds went from social outliers to life-saving spaces, and as with any and all spaces, people fucked in it. The invariant of people being near their computers while using their toys was broken, thanks to being able to inhabit, walk around in, and hump these new shared virtual spaces instead of just sitting quietly like a good user. Not only do they move more, their sessions are longer, with reports of some users using VR social worlds plus Buttplug related plugins (both hardware and software) for upwards of 6 hours at a time.

This user is a support problem, and also an asshole

The combination of “Room scale” VR plus lengthy sessions plus hiding radios in the meat and water caves we call butts means devices often lose connections as users move around and power levels decrease, and thus cause the support channel on my discord server to see far more traffic.

This is not good.

What now?

Buttplug’s current connection methods aren’t cutting it. It works fine for people being near their machines, but that doesn’t work for VR, nor for those who just want to use their phone for certain situations. The current development strategy also puts the library at odds with toy manufacturers, who develop for and test on mobile and basically ignores desktops.

To fix this, I need to figure out ways to combine phones (or small machines like Raspberry Pis) and desktops/laptops in order to work with more situations. This needs to happen while balancing three considerations:

  • Not ceding ground to manufacturers for online services, so the library isn’t just a frontend for a bunch of services we don’t own or can’t replicate.
  • Preserving the privacy of the user, making sure that someone who is fine with their local connection setup and doesn’t want to use network/remote control never has to.
  • Making sure development ergonomics don’t suffer, while also making sure developers understand and expose features to their users in a way that doesn’t undo the preserving privacy point.

A few solutions to this problem already exist, in the form of the Lovense Connect application, as well as the XToys web based toy control and scripting system. In the next couple of blog posts, I’ll be outlining how these two systems have built their solutions, and what the next iterations of Buttplug can steal from their products. I’ll finish out with a concrete overview of where Buttplug is headed, both in terms of fixing insertable toy connectivity issues as well as thinking ahead to building remote services with the library. Along the way we’ll learn about how to design these kind of services, check out new technologies available to speed development, and most importantly, have ample time to appreciate the selection of clip art images I hastily googled for while writing these posts.

Onward and inward!