Por que escrever seu próprio mecanismo de jogo?

Em dezembro do ano passado, na conferência Games Gathering 2017, fizemos um relatório no qual discutimos se as empresas que trabalham na indústria de jogos precisam escrever seus próprios mecanismos.

Unidade diante de uma variedade de mecanismos de jogos

Por que no mundo moderno, em que existem gigantes como a Unity, fazem algo próprio, escrevem seus próprios mecanismos de jogo?

Aqui está um slide com dados da Unity Technologies sobre o uso de vários mecanismos de jogos em 2017. No próximo ano, a situação, como você entende, mudará. O que nos interessa aqui é 41%, ou seja, motores de nosso próprio projeto. Se você observar as 5 maiores empresas representadas na conferência, cada uma delas terá seu próprio mecanismo. Acontece que na maioria das empresas que representam a indústria de jogos, algum tipo de desenvolvimento interno é usado. Nem sempre esta é a decisão mais razoável do mundo, mas é.

De quais tecnologias básicas as empresas podem pensar em desenvolver um projeto de jogo?

Exército das Sete Nações

A pirâmide que você vê no slide pode ser continuada para cima e para baixo. Absolutamente limita você. Inferior - o sistema operacional, ainda mais baixo - alguma tecnologia básica. Acima, há complementos sobre mecanismos, um kit de ferramentas pronto para uso que vem com jogos, como as ferramentas Neverwinter Nights. O que quer que você faça, de um jeito ou de outro, você se encontra dentro dessa coisa.

Suponha que eu queira estar no segundo nível desta pirâmide abaixo. No entanto, todos os caminhos acabam levando ao topo da pirâmide. Usaremos algo do existente, mas é muito importante que possamos ver no canto superior esquerdo do nível superior da pirâmide, ou seja, motores de nosso próprio projeto.

Agora analisamos o tempo, esforço e dinheiro necessários para desenvolver o jogo.

Voltar ao básico

Se todo o gráfico de pizza mostrado no slide for um jogo, o mecanismo será o setor azul. Em um mundo ideal, ao desenvolver um jogo, você pode retirar esse setor azul e colocar lá vermelho, amarelo ou verde. Você pode alterar um “U” grande para outro “U” grande ou pegar um pequeno “x”, e o que você escolher funcionará ali. Na realidade, não é assim, mas devemos nos esforçar para isso. Uma imagem semelhante, quando se trata de projetos reais, é constantemente observada na indústria de jogos. Também acontece que o diagrama inteiro está ocupado pelo mecanismo, mas isso é verdade apenas para alguns produtos de demonstração.

Nesse caso, dinheiro, tempo e tudo o mais são distribuídos dessa maneira. Faça o que fizer, você precisa lidar com tudo o que estiver na área verde do diagrama. Não muda de mecanismo para mecanismo. Como resultado, se você tiver recursos suficientes para suportar todo o processo de trabalho em um projeto de jogo, o desenvolvimento do mecanismo não será tão caro. No entanto, se alguém da empresa começar a falar sobre o desenvolvimento de seu próprio mecanismo, provavelmente encontrará um certo conjunto de objeções. Considere-os.

Mítico homem-mês

Suponha que você decida criar seu próprio mecanismo e informe ao tomador de decisão sobre isso. Em resposta, você ouvirá a mesma coisa que pode ser vista no slide: "Você fará isso por um longo tempo, é muito arriscado, é irracional, não nos ajudará a alcançar nossos objetivos". O que pode ser respondido? O ponto aqui é que todas essas objeções, exceto a última, não resistem às críticas.

Longo desenvolvimento do motor? Mas se o desenvolvimento com seu próprio mecanismo for mais rápido, isso não será um argumento. Talvez, em geral, ninguém saiba o que é "racional". Portanto, todas essas objeções são muito subjetivas.

