Joe Cassavaugh apresenta, em uma palestra publicada pela InfoQ, uma experiência que vai de seu trabalho como engenheiro de software à construção de um projeto individual em torno da série de jogos de quebra-cabeças Clutter. Cassavaugh afirma que a série ultrapassou US$ 6 milhões em vendas e lhe rendeu mais de US$ 2 milhões líquidos, e que ele estava se preparando para lançar o décimo nono jogo da franquia. No entanto, o valor da experiência não está apenas nos números, mas nos métodos que ele utilizou para transformar um único produto em uma atividade sustentável por anos.
A história começou depois que a empresa iWin interrompeu o desenvolvimento de um jogo no qual ele trabalhava. Sua futura parceira sugeriu que ele fizesse o jogo por conta própria, e ele desenvolveu um protótipo durante um fim de semana com base na ideia de combinar objetos semelhantes. Ele obteve da iWin os direitos de propriedade intelectual, com um acordo que concedia à empresa o direito de primeira recusa para publicar qualquer jogo novo durante dois anos. Em seguida, lançou o primeiro jogo Clutter em 2011.
O primeiro jogo não alcançou as expectativas que ele havia estabelecido; suas receitas chegaram a cerca de US$ 50 mil após 15 meses, em vez de um dos dois cenários que ele previa: menos de US$ 10 mil ou mais de US$ 100 mil. Ainda assim, ele utilizou a engine e as ferramentas existentes para construir a sequência em cerca de seis meses de desenvolvimento. A sequência rendeu aproximadamente US$ 50 mil e também ajudou a aumentar a receita acumulada do primeiro jogo. Foi então que Cassavaugh começou a tratar a série como um ativo que se acumula, e não como produtos separados.
O que realmente mudou?
Cassavaugh chamou esse efeito de “efeito franquia”. Cada novo lançamento atrai uma receita inicial, mas também reativa as vendas dos jogos anteriores. Ele afirma que os lançamentos nem sempre alcançam os mesmos resultados, mas que lançar um novo jogo mantém a série diante de seu público, o que o ajudou a acompanhar a contração do mercado de jogos para computador distribuídos por download.
A experiência também mostra os limites de responder às preferências do público. Quando o quarto jogo se afastou do estilo básico de Clutter e acrescentou minijogos, os jogadores não aceitaram a mudança como ele esperava. Em contrapartida, outras sequências tiveram resultados melhores porque apresentaram variações dentro da mecânica conhecida, em vez de substituí-la. Cassavaugh também utilizou histórias, imagens e citações para acrescentar personalidade aos quebra-cabeças e, depois, começou a solicitar diretamente o feedback dos jogadores.
Por que esta notícia é importante para os desenvolvedores?
A principal lição técnica da palestra é que a velocidade não veio de trabalhar mais horas, mas de reduzir o trabalho repetitivo. Depois de utilizar um framework interno que havia desenvolvido na iWin, Cassavaugh migrou gradualmente para a Unity e estima que sua produtividade aumentou de quatro a seis vezes em comparação com o ambiente anterior. No entanto, ele explica que a Unity também ampliou o escopo do que conseguia fazer e, por isso, nem todo aumento de capacidade se transformou diretamente em redução do tempo de desenvolvimento.
Depois disso, ele passou a depender de uma refatoração contínua. Criou uma classe básica para os minijogos, responsável por elementos compartilhados como a barra de menu, a navegação entre os jogos, o cronômetro e as janelas. Assim, pode adicionar um novo jogo sem reconstruir essas funções a cada vez. Ele também transferiu mais trabalho para arquivos de conteúdo e ferramentas automatizadas, em vez de escrever um novo código para cada quebra-cabeça.
Cassavaugh menciona um exemplo pequeno, mas significativo: modificar a forma de armazenar as configurações dos quebra-cabeças, utilizando mais de um par de chaves e valores na mesma linha, reduziu um trabalho que era repetido manualmente. Ele também automatizou a criação de conjuntos de imagens usando ferramentas como Batch e PaintShop Pro, depois que sua preparação costumava exigir cerca de três dias de trabalho repetitivo.
Equilibrando quantidade e capacidade de produção
Cada jogo inclui, segundo sua descrição, cerca de 1.800 quebra-cabeças em termos aparentes, mas o número prático está mais próximo de 900 ou 1.000 quebra-cabeças, porque grandes partes dependem da recombinação do conteúdo e da alteração dos conjuntos de imagens e das regras. A série oferece cerca de 200 quebra-cabeças baseados em citações ou parágrafos em cada lançamento. Essa distinção entre código e conteúdo permitiu ampliar o tamanho do jogo sem aumentar na mesma proporção o tamanho do sistema de software.
Ele também deu aos jogadores opções na forma de jogar, como pausar o cronômetro ou ajustar a velocidade de rotação dos elementos, mantendo as regras básicas do quebra-cabeça. Ele observa que aproximadamente metade de seus jogadores não utiliza o cronômetro, o que o levou a projetar a experiência para atender tanto quem busca um desafio quanto quem quer jogar tranquilamente.
A leitura editorial da certi.news
O que realmente mudou no caso de Clutter foi a transição de um jogo isolado para um pequeno sistema de produção administrado pela reutilização, pelo acúmulo de conteúdo e pela continuidade da relação com o público. Esta não é uma fórmula garantida para construir um projeto individual; os números apresentados por Cassavaugh dizem respeito à sua experiência e ao seu mercado, e seu sucesso também dependeu da perseverança ao longo dos anos e da existência de um público que retorna aos novos lançamentos.
A lição mais transferível para outros desenvolvedores é determinar o que deve permanecer constante e o que pode mudar: uma regra de jogo clara, uma estrutura técnica compartilhada e conteúdo renovado. As questões em aberto dizem respeito à possibilidade de repetir esse modelo em outros mercados e aos riscos de o projeto depender de uma única pessoa e de uma única franquia. Portanto, a palestra deve ser lida como um caso prático sobre gestão de escopo e produção, não como uma prova de que o trabalho individual geralmente supera as equipes de desenvolvimento.