1.INTRODUÇÃO

Jogos de construção de base comumente permitem que os jogadores manuseiam recursos (humanos, naturais, etc.) para criar e desenvolver um assentamento (vila, povoado, cidade, etc.). As tarefas do jogador normalmente incluem construir diversos tipos de estruturas, prover utilidades e serviços, gerir finanças e planejar infraestrutura (ruas, esgotos, etc.), porém, isso varia de acordo com a configuração e complexidade do jogo (Bereitschaft 2016, tradução nossa).

Tÿrunn e a Estrela Cadente é um jogo de construção de base singleplayer inspirado em jogos do mesmo gênero, como Kingdom Two Crowns e Timberborn. O jogador assume o papel de um Monarca em busca de recursos para construir seu reino e sobreviver às perigosas noites da “Ilha de Fjørna”.

Cientes da importância do gênero para o campo de jogos e reconhecimento das diversas mecânicas presentes no mesmo, o estudo visa superar os desafios propostos pelo professor responsável na matéria de Programação Aplicada, com foco em entender as mecânicas complexas encontradas nesse gênero de jogos e solucionar os problemas que serão encontrados durante o trajeto.

1.1.Objetivos

Desenvolver um jogo que implemente mecânicas do jogo Kingdom: Two Crowns com uma estética nórdica e com uma progressão linear, em vez de procedural.

• Objetivos específicos:
• Pesquisar aspecto estético da cultura nórdica
• Realizar um planejamento de design técnico
• Implementar o plano no motor de jogo selecionado

1.2.Procedimentos metodológicos

A metodologia utilizada no processo de desenvolvimento do jogo foi inspirada em metodologias de design como a metodologia básica do ciclo de design: análise, síntese, simulação e avaliação, desenvolvida por Koomen (1991). Porém o processo possui diferenças nas pessoas aplicadas e foi mais livre em sua aplicação.

O processo foi dividido em: Pesquisa, Análise, Produção e Avaliação, que foram seguidas de maneira linear. Similar a metodologia Double Diamond criada pelo British Design Council (2007), o processo se repetia após cada avaliação, onde os dados avaliados seriam tomados em conta para melhorar o projeto.

Etapas da Metodologia utilizada:

• Etapa 1. Pesquisa: Etapa constituindo da busca por informações através de jogos, artigos, pesquisas e referências.
• Etapa 2. Análise: Avaliação e sintetização dos dados coletados durante a etapa de pesquisa.
• Etapa 3. Produção: Desenvolvimento e produção do jogo, fazendo uso das informações adquiridas.
• Etapa 4. Avaliação: Teste do produto produzido e avaliação de aspectos positivos e negativos.

1.2.1. Metodologia de Projeto

O processo de pesquisa foi organizado com uma metodologia constituída das etapas: Definição, Protocolo e Execução.

• Etapa 1. Definição: Os objetivos de pesquisa são identificados.
• Etapa 2. Protocolo: Um protocolo de revisão é definido. O protocolo especifica as questões principais que a pesquisa busca responder e os procedimentos que serão utilizados para conduzir a revisão, incluindo quais estudos serão considerados relevantes para a revisão (critérios de inclusão e exclusão), critérios de qualidade.
• Etapa 3. Execução: Consiste na busca por informações, seguindo os critérios estabelecidos.

1.2.2. Metodologia de criação de assets de arte

A criação de arte foi organizada seguindo a metodologia consistindo nas seguintes etapas: Pesquisa, Rascunho, Peneira e Finalização

• Etapa 1. Pesquisa: Uma pesquisa é executada, buscando inspirações e ideias para montar um mapa mental e então iniciar a próxima etapa.
• Etapa 2. Rascunho: Se baseando na pesquisa feita anteriormente são feitos uma série de rascunhos explorando as múltiplas formas que essa arte pode tomar forma.
• Etapa 3. Peneira: Os rascunhos feitos na etapa 2 são peneirados, filtrando o que o time gostou ou não gostou.
• Etapa 4. Finalização: É escolhido os traços e as ideias que o time gostou, então a partir deles é feito uma arte final, que vai ser o asset que vai para dentro do jogo.

2.CONCEITO

Apoiando a mecânica central de construção de base, jogos deste gênero costumam envolver coleta de materiais, manejo de tropas e pensamento estratégico sobre a aplicação de recursos.