O último ponto sobre se o seu mecanismo contribui para o alcance de metas é muito importante. Se seu objetivo é ganhar graças a uma concessão do Unreal 4, provavelmente você não precisa criar seu próprio mecanismo, porque isso não leva a esse objetivo. Se você tem um objetivo, dentro da estrutura da qual precisa fazer algo em determinadas tecnologias, não precisa escrever seu próprio mecanismo - precisa aceitar o que é. Mas nem sempre é possível usar os motores prontos com eficiência. Por que, mesmo assim, escreva seu próprio mecanismo?

13 razões pelas quais

Quando você pode precisar de seu próprio mecanismo? Vamos analisar este slide por pontos:

• Time to Market - tempo de mercado para um produto. Isso é realmente sério. Metade dos motores que agora são usados ​​em grandes empresas foi desenvolvida precisamente porque, no momento em que essa empresa precisava ocupar rapidamente um nicho, o desenvolvimento de seu próprio era mais rápido do que pegar outra coisa e dominá-lo.
  

Aqui está uma história para você. Uma empresa tinha uma tarefa para programadores no site, com a seguinte aparência: “Pessoal, se você quiser trabalhar conosco, escreva Asteroids, que deve ser executado na plataforma Android sem usar bibliotecas externas. Acreditamos que 8 horas são suficientes para você. Chegou a hora. Então o tempo foi aumentado para 12 horas. Talvez pareça engraçado. No começo, assisti a isso, de fora, depois olhei para esta empresa e pedi que eu contasse o que eles enviaram na forma de uma resposta a essa tarefa. Como se viu, mais de duzentos programas passaram na seleção, ou seja, esses programas foram lançados e funcionaram. Isso significa que, se você deseja publicar repentinamente "Asteróides" para Android, existem pelo menos 200 pessoas que podem fazer isso em 8 horas. Não estou dizendo que possa ser vendido. Mas contei essa história ao fato de que, com muita frequência, o mecanismo é o Time to Market. Digamos, simplesmente porque você tem necessidades tão pequenas que estudará a documentação para o mesmo Unreal por mais tempo do que apenas pegar e criar a sua.

• O Senhor da plataforma é o mestre da plataforma. Existem plataformas para as quais não existem ferramentas prontas. Por exemplo, STB, decodificador (receptor de televisão digital) - uma caixa para televisão a cabo, que está sobre a mesa em cada terceiro americano.
  

A Warner possui 120 milhões de usuários desse serviço. Se você escrever um software lá, incluindo jogos, terá um dólar da caixa. São 120 milhões de dólares por ano. Ao mesmo tempo, ninguém mais pode escrever para isso, exceto você. Como não há DirectX, não há nada. Se você pode escrever programas para o STB, então você é o mestre da plataforma, possui esses cento e vinte milhões de dólares por ano. Por que não escrever seu próprio mecanismo?

É claro que agora estamos falando mais sobre algo como brinquedos de console, mas, em algumas situações, isso pode ser necessário. Aqui, por exemplo, máquinas caça-níqueis. Claro, agora, principalmente computadores. Mas temos diante de nós um dispositivo de ferro separado e um mercado enorme, para o qual é bem possível escrever algo próprio.

Podemos dizer que estamos interessados ​​em telefones, mas estamos falando de milhões de dólares. Por que não escrever para outros dispositivos? Como resultado, existem razões absolutamente claras para fazer isso.
Ou, por exemplo, temos os mais recentes relógios inteligentes. O SDK ainda não chegou a eles, ninguém entende o que fazer com eles e, se você puder escrever por si mesmo um produto de qualidade, você ganha um dólar com cada dispositivo. Se eles serão vendidos dois milhões - você receberá dois milhões de dólares. Escrever isso não é difícil, mas para isso você precisa criar seu próprio mecanismo, porque não há estranhos, e os fabricantes desses dispositivos não criarão mecanismos públicos para o desenvolvimento deles.

• Dispositivos fracos, mas orgulhosos, são dispositivos pequenos, mas orgulhosos. Se você cria jogos para celulares, coleciona pelo menos algumas estatísticas, então sabe que com o hardware dos dispositivos Apple tudo é mais ou menos normal, mas com a plataforma Android é apenas um desastre.
  

