Entendendo a base de qualquer jogo na Unreal Engine

Quando começamos a criar jogos na Unreal Engine, é comum focar primeiro no que aparece na tela: personagem andando, câmera seguindo o jogador, inimigos atacando, barra de vida diminuindo e itens sendo coletados.

Mas, por trás dessas ações, existe uma estrutura que organiza quem controla o quê, onde ficam as regras do jogo e como os dados são compartilhados.

Essa estrutura é o Gameplay Framework.

Neste artigo, vamos entender as principais classes desse framework, como elas se conectam e como funciona a inicialização de elementos como GameInstance, GameMode, GameState, PlayerController, PlayerState e Character.

1. O que é um Gameplay Framework?

Um framework é, basicamente, um conjunto de classes, sistemas e ferramentas criado para oferecer uma base estrutural ao desenvolvimento de um projeto. Idealmente, essa base deve ser modular o suficiente para se adaptar a diferentes necessidades.

No caso da Unreal Engine, o Gameplay Framework ajuda a organizar a lógica de gameplay e a gerenciar elementos como PlayerController, AIController, Character, Pawn, GameMode, GameState, PlayerState, entre outros.

Isso permite que o desenvolvedor aproveite uma arquitetura já preparada pela engine, em vez de precisar construir toda a estrutura do jogo do zero.

Quando começamos a estudar Unreal, é comum focarmos primeiro no que queremos ver funcionando: o herói andando, a câmera seguindo o personagem, um inimigo atacando, uma barra de vida diminuindo, uma porta abrindo ou um item sendo coletado.

Tudo isso é empolgante, mas por trás dessas ações existe uma estrutura muito importante que vale a pena entender. Essa estrutura é justamente o Gameplay Framework.

Entender essa base evita muitos problemas comuns, principalmente quando o projeto começa a crescer.

2. Por que o Gameplay Framework importa?

Em um protótipo pequeno, é tentador colocar tudo dentro da classe mais direta que começamos a mexer. No meu caso, muitas vezes essa classe foi o PlayerCharacter.

No começo, isso parece funcionar bem. Colocamos input, movimento, vida, ataque, inventário, condições de vitória, UI e qualquer outra lógica diretamente no personagem. É rápido, visual e dá a sensação de progresso.

O problema aparece com o tempo.

A classe do personagem começa a crescer demais. Ela passa a controlar coisas que não deveriam ser responsabilidade dela. O que antes era simples de modificar se torna difícil de manter, debugar e reaproveitar.

A partir desse ponto, qualquer alteração pode quebrar outra parte do projeto. O desenvolvimento, que antes parecia fluido, começa a virar uma sequência de ajustes delicados para não destruir algo que já estava funcionando.

Para evitar esse problema, precisamos distribuir melhor as responsabilidades.

A Unreal já oferece uma separação natural para isso. O Gameplay Framework existe justamente para ajudar a dividir o peso entre várias classes pensadas para funções diferentes. Mas é importante lembrar: ele não remove a necessidade de pensar em arquitetura. O que ele oferece é uma base para que essa arquitetura não precise começar do zero.

A seguir, vamos falar das principais classes desse framework. Você não precisa decorar todas elas de uma vez. O mais importante é entender o papel de cada uma e começar a aplicar essa lógica nos seus próprios projetos.

No final, deixei um pequeno desafio para ajudar a fixar essas ideias.

3. Quais são as principais classes desse framework?

Para evitar confusão e não sair apenas listando vários nomes, acho útil separar essas classes em três grandes grupos: as classes de estrutura e regras, as classes de controle e possessão e as classes de mundo e apresentação.

Essa divisão não é uma regra oficial da Unreal. É apenas uma forma didática de entender o papel de cada classe dentro da arquitetura do jogo.

Classes de estrutura e regras

São responsáveis por manter o jogo organizado em alto nível.

Nesse grupo temos:

• GameInstance
• GameMode
• GameState
• PlayerState

Classes de controle e possessão

São responsáveis por conectar decisões e comandos a entidades controláveis.

Nesse grupo temos:

• Controller
• PlayerController
• AIController
• Pawn
• Character

Classes de mundo e apresentação

São responsáveis por representar objetos, componentes e a forma como o jogador percebe o jogo.