Nosso jogo pega elementos similares aos do jogo Kingdom: Two Crowns, um valor atípico no gênero por ter a perspectiva side-scroller, e desenvolve a bidimensionalidade, ausente em Kingdom, permitindo muito mais dinamismo estratégico e de exploração.

Entre os elementos que não são mantidos de Kingdom estão os cidadãos do reino como entidades com IA própria e geração procedural de níveis. Em Tÿrunn, o reino é construído com estruturas verticais como torres que o jogador pode construir em qualquer lugar válido, e o mapa é um ambiente explorável feito à mão e igual em todas as runs que o jogador fizer.

Efetivamente, ao invés do jogo depender da mecânica de geração procedural para criar rejogabilidade, o desenvolvimento estará focado em abrir um leque de possibilidades para que os jogadores experimentem com builds diferentes e criem reinos novos em busca de formas mais eficientes de jogar. Isto será feito através da implementação de múltiplos tipos de defesa e de um sistema de danos e resistências que gere uma mecânica intransitiva.

Para a protagonista, nos decidimos em design simplificado mas com uma forte linguagem de forma, sendo composta por um retângulo, um cone e um círculo, focando em tentar manter ela como uma personagem ambígua e fria para o jogador poder mais facilmente se imergir no lugar dela. A decisão também de uma protagonista distante entra em contrapartida com o design de cenário e construções, que possuem mais personalidade e destaque.

Imagem 1: Concept Art inicial digitalizada da Protagonista

O conceito das construções estão sendo desenvolvidos seguindo o tema nórdico. Em função do mesmo, para cada conceito houve uma consideração com a arquitetura e aspectos da cultura nórdica através de pesquisa, moodboards e análise, enquanto manteve-se uma determinada liberdade criativa de forma a criar construções interessantes e não repetitivas.

Imagem 2: Concept Art Fazenda

Imagem 3: Concept Art Serraria

Algumas das construções foram mais influenciadas por aspectos de arquitetura real, como demonstrado pelos conceitos da fazenda na Imagem 2. Porém, outras construções fugiram mais das referências reais, e foram mais modificadas com “elementos de fantasia” como pode ser observado nos conceitos da serraria na imagem 3, que possui uma grande serra. Esse mesmo elemento não faz sentido para a arquitetura e cultura representada, mas serve como ferramenta para destacar a construção e sua função no jogo. Sendo uma forte figura cultural que remete a utilidade da construção à mente do jogador.

2.1. Mecânicas

• Perspectiva sidescroller platformer
• Andar e pular
• Construir edificações
• Destruir monstros (tower defense)
• Gerenciamento de recursos
• Destruir portais (spawn de inimigos)

2.2. Personagens Não Jogáveis

Foram criados três inimigos diversificados que possuem características diferentes, oferecendo ao jogador desafios variados e proporcionando um maior nível de complexidade ao jogo.

2.2.1. Amálgama

Inimigo mais básico, assume forma de uma conjuntura de massa negra, se move mais rápido que o Voador e o Golem, porém é mais fraco, atacam em grupos.

• Movimentação unidimensional, sendo no eixo x
• Habilidade de atacar construções
• Habilidade de atacar o jogador

2.2.2. Voador

Uma evolução do Amálgama, ganha asas e a habilidade de atacar a distância.

• Movimentação bidimensional, sendo nos eixos x e y.
• Habilidade de atacar construções a distância.
• Habilidade de atacar o jogador a distância.

2.2.3. Golem

Inimigo terrestre, um golem de massa negra, lento, porém forte e resistente, podem destruir muros básicos com um só golpe.

• Movimentação unidimensional, sendo no eixo x.
• Habilidade de atacar construções.
• Habilidade de atacar o jogador.

2.3.Telas e Interfaces

2.3.1. Menu Principal

• Botão de Novo Jogo
• Botão de Selecionar Dificuldade
• Botão de Sair do Jogo

2.3.2. Interface durante o jogo

• Menu com recursos disponíveis atualmente para o jogador
• Menu com horário do dia e a quantidade de dias que se passaram desde o jogador começou o jogo
• Menu pop-up de seleção de construções ao interagir com o Main Hub
• Menu pop-up de oferenda no altar
• Menu pop-up de oferenda para acampamentos

3.DESIGN TÉCNICO

Nos parágrafos a seguir será apresentada a arquitetura geral do código do projeto

