Um milionésimo jogo de tiro do zero: um caminho independente para desenvolvedores

Nos últimos cinco anos, tenho gerenciado programas educacionais na indústria de jogos na Escola Superior de Informática Empresarial da Escola Superior de Economia . Realizamos muitos eventos gratuitos com palestrantes interessantes, reunindo uma audiência através do Leader-ID. Em uma das últimas reuniões, outra história interessante foi ouvida, onde várias pessoas com idéias semelhantes lançaram um jogo de lançamento que arrecadou mais de 200 mil dólares.

A história é boa porque, além do final feliz, também descreve grandes falhas, graças às quais é adquirida uma experiência inestimável. E o mais importante - os caras estão felizes em compartilhar todos os detalhes e a lista de rake que eles coletaram nessa longa jornada.


Conheça Dmitry Svetlov. Por mais de 10 anos, ele dirige seu próprio estúdio de visualização arquitetônica - 3Dmode. Em algum momento, quando as coisas já estavam indo bem na empresa, ele precisava conquistar novos patamares e decidiu voltar à sua paixão de infância - a criação de jogos.

Nos três anos seguintes, ele, juntamente com um amigo, se dedicou ao desenvolvimento de um jogo de tiro de cima para baixo baseado em navegador. Eles trabalhavam principalmente à noite. No ano passado, um amigo debruçou-se sobre o código o tempo todo. Mas o projeto, como resultado, não foi lançado. Em seguida, uma segunda tentativa seguiu - o atirador VR Sacralith: a história do arqueiro - e acabou sendo bem-sucedida.


Abaixo está uma releitura da palestra de Dmitry, na qual ele contou muitos detalhes interessantes e observou cinco principais obstáculos que a equipe teve que enfrentar no caminho para um lançamento bem-sucedido.

Otimismo


Parece estranho, mas, de fato, ele se tornou o principal motivo do fracasso do primeiro projeto. Quando Dmitry, junto com seu amigo programador, começou a fazer um jogo de tiro de cima para baixo baseado em navegador, eles não tinham dúvida de que tudo daria certo.


Mas, apesar da rica experiência em trabalhar com gráficos 3D e da experiência de um amigo-programador, os caras não conseguiram lançar o jogo. A crença no sucesso os cegou.

Se você olhar para trás, poderá ver quantas imagens de "pessoas confiantes representam claramente o objetivo final e atingiram alturas sem precedentes". Tais personagens são replicados incansavelmente no espaço da mídia, promovendo uma idéia simples: "o principal é acreditar, e tudo vai dar certo". No entanto, há uma falha significativa nessa abordagem.




Esquema de desenvolvimento de competências O diagrama acima indica os estágios pelos quais cada especialista passa. Obviamente, a maioria daqueles que acreditam cegamente no sucesso estão no primeiro estágio. Mas a realidade é que as pessoas que alcançam resultados não são tão talentosas quanto trabalhadoras. Mas isso também não é a principal coisa.


Para criar um projeto, você precisa ser capaz de fazer projetos. Era exatamente o entendimento de como "iniciar", como "criar" e como "concluir" um projeto que não era suficiente para lançar seu primeiro jogo.

Pessimismo saudável é exatamente o que vem com a experiência. E não se trata de fé na própria força, mas de cautela e prudência banais. “Iniciante”, saindo de casa, levará um jogador com ele, enquanto “profissional” pegará um guarda-chuva, pílulas para dor de cabeça e, possivelmente, uma armadura.

Expectativas irrealistas


Ao iniciar um projeto, você está disponibilizando uma certa quantidade de tempo e recursos para o desenvolvimento, além de representar possíveis receitas e despesas . É bom quando as expectativas e os números reais estão próximos, mas para a maioria dos desenvolvedores independentes, isso está longe da primeira vez. Quando as pessoas estavam falando sobre a morte do flash e a extinção da era dos jogos de navegador, elas ainda acreditavam em um sucesso estonteante.

Havia algo semelhante com Sacralith. Um dos principais participantes, mesmo quando lhe foram mostradas as métricas atuais, acreditava cegamente que o projeto traria milhões de dólares. E ele finalmente trouxe milhões, mas rublos. Por causa disso, ele deixou o time.

Receitas da Sacralith


Para muitos, essa é a parte mais interessante da história.


Receita no Steam

Analisando esses números, vale lembrar que apenas metade desse valor chegará até você. O Steam deixará 30%, IVA 5%, então teremos controle de moeda e vários outros impostos.