Nesse grupo temos:

• Actor
• ActorComponent
• Camera
• HUD
• UI

Em outras palavras:

Algumas classes organizam as regras, outras conectam o jogador ou a IA às entidades controláveis, e outras dão forma ao mundo que o jogador vê.

Analisando a hierarquia da Unreal, percebemos que muitas classes importantes do Gameplay Framework derivam de Actor, como Pawn, Character, Controller, GameMode, GameState, PlayerState, HUD e CameraActor.

Isso não significa que todas tenham o mesmo papel no mundo do jogo. Algumas representam entidades físicas, como personagens e objetos. Outras representam regras, estado, controle ou apresentação.

Por isso, mais importante do que decorar a árvore de herança é entender a responsabilidade de cada classe.

A partir daqui, vamos olhar para cada uma delas com mais calma.

4. Actor: a base de quase tudo

O Actor é a classe base para qualquer objeto que pode existir em um Level.

Um inimigo, uma porta, uma arma no chão, um projétil, uma plataforma móvel, um item coletável ou um volume de dano podem ser Actors.

De forma simples:

Se algo precisa existir no mundo do jogo, provavelmente será um Actor ou herdará de Actor.

Actors podem ter componentes, lógica própria, posição no mundo, eventos e comportamento. Mas um Actor, por si só, não significa necessariamente que ele é controlável pelo jogador.

Para isso, entramos no conceito de Pawn.

5. Pawn: algo que pode ser possuído

O Pawn representa uma entidade que pode ser controlada.

Pode ser um personagem humanoide, um carro, uma nave, uma câmera livre ou qualquer outra entidade que receba controle de um jogador ou de uma IA.

A palavra importante aqui é: possuído.

Na Unreal, um Pawn pode ser possuído por um Controller. Isso significa que a lógica de decisão pode ficar separada da entidade física que existe no mundo.

Um jeito simples de pensar é:

• O Pawn é o corpo.
• O Controller é quem dá as ordens.

Essa separação é muito poderosa, porque permite trocar quem controla o mesmo Pawn. Um personagem pode ser controlado pelo jogador em um momento e por uma IA em outro, dependendo da lógica do jogo.

6. Character: um Pawn especializado

O Character é uma versão especializada de Pawn, muito usada para personagens que se movimentam andando, pulando, caindo ou navegando pelo mundo.

Ele já vem com estruturas úteis, como:

• Capsule Component
• Skeletal Mesh
• Character Movement Component
• suporte a movimento comum de personagens
• integração com colisão e física de movimentação

Na prática, se você está criando um personagem jogável humanoide, um inimigo que anda pelo mapa ou um NPC com locomoção tradicional, provavelmente vai começar usando Character.

Mas isso não significa que tudo precisa ser Character.

Um carro, por exemplo, pode fazer mais sentido como Pawn. Uma câmera estratégica também. Uma nave espacial talvez precise de uma implementação própria.

A pergunta não deve ser apenas:

Posso fazer isso com Character?

A pergunta mais importante é:

Essa entidade realmente precisa do comportamento padrão de personagem da Unreal?

Se a resposta for sim, Character provavelmente é uma boa escolha. Se não, talvez um Pawn ou até um Actor seja suficiente.

7. PlayerController: a ponte entre o jogador e o jogo

O PlayerController representa o jogador dentro da lógica da Unreal.

Ele recebe input, interpreta intenções e controla um Pawn.

Isso é importante porque o PlayerController não é o personagem. Ele é a camada de controle do jogador. O personagem pode morrer, trocar, renascer ou ser substituído, mas o PlayerController continua representando aquele jogador.

Um exemplo comum:

• O jogador aperta o botão de ataque.
• O PlayerController, ou o sistema de input ligado a ele, interpreta esse comando.
• O Pawn ou Character executa a ação correspondente.

Em projetos pequenos, muita coisa acaba indo direto para o Character. Mas, em jogos mais estruturados, vale pensar melhor no que pertence ao PlayerController e no que pertence ao Character.

Regra prática:

• Input e intenção do jogador tendem a ficar no PlayerController ou em sistemas ligados a ele.
• Execução física da ação tende a ficar no Pawn ou Character.
• Regras gerais da partida não devem ficar em nenhum dos dois.

