RESUMO

O desenvolvimento de jogos é notoriamente um difícil processo conhecido por ser lento e árduo, normalmente envolvendo multidisciplinaridade entre todos os membros da equipe e alto nível coordenação de time vindo dos diretores e produtores. Várias ferramentas existem para auxiliar e acelerar os desenvolvedores de inúmeras formas, porém nem todos utensílios feitos para ajudar na criação de jogos são igualmente eficazes. Através deste artigo e projeto, buscamos conseguir estudar, entender e então poder com confiança validar o uso de algumas destas ferramentas durante a prática, e analisar seu impacto no processo de desenvolvimento de um jogo 2d de ação e plataforma simples. Ao implementar addons e shaders na game engine godot, visamos conseguir acelerar o desenvolvimento e aumentar a qualidade dos assets visuais além da programação feita durante a realização do jogo, e então criando um produto que excede as expectativas de o quão bom ele seria e em menos tempo.

Palavras-chave: Godot; Addon; Shader; Platformer.

 1. Introdução

O design de jogos do gênero plataforma concentra-se na criação de obstáculos que o jogador deverá superar através de controle e precisão. É preciso focar em design de nível, preocupando-se com a disposição das titulares plataformas, criando zonas seguras e perigosas que geram uma narrativa lúdica que informa a experiência de jogar, de forma a manter a credibilidade do jogador durante toda a experiência (Camilleri et al. 2016)

Com um game design bom, um jogo de plataforma pode tornar-se, simultaneamente, uma experiência acessível a iniciantes e recompensante a veteranos, com baixo piso e alto teto de habilidade.

Nosso projeto mira a construção de um jogo digital do gênero plataforma, inspirado em títulos como "Celeste" (Maddy Makes Games inc) e "Super Mario Bros" (Nintendo).

A jogabilidade principal se dá pela movimentação através de campos obstáculos em perspectiva lateral, utilizando das mecânicas de pulo e dash precisamente para avançar. O jogador tem vidas infinitas, mas reinicia o nível se for atingido por qualquer obstáculo.

O projeto será desenvolvido no motor de jogo Godot 4.4, e usufruirá de addons para acelerar e facilitar o processo de programação. Addons são fragmentos de código com funcionalidade contida que podem ser adicionados a projetos existentes para utilizar a implementação de um sistema sem precisar construí-lo do zero. Addons são

Os addons utilizados serão "Metroidvania System" (KoBeWi), para carregamento de níveis; "Health, HitBoxes, HurtBoxes and HitScans" (ClutteredCode) para lidar com vida e dano; "Ultimate Platfomer Controller 2D" (noaseynoah), para a movimentação de plataforma e SimpleState (AuraTheEnby) para implementar máquinas de estado.

1.1. Justificativa

Este projeto explorará a incrementação de eficiência e qualidade da produção de assets de programação ofericido pelo uso de addons disponíveis nas game engines, verificando a viabilidade de seu uso em projetos maiores e estudando sua compatibilidade com modificações de código próprio. Além disso, utilizaremos o projeto como plataforma de aprendizado sobre o uso e aplicação de shaders na godot.

1.2. Objetivos

Desenvolver um jogo de plataforma 2D para testar a viabilidade da utilização de addons da Godot como forma de acelerar e facilitar o processo de iteração e game design. E também testar diferentes modos de utilização e aproveitamento de shaders dentro da game engine, de forma a desenvolver efeitos visuais de maneira mais eficiente.

Criaremos um protótipo inicial, a partir do qual o conceito do jogo será implementado com assets próprios. Refinaremos nossa pipeline de produção em busca de maior eficiência e qualidade. 

1.3. Procedimentos metodológicos

Abaixo descreveremos o processo de desenvolvimento do projeto e da pesquisa deste artigo.

1.3.1. Metodologia do projeto

