Recentemente, eu estava relendo minha Entrevista com um desenvolvedor web do PornHub e uma parte em que comecei a pensar foi a questão da RV e a ideia de fazer com que os usuários não apenas vejam, mas sintam”. algo. O feedback háptico dos jogos de RV é o que realmente os diferencia de um jogo padrão de PC ou console. Então, quando se trata de tecnologia sexual, como é criar experiências que o senhor sente em vez de ver? Tive a oportunidade de entrevistar Kyle Machulis, também conhecido como qDot, sobre a codificação de experiências hápticas que proporcionam boas vibrações às pessoas. Aproveite!

Aviso: Esta publicação do blog detalha a codificação de brinquedos sexuais e outras conversas adultas. Interrompa a leitura se esses tópicos puderem ofender o senhor.

Qual foi a inspiração original do projeto buttplug.io?

A inspiração original continua sendo a principal inspiração hoje: Permitir que as pessoas com recursos criem o que quiserem para o hardware sexual controlado por computador que possuem.

Na verdade, eu não tinha um nicho ou uma comunidade específica que pretendia atingir com isso, em vez disso, queria apenas tirar as coisas chatas de programação do caminho para que as pessoas pudessem construir o que lhes interessava sem ter que aprender as excentricidades do Bluetooth/USB/etc entre plataformas, certificando-se de que ele se conectasse à rede corretamente e tudo mais…

O senhor hesitou em dar a ele um nome tão direto? O nome foi positivo ou negativo para o projeto?

Curiosamente, o nome original do projeto era Fuck Everything (Foda-se tudo). Várias pessoas me convenceram a desistir dessa ideia, principalmente com o argumento de que “o senhor nunca conseguirá falar facilmente sobre isso na mídia ou fazer referência a ele”.