8. AIController: controle para personagens não jogáveis

Assim como o PlayerController controla um Pawn a partir das ações de um jogador humano, o AIController controla um Pawn a partir de lógica artificial.

Ele pode usar Behavior Trees, Blackboards, percepção, navegação e outros sistemas para decidir o que um inimigo ou NPC deve fazer.

Essa separação deixa a arquitetura mais limpa.

O inimigo não precisa ser “a IA inteira”. Ele pode ser apenas o corpo que executa ações, enquanto o AIController decide quando atacar, perseguir, patrulhar ou fugir.

9. GameMode: as regras do jogo

O GameMode define as regras principais da partida ou do modo de jogo.

Ele existe apenas no servidor em jogos multiplayer, mas mesmo em single-player continua sendo uma classe importante para organizar regras globais.

Exemplos de responsabilidades do GameMode:

• definir qual Pawn será usado pelo jogador
• controlar regras de início e fim da partida
• decidir condições de vitória ou derrota
• escolher PlayerController, GameState, HUD e classes padrão
• gerenciar regras específicas de um modo de jogo

Um erro comum é colocar regra de partida dentro do personagem.

Por exemplo:

Quando todos os inimigos morrerem, termina a fase.

Essa lógica não pertence ao Character do jogador. Ela provavelmente pertence ao GameMode, ao GameState ou a algum sistema específico de gerenciamento da fase.

A documentação da Unreal também separa bem os conceitos de GameMode e GameState: o GameMode concentra regras da partida, enquanto o GameState guarda informações sobre o estado atual do jogo.

10. GameState: o estado compartilhado da partida

O GameState armazena informações sobre o estado atual do jogo.

Se o GameMode define as regras, o GameState representa os dados que descrevem como a partida está neste momento.

Exemplos:

• tempo restante da partida
• pontuação dos times
• estado atual da fase
• número de jogadores conectados
• informações que precisam ser conhecidas por todos os jogadores

Em multiplayer, o GameState é especialmente importante porque pode replicar informações para os clientes.

Uma forma simples de pensar:

• GameMode: decide as regras.
• GameState: informa o estado atual dessas regras.

11. PlayerState: informações de cada jogador

O PlayerState guarda dados relacionados a um jogador específico.

Ele é útil para informações que pertencem ao jogador, mas não necessariamente ao Pawn atual.

Exemplos:

• nome do jogador
• pontuação
• time
• quantidade de mortes
• estatísticas da partida
• dados que continuam existindo mesmo se o personagem morrer e renascer

Isso é diferente de guardar vida, stamina ou munição atual do personagem. Esses dados normalmente pertencem ao Pawn, ao Character ou a algum componente dele.

Mas a pontuação do jogador, por exemplo, faz mais sentido no PlayerState.

12. HUD e UI: apresentação não é regra de jogo

A Unreal também possui classes relacionadas à interface, como HUD e Widgets.

Um ponto importante é não misturar UI com regra de jogo.

A barra de vida mostra a vida, mas ela não deve ser a dona da vida. O widget pode observar ou receber dados do personagem, de um componente ou de algum sistema, mas a lógica real precisa estar em outro lugar.

Uma boa separação seria:

• O Character ou um componente de atributos guarda a vida.
• Algum evento avisa que a vida mudou.
• O Widget atualiza a barra visual.

Assim, a interface apenas apresenta o estado do jogo, sem controlar diretamente a regra principal.

13. Como essas classes se conectam?

Uma estrutura comum seria:

GameMode
 ├── Define regras da partida
 ├── Escolhe classes padrão
 └── Controla início/fim do jogo

GameState
 └── Guarda estado geral da partida

PlayerController
 └── Recebe input e controla um Pawn

PlayerState
 └── Guarda dados persistentes do jogador

Pawn / Character
 └── Representa a entidade controlada no mundo

AIController
 └── Controla Pawns inimigos ou NPCs

HUD / Widgets
 └── Mostram informações para o jogador

O ponto central é que cada classe tem uma responsabilidade.

Quando essas responsabilidades ficam claras, o projeto cresce de forma mais saudável.

14. Em que ordem essas classes aparecem no jogo?

