GuildOps — gestão de guilda numa só app

O Discord guarda a conversa da noite. Não guarda, com fiabilidade, quem está na guilda, quem faltou ao raid de quinta e que peça saiu para quem. Quando essa informação vive em pins, em notas de officer e na memória de uma pessoa, a guilda parte no dia em que essa pessoa sai. GuildOps é a app da Battlehorns para essa camada: membros, eventos, loot e recursos, num sítio só.

Convém separar os nomes. Battlehorns em battlehorns.net é alojamento web para comunidades gaming — guildas, clãs e esports — e não a banda de metal. O GuildOps vive em guildmanager.battlehorns.net. Um é o site público que publicas por FTP. O outro é o painel interno. Não são a mesma página, e não precisam de ser.

O problema de usar só o Discord

O chat é bom a acordar pessoas e mau como arquivo. Procura «loot» num servidor com dois anos e recebes trezentas mensagens, metade a brincar. Procura a lista de membros e dependes de roles que ninguém actualizou desde a última temporada. Procura o calendário e encontras um evento do bot por cima de outro evento criado à mão.

Isso custa três coisas concretas.

• Recrutas não devem ler o histórico interno para perceber as regras de loot. Esse texto pertence ao site, em versão curta. O detalhe operacional não lhes pertence ainda.
• Officers discutem a mesma ausência três vezes porque não há um registo do evento, só mensagens de «hoje vim».
• Quem sai leva consigo o Notion, a folha de cálculo ou o canal escondido onde a verdade estava. A guilda recomeça do zero.

Não se trata de abandonar o Discord. Trata-se de lhe tirar o papel de fonte única. O chat avisa. O GuildOps regista. O site, no alojamento, mostra ao público só o que é público. Essa divisão está também no guia de web hosting para comunidades.

O que o GuildOps faz

O produto está descrito pela própria Battlehorns em quatro blocos: membros, eventos, loot e recursos. Não é um construtor de sites, não é um fórum e não substitui o alojamento. É o painel onde a guilda de MMO deixa de depender de mensagens soltas para essas quatro coisas.

Membros. A lista que importa é a de quem joga convosco, com que role e em que estado: trial, membro, officer, inactivo. Roles de Discord aproximam-se disto e falham quando alguém muda de classe e o role fica. No painel, a ficha é a referência. O Discord pode espelhar um anúncio; não deve ser o único sítio onde a ficha existe.

O que não promete. Não inventes, ao apresentá-lo à guilda, um importador automático de armory, um bot que faz tudo, ou um sistema de DKP com fórmulas que a página do produto não descreve. Se a tua guilda precisa dessas peças no primeiro dia, confirma no próprio GuildOps o que está disponível antes de o venderes internamente como «o addon completo». O núcleo — pessoas, eventos, loot, recursos — já resolve o caos habitual.

Eventos e assiduidade

Um evento tem data, hora, tipo (raid, scrim, treino, reunião de officers) e uma lista de quem ficou de ir. No Discord isso é uma reacção a um emoji. Funciona até ao dia em que o emoji é usado para outra coisa, ou em que o evento é editado e as reacções ficam no sítio errado.

No GuildOps o evento é o registo. A prática que vale a pena, mesmo simples:

1. Criar o evento com o horário no fuso que a guilda usa de verdade, escrito por extenso na primeira vez («22h de Lisboa»).
2. Marcar quem confirmou e quem faltou depois da sessão, no próprio dia. No dia seguinte já ninguém se lembra.
3. Não abrir um debate novo no chat para cada falta. O registo responde. O chat só avisa de mudanças de hora.

Assiduidade deixa de ser uma discussão de humor e passa a ser uma contagem. Isso importa quando há mais candidatos do que vagas, ou quando um trial diz que «veio sempre» e o calendário diz outra coisa. Três meses de eventos preenchidos convencem mais do que um parágrafo zangado.

Loot e recursos

Loot sem registo gera as mesmas discussões em todos os MMOs: quem ficou com a peça, se era prioridade de main ou de alt, se o recurso de guilda foi gasto num reparo ou num craft. O chat guarda a versão de quem falou por último.

Um registo mínimo, por evento, chega: item ou recurso, quem recebeu, em que regra (necessidade, prioridade, sorteio, banco da guilda). Não precisas de publicar essa tabela no site. Precisas que dois officers vejam a mesma linha uma semana depois. Recursos — ouro de guilda, materiais, créditos de temporada — seguem a mesma lógica: entrada, saída, saldo. Se isso está numa folha que só uma pessoa edita, não está na guilda.

O site público pode ter três frases da política («loot de progressão vai a quem o usa no próximo raid; alt não compete com main»). O livro de razão fica no GuildOps. Candidatos lêem a política em recrutamento e painel de membros. Membros vêem o detalhe depois de entrar.

Ligação ao site Battlehorns

O site e o GuildOps não se fundem num login só porque ambos dizem Battlehorns. Liga-os de propósito, com poucos URLs.

• No site, um botão «Área de membros» que aponta para o GuildOps, visível para quem já entrou. Quem ainda é candidato vê «Candidatar» e não o painel.
• No GuildOps, a descrição da guilda pode repetir o endereço do site (https:// incluído), para ninguém partilhar um convite de Discord como se fosse a morada oficial.
• Não copies o roster completo para um HTML que ficas de actualizar à mão. Ou o roster público é uma página curta e revista, ou não está no site. Duas listas desencontradas são piores do que uma.

O alojamento entra quando queres a página que o Google e a liga conseguem abrir: regras, horários, candidatura em PHP se precisares de a gravar numa base MariaDB. Isso é o plano em hosting, explicado em alojamento gratuito e montado no tutorial. Se ainda estás a decidir entre escrever esse site ou usar um construtor, lê hosting versus construtores e a comparação com Guildtag, Shivtr e Guildwork.

Primeiros passos

Não migres dois anos de pins no primeiro dia. A sequência que cola é esta.

1. Abre o GuildOps e cria a guilda com o nome que já usam no jogo, não com uma abreviatura que só os officers percebem.
2. Mete os membros activos, com role. Inactivos ficam marcados como tal, ou não entram. Uma lista inflacionada mente.
3. Cria o próximo evento real, não um evento de teste chamado «asdf».
4. Depois desse evento, regista loot ou recursos que tenham saído. Uma linha verdadeira vale mais do que um sistema vazio.
5. No site, quando existir, liga o botão. Até lá, o Discord anuncia o painel com um link fixo, não com um print.

Se o que falta é a página pública, o registo no alojamento é outro passo, não um pré-requisito do GuildOps. Podes operar a guilda no painel e publicar o site na semana seguinte. O erro é achar que um substitui o outro.

Nesta série: alojamento gratuito para guildas, hosting ou construtor, guia de web hosting, GuildOps, tutorial do site, comparação de plataformas e recrutamento que converte.