Metade dos dispositivos no mercado são baseados no chipset ARM Mali-400; qualquer telefone econômico é o Mali-400. E se você é pago pelo que faz com os aplicativos de telefone, escreva para esses dispositivos pequenos, mas orgulhosos, que ainda não sairão do mercado e o deixarão em breve.

Além disso, no caso do iPhone, você pode fazer pelo menos algumas apostas em andamento. Por exemplo, espera-se que a Unreal funcione no iPhone 10, embora até tudo isso seja lembrado, já haverá alguns iPhone 12, 15 ou 17. Mas, no caso do mundo em geral, é mais difícil progredir no curto prazo. Porque a atualização dos dispositivos é muito lenta.

Se você quer uma imagem competitiva e se é muito importante, não opta por dispositivos de baixa energia. Mas você deve ter em mente que todos os mecanismos modernos não diminuem muito. Se você não deseja uma imagem competitiva, leve em consideração os recursos de telefones fracos. Portanto, se você estiver em uma situação em que não está interessado nos dispositivos mais rápidos, por exemplo, você é o único distribuidor em algum lugar de Portugal ou do Brasil, precisará pensar nisso.

• Idioma próprio para idéias próprias - idiomas próprios para idéias próprias. Quando você mesmo faz o mecanismo, pode usar esse conceito. O fato é que o principal problema de nossa indústria é que o domínio do designer de jogos é a filologia. Ele pensa na linguagem comum. Ele não pode fazer mais nada. Mas o programador pensa no domínio da programação e há uma lacuna entre eles. Como resultado, uma certa iteração, que deve ser repetida continuamente, custa, por exemplo, dois dólares. E você gasta constantemente esse dinheiro.
  

Motores padrão tentam cobrir todos. De fato, vemos como eles estão tentando fazer transformações naturais de domínio de linguagem para linguagem e de espaço para espaço. Mas para todos. E você tem suas próprias idéias e pode implementá-las diretamente, criando seu próprio conjunto de ferramentas. É claro que tudo isso, na forma de plug-ins, pode ser feito sobre os mecanismos existentes, mas o mecanismo dele abre possibilidades completamente diferentes.

• Mecânica Exclusiva = Mecanismos Exclusivos - Mecânica Exclusiva = Mecanismos Exclusivos. Meus amigos escreveram Minecraft no décimo quinto ano usando o Unity. Houve algum motivo para fazer tudo isso - uma pergunta em aberto. Mas eles escolheram o motor e começaram a trabalhar. No entanto, o motor, obviamente, os estava incomodando muito. Foi difícil para eles. Eles tiveram iterações muito longas. Depois de consultá-los, eles escreveram, literalmente em três dias, sua própria renderização. Além disso, o restante do código responsável, digamos, por construir o mundo, é claro, não desapareceu. Tudo deixou de estar em C #, deixou de estar em Unity. E o trabalho começou a ferver. Não sei se eles conseguiram ganhar dinheiro com isso, mas a principal conclusão dessa história é que eles inicialmente não precisavam usar o Unity.
  

Ou seja, há um grande número de mecânicos para os quais os motores padrão, grandes e universais não são adequados simplesmente porque são projetados para tudo. Portanto, se você criar algo especial amanhã, algum tipo de mecanismo complexo de voxel, trabalhar com mecanismos padrão será inconveniente para você. Ou seja, existem mecanismos para os quais os motores padrão não são adequados e que são bastante simples de implementar independentemente.

• O jogo não é uma renderização - o jogo é tudo o resto - o jogo não é uma renderização, o jogo é tudo o resto. Já falamos sobre isso. Se o seu único problema era desenhar algo ou, digamos, usar o som para criar um jogo multiplataforma, você poderia ver histórias semelhantes na pirâmide discutidas anteriormente. Se você disser: "Quero tocar som em três plataformas", não será necessário um "U" grande para isso - um pequeno "c" será suficiente.
  

Consideramos as razões para o desenvolvimento de nosso próprio mecanismo. Vamos agora pensar nas vantagens que a empresa oferece com o desenvolvimento de seu próprio mecanismo.

As vantagens de desenvolver seu próprio mecanismo

