Empacotamento (Packaging) do projeto e verificação final de gameplay

O que é “Packaging” e por que ele muda o comportamento do jogo

Empacotamento (Packaging) é o processo de gerar uma versão executável do seu projeto para uma plataforma-alvo (Windows, Android, etc.). Diferente de jogar no Editor (PIE/Standalone), a build empacotada roda com outro conjunto de regras: só leva os arquivos “cozidos” (cooked) e incluídos no pacote, usa o mapa inicial configurado nas Project Settings, pode aplicar qualidade diferente, e expõe problemas comuns como assets não referenciados, mapas fora da lista e referências quebradas.

Objetivo deste capítulo: configurar o projeto para build, gerar uma build de teste, checar a saída gerada e validar se o gameplay funciona fora do Editor (interações, HUD, áudio, partículas, checkpoints e pontuação).

Configurações essenciais em Project Settings (antes de empacotar)

1) Mapas padrão (Game Default Map e Editor Startup Map)

O erro mais comum em build é abrir um mapa vazio ou errado. Configure explicitamente:

• Edit > Project Settings > Maps & Modes
• Game Default Map: mapa que deve abrir na build
• Editor Startup Map: mapa que abre ao iniciar o Editor (não afeta a build, mas evita confusão)
• Default GameMode: confirme se o GameMode correto está definido (ou se cada mapa sobrescreve isso em World Settings)

2) Plataforma-alvo e opções de empacotamento

As opções de build ficam em:

• Edit > Project Settings > Packaging

Configurações recomendadas para uma build de teste (iterar rápido):

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Build Configuration: Development (mais fácil de diagnosticar do que Shipping)
• Use Pak File: ligado (gera arquivos .pak; facilita distribuição e reduz arquivos soltos)
• Include Prerequisites Installer (Windows): ligado se você for enviar para outra máquina
• Full Rebuild: desligado para builds frequentes; ligue quando suspeitar de lixo de build
• For Distribution: desligado em testes (use apenas quando for publicar)

3) Lista de mapas incluídos na build

Mesmo que um mapa exista no Content Browser, ele pode não entrar no pacote se não estiver referenciado. Para garantir:

• Project Settings > Packaging > List of maps to include in a packaged build
• Adicione: mapa inicial, mapas de gameplay, mapas de menu (se houver), mapas de teste que você realmente precisa

Dica prática: se você tem um mapa de “MainMenu” que carrega o mapa de gameplay via Open Level, inclua ambos na lista.

4) Qualidade e escalabilidade (para evitar diferenças grandes entre Editor e build)

Diferenças de qualidade podem afetar VFX, pós-processamento e até performance que altera a sensação de input. Para padronizar:

• Teste a build com configurações de escalabilidade próximas do alvo (Low/Medium/High)
• Se você usa Niagara, valide se os efeitos aparecem em qualidade baixa (alguns sistemas podem ser reduzidos/desativados por escalabilidade)

Em projetos iniciantes, a prática mais segura é testar pelo menos em Medium e Low para garantir que feedbacks essenciais (partículas de interação, hit, coleta) não desapareçam.

5) Input: garantindo que controles funcionem fora do Editor

O input pode falhar na build por foco de janela, modo de input e captura do mouse. Verifique:

• Se o jogo inicia em modo UI e não captura input do personagem, revise o fluxo inicial (por exemplo, se um menu UMG está definindo Set Input Mode UI Only e não volta para Game Only ou Game and UI)
• Se usa mouse-look, confirme que o cursor está oculto quando necessário e que há captura do mouse

Para builds de teste, evite depender de cliques no viewport do Editor para “ativar” o input: na build, o jogo já deve iniciar pronto para receber comandos.

Passo a passo: criando uma build de teste (Windows como exemplo)

1) Preparar o projeto

• Salve tudo (mapas e Blueprints)
• Feche janelas de Play/Simulate
• Se houver warnings críticos no Output Log relacionados a assets ausentes, resolva antes

2) Selecionar plataforma

• No topo do Editor: Platforms (ou File > Package Project, dependendo da versão)
• Escolha Windows (64-bit)

3) Iniciar o empacotamento

• Escolha uma pasta de saída (ex.: Builds/Windows_Test_Dev)
• Acompanhe o progresso no canto inferior direito e/ou no Output Log

4) Validar a saída gerada

Ao final, você deve ter uma estrutura semelhante a:

Windows_Test_Dev/YourProjectName.exeWindows_Test_Dev/YourProjectName/Content/Paks/...

Checagens rápidas:

• Existe um .exe (Windows) e a pasta de conteúdo/paks
• O tamanho do pacote parece coerente (se ficou “pequeno demais”, pode ter faltado conteúdo)
• Execute o .exe diretamente (não pelo Editor)

Checklist de verificação final de gameplay (fora do Editor)