Receitas na loja Oculus As

explosões nos gráficos são vendas organizadas por nós com descontos de 35 a 50%. E na PS Store, as coisas são ainda piores - não há como vender nada sem promoção. Como resultado, atualmente, em todos os sites, foram vendidas cerca de 12 mil cópias.

Início dos custos de desenvolvimento e projeto


O desenvolvimento de Sacralith: The Archer`s Tale começou em 2007. Ao mesmo tempo, Dmitry fez um curso profissional de reciclagem " Game Project Management " na Escola Superior de Economia, Escola Superior de Economia, porque em algum momento ele percebeu que era necessário começar com a administração.

Os custos para todo o projeto foram os seguintes:


Orçamento de desenvolvimento O

cálculo é muito aproximado. Se Dmitry pagasse um salário a si mesmo no valor de pelo menos 150 mil rublos. por mês, o custo total de desenvolvimento aumentaria em mais de três milhões.

Uma variedade de técnicas tem sido usada para otimizar custos. Por exemplo, para gravar animação facial, a empresa fabricou seu capacete, que custou apenas 70 € (o original custa 1800 €).


Um scanner de rosto especial também foi montado (custa 80.000 rublos). Anteriormente, a digitalização de um personagem no estúdio custava 30.000 rublos.


Exemplos de rostos de caracteres

Tempo e problemas com seu cálculo


No exemplo do trabalho de seu estúdio 3Dmode, Dmitry falou sobre planejamento. Nos primeiros anos de trabalho, o estúdio geralmente não se mantinha atualizado. Dmitry decidiu realizar um estudo interno e introduziu um sistema de rastreamento de tempo no qual as tarefas eram divididas em categorias.

Inicialmente, o processo de avaliação do tempo necessário foi o seguinte:


Após analisar os custos em tempo real, o circuito começou a ficar assim:


O tempo real de produção já era de 12 dias.

Não levou em consideração o tempo de "mudanças internas", as expectativas dos comentários dos clientes. Houve um coeficiente de x1,2 para o seguro contra situações imprevistas, por exemplo: um especialista importante adoeceu, a renderização caiu, o servidor foi cortado ...

E tudo isso aconteceu com tarefas previamente conhecidas e cumpridas. No desenvolvimento de jogos, todas as tarefas eram novas. Por exemplo, durante a gravação das animações em movimento do monge para Sacralith, os caras colaboraram com o estúdio Pilot (esta é a empresa que criou os personagens populares Hryun e Stepan). À primeira vista, tudo era natural, mas após a renderização final, a cena parecia de alguma forma antinatural. Durante muito tempo eles não conseguiram entender o porquê. Após duas semanas de pesquisa, o motivo foi encontrado. Aconteceu que não havia problemas com a animação do corpo, mas a coisa toda era a aparência não natural do herói.

A equipe teve que desenvolver urgentemente um sistema de olhar processual do personagem. Dependendo da situação, o herói pode olhar claramente para a câmera, para os principais pontos de interesse, ou simplesmente abaixar o olhar. Ninguém pensou que levaria mais um mês de desenvolvimento. E havia muitos desses "ninharias" a caminho do lançamento.

Entropia e planejamento neuroticismo


O planejamento é a ferramenta mais importante para trabalhar com projetos complexos. Mas o valor do plano em condições de total incerteza e imprevisibilidade tende a zero. É muito mais importante ver claramente o seu destino do que seguir cuidadosamente uma rota previamente traçada. Se cada participante do processo entende o que está fazendo, por que está fazendo e quando precisa finalizá-lo, o desenvolvimento avança.


Ao criar o Sacralith, Dmitry substituiu o plano por um esquema condicional que consistia em objetivos simples. Por exemplo, o objetivo final era lançar em fevereiro e 5.000 vendas a um preço de US $ 20 no início.


O esquema do objetivo

O próximo princípio que o estúdio usou foi o princípio do MVP (produto mínimo viável), ou seja, criando um produto minimamente viável em todas as fases do desenvolvimento. Com essa abordagem, você cria um disco de trabalho, que aprimora ainda mais todos os principais indicadores.

Na figura abaixo, você pode ver que, já no primeiro estágio, uma máquina viável deve funcionar, que posteriormente "cresce" com detalhes.


No exemplo de Sacralith, a equipe identificou a seguinte pirâmide de desenvolvimento, composta por características, vantagens e valores:

  • Características (características do jogo): tiro com arco, sistema de bombeamento, inimigos e cenas cortadas.
  • Vantagens (em relação aos concorrentes): física das flechas e gráficos coloridos.
  • Valores (idéias principais): o simulador de arqueiro mais sangrento da Idade Média.

Depois de identificar esses componentes, você pode começar a trabalhar no MVP. É importante focar nos valores do projeto. Quanto melhor você os demonstrar em um estágio inicial de desenvolvimento, maiores serão as chances de sucesso do seu produto.


Você pode começar com os recursos, como mostrado na pirâmide superior esquerda, mas essa é uma opção ruim. A opção normal é quando criamos recursos que podem demonstrar valor (canto inferior esquerdo) e a melhor opção é quando pensamos em como demonstrar valor para nós (canto inferior direito).

Teimosia


Qualidade útil nos negócios, mas se estamos falando de desenvolvimento independente, às vezes isso atrapalha. Vamos dar uma olhada no exemplo da criação de animações de maquete para o Sacralith. Para gravá-los, você precisa de equipamentos e atores especiais que descrevam os movimentos de que você precisa.


Grave animação de maquete. Um dos atores da foto, o fundador do estúdio Pilot,

Dmitry, disse que estava tentando obter a máxima seriedade nos movimentos dos atores. E, apesar de todos os esforços, nos gestos dos atores, anotações de parentes para eles Khryun e Stepan. No entanto, foi essa natureza cômica dos personagens que permitiu aos desenvolvedores dar uma nova olhada no projeto.

Como resultado, o humor apareceu no jogo, os personagens se tornaram mais carismáticos. Sim, todas essas decisões apareceram espontaneamente, mas o produto final apenas se beneficiou dessas mudanças. Assim, em condições de recursos limitados, é importante acompanhar o fluxo e, às vezes, até mudar o destino. Obviamente, se você acredita que isso beneficiará o produto final.

Uma história semelhante foi com modelos de personagens. Ao contrário do esquema de desenvolvimento clássico, a equipe de Dmitry usou a abordagem exatamente oposta:

  1. os caras coletam um banco de dados de ativos prontos (sons, modelos 3D, ambiente) que estão disponíveis ou disponíveis para compra em uma loja especializada;
  2. com base nisso, projete os níveis e personagens;
  3. elaborar o script e finalizar a configuração (um estilo único de jogo).


Pipeline clássico (esquema de desenvolvimento)


Pipeline elaborado por Sacralith,

ou seja, o desenvolvimento não procedeu do plano e do cenário, mas o cenário foi adaptado aos modelos disponíveis e outros recursos. Essa abordagem economizou muito tempo e dinheiro; portanto, o produto final foi capaz de trazer lucro aos criadores.

Primeiras críticas: cebolas reais, mas todo mundo pensa de maneira diferente


O trabalho no produto não para após o lançamento do jogo na plataforma (Steam e outros). As primeiras revisões (especialmente negativas) devem ser percebidas adequadamente, tentando encontrar um núcleo racional. E mesmo que você tenha escrito apenas algumas palavras, pergunte ao autor o que exatamente o confundiu em seu produto.

Por exemplo, após o lançamento do Sacralith, os desenvolvedores receberam várias críticas irritadas sobre as cebolas irrealistas. Como resultou do diálogo com o usuário, o problema foi a localização da seta em relação ao eixo. No jogo, esse momento foi realizado historicamente verdadeiro, como na Idade Média. Mas nos arcos modernos, a “prateleira” da flecha fica à esquerda. Por causa disso, os usuários ficaram indignados, dizendo "os desenvolvedores nunca seguraram um arco em suas mãos!" Refazendo rapidamente esse detalhe, os caras imediatamente receberam um feedback positivo da platéia. Conseguimos transformar várias críticas negativas em positivas, o que resultou nas necessárias críticas positivas de 90%.



Roubo


Certamente, muitos de vocês temem que uma idéia brilhante seja roubada. Se você voltar ao início do artigo e se lembrar das palavras de Edison, entenderá que não deve ter medo disso. Pelo contrário, para melhorar e criar um produto mais bem-sucedido, é importante contar a todos sobre sua ideia, coletar cuidadosamente as críticas e melhorar o desenvolvimento.

Sumário


Espero que essa história e a experiência de Dmitry sejam úteis para aqueles que estão desenvolvendo seu projeto de jogo ou estão pensando seriamente sobre isso. O principal é superar sua autoconfiança, ouvir críticas e métricas reais.

Se você está interessado em assistir a sua performance ao vivo, onde um pouco mais de detalhes, é aqui .

All Articles