Considere as vantagens de desenvolver seu próprio mecanismo, com base nas principais idéias apresentadas no slide:

• A compra costuma ser melhor do que a hipoteca - a compra é preferível às hipotecas. Desenvolvimento de jogos é dinheiro de qualquer maneira. Existem maneiras de monetizar, usando qual compra não é apenas melhor do que uma hipoteca, mas essa é apenas a única opção.
  

Se alguém trabalhou em tecnologias móveis, você entende tudo. Se a caixa do mecanismo disser: "10% dos royalties", isso é categoricamente inaceitável, você não ganhará muito. Você pode ter um lucro de cem por cento, mas trabalha com 2. Ou seja, se você possui royalties, essa é uma razão puramente econômica para abandonar o mecanismo. Mas devo dizer que três, ou melhor, dois dos motores mais populares no momento, isso é apenas uma questão de deduções. Ou seja, essa opção desaparece imediatamente.

• A especificidade é melhor que a universalidade a longo prazo - a longa distância, ferramentas especializadas são sempre melhores que as universais. Obviamente, a universalidade é sempre mais lenta, é menos produtiva e menos específica que as coisas especializadas. Um mecanismo escrito para uma tarefa específica irá lidar com isso melhor e mais rapidamente do que uma ferramenta universal. A longa distância, ferramentas especiais são muito mais lucrativas que as universais.
  
• Ferramentas e pipelines são desenvolvidos dentro de - pipelines e ferramentas de desenvolvimento criadas internamente. Qualquer mecanismo inventado por pessoas fora da sua empresa é guiado por várias coisas. A primeira são as melhores práticas. Ou seja, o mecanismo de outra empresa não se concentra em como seu artista pinta, mas em como os artistas pintam, ideal do ponto de vista deles. É possível que seus artistas pintem de maneira diferente. Eles têm seu próprio pipeline e têm sucesso.
  

Você tem duas opções: treine-as novamente como deveria, do ponto de vista das melhores práticas, ou use as suas. Existem exemplos simples. Suponha que você diga: "Importamos modelos 3D". Você não sabe o que há do outro lado. Portanto, você precisa de um formato intermediário. Formato intermediário que seja FBX. FBX falha todos que fazem isso sabem. E você não tem para onde ir, porque não sabe o que será feito lá, não gravará plug-ins para 450 ferramentas de modelagem 3D.

Quando você trabalha na sua empresa, pode implementar o mesmo pipeline que você já possui e colocar em cima do que está fazendo. De fato, isso é muito importante. O fato é que tudo isso tem a ver com tempo de desenvolvimento e, como conseqüência, com custo. Portanto, quando você se desenvolve em casa, pode descartar o pipeline que já possui. Caso contrário, você terá um documento chamado "A regra para fazer upload de modelos 3D e criar materiais para artistas" que será mais do que um documento de design, o que está errado.

• Tempo de reação - tempo de reação. Estamos falando do tempo de reação do fabricante do motor às suas solicitações, da possibilidade de equipar o motor com novas funcionalidades e da pesquisa operacional de novas tecnologias.
  

Digamos, no próximo escritório há pessoas que fabricam o motor. Todo mundo que tentou consertar o bug no mecanismo universal, ou seja, escrever Unity ou Epic no rastreador, sabe que é melhor nem começar. E se os desenvolvedores estiverem no próximo escritório, você poderá entrar em contato com eles e resolver o problema em 15 minutos.

O mesmo se aplica à proposta de nova funcionalidade, se você tiver o direito de fazê-lo. O estudo de novas tecnologias também é simplificado usando nossos próprios mecanismos.
Suponha que o seu programador foi a uma conferência e ouviu uma palestra sobre algo novo lá. Ele imediatamente tentou, você teve uma idéia sobre esse novo e sabe se precisa ou não. Você pode reagir diretamente para tentar algo interessante do mundo da ciência. E isso, a propósito, significa que a empresa pode ter uma pessoa que será chamada de “pesquisadora”. Ao mesmo tempo, você pode fazer pesquisas sobre o mesmo Unreal, já que ele vem na fonte.