3.1.Motor de Jogo

Será utilizado o motor de jogo Godot 4.2, que implementa uma filosofia de design orientada a objeto com Nodes que podem ser instanciados múltiplas vezes.

Para os assets 2D e spritesheets de animação será utilizado o software Clip Studio Paint.

Para jogar o jogo será necessário baixar o executável em uma máquina com o sistema operacional Windows.

3.2. Descrição dos Scripts

O node principal do jogo cuida do carregamento de cenários e das funções de manager.

O node do jogador contém a classe PlayerMovement, que lida com a movimentação do personagem do jogador.

Inimigos herdam de uma classe base que contém comportamentos compartilhados, e seus nodes herdam de um node base que implementa outros nodes relacionados seguindo o padrão de design de composição.

Um sistema de vida e dano consiste de dois nodes que se comunicam através dos colisores de seus nodes pais.

Recursos são produzidos pelas construções e precisam ser coletados como itens que são instanciados pelas construções quando o jogador passa perto delas.

O mapa é baseado em um tilemap de blocagem, utilizado para formar a caixa de colisão do nível, e sprites são colocadas por cima livremente para compor a estética do cenário.

Há uma tela de carregamento que aparece quando o jogo carrega o mapa pela primeira vez. Planejamos ter mais áreas que carregam sem corte, utilizando funções de multi-threading do motor.

3.2.1. NavigationScript

Os inimigos têm um sistema de pathfinding criado para o projeto. Ele utiliza um sistema de áreas e andares: áreas servem como listas que carregam os possíveis alvos que um inimigo poderia ter, e os andares servem como indicação se o inimigo se encontra no mesmo nível/patamar que o alvo.

O inimigo sempre tentará ir para o alvo mais perto de si. Isso é feito por um cálculo de distância entre pontos, sendo esses: o Alvo, o Inimigo, e, caso haja, os P.T.As (pontos de transição de andar) A e B.

O Inimigo primeiro vê o alvo mais próximo de si na Área que ele está. Caso não encontre, ele refaz o cálculo para ver o Inimigo mais próximo de si no geral, procurando primeiro no andar em que ele está e armazenando essa informação para comparar com os alvos de outros andares, e então vai para qual a distância seja menor. Caso o alvo mais próximo se encontre em outro andar, o inimigo irá primeiro para o P.T.A entre si e o alvo.

3.3.Inteligência Artificial

De acordo com Shapiro: “Inteligência Artificial (IA) é definida como um campo de ciência e engenharia preocupada com o entendimento computacional do que é comumente chamado comportamento inteligente, e com a criação de artefatos que exibem tal comportamento” (tradução nossa).

Nesse projeto, a inteligência artificial dos inimigos consiste de um algoritmo de pathfinding e um de priorização de alvos baseado em tags que os guia para a base do jogador.

3.4.Delineamento de Testes

Abaixo seguem os testes realizados para validar o código do jogo.

3.4.1. Teste de Produção de Recursos:

• Descrição: Interagir com as construções várias vezes para comprar cargas de produção, e depois, passado o tempo de produção, coletar os recursos
• Um número de cargas foi adicionado à interface para facilitar a depuração
• Realizado por: Ricardo
• Resultado: iterações resultaram em um sistema funcional

3.4.2. Teste de Pathfinding

• Descrição: implementação de um node Label para o teste de seleção de alvos, que cumpre a função de informar qual alvo o inimigo está mirando
• Realizado por: Lucas
• Resultado: o sistema de Pathfinding foi implementado com sucesso

3.4.3. Teste de Tilemap

• Descrição: Criar um level protótipo usando o novo sistema de tilemap, buscando testar o pipeline de trabalho e a performance do sistema
• Realizado por: Ricardo
• Resultado: Deixar o tilemap com muitos tiles impede que o level carregue normalmente. Foi necessário aumentar o tamanho dos tiles individuais para cobrir o level pretendido.

3.5. Modelo de Dados

No momento do salvamento (que será automático ao início de cada manhã) o jogo registrará:

• O dia em que o jogador está (int)
• A presença de cada instância de construção que o jogador construiu (BuildingBaseClass[ ])
• O processo de produção de recursos, se aplicável (EconomyBuildingBaseClass[ ])
• Os pontos de vida de cada construção (int[ ])
• A posição do jogador no momento do salvamento (Vector2)
• Os pontos de vida do jogador (int)
• Os colecionáveis de progressão adquiridos (bool[ ])

