• Importação e convenções:
  se a equipe não padroniza nomes, unidades (cm vs m), pivôs e níveis de LOD, qualquer engine vai virar gargalo.
  A diferença é que, em projetos Unity, eu consigo ajustar regras e automações de build com mais flexibilidade
  no ecossistema C#; no Unreal, eu aproveito as ferramentas internas de edição e visualização para
  revisar rapidamente “como vai ficar”.
• Fluxo de edição:
  Unreal tende a favorecer workflows voltados ao editor (principalmente para ambiente e iluminação),
  enquanto Unity costuma ser mais ágil para gameplay “codificado” com iterações curtas.
• Reprodutibilidade de resultados:
  eu me preocupo com builds consistentes.
  Em equipes grandes, o que mata é quando “na minha máquina funciona” por diferenças de versão, shaders ou settings.
  Por isso, independentemente da engine, eu trato:
  configurações de render, versões do runtime e política de dependências.

• Unity (componentes + ciclo de vida):
  eu organizo gameplay em MonoBehaviours e componentes com responsabilidades claras.
  Para performance, eu evito lógica pesada no Update e uso padrões como:
  caches de referência, menos alocações por frame e separação por sistemas (ex.: movimentação, combate, inventário).
• Unreal (atores + blueprints/c++):
  eu penso em Actors e componentes do lado do Unreal.
  Se o projeto precisa de alto controle e performance previsível, eu encaro C++ como base.
  Se o time precisa iterar rápido com designers, eu uso blueprints como camada de composição, mantendo a lógica crítica em C++.
• Interface de gameplay:
  eu defino contratos cedo:
  eventos (damage, hit, death), estados (stun, invulnerável), e fluxo de UI (HUD/menus).
  Isso reduz retrabalho quando o protótipo vira vertical slice.
• Dados e tuning:
  ambos suportam fluxos para parametrizar valores.
  O ponto é: não deixo balanceamento “espalhado”.
  Eu centralizo em assets/datasources e crio uma rota clara para validar mudanças (build + logs + testes manuais).

• CPU vs GPU:
  eu mapeio gargalos com métricas:
  CPU (lógica por frame, colisão, animação, instâncias) e GPU (overdraw, sombras, pós-process, complexidade de materiais).
  Se o seu jogo é “efeito pesado”, a escolha de engine importa, mas o maior ganho vem de reduzir passes e simplificar materiais.
• Shaders e materiais:
  Unity e Unreal têm caminhos diferentes para material workflow.
  Eu evito “shader monster”: materiais com muitas variações e branches desnecessárias.
  Em ambos, eu:
  limito instruções, uso LODs visuais, avalio mapas e normal detalhados apenas quando necessário.
• Iluminação e sombras:
  se você quer realismo alto, Unreal costuma entregar um caminho forte de iluminação.
  Em Unity, você consegue resultados bons, mas eu monto uma estratégia de performance:
  sombras limitadas, distância de culling, e política para iluminação dinâmica.
• Streaming e mundo aberto:
  no Unreal, o ecossistema de mundo e streaming é bem robusto.
  No Unity, eu também consigo escalar bem, mas preciso ser disciplinado com scene splitting, Addressables/asset loading e culling.

• Estratégia de assets:
  eu penso em memória e carregamento.
  Para projetos grandes, eu separo:
  assets por fase/bioma, gestão de texturas (resolução + compressão) e comportamento de carregamento assíncrono.
  Isso evita quedas e “travadas” na primeira visita a áreas novas.
• Testes por plataforma:
  eu não assumo que vai rodar igual em PC e console/móvel.
  Faço um checklist de performance:
  resolução alvo, escalonamento de render, limites de sombras e efeitos volumétricos.
  Em seguida, crio um baseline de frame time e comparo versões.
• Logs e diagnóstico:
  eu trato diagnósticos como feature.
  Logs de carregamento, contadores de pools/instâncias e tracking de eventos me deixam rápido na correção.
• Manutenção do projeto:
  versão de engine/runtime, pipeline de shaders e compatibilidade com drivers são parte do custo.
  Eu planejo isso cedo para evitar “downtime” quando precisar atualizar.

// Unity/C# — exemplo de "tick" com intervalo
using UnityEngine;

public class IntervalTick : MonoBehaviour
{
    [SerializeField] private float intervalSeconds = 0.2f;
    private float nextTickTime;

    private void OnEnable()
    {
        nextTickTime = Time.time + intervalSeconds;
    }

    private void Update()
    {
        // Em vez de rodar lógica pesada todo frame:
        if (Time.time < nextTickTime) return;

        nextTickTime += intervalSeconds;

        // Aqui entra o trabalho leve/necessário.
        // Ex.: checar distância, atualizar UI de status, recalcular alvo, etc.
        DoTick();
    }

    private void DoTick()
    {
        // Implementação do tick
    }
}

Observação: eu mantenho a lógica determinística quando necessário e ajusto o intervalo conforme a sensibilidade do sistema.
Para lógica crítica (combate, física), eu não “atraso” o gameplay; eu otimizo o conteúdo que entra no frame.