Com isso em mente, eu ainda queria algo apropriadamente obsceno, então Buttplug foi o que escolhi (fiz um vídeo sobre esse raciocínio também: https://youtu.be/c6bghuCy6d8). Era e ainda é definitivamente um risco, mas quais são minhas alternativas? Eu poderia optar por algo benigno, que funcionaria, mas seria meio chato (e foi isso que fiz com o Intiface, o nome da linha de aplicativos que fica em cima do Buttplug, para poder usá-lo nas lojas de aplicativos). Como Buttplug é o nome da biblioteca e será usado principalmente por desenvolvedores (“embutido” em seus programas, por assim dizer), parecia um lugar seguro para ser um pouco bobo.

Qual era o objetivo no início do projeto e como o senhor chegou onde está hoje?

Eu defini a meta na pergunta de inspiração, então vou continuar com ela. Em termos de medir o alcance do projeto, acho que a melhor maneira de mostrar isso é por meio de nossa lista “Awesome”: https://awesome.buttplug.io.

É aqui que tento acompanhar a nossa comunidade, listando tudo o que eles criaram usando a biblioteca. A maior parte da concentração tende a ser em torno da sincronização de jogos ou filmes, mas há todos os tipos de projetos que surgiram em torno dela, e ouvimos falar de novos projetos todos os meses. A variedade de tipos de projetos por si só é o que nos faz continuar.

Do ponto de vista técnico, quais são algumas das tecnologias e ideias de destaque por trás do projeto?

A tentativa de criar uma espécie de “linguagem técnica comum” para a háptica íntima é uma grande parte do foco técnico. Isso é SUPER difícil de fazer e já seguimos vários caminhos errados, mas eu sabia que seria um longo curso de refinamentos e não diria que estamos muito longe disso, especialmente considerando a quantidade de projetos implementados usando a biblioteca.

Também acabamos tendo que implementar a maior parte de nossa própria biblioteca Bluetooth LE (https://github.com/deviceplug/btleplug), embora eu tenha sorte de o ecossistema Rust também nos fornecer o que precisamos.

Por fim, poder apresentar o projeto às pessoas em seu território (linguagem/plataforma de programação) em vez do nosso é um desafio constante. Atualmente, enviamos a biblioteca principal em Rust, com ligações em C#, Javascript/WASM, Java e Python, e as pessoas criaram ligações para linguagens como Haskell e Go. É muito importante que as pessoas possam abordar esse trabalho da forma como se sentirem confortáveis, em vez de terem que aprender outra linguagem, portanto, o design precisa ser flexível o suficiente para funcionar em vários contextos técnicos.

Quais são alguns dos principais termos de engenharia que é importante conhecer?

  • Haptics – O estudo do tato
  • Feedback Haptic – Uso do sentido do tato para notificar os usuários sobre eventos ou outras situações
  • Rumble – Como normalmente discutimos o feedback de videogames, com motores no gamepad
  • Rumble/Haptics “HD” – Um desenvolvimento recente em haptics para consumidores, principalmente em controles de jogos mais recentes (Switch Joycon, PS5 DualSense, controladores de VR) que usam pequenos atuadores que podem mudar rapidamente de velocidade, ampliando o vocabulário háptico além do rumble para coisas como toques, batidas etc.
  • Teledildonics – O termo original (cunhado por Rheingold) refere-se ao sexo remoto entre duas pessoas, mas atualmente o termo é usado livremente para se referir a brinquedos sexuais que podem se comunicar com/ ser controlados por computadores em geral.

Como a abordagem tecnológica do senhor mudou desde o início do projeto até agora? Como cada linguagem (JavaScript, Rust, etc.) melhorou com o passar do tempo para tornar o projeto melhor?

Aqui está uma rápida linha do tempo das implementações:

  • 2013: Tentei uma implementação simples em Python, mas não fui muito longe porque não havia muito hardware disponível e o suporte a bluetooth era duvidoso em todos os lugares.
  • 2016: Experimentei o Rust, mas era um pouco cedo demais e eu teria que implementar muita coisa do zero. O Tokio era a opção assíncrona na época, mas era bastante complicado de usar, e eu estava acostumado com estruturas assíncronas em outras linguagens (JS/C#), então não deu certo.
  • 2017: Passei a tentar uma implementação em C#, para que pudéssemos pelo menos dar suporte ao Windows com suas novas APIs UWP Bluetooth (lançadas em abril de 2017). Isso funcionou muito bem, mas também nos prendeu ao Windows e ao C#, e mesmo assim eu me sentia mais confortável com o Rust e queria o sistema totalmente multiplataforma.
  • Mais tarde, em 2017: Adicionei o Buttplug JS, porque tínhamos o WebBluetooth/WebUSB/WebGamepad disponível. Essa foi uma implementação completamente separada do C#, porque o WASM ainda não era uma coisa realmente existente.
  • 2019: finalmente me cansei de manter a implementação lado a lado do C# e do JS, o Rust estava prestes a lançar o async e o WASM estava começando a parecer bom, então comecei a desenvolver uma terceira versão do Buttplug em Rust, enquanto ainda mantinha o C#/JS.
  • 2020: De repente, eu tinha MUITO tempo livre em casa, então a implementação do Rust continuou durante o ano. No final do ano, não só tínhamos uma implementação do Rust, mas o C# estava trabalhando basicamente com a mesma API em cima do Rust, e o Rust também podia compilar quase diretamente para o WASM, o que significa que tínhamos cerca de 95% do mesmo código fazendo o backup de todas as implementações de linguagens diferentes
  • 2021: Mudamos completamente para o Rust, que é onde estamos até hoje.

Como seu código passa do código-fonte bruto para a compilação e depois para os dispositivos? Como é o processo de teste e depuração?

Em primeiro lugar, não há realmente um “para dispositivos” aqui. A biblioteca não é um firmware, é um software, criado para que os aplicativos se comuniquem ou se integrem. Nosso trabalho é fazer a interface com qualquer firmware que já esteja no dispositivo, mas não especificamos que um determinado firmware tenha para estar lá. Implementamos protocolos para muitas marcas diferentes, bem como alguns sistemas de código aberto/DIY (como o T-Code, uma derivação semelhante ao código g para brinquedos feitos por outro projeto comunitário DIY): https://stpihkal.docs.buttplug.io/protocols/tcode.html).

Em termos de compilação/distribuição, trata-se apenas de um software, como qualquer outro, portanto, não há nada de especial nisso. Todas as nossas bibliotecas e aplicativos passam por CI (uma mistura de Azure ou Github Actions neste momento), todos os nossos aplicativos são assinados (para que as pessoas possam, pelo menos, confiar que vieram de nós), etc…

Oferecemos suporte a várias plataformas (Win/Mac/Linux/iOS e, esperamos, Android em breve) e linguagens (o sistema principal é o Rust, mas há bibliotecas de suporte em C#, Javascript/Typescript (via WASM), Python, Java, Haskell, Lua e a lista continua, escritas por mim ou pela comunidade), portanto, o empacotamento delas também é feito no CI.

A depuração e os testes são… difíceis porque, neste momento, oferecemos suporte a mais de 20 marcas de brinquedos, além dos projetos DIY, e cada uma dessas marcas pode ter mais de 10 brinquedos. Em suma (de acordo com o IOSTIndex, um site que lista todos os brinquedos controlados por computador conhecidos: https://iostindex.com/?filter0Availability=Available,DIY&filter1Connection=Digital&filter2ButtplugSupport=4), a biblioteca suporta 247 brinquedos no momento.

Eu adoraria ter um sistema de teste mais robusto para hardware, pois acho que muitos dos testes de hardware poderiam ser automatizados de maneiras realmente interessantes com a criação de dispositivos de simulação que ainda usam os barramentos de comunicação Bluetooth/USB/etc reais, mas esse é um projeto que me escapou de ter tempo para realizá-lo.

Obviamente, não podemos testar TODOS esses cerca de 247 brinquedos em cada versão, pois a biblioteca é desenvolvida principalmente por mim e talvez por uma ou duas outras pessoas que ajudam com um pouco de código ou controle de qualidade. Tentamos testar as marcas mais populares, como Lovense e Kiiroo, e dependemos dos relatórios dos usuários para detectar bugs e atualizações sobre falhas. O servidor do discord (https://discord.buttplug.io) tem sido um recurso fantástico para isso, pois foi criada uma comunidade muito engajada em torno da biblioteca. Muitas vezes, as pessoas aparecem com brinquedos que ainda não conseguimos obter e podemos trabalhar com elas remotamente para integrar o suporte à biblioteca, às vezes antes mesmo de qualquer desenvolvedor da biblioteca receber um.

O que cada linguagem de programação poderia acrescentar para tornar o buttplug.io melhor?

  • O Rust nos dá a base de segurança de que preciso para me sentir bem ao lançar um projeto que realmente funcione de forma multithread enquanto estiver no corpo das pessoas.
  • O JS/WASM facilita a criação de protótipos de forma MUITO rápida e efêmera, pois as pessoas podem brincar com o Buttplug completamente no navegador. Isso significa que se elas não quiserem verificar os repositórios git ou ter outras coisas que possam ser vistas como incriminadoras (por falta de um termo melhor) em seu computador, elas podem simplesmente fazer algo no glitch ou jsfiddle ou qualquer outra coisa e ainda ter controle total do hardware
  • O C# é agora nossa porta de entrada para jogos, especificamente para o Unity. Temos um plug-in para Unity e uma biblioteca completa em C#, e há muito mais desenvolvedores lá do que em Rust, portanto, isso expande o uso.
  • O mesmo acontece com Python. É rápido e fácil para as pessoas criarem protótipos de coisas, e mais pessoas o conhecem.
  • O único motivo pelo qual planejo usar C++ é para dar suporte ao Unreal no momento. 🙂

Quais são algumas das organizações que usam seu projeto? O trabalho do senhor entrou no setor de filmes adultos convencionais?

  • https://xtoys.app usa nossa biblioteca para algumas de suas integrações de hardware (embora eles ofereçam suporte a mais tipos de hardware do que nós!)
  • ViRo Playspace usa nossa biblioteca para acesso ao hardware e é distribuído no Steam!
  • Também estamos em alguns jogos financiados pelo Patreon, como Heat (Calor) e FarmD

Em termos do setor cinematográfico, nossa biblioteca é muito usada para “movie sync”, que é um esforço da comunidade para criar scripts que sincronizam hardware com filmes. O principal local para isso é o https://eroscripts.comembora também existam empresas como a SexLikeReal que fazem a sincronização de hardware.

Uma das dificuldades da maioria dos projetos de código aberto é o financiamento e a monetização – como a monetização foi considerada no projeto ao longo dos anos?

Passei quase um ano avaliando e experimentando diferentes estratégias para trabalhar em tempo integral na biblioteca, mas, no final, embora algumas delas parecessem viáveis, acabei descobrindo que não era algo que eu realmente gostaria de fazer. queria fazer. Estou satisfeito em manter o Buttplug como um projeto paralelo. No entanto, ainda é um projeto paralelo caro, por isso tento manter algum dinheiro entrando para financiar máquinas e hardware de pesquisa.

A maior parte do financiamento vem de três fontes:

  • Crowdfunding (financiamento coletivo): Eu uso o Patreon (https://patreon.com/qdot) e patrocinadores do github (https://github.com/sponsors/qdot), embora o Patreon tenha sido mais de 90% dessa parte da renda. Ofereço níveis em que os doadores podem receber atualizações semanais, adesivos, videoconferências individuais, etc. Tem sido uma maneira muito boa de interagir com a comunidade
  • Afiliados: Acontece que as empresas de brinquedos sexuais pagam para que o senhor venda brinquedos para elas e, como a biblioteca não existe realmente sem os brinquedos de outras empresas, isso acaba sendo uma estratégia de monetização muito boa para o projeto também. Isso também me permite estabelecer parcerias com empresas, o que não era algo que eu pudesse fazer muito antes, pois muitas empresas viam o Buttplug como algo que tirava a receita em vez de trazer novos usuários.
  • Consultoria: Graças a toda a experiência que adquiri com o Buttplug e ao trabalho com tecnologia sexual durante todos esses anos, agora posso prestar consultoria sobre engenharia, UX etc. em tecnologia sexual para empresas do setor. O que a biblioteca faz e o que nossa comunidade constrói ainda está muito à frente do que a maioria das empresas está vendo seus usuários pedirem, portanto, trabalhar comigo permite que elas planejem o futuro.

Vejo uma variedade de controladores de videogame na sua lista de dispositivos que serão suportados em breve. Tenho que perguntar… qual é a demanda por suporte para esses tipos de dispositivos?

Na verdade, não se trata tanto de demanda, mas de reconhecimento da disponibilidade. Os controles de jogos com vibração são facilmente o tipo mais comum de vibradores controlados por computador. O suporte a controles de jogos que vibram significa isso:

  • Os desenvolvedores podem simplesmente ter algo em suas mesas que não seja um brinquedo para testar
  • Os usuários podem ver o que os programas que usam o Buttplug fazem antes de realmente gastar dinheiro em um brinquedo

Portanto, é uma vitória para ambos os lados da comunidade

O senhor precisa levar em consideração algum risco à saúde em seu projeto? Um bug pode causar danos físicos a alguém?

Certamente, e isso é algo de que tento estar ciente. Tento oferecer suporte apenas a brinquedos que não representem um perigo claro para os usuários, portanto, embora não haja problema com vibradores e masturbadores, tentamos ficar longe de coisas como colares de choque, eletroestimulação etc. Também estou trabalhando em configurações que permitam que os usuários definam máximos para a saída do brinquedo, para que possam dimensionar os recursos de acordo com suas próprias necessidades.

É também por isso que a biblioteca é de código-fonte aberto, portanto, se as pessoas acharem que não podem confiar em algo, elas são mais do que bem-vindas para ver o interior ou me perguntar. No entanto, mesmo com o projeto sendo de código aberto, também sou extremamente cuidadoso ao aceitar quaisquer PRs e exijo uma grande quantidade de verificação antes. Temos muitas pessoas que realmente querem ajudar na biblioteca, mas nunca a usaram ou, pior ainda, dizem “Ah, sim, eu gostaria de aprender [insert programming language here] contribuindo” e eu sempre tenho que perguntar: “O senhor confia que o código que acabou de aprender estará no corpo das pessoas”? Eu realmente gostaria que mais pessoas dissessem “não” a essa pergunta, heh.

Dito isso, não há muito que eu possa fazer, porque os usuários farão o que quiserem com o sistema, então adiciono as proteções que posso, faço auditoria de segurança e tento torná-lo tão configurável quanto os usuários precisam para que eles também se sintam seguros.

Como o projeto cresceu desde o início? Qual é a presença da comunidade?

O projeto deu origem a outros projetos (https://iostindex.com é administrado por alguém que também trabalha com o Buttplug, por exemplo, e há todo o material sobre o https://awesome.buttplug.io(muitos com suas próprias comunidades), ela tem um servidor discord com milhares de usuários, e já ministrei workshops ao vivo nele. É difícil ter uma ideia exata do tamanho de tudo isso atualmente, porque há muita amplitude e também porque não tenho visibilidade de tudo isso. Como é de código aberto e gratuito, e eu não faço muito controle, às vezes ele aparece em lugares que eu não esperava, ou sou marcado em discussões em lugares que eu nem sabia que existiam.

Como é o seu dia de trabalho típico?

Inimaginavelmente entediante. A mesma engenharia da maioria dos lugares, mas com um contexto diferente. Normalmente, estou ajustando estruturas de dados ou resolvendo problemas de experiência do usuário ou qualquer outra coisa, tudo isso cercado por brinquedos sexuais que estão acumulando poeira ou que só são ativados para executar testes de fumaça antes dos lançamentos.

Os dias divertidos são aqueles em que decido fazer algo bobo com toda a porcaria que construí. Por exemplo, na semana passada, fiz um mod Elden Ring rápido para fazer um brinquedo vibrar sempre que o jogo faz o controle vibrar. A tecnologia não era muito avançada (há um artigo explicativo aqui), mas observar a reação nas mídias sociais é divertido, e acabo participando de conversas que são surpreendentemente positivas na maioria das vezes.

Existe algum estigma em contar a amigos, familiares e conhecidos que o senhor trabalha com tecnologia de brinquedos para adultos? Há alguma hesitação em dizer às pessoas no que o senhor trabalha?

Para mim, pessoalmente, não. Trabalho com tecnologia sexual desde 2004 e tenho usado meu nome e identidade reais durante todo esse tempo. Embora isso tenha causado dificuldades em alguns lugares no passado, de modo geral, proporcionou um nível extra de confiança para mim. As pessoas sabem quem eu sou, sabem de onde vem o projeto e eu tenho o privilégio de poder compartilhar isso, o que é raro nesse tipo de tecnologia. Há muitos autores de software de tecnologia sexual por aí que são obrigados a permanecer anônimos por vários motivos, e isso é bom e compreensível, mas eu queria realmente estar lá fora e disponível sobre esse tópico quando vi que tinha a chance, e isso realmente valeu a pena.
Dito isso, não é algo que vem de graça. Tenho que passar muito tempo “curando minha marca”, por falta de um termo mais humano. É preciso pensar muito para apresentar o projeto como ético e positivo em relação ao sexo, tanto que tenho que uma seção inteira do nosso guia de desenvolvimento dedicada a isso. Como isso também está em meu currículo/cv/LinkedIn/etc, tenho que pensar constantemente em qual é a perspectiva externa do projeto e tentar manter a forma de que isso seja algo que eu queira.

Fim da entrevista

Há algo realmente interessante na criação de experiências hápticas. Sempre confiei muito na aparência de algo, mas saber quando o senhor criou uma ótima experiência háptica deve ser incrivelmente difícil. Depois, acrescente o número de dispositivos aos quais o senhor deseja dar suporte, as preferências do usuário, o número de fornecedores e o estigma que o trabalho às vezes traz. Muito obrigado a Kyle por compartilhar sua perspectiva e experiência!