3.6. Cronograma

Segue o cronograma seguido e esperado para o semestre de trabalho.

Imagem 4: Diagrama de Gantt

3.7. Mudanças após playtest

Após participar do evento “Test Night”, sediado na Univali no dia 8 de Novembro de 2024, e receber opiniões de jogadores, vários erros foram identificados e consertados, listados abaixo:

Erro: Cancelar o ato de construir faz com que a construção sempre seja cancelada automaticamente.

Solução: Chamar a função _reset_keys() quando a construção for cancelada para que a booleana de input não fique travada em true.

Erro: Destruir o primeiro portal faz com que o jogo sofra um crash na próxima noite.

Solução: Desconectar os sinais relativos à passagem do tempo uma vez que o portal seja destruído e não deletá-lo da memória, mantendo apenas invisível e inativo.

Erro: Serraria não gera itens após o jogador entrar na caixa de colisão da construção.

Solução: Criar uma variável que lembre durante todos os quadros em que o jogador permaneça dentro da caixa de colisão da construção.

Erro: Casas e Quartel não têm colisão pros inimigos destruírem

Solução: Adicionar um Collision Shape válido às duas construções.

Após o teste, foram implementadas dicas de controles nos menus que indiquem quando o jogador pode selecionar outras opções para construir e esquemas de controle alternativos, utilizando as setas do teclado e o botão enter.

4.CONSIDERAÇÕES FINAIS

O objetivo do projeto é criar um jogo que implemente elementos da jogabilidade de Kingdom: Two Crowns com uma estética nórdica e espaço de jogo vertical. Segue uma análise SWOT (Puyt, 2020) do projeto como um todo:

• Forças: Temática única, jogo engajante, exploração (não é comum em jogos base building), jogabilidade proativa (ao contrário de reativa), narrativa indireta

• Fraquezas: Pouca experiência do time no desenvolvimento de jogos desse gênero, interface pouco dinâmica, falta de polimento nas interações, gameplay repetitiva, falta de conteúdo, narrativa indireta
• Oportunidades: Temática inovadora, nichado (poucos competidores), poucos jogos desse gênero
• Ameaças: Nichado (público limitado)

A recepção do projeto no evento de testagem foi geralmente positiva, e mais engajada se comparada a eventos onde uma versão anterior do projeto foi demonstrada. Isso revela melhoras no produto e no processo de trabalho da equipe.

Num nível básico, o objetivo foi atingido. Resta desenvolver e polir de forma a encorpar o escopo e trazer mais conteúdo e refino para o produto, sempre buscando manter a coesão estética e criativa.

Vídeo com o código:

REFERÊNCIAS

Design Council UK. 11 Lessons: managing design in eleven global brands Desk research report [online] London: Design Council, 2007.

KOOMEN, C. J. The basic design cycle. The design of communicating systems: A system engineering approach. pp. 3- 10. Boston, MA: Springer US, 1991.

Shapiro SC. Artificial intelligence. In: Shapiro SC. (ed) Encyclopedia of Artificial Intelligence, vol. 1, 2nd edn. New York: Wiley, 1992. Acessado em: 09 out. 2024. Disponível em: https://cse.buffalo.edu/~shapiro/Papers/ai.pdf.

Puyt, Richard, et al. “Origins of SWOT Analysis.” Academy of Management Proceedings, vol. 2020, no. 1, Aug. 2020, p. 17416. DOI.org (Crossref), https://doi.org/10.5465/AMBPP.2020.132.

Ficha completa da equipe:

Pedro Antônio Cafiero Souza  - https://cafiero.itch.io

Guilherme Damiani Fretta - https://antiumbra.itch.io/

Lucas Jordano - https://lucas-jordano.itch.io/

Ricardo Menoncin - https://hairohukosu.itch.io/

Erik von Wangenheim - https://erik-von-wangenheim.itch.io/

Marcelo Dornbusch Lopes - Orientador - m4rc3lo

Universidade do Vale do Itajaí - UNIVALI

Cesar Albenes Zeferino | Diretor Escola Politécnica

Giorgio Gilwan | Coordenador do Curso de Design de Jogos

Rafael Kojiio | Coordenador Gamelab UNIVALI