Enzo Ribeiro
Minhas contribuições
- Ajudar a documentar nossas ideias e decisões por meio do GDD, dashboards e slides
- Projetar a mecânica central do jogo, com foco no movimento do jogador
- Projetar os tipos de obstáculos, o posicionamento e a combinação do jogo
- Projetar o loop de jogabilidade
- Desenvolver o design de níveis e implementá-lo no mecanismo, observando as diferenças entre mapas 3D x 2D no jogo e no editor
Fase de polimento:
- Programar e implementar a interface de usuário visual, o menu e as transições de nível
- Programar e implementar os efeitos sonoros e a trilha sonora
- Revisar e corrigir a coloração do nível e o posicionamento dos recursos 2D+3D
- Implementar o culling de distância básico
Game Design
Conceito inicial
Minha primeira proposta em relação a esse projeto foi criar uma mecânica central que pudesse explorar o fato de termos artistas 2D e 3D na equipe. Assim, nossas primeiras conversas giraram em torno de um loop de jogo que poderia se tornar um uso dinâmico dessa mecânica, inicialmente no controle do jogador. Uma de nossas principais referências sobre a mecânica de perspectiva do jogador foi FEZ (2013), da Polytron Corporation.
Acabamos escolhendo um jogo runner, pelo apelo dinâmico e por usar uma base simples e conhecida para tentar fazer com que nossos pontos exclusivos fossem facilmente percebidos.
Esquemas de mecânicas centrais iniciais
Obstáculos/dificuldade
Depois de nos debatermos um pouco sobre como planejar a experiência de jogo antes de termos qualquer tipo de protótipo ou MVP disponível, a equipe de design de jogos começou com um gráfico de escala de dificuldade. Com isso, poderíamos medir a curva de aprendizado do jogador, visualizando quando cada nível teria novos obstáculos e mecânicas.
Fizemos isso com todas as nossas intenções de nível como um conceito para a fase de prototipagem. Esses gráficos foram originalmente feitos em colaboração por meio do figma.
Gráfico de dificuldade/tensão do primeiro nível
Decisão sobre o fluxo de trabalho 2D x 3D definiu os obstáculos
Enquanto esses gráficos eram feitos, houve conversas com o restante da equipe, definindo como usaríamos o 2D x 3D no jogo e, após discussões e considerações cuidadosas, concordamos em seguir uma mistura com os ativos, mas com uma divisão clara entre os níveis 2D e 3D, tornando-os instâncias completamente separadas para simplificar o trabalho dos artistas e programadores com nosso cronograma apertado de forma independente, em seus horários e estruturas de trabalho individuais preferidos.
Agora que a forma como o jogo seria construído estava definida, a equipe de design do jogo começou a desenvolver os obstáculos reais. A primeira preocupação era ter obstáculos que pudessem se deslocar pelos níveis, pois agora eles tinham dimensões e ângulos de visão diferentes. Como isso limitaria nosso resultado, reconhecemos que, desde que os movimentos e a mecânica principais do jogador pudessem ser mantidos, poderíamos ensinar como usá-los para superar qualquer obstáculo, 2D ou 3D, desde que todos eles pudessem ser evitados com o básico.
Esquemas iniciais de mecânicas centrais
.png)
Rascunho inicial de nível, com tipos de obstáculo baseados nas ações do jogador
Types of obstacle
Following our previous conclusions, we kept it simple. Using familiar obstacles so that no matter how weird they look the player could learn how to overcome them instinctively. So we basically had obstacles based on the player's actions:
1.Jumping; 2.Sliding/crouching; 3.Jumping+Sliding; 4.Avoid/change lane.
The next steps were inserting combinations of those obstacles in the already finished difficulty charts, then having clear instructions for a block-out inside the engine. But, as we did that, we had many ideas on how the game feel could be improved but most of them were clear stretches from our original schedule and scope, changing a lot of the gameplay so we chose 1. The hover.
Rascunho inicial de nível
O hover é simplesmente uma extensão do salto. Ele não faz com que você pule mais alto ou voe potencialmente, mas faz com que você caia mais devagar, portanto, não exigindo novos obstáculos. Não é um conceito totalmente novo, portanto o jogador pode entendê-lo com uma representação clara. E, o que é mais importante, trouxe a possibilidade de algo que poderia apimentar todo o jogo, não necessariamente mudando suas trilhas: O gerenciamento de recursos. Como o hover poderia ser usado para contornar obstáculos com facilidade, era necessária uma limitação, mas, em vez de um tempo de espera, optamos por adicionar algo que o jogador teria de controlar e decidir. Mais liberdade pareceu ser a escolha certa, pois isso se torna uma camada de estratégia que complementa o que normalmente se torna um jogo de memória com a maioria dos corredores que não são gerados processualmente.
Rascunhos de configuração de câmera
Inserção do tema
O tema foi desenvolvido simultaneamente com os níveis, incorporando ativamente o design e a mecânica.
Definimos configurações diferentes para cada instância 2D, de acordo com o cenário.
Os mapas punk tropicais tinham uma visão mais limitada e próxima da pista, dando uma sensação de confinamento, exigindo mais tempo de reação e adaptação do jogador. É claro que tentamos calibrar os obstáculos para que não se tornassem frustrantes.
Os mapas do Solar Punk tinham uma visão mais ampla, permitindo antecipar a pista e planejar como se mover. Não o suficiente para perder a dinâmica da corrida, mas a quantidade necessária para identificar novas plataformas estranhas e ramificações da pista.
Aplicação na Engine
Eu estava encarregado de criar nossas pistas conceituais no mecanismo. Usar os esboços dos obstáculos foi suficiente para um bloqueio inicial, mas, como eu mesmo testei o jogo e pedi opiniões, muitas pequenas alterações foram feitas, pois agora fatores novos e mais tangíveis faziam parte do cenário, como a velocidade do jogador e a gravidade/extensão do salto. Para obter resultados satisfatórios, os gráficos de dificuldade ajudaram a manter as ideias alinhadas com o conceito original.
Depois de obter resultados decentes, comecei a substituir os blocos por nossos ativos 2D e 3D, o que incluiu a importação e a verificação da compatibilidade.
Com o cenário começando a se formar, usei os assets que Gratz programou para as caixas de colisão de obstáculos e as modelei de acordo com cada asset que estávamos usando como obstáculo.
Configuração final do primeiro nível 3D
Wireframes para assets e colliders em perspectivas diferentes na engine
Configuração final de colliders de atores obstáculo
Mapas 2D
Para esses mapas, usamos o plug-in Paper 2D, que usa um grid baseado em conjuntos de blocos, portanto, aprender a usá-lo e criar colisores para blocos específicos fez parte do projeto. O processo geral não foi muito diferente dos mapas 3D, apenas com ferramentas e interfaces diferentes.
Configuração final do segundo nível Solar Punk com assets
Final second Solar Punk level tileset in scene
Customização final do Tileset do segundo nível Solar Punk com Paper 2D
Programação
Inicialmente, eu me concentrei em ajudar a ser o principal contato entre a equipe de design e os programadores, pois já havia usado blueprints antes, então a maior parte da programação que eu mesmo fiz nessa fase foram tarefas secundárias, como:
- Transição de nível por meio de atores de "portal";
- Adaptar folhas de sprite em animações 2D utilizáveis e adicioná-las ao blueprint do jogador;
- Criar e configurar atores de Sound Cue e como fazer referência a eles e reproduzir faixas;
- Ajustes gerais da câmera do jogador;
- Importar e configurar os blueprints de assets 2D para que se ajustem ao nosso método de trabalho.
Portal transition function blueprint example
Polimento
Mais tarde, nos estágios finais dos projetos, eu me tornei oficialmente parte da equipe de programação, corrigindo bugs e implementando recursos, principalmente complementando os sistemas que já existiam, como:
* Redefinição de recursos ao longo dos níveis;
* Tempo, transições e resposta de entrada de animações 2D;
* SFX implementado, vinculado a ações e alguns como sons espaciais nos mapas;
* Iluminação/coloração de mapas;
* UI funcional com assets visuais implementados;
* "Cutscene" de quadrinhos implementada e pulável.