Motor Unigine
Vamos começar com a versão Unigine. Estamos usando a versão 2.11, lançada nesta primavera, a partir da qual uma licença gratuita apareceu no motor. No momento, 2.12 está fora e 2.13 é esperado em breve.
O que geralmente vale a pena saber sobre o Unigine é um motor de jogo Tomsk frequentemente usado para benchmarks e simulações. Ao longo dos anos, lançou jogos como Oil Rush, Cradle e, por exemplo, o relativamente recente mmo Dual Universe.
Muitas soluções interessantes e promissoras são usadas internamente, ele renderiza uma imagem bastante bonita e pode ser bastante atraente para os artistas, especialmente se eles modelarem em um pacote 3D separado, e não por meio do próprio motor.
O terreno está lá fora da caixa, assim como água, nuvens, volumetria, projetores e outras coisas úteis. Várias máscaras são aplicadas no topo do terreno para detalhamento e outras coisas - uma ferramenta muito legal para criar paisagens, embora em termos de usabilidade haja espaço para melhorias.
Como uma ferramenta para um desenvolvedor de jogos - aqui, em princípio, a experiência de usar C # no Unity é aplicável, embora o Unigine não tenha a mesma variedade de soluções de componentes prontas. No entanto, algumas coisas básicas são implementadas e a documentação o ajudará a escrever o resto. C ++ também não foi a lugar nenhum.
O motor ainda não é adequado para uma plataforma móvel, bem como para o desenvolvimento sem programação (embora esteja previsto desenvolvê-lo também nestas áreas). Requisitos de hardware no nível de consulta Unreal, o tamanho mínimo do arquivo do aplicativo é muito grande. Mas é bom e bem otimizado.
Mas voltando ao protótipo do jogo. Na versão para Unigine, as principais dificuldades estavam associadas ao design visual da física para uma máquina de escrever, pois a documentação sugere fazer tudo isso às cegas, por meio de código, além disso, todos os tipos de configurações físicas estão espalhadas em diferentes lugares do editor e o pipeline de montagem visual em si não é descrito. Ou seja, não havia nenhum exemplo pronto trivial que pudesse ser modificado sem mergulhar em todas as nuances. Na versão 2.12 apareceu um demo com um trator cavando o solo, mas, talvez, esteja novamente sendo montado por código, não assisti esse momento.
Seja como for, montei mais ou menos a máquina, focando na documentação. Sobre o que escrevi anteriormente o artigo correspondente: Como coletei a física das rodas no Unigine .
Em termos de jogabilidade, no Unigine, ao contrário do Unity e Godot, por exemplo, acabou por ser bastante fácil mudar a física do carro em tempo real, não apenas o visual, mas também a localização / tamanho das rodas. Sem inventar manobras adicionais para não cair no chão e sem reconstruir a maquete. Embora, haja alguma chance de cair na textura, mas em situações completamente diferentes, e não na hora de trocar a máquina.
O conceito de um único veículo que simplesmente muda de forma, se transforma, se adapta, vê o que está acontecendo em outras dimensões e assim por diante se encaixa bem a tudo isso. Pelo menos a jogabilidade principal poderia ser construída em torno dessas mudanças, embora não necessariamente.
O que é triste sobre o mecanismo é a montagem da IU a partir do editor - tudo é de alguma forma complicado, com scripts separados pendurados para cada elemento interativo. Embora aqui eu tenha editado apenas a implementação que estava nos exemplos, não entendi muito, além disso, não descobri imediatamente como exibir a camada gui para ver a representação visual no editor.
Por outro lado, se nos referimos a um jogo mais orientado para o console, sobre jogabilidade atrelada a um pequeno número de botões, com uso mínimo da interface e com um mínimo de elementos de interface, então este não é mais um problema perceptível.
Outra coisa deprimente, animações simples gravadas em um instrumento interno - um rastreador. Sim, é poderoso em sua própria maneira, mas de alguma forma muito aninhado para usar. Além disso, a animação gravada desta forma pode ser reproduzida apenas usando a linguagem UnigineScript desatualizada. Isso enquanto em Unity ou Godot você pode animar literalmente tudo ao redor do perímetro. Sim, você pode importar animação de osso, mas isso é um pouco diferente (além disso, ainda não experimentei esse método e não sei como é).
Se, novamente, você olhar do outro lado, então o motor está ainda mais focado em simulações físicas e interações, então por que não usar isso em vez de preparar algumas animações predefinidas lá - ou seja, para fazer alguns emissores, interruptores, estruturas interagindo, aplicando forças, usando a gravidade e assim por diante. Portanto, você pode fazer sem um animador interno, mas se ele foi implementado corretamente, então isso também é um grande negócio, mesmo que apenas em termos de direção - com alguns cliques você pode gravar o voo da câmera pelo palco com todos os tipos de elementos interativos, e aqui você tem um filme concluído Além disso, com essas oportunidades para uma imagem cinematográfica.
Quanto ao meu projeto - no momento, após várias iterações, finalmente compilei e postei uma demonstração mais ou menos sólida que pode ser testada.
O arquivo para Win64 pode ser baixado aqui (peso 687Mb): DROPBOX
ou na página itch.io : NEWANGERS
descompactado leva 3Gb
O que há:
- A construção tem três modos de exibição principais - "dia" e "noite" (com predefinições de configurações gráficas altas) e modo "a la comic" (com configurações gráficas mais baixas).
- Para alternar entre os modos, pressione Esc para que o cursor do mouse apareça e selecione a opção desejada no menu no canto superior esquerdo.
- Existem objetos interativos nos níveis - portais em forma de estrela azul, através dos quais o carro é transportado para outros mundos e você pode retornar ao entrar no portal por aquele lado.
- Muitos objetos do nível são permeáveis, mas alguns têm colisões e os próprios níveis são mais ou menos cercados por paredes de bloqueio.
- , , WASD. Q E. , , , R. Tab , , , .
- , .
- 1,2,3,4,5,6,7 — . .
- , «» .
- PgUp , . PgDown — .
- P — , L — .
Um amigo postou as fontes anteriores deste protótipo em sua página, junto com algumas edições da física das rodas da versão original: GITLAB .
Motor Godot
Passando para o próximo motor de nossa lista. Uma solução compacta de código aberto com enormes capacidades (Blender do mundo dos motores de jogo), mas, novamente, ainda é inferior ao Unity em termos de variedade de componentes prontos. Embora já tenham sido escritas várias soluções não oficiais, bem como exemplos com códigos-fonte para Godot, e devido à relativa simplicidade / velocidade de implementação da nova funcionalidade, não posso dizer que se trate de algum tipo de problema no momento.
Godot tem uma reputação melhor como motor 2D, graças à variedade de ferramentas bem desenvolvidas especificamente para 2D, mas são uma vantagem adicional para 3D - é muito mais fácil fazer uma interface de usuário de jogo. Ainda mais fácil do que no Unity, quanto a mim. No momento, Godot em seu desenvolvimento atingiu a versão 3.2.3 estável (mas todo mundo está esperando por 4 por causa do vulcão, otimizações e assim por diante. Montagens instáveis dos quatro, aliás, você já pode tentar - pelo menos avaliar a imagem).
O motor não requer hardware poderoso para gráficos 3D e produz uma imagem bastante decente. Não há um grande número de ferramentas tridimensionais prontas, mas algumas das mais necessárias, úteis e universais foram implementadas. O mesmo vale para otimizações. Por exemplo, o motor implementa o habitual abate frustrum, que corta a geometria fora do campo de visão da câmera. Seleção de oclusão (de modo a não contar os objetos fechados por paredes), você terá que sugerir a implementação você mesmo (o que não é tão difícil, especialmente em alguns pontos, e não em todos os jogos que você precisa). Também fora da caixa no motor não há lote de geometria (embora haja parcialmente para gles2) e terreno, mas isso não é um problema, você só precisa otimizar algo manualmente - costurar algumas malhas, quebrar a geometria em pequenas partes ou usar pedaços e assim por diante Mais longe.Você pode encontrar algum tipo de implementação em uma pequena loja local, por exemplo, adicionar uma solução de terreno pronta para o seu projeto.
A interface do motor, aliás, é bastante atenciosa e personalizável (embora haja alguns elementos inflexíveis). Geralmente é conveniente usar. Existem idiomas com suporte suficiente para diferentes níveis de imersão. Há C ++ e C # e um GDScript interno bastante conveniente que roda dentro do editor sem exigir um ambiente separado para ser iniciado. O script visual também está presente, então sem conhecimento de programação em Godot também é bem possível viver - construir alguma lógica mínima, animar algo (Godot tem uma ferramenta simples e legal para gravar animações).
O baixo peso do aplicativo, a natureza multiplataforma, a velocidade de desenvolvimento, a facilidade de implementação de várias soluções de terceiros também são vantagens importantes do mecanismo. Existem duas opções de renderização - gles2 e gles3, ambas suportam 3D, mas na primeira é mais simples e em geral é mais adequado para 2D e telefones celulares. Gles3 oferece um nível mais avançado de gráficos, algumas partes dos dispositivos móveis também o suportam.
Vamos passar para um protótipo de jogo baseado neste motor. Em Godot, um modelo físico simples de veículo sai quase fora da caixa, então trazer seus carros aqui foi muito fácil.
Com o que surgiram alguns problemas - não é tão fácil intervir em um objeto físico lançado, por exemplo, para teletransportá-lo de um ponto para outro ou para mudar a localização da roda do carro em movimento. Portanto, aqui um truque como no Unigine não funciona e, pelo que entendi, em Godot é mais fácil recriar um objeto do que alterar a configuração física ou algo parecido em tempo real. Mas, na verdade, tudo isso não é particularmente necessário, e neste protótipo eu apenas retornei à ideia padrão de jogabilidade, quando você dirige para carros diferentes, mudando de um para outro em algum lugar especial separado.
Godot tem ferramentas interessantes como objetos CGS e multi-malhas. Escrevi com mais detalhes sobre os recursos de seu uso no artigo: Godot, 1000 pequenas coisas
O protótipo do Nevanger neste motor recebeu um nome separado -Motores selvagens . Em geral, recebo uma espécie de família de projetos semelhantes, unidos pelo conceito de carros estranhos viajando por mundos estranhos. E como um nome coletivo de trabalho, eu costumava chamá-los de Nevangers, até que um nome mais específico surgiu. O protótipo do Godot agora tem nome próprio, a versão suspensa na versão 0.9 do Unity (que deu início a tudo) também tem um nome diferente, mas isso virá depois, se houver tempo de voltar a ele.
No início, não tive uma visão especial do que gostaria de implementar na demonstração do Wild Engines, apenas fiz esboços de níveis, tentando entender como implementar melhor o terreno e que tipo de oportunidades gostaria de ver. Então tive a ideia de fazer a câmera se mover atrás do mouse e tornou-se possível realizar uma mira mais controlada da arma do que em outras versões. Assim, este protótipo provavelmente ficará mais focado no uso de tiro.
Ao longo do caminho, comecei a montar um nível a partir de plataformas compostas por pequenos blocos, tentando várias abordagens de otimização e medição de desempenho. Otimização por otimizações, mas em algum momento já enchi a área visível para a câmera de geometria tanto que o editor parou de arrastar toda a cena em execução, caindo com erros. O que foi corrigido incluindo mais memória nas configurações. Então, levei a geração da plataforma mais para dentro do código, deixando apenas blocos dimensionais simplificados com identificadores no palco, que carregaram a plataforma necessária neles quando o jogo foi iniciado. Em seguida, reverti a quantidade de memória usada para um valor inferior e aumentei o nível várias vezes mais sem problemas. Além disso, com tal implementação, há sempre a opção de reutilizar as plataformas já carregadas, movendo-as para outros locais do nível,quando a máquina está indo nessa direção para poder desenhar o espaço plano com eles praticamente ao infinito com os mesmos recursos e sem transições.
De forma semelhante, posteriormente coletei sketches de um nível semelhante no Unigine, só que lá o editor imediatamente puxa toda a cena sem a necessidade de carregar plataformas em blocos através do código (mas para Unigine, um computador muito mais poderoso é usado).
Como resultado, na versão demo do Wild Engines existem 4 carros, um dos quais deve ser selecionado para começar, e dois pequenos níveis (Nível A e Nível B). Alguns dos primeiros mapas também permaneceram (Níveis 0 e 1), mas eles são ainda mais testadores e a paisagem não está otimizada.
O modo de tela inteira e sombras podem ser ativados / desativados no menu.
Os botões 1, 2 e 3 mudam a posição da câmera. O mouse aponta e gira a câmera, quanto mais distante o cursor está do centro.
WASD - movimento. PgDown - pula. Q - impulso aleatório.
Botão esquerdo do mouse - tiro.
Com Enter, uma dica sobre o controle aparece e um botão para retornar ao menu principal, onde você pode alterar a máquina / nível.
Versão Win64 (42 Mb): DROPBOX wildengines_x64
versão Linux (44 Mb): DROPBOX wildengines_linux
Bônus
E aqui está um dos novos mechas emergentes, o Necromancer:
Você pode montá-lo na versão Unigine.
Outro novo mechos, rosa com retroiluminação azul, Debag, está aqui e ali.
Havia também um cartucho antigo por aí ... o que você acha, clones de qualquer jogo de oito bits poderiam ser escondidos sob esse nome em um cartucho chinês, se Vangers fosse uma franquia mundialmente famosa naqueles tempos distantes?