Em função de manter o processo de pesquisa organizado e sistemático com o objetivo de alcançar resultados desejados, seguimos o Método do Caminho Crítico (CPM) de Kelley & Walker (1950s), uma técnica de gestão de projetos que identifica a sequência de tarefas mais críticas e dependentes para a conclusão do projeto no menor tempo possível. Também fizemos uso da metodologia básica do ciclo de design: análise, síntese, simulação e avaliação (Koomen, 1991) e aplicarmos a metodologia Double Diamond durante todos os processos do desenvolvimento do projeto, adaptada de acordo com nossas necessidades. Double Diamond é, de acordo com Conselho de Design Britânico (tradução dos autores):

"Dividido em quatro fases distintas - Descoberta, Definição, Desenvolvimento, Devolução - a metodologia Double Diamond mapeia os estágios divergentes e convergentes do processo de design, mostrando os diferentes modos de pensamento que os designers usam."

1.3.2. Metodologia da pesquisa

Utilizamos palavras-chave relacionadas ao projeto como "Jogo de Plataforma", "Godot Engine", "Boss Rush" e "Desenvolvimento de Jogos" para afunilar nossa pesquisa de artigos relevantes nos anais da SBGames, Repositório Institucional da UFSC e no Google Scholar (Piasecki et al., 2018). 

1.4. Revisão de literatura

Entre os artigos disponíveis pesquisados, identificamos alguns relevantes ao projeto. 

Para a pipeline de produção de assets de arte: “DESENVOLVIMENTO DE ANIMAÇÕES 2D QUADRO A QUADRO PARA UM JOGO “BOSS RUSH” 

Para o game design de um platformer: “Fail, fail again, fail better: How players who enjoy challenging games persist after failure in “Celeste”.

2. Conceito

O conceito do jogo baseia-se na ideia de providenciar um jogo de plataforma com mecânicas fluidas. No jogo, o player, deve atravessar as ruínas de uma cidade tomada pela natureza, desviando de obstáculos e atravessando um ambiente traiçoeiro, a fim de alcançar a sala final. Além das mecânicas de platformer, o jogador deverá enfrentar um boss como um obstáculo final, adicionando um novo nível de dificuldade e complexidade para o gameplay.

2.1.  Resumo da história

Deuses, cada um governando seus próprios domínios, mantinham o equilíbrio das forças que impulsionam a criação e a entropia. Mas, de forma sem precedentes, algo mudou. Os deuses enlouqueceram à medida que seus poderes saíam de controle e sua sanidade se desfazia por completo. Uma força desconhecida mirou ao divino, e o universo estremeceu enquanto os pilares que o sustentavam ameaçavam se tornar sua própria ruína.

Runnty, como uma criatura nascida do pó e da luz das estrelas, é seu dever cortar as partes apodrecidas antes que seu veneno se espalhe para o restante do panteão. Sua tarefa mais recente: um deus de cascas e raízes, cuja vegetação retorcida se espalha até além do véu de seu domínio. Sozinho, você deve adentrar seu lar de vinhas sinuosas e obeliscos arruinados para matar um deus, antes que sua essência ameace arrastar outros em sua queda.

3. Requisitos e Ferramentas

Desenvolver jogos digitais requer grande investimento tecnológico, tanto em software quanto em hardware. Abaixo são listados os programas utilizados pela equipe no desenvolvimento do projeto:

• Engine/Frameworks: Godot
• Linguagens: GDScript
• Ferramentas auxiliares: GitHub Desktop (controle de versão), Aseprite (assets pixel-art), FL Studio (sonorização)
• Hardware recomendado: PC Windows

3.1. Arquitetura do Projeto (Design Técnico)

A Godot Asset Library é uma biblioteca de componentes adicionáveis ao motor que expandem sua funcionalidade baseado em código aberto desenvolvido por membros da comunidade. À partir dela, baixamos esses pedaços de software para editá-los e moldá-los às nossas necessidades dentro do projeto.

Dentro do motor, nossa estrutura de pastas é subdividida em: Addons, Assets, Scenes e Scripts. Addons é a pasta onde a própria Godot instala os plugins baixados pelos desenvolvedores. Assets é onde importamos imagens, sons e outros arquivos usados pelo código. Scenes é onde salvamos as cenas de nós junto de seus scripts apropriados. Scripts é onde guardamos código que não tem um nó relacionado, usualmente singletons e outros sistemas específicos.