• Desempenho - desempenho. A indústria de jogos é sempre produtividade. A primeira abordagem para alcançar alto desempenho é usar soluções personalizadas. Quanto mais específicas as soluções, mais produtivas elas são. A segunda abordagem - também, a propósito, querida, é a otimização de motores prontos. Como exatamente isso vai parecer - é altamente dependente desses mecanismos.
  

Desenvolver seu próprio mecanismo não é apenas uma vantagem. Estes também são riscos. Considere-os.

Riscos associados ao desenvolvimento de seu próprio mecanismo

Considere os riscos que acompanham o desenvolvimento e o uso de nossos próprios motores:

• Tempo de desenvolvimento - tempo de desenvolvimento. Esse conceito se cruza com o que falamos quando entrar no mercado. O desenvolvimento do motor pode ser muito longo e rápido o suficiente. Mas o tempo de desenvolvimento do mecanismo, em qualquer caso, contribui para o tempo geral de desenvolvimento do projeto. Portanto, isso também é um risco. Por exemplo, conheço equipes nas quais o tempo de desenvolvimento do mecanismo tende ao infinito.
  
• Caixas terminais de bloqueio de fornecedor - caixas terminais de ligação ao fornecedor. Isso se aplica não apenas às grandes empresas, mas também às pequenas. Digamos que você contratou Vasya, ele escreveu o motor, depois se apaixonou, se despediu de você e ninguém entende o que ele escreveu. Como resultado, você tem um bloqueio de fornecedor pior que o Google. Porque você ainda pode escrever uma carta para o Google, embora eles não atendam, mas aqui com a saída do programador tudo acabou. O resultado é perda de tempo de desenvolvimento e outras conseqüências desagradáveis. Você deve poder evitar esses riscos.
  
• Reinvente a roda - a invenção da roda. O ponto é que vivemos em um mundo em que você ainda inventa bicicletas. Ao desenvolver o motor, verifica-se que a fábrica de bicicletas é transferida do código do jogo para o código do motor, embora elas não pertençam a esse local.
  
• Ecossistema fechado - um ecossistema fechado.Tudo o que é feito dentro da empresa pertence a esta empresa. Conheço um monte de empresas que têm algo como sua própria linguagem de script. Pode ser algum tipo de XScript que funciona apenas como parte de sua solução.
  

Os programadores que conhecem essa tecnologia, de fato, não podem fazer mais nada. Isso pode ser considerado um dos fatores que ajudam a reter os funcionários. Portanto, a resposta para a questão de saber se é boa ou ruim, se o uso de suas próprias tecnologias é um risco depende da situação específica. Por exemplo, tentamos não usar os conceitos de nossa própria invenção. Por exemplo, conheço uma empresa que possui Lua, fortemente tipada, com sintaxe Pascal. Pode ser dominado, mas esse conhecimento está morto, como o grego. Tentamos tanto não agir.

A questão principal da vida, o universo e tudo o mais

Considere uma questão muito importante. Que recurso é necessário principalmente para desenvolver seu próprio mecanismo? Um recurso sem o qual não faz sentido pensar em criar ou não seu próprio mecanismo. A resposta para isso, obviamente, não é 42. A questão é o que é necessário para pelo menos ser capaz de dizer: "Sim, temos pelo menos alguma coisa, podemos começar a fazer alguma coisa". A resposta a esta pergunta é que são necessários programadores para desenvolver seu próprio mecanismo.

Programadores

Para criar seu próprio mecanismo, você precisa de programadores. Se você não souber, pesquise no Google a diferença entre as palavras "desenvolvedor" (desenvolvedor) e "programador" (programador). Isso é muito importante. Os desenvolvedores são o grupo principal. A indústria de jogos é tão organizada que a maioria das pessoas nela não pode ser chamada de programador. Desculpe, mas eles são desenvolvedores. Os desenvolvedores não conseguem fabricar o mecanismo corretamente. Novamente, se você observar a diferença entre o primeiro e o segundo, os desenvolvedores criam os jogos e os programadores criam as ferramentas. Os desenvolvedores produzem um produto, a empresa ganha com o produto, mas as ferramentas devem ser feitas pelos programadores, caso contrário, elas simplesmente não funcionarão.