Além de entender a responsabilidade de cada classe, também é importante entender quando elas entram em cena.

Uma dúvida muito comum ao estudar Unreal é:

Onde eu coloco minha lógica de inicialização?

A resposta depende bastante de qual classe você está usando e do momento em que aquela classe existe dentro do jogo.

De forma simplificada, podemos pensar em uma sequência parecida com esta:

Jogo inicia
 └── GameInstance é criada

Um mapa/level é carregado
 ├── GameMode é criado
 ├── GameState é criado
 └── Actors do mundo começam a ser inicializados

Um jogador entra na partida
 ├── PlayerController é criado
 ├── PlayerState é criado
 ├── Pawn/Character é spawnado
 └── PlayerController possui o Pawn/Character

Gameplay começa
 ├── BeginPlay dos Actors
 ├── lógica de input
 ├── UI
 └── sistemas de gameplay em execução

Essa sequência é uma simplificação didática. A ordem exata pode variar dependendo do contexto, principalmente em multiplayer, seamless travel, level streaming, respawn, troca de mapas e configurações específicas do projeto.

Ainda assim, ela ajuda a entender uma ideia importante: algumas classes pertencem à execução inteira do jogo, outras pertencem ao mapa ou modo de jogo, outras ao jogador, e outras ao corpo que existe no mundo.

GameInstance: nasce com o jogo e sobrevive entre mapas

A GameInstance é uma das primeiras classes importantes a existir.

Ela é criada quando o jogo inicia e continua viva enquanto o jogo estiver rodando. Diferente de classes como GameMode e GameState, ela não é recriada toda vez que você troca de mapa.

Por isso, ela é útil para dados e sistemas que precisam sobreviver entre fases.

Exemplos de uso:

• dados de sessão
• configurações globais
• referência para sistemas persistentes
• dados temporários entre mapas
• estado geral do jogo fora de uma fase específica

Mas é importante ter cuidado: a GameInstance não deve virar um depósito global para qualquer coisa.

Ela não é o melhor lugar para lógica específica de combate, vida do personagem, regras de uma fase ou comportamento de inimigos.

Uma boa pergunta para decidir se algo pertence à GameInstance é:

Essa informação precisa continuar existindo mesmo quando eu trocar de mapa?

Se a resposta for sim, talvez faça sentido estar na GameInstance.

GameMode: nasce com o mapa e define as regras da partida

O GameMode é criado quando um mapa é carregado e define as regras principais daquele modo de jogo.

Ele decide, por exemplo, qual PlayerController, Pawn, HUD, GameState e outras classes padrão serão usadas naquele mapa ou modo de jogo.

É aqui que entram regras como:

• como a partida começa
• como a partida termina
• qual personagem será usado pelo jogador
• o que acontece quando o jogador morre
• como um novo jogador entra no jogo
• quais são as condições de vitória ou derrota

Em multiplayer, o GameMode existe apenas no servidor. Isso é muito importante. Se você colocar uma informação no GameMode esperando que todos os clientes acessem diretamente, pode ter problemas.

Regra prática:

O GameMode decide as regras, mas não é o melhor lugar para guardar informações que todos os jogadores precisam enxergar diretamente.

Para isso, usamos o GameState.

GameState: nasce com a partida e guarda o estado compartilhado

O GameState também existe durante a partida, mas tem uma função diferente do GameMode.

Enquanto o GameMode define e executa regras, o GameState guarda informações sobre o estado atual do jogo.

Exemplos:

• tempo restante
• pontuação geral
• estado atual da fase
• quantidade de inimigos vivos
• fase em andamento
• objetivo atual
• dados que precisam ser conhecidos por todos os jogadores

Uma forma simples de separar é:

GameMode  -> decide o que deve acontecer
GameState -> mostra em que estado o jogo está agora

Por exemplo, se todos os inimigos morrerem, o GameMode pode decidir que a fase acabou. Mas o número de inimigos restantes pode estar no GameState, especialmente se essa informação precisar aparecer para outros jogadores ou para a UI.

PlayerController: nasce quando o jogador entra

O PlayerController representa o jogador dentro da partida.

Ele costuma ser criado quando o jogador entra no jogo. Depois disso, ele pode possuir um Pawn ou Character.