Use esta lista como roteiro de QA rápido. A ideia é detectar problemas típicos de build: referências não cozidas, mapas não incluídos, diferenças de performance e inicialização.

1) Fluxo de início e mapa correto

• O jogo abre no mapa esperado (menu ou gameplay)?
• Se há menu, o botão “Jogar” carrega o mapa correto?
• O GameMode correto está ativo (regras, HUD, pontuação)?

2) Interações principais

• Interagir/usar/pegar funciona sem precisar “clicar na janela” primeiro?
• Objetos interativos respondem com o feedback esperado (som/VFX/HUD)?
• Não há interações “fantasmas” (ex.: prompt aparece sem objeto)?

3) HUD e feedback visual

• HUD aparece ao iniciar (sem widgets duplicados)?
• Textos/ícones atualizam (pontuação, prompts, estado)?
• Escala e ancoragem estão corretas na resolução alvo (teste ao menos 1080p e uma resolução menor)

4) Áudio

• SFX essenciais tocam (coleta, interação, dano, UI)?
• Música/ambiente inicia e faz loop como esperado?
• Volumes estão equilibrados (Master/Music/SFX se houver)?

5) Partículas e VFX (Niagara)

• VFX de ações importantes aparecem (coleta, impacto, checkpoint)?
• Não há VFX “sumindo” em qualidade baixa (teste escalabilidade Low/Medium)?
• Performance: VFX não causa travadas perceptíveis em momentos críticos

6) Checkpoints e respawn

• Checkpoint ativa e dá feedback (HUD/áudio/VFX)?
• Ao morrer/respawnar, o jogador volta ao último checkpoint correto?
• Após respawn, input e câmera continuam funcionando?

7) Pontuação e regras

• Pontuação incrementa ao coletar/atingir objetivos?
• Ao reiniciar fase ou morrer, a pontuação se comporta como planejado?
• Se há tela de fim, ela aparece e mostra valores corretos?

8) Performance e estabilidade

• Sem travamentos ao carregar mapa
• Sem quedas bruscas de FPS em áreas com muitos efeitos
• Sem congelar ao pausar/abrir menu

Resolução de problemas comuns (passo a passo)

Problema A: A build abre no mapa errado (ou mapa vazio)

Sintomas: o jogo inicia em um level de teste antigo, um mapa vazio, ou cai em um “default” inesperado.

Passo a passo para corrigir:

1. Abra Project Settings > Maps & Modes e defina Game Default Map para o mapa correto.
2. Verifique se o mapa inicial está na lista: Project Settings > Packaging > List of maps to include....
3. Se você usa carregamento por Blueprint (ex.: Open Level), confirme que o nome do mapa está correto (sem typos) e que o mapa existe com esse nome.
4. Re-empacote em Development e teste novamente.

Problema B: Assets faltando na build (materiais, sons, VFX, widgets)

Sintomas: objetos aparecem sem material, sons não tocam, partículas não aparecem, widgets não carregam.

Causas comuns: assets não referenciados diretamente (referência “solta”), conteúdo não cozido, ou dependências quebradas.

Passo a passo para corrigir:

1. Identifique o asset faltando (ex.: qual som, qual Niagara System, qual Widget Blueprint).
2. Garanta que ele esteja sendo referenciado por algo que entra na build (por exemplo: um Blueprint colocado no mapa, um DataAsset usado, um Widget criado no fluxo principal). Assets que só existem “na pasta” podem não ser cozidos.
3. Se o asset é carregado dinamicamente por caminho/nome, prefira uma referência direta (variável do tipo do asset) em um Blueprint que sempre entra no pacote.
4. Confira o Output Log durante o packaging: procure por mensagens de Warning/Error indicando falha ao encontrar arquivo.
5. Ative Full Rebuild uma vez e empacote novamente para eliminar cache de build.

Problema C: Referências quebradas (Blueprints funcionam no Editor, mas falham na build)

Sintomas: interações param de funcionar, HUD não atualiza, eventos não disparam, mas no Editor parecia ok.

Causas comuns: dependência de objetos do Editor, ordem de inicialização diferente, referências não válidas no BeginPlay, ou assets renomeados/movidos sem atualizar tudo.

Passo a passo para corrigir:

1. Rode a build em Development e reproduza o problema.
2. Volte ao Editor e procure por referências “None” em variáveis expostas (especialmente em Blueprints colocados no mapa).
3. Verifique se o fluxo de inicialização depende de algo que pode não existir no momento (ex.: buscar HUD/PlayerState cedo demais). Garanta checagens de validade antes de usar referências.
4. Abra os Blueprints envolvidos e compile todos; corrija warnings de compilação.
5. Se houve renomeação/movimentação de assets, use o sistema de redirectors do Content Browser (corrigir redirectors na pasta) e recompile.
6. Re-empacote com Full Rebuild para garantir que a build não está usando dados antigos.

Rotina recomendada de “build de teste” durante o desenvolvimento