Por um lado, é um mundo muito aberto agora. Por exemplo, eu sei o código do Unreal 4 e do CryEngine, ele está aberto. Quem quiser saber pode descobrir o código do Unity, há uma enorme quantidade de materiais relevantes. Isso significa que alguém que é programador e lê inglês pode fazer isso. Não há ciência de foguetes lá. Por outro lado, porém, é muito difícil encontrar programadores que leem em inglês. Portanto, você deve saber onde eles são encontrados, deve poder recrutar, usar, promovê-los. Se você sabe como, então você já pode pensar sobre o seu motor. Se você não tem essas pessoas, ainda não terá sucesso. Exemplos disso são as trevas. Não é que haja soluções boas e ruins. Existem apenas coisas que não podem funcionar inicialmente.

Os programadores precisam poder contratar. Saiba como contratar - você pode fazer um motor. Não sabe como contratar - então você precisa levar algo pronto. Além disso, o engraçado é que, quando você pega algo pronto, se você é uma grande empresa, ainda precisa de duas pessoas desses programadores que lêem em inglês.

Se forem necessários programadores para desenvolver o mecanismo, teremos imediatamente algumas perguntas. Onde procurar programadores? Como organizar o seu trabalho? Em que devo prestar atenção ao pensar nos caminhos de desenvolvimento das empresas de jogos?

Epidemia técnica

Agora, é apropriado relembrar outro aspecto da busca por funcionários, que diz respeito principalmente a grandes empresas. Essas empresas têm várias abordagens para o recrutamento de pessoal.

Em primeiro lugar, você pode recrutar pessoas, se associar, organizar estágios e, treinando-as dentro da empresa, de alguma forma, atingir o nível desejado. Essa é uma abordagem normal. Ao mesmo tempo, muitos problemas tecnológicos também são resolvidos, porque é mais fácil encontrar uma linguagem comum com uma pessoa que inicialmente percebe a cultura corporativa e estuda determinadas tecnologias.

Em segundo lugar, existe uma abordagem que, em princípio, professamos. Como o kefir funciona? Ele transforma tudo em si mesmo. Você pega leite, joga kefir lá - e não há leite, tudo se transforma em kefir. Parece assim para nós: "Pessoal, vamos pegar 5 programadores fortes, será um centro de tecnologia interno". E digo a todos que, se você pode se dar ao luxo de fazer um departamento de pesquisa e desenvolvimento, se você é uma grande empresa, faça-o. Que eles nem façam nada de útil do ponto de vista do dinheiro. Se uma empresa fortaleceu sua posição no mercado e surge a questão de onde expandir, a criação de um departamento de RnD pode ser a resposta para essa pergunta. Quando uma empresa já é rica, por isso não é uma perda de dinheiro, porque já perde tanto dinheiro com a eficiência que nossa indústria de jogos está trabalhando agora que simplesmente não percebe os custos da pesquisa.

Agora considere a abordagem: a empresa organizará uma equipe que fabrica o motor ou outras coisas interessantes. Isso é trabalho para o futuro. Você pode conduzir entrevistas, dizer que dá dinheiro, que tem uma tarefa interessante, que cria um motor. Você pode escolher entre os candidatos, as pessoas vão até você e, dentro da empresa, você sempre tem uma atmosfera assim quando pode motivar, incentivar e, como resultado, atingir seus objetivos.

Por exemplo, tenho alguns módulos sendo desenvolvidos por empresas de alimentos, porque eles precisam. Ou seja, uma física foi ordenada e, em vez de serrar algumas de nossas próprias coisas, dizemos: “Vamos fazê-lo. Acabamos de criar interfaces comuns, um tanto generalizadas, e você fará isso. ” E como parte de tarefas típicas, isso é muito bom. Isso é, em princípio, é bom disseminar a tecnologia dentro da empresa.