Um ponto importante é que o PlayerController pode continuar existindo mesmo se o personagem morrer, for destruído ou for substituído.

Isso faz dele um bom lugar para lógicas relacionadas à intenção do jogador, como:

• input
• comandos de câmera
• abertura de menus
• seleção de alvo
• interação com UI
• lógica de controle que não deve morrer junto com o personagem

Mas ele não deve ser usado como depósito para tudo.

A vida do personagem, por exemplo, normalmente não deveria estar no PlayerController, porque a vida pertence ao corpo controlado, não ao jogador abstrato.

PlayerState: nasce para guardar dados do jogador

O PlayerState guarda informações sobre um jogador específico dentro da partida.

Ele é muito útil para dados que pertencem ao jogador, mas que não deveriam ser perdidos quando o personagem morre.

Exemplos:

• nome do jogador
• pontuação
• time
• número de mortes
• estatísticas da partida
• progresso dentro daquela partida

A diferença entre PlayerController, PlayerState e Character pode parecer confusa no início, mas uma forma simples de pensar é:

PlayerController -> o jogador dando comandos
PlayerState      -> os dados do jogador na partida
Character        -> o corpo do jogador no mundo

Se o personagem morrer e renascer, o PlayerState pode continuar guardando a pontuação. Já o Character anterior pode ter sido destruído.

Pawn ou Character: nasce quando algo controlável aparece no mundo

O Pawn ou Character normalmente é criado quando o jogo precisa colocar uma entidade controlável no mundo.

No caso do jogador, o GameMode pode definir qual classe de DefaultPawn será usada. Depois, o PlayerController possui esse Pawn.

No caso de inimigos, eles podem ser colocados diretamente no mapa ou spawnados durante o jogo. Depois, podem ser controlados por um AIController.

O Character deve guardar informações e comportamentos ligados ao corpo físico no mundo, como:

• movimento
• colisão
• vida atual
• stamina atual
• animações
• ataque
• dano recebido
• interação física com o ambiente

Regra prática:

Se a lógica depende do corpo que existe no mundo, provavelmente ela pertence ao Pawn, ao Character ou a algum componente ligado a ele.

HUD e UI: geralmente entram depois que já existe contexto de jogo

A interface normalmente depende de dados que vêm de outras classes.

Por exemplo, uma barra de vida precisa saber qual personagem está sendo observado. Um contador de inimigos precisa saber o estado da fase. Uma tela de vitória precisa saber que a partida terminou.

Por isso, é comum que a UI seja criada ou atualizada depois que já existem referências para PlayerController, PlayerState, Character ou GameState.

Mas a UI deve apenas apresentar informações ou enviar intenções do jogador. Ela não deve ser a dona das regras principais.

Por exemplo:

Errado:
Widget decide se o jogador morreu.

Melhor:
Character ou sistema de atributos detecta a morte.
GameMode ou outro sistema decide o que acontece depois.
Widget apenas mostra a tela de derrota.

15. Onde colocar lógica de inicialização?

Uma forma prática de pensar é separar a inicialização por escopo:

Escopo	Classe provável	Exemplos
Jogo inteiro	GameInstance	configurações globais, dados entre mapas, sistemas persistentes
Fase ou modo de jogo	GameMode / GameState	iniciar rodada, controlar condição de vitória, armazenar estado da partida
Jogador	PlayerController / PlayerState	input, HUD do jogador, pontuação individual, time
Corpo no mundo	Pawn / Character / componentes	vida, stamina, movimento, ataques, colisão
Visual	HUD / Widgets	barra de vida, objetivo atual, mensagens, telas de vitória/derrota

16. Exemplo prático: um jogo de ação simples

Imagine um jogo de ação em terceira pessoa.

O jogador controla um personagem que pode andar, atacar, esquivar e derrotar inimigos. A fase termina quando todos os inimigos são eliminados.

Uma possível divisão seria:

GameInstance

Responsável por:

• manter configurações globais
• guardar dados temporários entre mapas
• armazenar referências para sistemas persistentes, se necessário

GameMode

Responsável por:

• iniciar a fase
• verificar condição de vitória
• definir o que acontece quando o jogador morre
• decidir quando a partida termina

GameState