Abaixo segue uma representação de como estão organizadas nossas pastas dentro do projeto:

Diretório Root

• Addons
  • Metroidvania System
  • Health, HitBoxes, HurtBoxes and HitScans
  • SimpleState
• Assets
  • Levels (sprites e sons de environment)
  • Player (sprites e sons do player)
  • Enemies (sprites e sons dos inimigos)
• Scenes
  • levels
  • platforming elements
    • (cada elemento em uma subpasta)
  • player
  • systems
  • ui
• Scripts (singletons e toolbox)

Padrões de programação usados:

Utilizamos o padrão de programação singleton ao criar um script que mantém referências ao objeto do jogador e do nível atualmente carregado, servindo também como um game manager para lidar com eventos e informações persistentes entre níveis. Tal implementação não é boa prática para projetos maiores, pois que qualquer script tenha acesso unidirecional ao player, mas, considerado o escopo pequeno do projeto, foi escolhido desenvolver assim pela simplicidade imediata.

Além disso, utilizamos o padrão de herança de forma que os níveis herdam de um nó base (com classe pai acompanhando) para sincronizar mecanismos universais de transição de nível dentro do Metroidvania System.

3.2. Implementação das Mecânicas

Movimento do player:

Utilizamos o addon Ultimate Platformer Controller 2D, por noaseynoah, como base, modificando o código fonte para consertar pequenos erros encontrados e oficializar mecânicas de movimento avançadas emergentes de interações dos sistemas do addon (como o Jump Dash Cancel (JDC), um pulo mais alto causado por cancelar o dash que permite encadear mais dashes).

Sistema de combate:

Hitboxes e Hurtboxes utilizadas diretamente do addon. O player tem 1 hp e todos os hazards e ataques de inimigos dão 1 de dano. Um sistema de respawn faz com que pouco progresso seja perdido a cada morte.

IA do boss:

Implementada usando uma máquina de estados estendendo a funcionalidade do addon SimplesState

func _dash_input_pause(time): await _inputPauseReset(time) if is_dashing and !dash_was_just_canceled:      is_dashing = false      if velocity.y > 0: velocity.y = 0      if velocity.y < 0: velocity.y = -maxSpeed      return dash_reset() #here is where the JDC happens

Modificação do Ultimate Platformer Controller 2D que permite o JDC.

func _respawn_reposition(): global_position = current_spawn_point_position respawn_raycast.force_raycast_update() if respawn_raycast.is_colliding():      var target: Vector2 = respawn_raycast.get_collision_point()      global_position.y = target.y - 8 func reset_player_state(): health_component.fill_health() velocity = Vector2.ZERO Signals.player_respawn_finished.emit() #TODO FIX camera moving when changing rooms func on_death(): #TODO add animation delay reset_player_state() _respawn_reposition() $RespawnRaycast.force_raycast_update() func _on_health_died(entity: Node) -> void: on_death()

Lógica de respawn do player. O respawn_raycast garante que o player não esteja flutuando ao renascer, mesmo se o Node de checkpoint esteja acima do chão.

Interface do Metroidvania System, permitindo criar mapas sidescroller complexos com facilidade

3.3. Otimização e Debugging

Fazer mapas grandes envolveria tilemaps pesados trazendo problemas potenciais. Isso é resolvido pelo uso do Metroidvania System, que reparte os mapas em salas menores, permitindo que um espaço contínuo seja simulado em múltiplas cenas.

4. Conclusão e Próximos Passos

Conclui-se que o uso de addons para o desenvolvimento de um jogo 2D acelera e aperfeiçoa o resultado do processo de produção e permite aos desenvolvedores explorar outras ideias devido ao tempo salvo.

4.1. Testes e Resultados