Se a empresa já é tão grande que pode se dar ao luxo de fazer algo interessante por si mesma, compensa mesmo do ponto de vista do dinheiro. Portanto, se você puder, tente. Pode parecer como você gosta - digamos, seu próprio ramo Unreal é criado e lá processamos tudo do jeito que você deseja. Por exemplo, criei um navegador em uma das empresas que cabe em 2,5 megabytes de memória. E ele trabalhou. Por que - eu não sei, mas era infinitamente interessante.

Acima, mencionamos o problema das empresas de jogos, que é a organização da interação efetiva entre programadores e designers. Vamos nos debruçar sobre esse problema com mais detalhes.

Dois mundos

Chegou a hora de mostrar o local de trabalho do nosso designer de jogos. Esta é uma imagem real. Alguma demonstração é mostrada aqui, a implementação do comportamento, um pouco mais tarde, abordaremos isso com mais detalhes.

Dois mundos coexistem na indústria de jogos. As pessoas estão focadas na solução de problemas tecnológicos ou na narrativa. E no meio - algum tipo de artesanato. Ou seja, praticamente não existem ferramentas. Palavras, palavras, palavras - bang - código. Novamente as palavras - e novamente o código. Acreditamos que precisamos de ferramentas que nos permitam conectar-se ao que resultará do trabalho no jogo, um designer de jogos, gerente, outros funcionários que não são programadores.

No slide, você pode ver a árvore de comportamento, a árvore de comportamento. Em princípio, isso é algo retirado da Wikipedia, mas na nossa frente foi retirado de lá pela Unreal. Não há nada de errado nisso. Portanto, a documentação para isso está no site da Unreal, não foi difícil para nós tornar uma interface adequada compatível com o que é feito na Unreal. Ou seja, você pode pegar qualquer exemplo no site de ação Anryl, um exemplo do próprio comportamento, já que o formato é o mesmo, reescrevê-lo dessa maneira e funcionará. Isso significa que facilitei minha vida, não estou escrevendo documentação. E há muitas dessas coisas.

No exemplo do slide, algo acontece, um caranguejo corre, pega alguém, em geral, isso não importa. Por dentro, o programador resolve problemas que parecem "vá para ...", "atire em ...", "calcule a distância" - e isso é tudo. Todo outro comportamento é escrito neste editor por uma pessoa que não tem absolutamente nada a ver com programação. E isso funciona, em vez de traduzir texto em código. Além disso, falando em equilíbrio, digamos. O que é equilíbrio? Esses são 15 fatores que podem ser alterados. E aqui está o comportamento, não os coeficientes.

Ou seja, por exemplo, o comportamento de "patrulhamento" é descrito pelo criador do jogo, não pelo programador. Isso significa que demos o passo que a maioria das pessoas não dá. Eles simplesmente escrevem em um documento de design: "patrulhas". E um programador pode traduzir isso de 50 maneiras diferentes. O que é patrulhar? E aqui o designer do jogo escreve exatamente o que ele quer dizer. E isso é uma vitória, meus amigos. Para isso, você precisa de suas próprias ferramentas. Para facilitar a transição da definição verbal de seu visionário que vê o jogo, por assim dizer, dentro de sua cabeça, para programadores. Caso contrário, eles deixarão de ser programadores, se tornarão desenvolvedores e capinarão a grama por toda a vida.

Sumário

Para resumir. Falamos sobre razões para escrever seu próprio mecanismo. Digamos, se você olhar para dispositivos desatualizados, isso não será bom nem ruim. Ou seja, você deseja que seus jogos sejam executados em um determinado intervalo de dispositivos que não são mais suportados por mecanismos comerciais. Ao mesmo tempo, você quer parecer moderno. Como conseguir isso? Escreva o seu.

Deseja possuir uma plataforma? Você tem um projeto específico que simplesmente não requer o uso de soluções universais? Ou, pelo contrário, você tem um projeto muito grande e complexo com uma imagem específica? Nessas situações, novamente, você pode pensar em seu mecanismo. Ao mesmo tempo, para criar seu próprio mecanismo, você precisa de recursos. E os recursos são programadores.

Como resultado, se você tiver motivos para escrever seu mecanismo e tiver os recursos - pegue e escreva.