Responsável por:

• quantidade de inimigos restantes
• estado atual da fase
• tempo de partida, se existir

PlayerState

Responsável por:

• pontuação do jogador
• número de mortes
• time, caso exista
• dados do jogador que continuam após respawn

PlayerCharacter

Responsável por:

• movimento
• ataque
• esquiva
• animações
• colisão
• atributos como vida e stamina, talvez por componentes

PlayerController

Responsável por:

• input do jogador
• troca de alvo
• comandos de câmera
• abertura de menus
• interpretação da intenção do jogador

AIController

Responsável por:

• lógica de perseguição
• decisão de ataque
• patrulha
• reação ao jogador

UI

Responsável por:

• mostrar vida
• mostrar stamina
• mostrar objetivo atual
• exibir tela de vitória ou derrota

Essa organização evita que o Character vire o “deus” do projeto.

17. O erro mais comum: colocar tudo no Character

No começo, parece natural colocar tudo no personagem, porque ele está no centro da experiência.

Mas isso cria vários problemas:

• o Character fica difícil de entender
• qualquer mudança pode quebrar várias partes do jogo
• a lógica não pode ser reaproveitada com facilidade
• multiplayer fica mais complicado
• sistemas como IA, UI e regras de fase ficam acoplados demais

Uma boa arquitetura não significa criar dezenas de classes sem necessidade. Significa colocar cada responsabilidade no lugar certo.

O objetivo não é complicar o projeto. É evitar que tudo dependa de uma única classe.

18. Blueprint ou C++?

As classes que vimos aqui podem ser usadas tanto em Blueprint quanto em C++.

Blueprint é excelente para prototipagem, iteração rápida e lógica visual. C++ é poderoso para sistemas mais robustos, performance, organização em larga escala e criação de bases reutilizáveis.

Uma abordagem comum é:

• criar a base em C++
• expor variáveis e eventos para Blueprint
• ajustar comportamento e balanceamento no editor

Mas, para aprender o Gameplay Framework, Blueprint pode ser uma ótima porta de entrada. O mais importante é entender a arquitetura antes de se preocupar demais com a linguagem.

Antes de perguntar “isso deve ser Blueprint ou C++?”, vale perguntar:

Onde essa responsabilidade deveria existir dentro da estrutura do jogo?

Depois que essa resposta fica clara, escolher entre Blueprint e C++ se torna uma decisão muito mais simples.

Conclusão

O Gameplay Framework é uma das bases mais importantes para quem quer se aprofundar em Unreal Engine.

Ele não é apenas uma lista de classes para decorar. Ele é uma forma de pensar a estrutura do jogo.

Quando você entende a diferença entre Actor, Pawn, Character, PlayerController, GameMode, GameState, PlayerState e GameInstance, começa a tomar decisões melhores sobre onde colocar cada parte da lógica.

Mas existe outro ponto tão importante quanto saber o papel de cada classe: entender quando cada uma existe.

A GameInstance acompanha a execução do jogo. O GameMode e o GameState organizam a partida. O PlayerController representa o jogador. O PlayerState guarda dados daquele jogador. O Character representa o corpo no mundo. A UI apresenta informações para quem está jogando.

Quando essa separação fica clara, o projeto cresce de forma mais saudável.

Principalmente em jogos maiores, separar bem responsabilidades é o que permite que o jogo continue evoluindo sem virar uma bagunça difícil de manter.

Desafio

Pense em um jogo simples que você gostaria de criar, como um jogo de ação, plataforma, terror ou aventura.

Agora tente responder:

• O que precisa existir desde o início do jogo e sobreviver entre mapas?
• O que deve ser configurado quando a fase começa?
• O que ficaria no Character?
• O que ficaria no PlayerController?
• Quais regras pertenceriam ao GameMode?
• Quais informações deveriam ir para o GameState?
• Que dados fariam sentido no PlayerState?
• A UI está apenas mostrando informações ou também está controlando regras do jogo?

Esse exercício ajuda a transformar o Gameplay Framework em algo prático, e não apenas em uma lista de classes da Unreal.

Referência

Este artigo foi baseado na documentação oficial da Unreal Engine da Epic Games sobre o Gameplay Framework da Unreal Engine.