Para realização de nossos playtests, nos inspiramos em Looney, que escreve no Kobold Guide to Board Game Design [Selinker, 2011, p. 34], defendendo uma abordagem de multi estágios para testes de jogo que distingue entre um "Círculo Interno de amigos", e "Estranhos Aleatórios", com cada grupo oferecendo feedback sobre diferentes aspectos do jogo. Em nosso caso, realizamos um grande número de playtests com “Círculo Interno de amigos” (grupo de desenvolvedores), para determinar bugs, o funcionamento das mecânicas e loop de gameplay.

Com os mesmos, adquirimos os seguinte resultados:

Jogador 1:

• Wall jump ótimo
  • :)
• JDC não intuitivo
  • Sob revisão
• Gostaria que desse de dar dash no outro shift
  • Foi implementado

Jogador 2:

• Jogo legal
• • :)

Jogador 3:

• Dash não intuitivo
  • Avaliamos que não há muito o que mudar sem alterar a natureza fundamental da gameplay que buscamos, então elegemos ignorar
• Falta de coyote time
  • Sob revisão
• Movimentação inicialmente parece dura e demora um pouco para se familiarizar 
  • Sob revisão (noob)

4.2. Testes Futuros

Com o intuito de alcançar resultados superiores, temos planos de aplicar o jogo com "Estranhos Aleatórios" durante o evento Test Night (acontecerá dia 6 de julho). Com isso poderemos coletar dados e insights de fontes externas (fora do nosso grupo imediato), que serão usados para solucionar qualquer problema e polir o jogo.

5. Referências

11 lessons: a study of the design process. Disponível em: <https: www.designcouncil.org.uk="" our-resources="" archive="" reports-resources="" 11-lessons-managing-design-global-brands="">.  </https:>

Cardouzo, Herick Henrique, et al. “Classificação de Gênero de Jogos Digitais - Mapeamento Sistemático de Literatura.” Simpósio Brasileiro de Jogos e Entretenimento Digital (SBGames), SBC, 2024, pp. 50–61. sol.sbc.org.br, https://doi.org/10.5753/sbgames.2024.240942.

Design Council (2005). A Study of the Design Process—The Double Diamond.

Godot Asset Library. Disponível em: <https: godotengine.org="" asset-library="" asset="">.  </https:>

HEFKALUK, N., LINEHAN, C. and TRACE, A.; (2024). Fail, fail again, fail better: How players who enjoy challenging games persist after failure in “Celeste”. International Journal of Human-Computer Studies, 183, 1–11. https://doi.org/10.1016/j.ijhcs.2023.103199

Health, HitBoxes, HurtBoxes and HitScans - Godot Asset Library. Disponível em: <https: godotengine.org="" asset-library="" asset="" 3636="">. Acesso em: 8 maio. 2025.  </https:>

Hefkaluk, N., Linehan, C., & Trace, A. Metroidvania System - Godot Asset Library. Disponível em: <https: godotengine.org="" asset-library="" asset="" 2301="">. Acesso em: 8 maio. 2025.  </https:>

Kelley, James E., Jr., and Morgan R. Walker. "Critical-Path Planning and Scheduling." Proceedings of the Eastern Joint Computer Conference, 1959, pp. 160–173. doi:10.1145/1460299.1460318.

Mlanarczyki P., DESENVOLVIMENTO DE ANIMAÇÕES 2D QUADRO A QUADRO PARA UM JOGO “BOSS RUSH”. Repositório Institucional UFSC. 2023. Disponivel em: https://repositorio.ufsc.br/handle/123456789/248612

SELINKER, M. (2011). The Kobold guide to board game design. Kirkland, WA, U.S.A.: Open Design LLC.

SimpleState - Godot Asset Library. Disponível em: <https: godotengine.org="" asset-library="" asset="" 1578="">. Acesso em: 8 maio. 2025.  </https:>

Ultimate Platformer Controller 2D - Godot Asset Library. Disponível em: <https: godotengine.org="" asset-library="" asset="" 3312="">. Acesso em: 8 maio. 2025.  </https:>