Por que o Lua se destaca na incorporação e em scripts para jogos

Lua em um Minuto: o que “incorporar” realmente significa

“Incorporar” uma linguagem de script significa que sua aplicação (por exemplo, um motor de jogo) vem com um runtime da linguagem embutido, e seu código chama esse runtime para carregar e executar scripts. O jogador não inicia o Lua separadamente, não o instala nem gerencia pacotes; ele faz parte do jogo.

Em contraste, scripting standalone é quando um script roda em seu próprio interpretador ou ferramenta (como executar um script pela linha de comando). Isso pode ser ótimo para automação, mas é um modelo diferente: sua app não é o host; o interpretador é.

Por que jogos incorporam linguagens de script

Jogos são um mix de sistemas que precisam de velocidades de iteração diferentes. Código de motor de baixo nível (renderização, física, threading) se beneficia de performance em C/C++ e controle estrito. Lógica de gameplay, fluxos de UI, quests, balanceamento de itens e comportamentos de inimigos se beneficiam de serem editáveis rapidamente sem recompilar o jogo todo.

Incorporar uma linguagem permite às equipes:

• mudar regras de gameplay mais rápido (frequentemente sem compilar tudo)
• manter o código do motor estável enquanto o conteúdo evolui
• permitir que designers e artistas técnicos contribuam com segurança
• construir pipelines de modding ou atualização ao vivo quando apropriado

O que “linguagem de escolha” quer dizer aqui

Quando se diz que Lua é a “linguagem de escolha” para incorporação, normalmente não significa que ela seja perfeita para tudo. Significa que ela foi testada em produção, tem padrões de integração previsíveis e faz trade-offs práticos que caem bem para jogos enviados: runtime pequeno, boa performance e uma API em C amigável que já foi muito usada durante anos.

O que este post vai cobrir

A seguir veremos o footprint e performance do Lua, como a integração C/C++ normalmente funciona, o que corrotinas permitem para o fluxo de gameplay e como tabelas/metatables suportam design orientado a dados. Também cobriremos opções de sandboxing, manutenibilidade, ferramentas, comparações com outras linguagens e uma checklist de boas práticas para decidir se Lua se encaixa no seu motor.

Footprint pequeno, fácil de distribuir

O interpretador do Lua é famoso por ser enxuto. Isso importa em jogos porque cada megabyte extra afeta tamanho de download, tempo de patch, pressão de memória e até requisitos de certificação em algumas plataformas. Um runtime compacto também tende a iniciar rápido, o que ajuda ferramentas de editor, consoles de scripting e fluxos de iteração rápidos.

Tamanho do interpretador pequeno, baixo uso de memória

O core do Lua é leve: menos partes móveis, menos subsistemas ocultos e um modelo de memória que você consegue raciocinar. Para muitas equipes, isso se traduz em overhead previsível — seu motor e conteúdo normalmente dominam a memória, não a VM de script.

Fácil de distribuir em várias plataformas

Portabilidade é onde um core pequeno realmente compensa. Lua é escrito em C portátil e é comumente usado em desktop, consoles e mobile. Se seu motor já compila C/C++ para múltiplos alvos, Lua costuma se encaixar nesse mesmo pipeline sem ferramentas especiais. Isso reduz surpresas de plataforma, como comportamento diferente ou funcionalidades do runtime faltando.

Dependências mínimas, história de build simples

Lua geralmente é compilado como uma pequena biblioteca estática ou diretamente embutido no seu projeto. Não há um runtime pesado a instalar nem uma grande árvore de dependências para alinhar. Menos peças externas significam menos conflitos de versão, menos ciclos de updates de segurança e menos pontos onde builds podem quebrar — especialmente valioso para branches de jogo com longa vida.

Por que um core pequeno importa para jogos e ferramentas

Um runtime de script leve não é apenas sobre distribuição. Ele habilita scripts em mais lugares — utilitários do editor, ferramentas de mod, lógica de UI, lógica de quests e testes automatizados — sem parecer que você está “adicionando uma plataforma inteira” à base de código. Essa flexibilidade é uma grande razão para equipes escolherem Lua quando incorporam uma linguagem em um motor de jogo.

Performance onde jogos precisam

Equipes de jogos raramente precisam que scripts sejam “o código mais rápido do projeto”. Elas precisam que os scripts sejam rápidos o suficiente para que designers possam iterar sem arruinar o frame rate, e previsíveis o bastante para que picos sejam fáceis de diagnosticar.

O que significa “rápido o suficiente” para scripting de gameplay

Para a maioria dos títulos, “rápido o suficiente” é medido em milissegundos por orçamento de frame. Se seu trabalho de scripting ficar dentro da fatia destinada à lógica de gameplay (frequentemente uma fração do frame), os jogadores não notarão. O objetivo não é vencer C++ otimizado; é manter o trabalho por frame estável e evitar picos de garbage ou alocações.

Como a VM e o bytecode do Lua ajudam

Lua executa código dentro de uma pequena máquina virtual. Sua fonte é compilada para bytecode e então executada pela VM. Em produção, isso permite enviar chunks pré-compilados, reduzindo overhead de parsing em runtime e mantendo a execução relativamente consistente.

A VM do Lua também é sintonizada para as operações que scripts fazem constantemente — chamadas de função, acesso a tabelas e branching — então a lógica típica de gameplay tende a rodar bem mesmo em plataformas restritas.

Onde o Lua brilha (e onde não deveria)

Lua é comumente usado para:

• lógica de decisão de IA (state machines, regras de comportamento)
• fluxo de UI e lógica de menus
• quests, triggers, diálogos, cutscenes
• configuração de entidades e comportamentos orientados a dados

Lua não costuma ser usada em loops internos quentes como integração de física, skinning de animação, kernels de pathfinding ou simulação de partículas. Esses ficam em C/C++ e são expostos ao Lua como funções de nível superior.

Evitar armadilhas comuns de performance

Alguns hábitos mantêm o Lua rápido em projetos reais:

• Minimize alocações por frame: reutilize tabelas, cacheie objetos usados frequentemente e evite construir tabelas temporárias em atualizações críticas.
• Reduza churn de tabelas: criar e descartar tabelas aninhadas repetidamente pode criar pressão de memória e tempos de frame irregulares.
• Cacheie lookups: armazene referências a funções ou campos que você chama a cada frame (por exemplo, localize globais) para reduzir buscas em hash repetidas.
• Empurre trabalho para APIs do motor: deixe o Lua orquestrar e deixe C/C++ fazer o trabalho pesado em lotes.

Um modelo prático e bem testado de integração C/C++

Lua ganhou sua reputação em motores de jogo em grande parte porque sua história de integração é simples e previsível. Lua é distribuído como uma pequena biblioteca em C, e a Lua C API é projetada em torno de uma ideia clara: seu motor e os scripts se comunicam através de uma interface baseada em pilha.

Por que a C API parece direta

No lado do motor, você cria um estado Lua, carrega scripts e chama funções empurrando valores numa pilha. Não é “mágica”, o que é exatamente o porquê de ser confiável: você pode ver cada valor cruzando a fronteira, validar tipos e decidir como erros são tratados.

Um fluxo de chamada típico é:

• O motor empurra função + argumentos
• O motor solicita a chamada
• O motor lê valores de retorno

Chamar C/C++ a partir de Lua e Lua a partir de C/C++

Ir de C/C++ → Lua é ótimo para decisões scriptadas: escolhas de IA, lógica de quests, regras de UI ou fórmulas de habilidades.

Ir de Lua → C/C++ é ideal para ações do motor: spawnar entidades, tocar áudio, consultar física ou enviar mensagens de rede. Você expõe funções C ao Lua, frequentemente agrupadas em uma tabela estilo módulo:

lua_register(L, "PlaySound", PlaySound_C);

Do lado do script, a chamada é natural:

PlaySound("explosion_big")

Estratégias de binding: manual vs geradores

Bindings manuais (cola escrita à mão) permanecem pequenos e explícitos — perfeitos quando você expõe apenas uma API curada.

Geradores (abordagens estilo SWIG ou ferramentas de reflexão customizadas) podem acelerar APIs grandes, mas podem expor demais, amarrar você a padrões específicos ou produzir mensagens de erro confusas. Muitas equipes misturam ambos: geradores para tipos de dados, bindings manuais para funções voltadas a gameplay.

Padrões comuns que escalam

Motores bem estruturados raramente despejam “tudo” no Lua. Em vez disso, expõem serviços focados e APIs de componentes:

• Services: Audio, Input, Save/Load, Analytics (cada um como uma tabela/módulo em Lua)
• Components: Entity:GetTransform(), Character:AddStatus(), Inventory:HasItem()
• Callbacks do motor: OnSpawn, OnUpdate, OnDamage — Lua implementa comportamento, C++ controla timing e segurança

Essa divisão mantém scripts expressivos enquanto o motor retém controle sobre sistemas críticos de performance e guardrails.

Corrotinas para fluxo de gameplay e scripts estilo async

As corrotinas do Lua combinam naturalmente com lógica de gameplay porque deixam scripts pausar e retomar sem travar o jogo. Em vez de dividir uma quest ou cutscene em dezenas de flags de estado, você pode escrevê-la como uma sequência simples e legível — e dar yield de volta ao motor sempre que precisar esperar.

Por que isso se encaixa bem no gameplay

A maioria das tarefas de gameplay é, por natureza, passo-a-passo: mostrar uma linha de diálogo, esperar input do jogador, tocar uma animação, esperar 2 segundos, spawnar inimigos etc. Com corrotinas, cada ponto de espera é só um yield(). O motor retoma a corrotina mais tarde quando a condição for satisfeita.

Exemplos concretos que você realmente vai usar

• Cutscenes: executar movimentos de câmera, tocar VO, esperar marcadores de animação e então continuar.
• Quests: “vá até o local → espere até o item ser coletado → desbloqueie objetivo.”
• Diálogos: dar yield até a UI retornar uma escolha, então ramificar.
• Eventos temporizados: dar yield por N segundos sem travar o frame.

Agendamento cooperativo vs threads

Corrotinas são cooperativas, não preemptivas. Isso é uma vantagem para jogos: você decide exatamente onde um script pode pausar, o que torna o comportamento previsível e evita muitos problemas de thread-safety (locks, races, contenção de dados compartilhados). Seu game loop permanece no controle.

Padrões “async-like” sem bloquear o loop

Uma abordagem comum é prover funções do motor como wait_seconds(t), wait_event(name) ou wait_until(predicate) que internamente fazem yield. O agendador (geralmente uma lista simples de corrotinas rodando) checa timers/eventos a cada frame e retoma as corrotinas prontas.

O resultado: scripts que parecem assíncronos, mas continuam fáceis de raciocinar, depurar e determinísticos.

Tabelas, Metatables e design flexível orientado a dados

A “arma secreta” do Lua para scripting de jogo é a tabela. Uma tabela é uma estrutura única e leve que pode agir como objeto, dicionário, lista ou blob de configuração aninhado. Isso significa que você pode modelar dados de gameplay sem inventar um novo formato ou escrever pilhas de código de parsing.

Tabelas como modelos de dados flexíveis

Em vez de codificar cada parâmetro em C++ (e recompilar), designers podem expressar conteúdo como tabelas simples:

Enemy = {
  id = "slime",
  hp = 35,
  speed = 2.4,
  drops = { "coin", "gel" },
  resist = { fire = 0.5, ice = 1.2 }
}

Isso escala bem: adicione um novo campo quando precisar, omita quando não for necessário e mantenha conteúdo antigo funcionando.

Prototipar objetos e configurações rapidamente

Tabelas tornam natural prototipar objetos de gameplay (armas, quests, habilidades) e ajustar valores in-place. Durante iteração você pode trocar uma flag de comportamento, ajustar um cooldown ou adicionar uma sub-tabela opcional para regras especiais sem tocar no código do motor.

Metatables: comportamento sem classes pesadas

Metatables permitem anexar comportamento compartilhado a muitas tabelas — como um sistema de classes leve. Você pode definir defaults (por exemplo, stats faltantes), propriedades computadas ou simples reutilizações tipo herança, mantendo o formato de dados legível para autores de conteúdo.

Por que isso impulsiona design orientado a dados e modding

Quando seu motor trata tabelas como a unidade principal de conteúdo, mods ficam simples: um mod pode sobrescrever um campo de tabela, estender uma lista de drops ou registrar um novo item adicionando outra tabela. Você acaba com um jogo mais fácil de ajustar, estender e amigável para a comunidade — sem transformar a camada de script em um framework complicado.

Segurança e opções de sandboxing

Incorporar Lua significa que você é responsável pelo que scripts podem acessar. Sandboxing são regras que mantêm scripts focados nas APIs de gameplay que você expõe, evitando acesso à máquina host, arquivos sensíveis ou internals do motor que você não quis compartilhar.

Restringir o que scripts podem acessar

Uma linha de base prática é começar com um ambiente mínimo e liberar capacidades intencionalmente.

• Corte bibliotecas padrão: muitos jogos desativam io e os completamente para prevenir acesso a arquivos e processos.
• Sem rede por padrão: forneça funcionalidades HTTP/WebSocket apenas através de uma API do motor vetted (e apenas para scripts confiáveis).
• Evite carregar código arbitrário: desative loadfile e, se permitir load, aceite apenas fontes pré-aprovadas (por exemplo, conteúdo empacotado) em vez de entrada bruta do usuário.

Em vez de expor toda a tabela global, forneça uma única tabela game (ou engine) com as funções que você quer que designers ou modders chamem.

Adicionar limites de recurso (tempo, memória, recursão)

Sandboxing também evita que scripts travem um frame ou esgotem a memória.

• Tempo: use debug hooks (hooks por instrução/contagem) para interromper loops runaway e retornar um erro controlado.
• Memória: defina um alocador customizado e aplique um orçamento por estado; falhe alocações graciosamente e mostre mensagens claras.
• Profundidade de recursão: coloque guardrails na sua API (e/ou debug hooks) para detectar profundidade excessiva antes que vire crash.

Separe scripts confiáveis e não confiáveis

Trate scripts first-party diferente de mods.

• Rode conteúdo não confiável em um estado Lua separado com superfície de API menor.
• Mantenha scripts confiáveis mais próximos dos internals do motor para produtividade.
• Considere isolamento por processo para conteúdo altamente não confiável, mas muitos projetos conseguem ótimo resultado com “estado separado + API limitada + cotas”.

Manutenibilidade: manter motor e scripts sincronizados

Lua costuma ser introduzida para acelerar iteração, mas seu valor de longo prazo aparece quando um projeto passa meses de refatorações sem quebrar scripts constantemente. Isso exige práticas deliberadas.

Mantenha uma fronteira estável entre motor e scripts

Trate a API exposta ao Lua como uma interface de produto, não como um espelho direto das suas classes C++. Exponha um conjunto pequeno de serviços de gameplay (spawn, tocar som, consultar tags, iniciar diálogo) e mantenha internals do motor privados.

Uma fronteira fina e estável reduz churn: você pode reorganizar sistemas do motor mantendo nomes de funções, formatos de argumentos e valores de retorno consistentes para designers.

Versione scripts — e seus bindings

Mudanças que quebram são inevitáveis. Torne-as gerenciáveis versionando seus módulos de script ou a API exposta:

• Adicione parâmetros opcionais em vez de mudar significados
• Depreque funções com avisos antes de remover
• Mantenha um shim de compatibilidade por uma ou duas releases

Até um API_VERSION simples retornado ao Lua pode ajudar scripts a escolher o caminho correto.

Hot-reload: recarregue comportamento, não estado

Hot-reload é mais confiável quando você recarrega código mas mantém estado runtime sob controle do motor. Recarregue módulos que definem habilidades, comportamento de UI ou regras de quests; evite recarregar objetos que detêm memória, corpos de física ou conexões de rede.

Uma abordagem prática é recarregar módulos e então rebindar callbacks em entidades existentes. Se precisar de resets mais profundos, forneça hooks de reinicialização explícitos em vez de confiar em efeitos colaterais de módulos.

Logging e erros que não-programadores conseguem usar

Quando um script falha, o erro deve identificar:

• O arquivo/módulo Lua e o número da linha
• O nome da função (ou evento) que o disparou
• Contexto chave (id/nome da entidade, nível, etapa da quest)

Encaminhe erros Lua para o mesmo console in-game e arquivos de log que mensagens do motor usam, e mantenha traces de stack intactos. Designers resolvem problemas mais rápido quando o relatório parece um ticket acionável, não um crash enigmático.

Ferramentas, depuração e profiling em projetos reais

A maior vantagem de tooling do Lua é que ele se encaixa no mesmo loop de iteração do seu motor: carregue um script, rode o jogo, inspecione resultados, ajuste, recarregue. O truque é tornar esse loop observável e repetível para todo o time.

Depuração: stepping, breakpoints, watch values

Para o dia-a-dia, você quer três fundamentos: colocar breakpoints em arquivos de script, step por linha e observar variáveis enquanto mudam. Muitos estúdios implementam isso expondo debug hooks do Lua para uma UI do editor, ou integrando um debugger remoto pronto.

Mesmo sem um debugger completo, adicione facilidades de desenvolvedor:

• Um console ao vivo para rodar pequenos trechos de Lua no estado atual do jogo
• Logging estruturado que inclui arquivo e número da linha do script
• Relatórios de erro do motor que preservem stack traces do Lua (não os oculte)

Profiling: encontrar hotspots de script

Problemas de performance em script raramente são “Lua é lento”; normalmente são “esta função roda 10.000 vezes por frame.” Adicione contadores leves e timers ao redor de pontos de entrada de script (ticks de IA, updates de UI, handlers de eventos) e então agregue por nome de função.

Ao achar um hotspot, decida se vai:

• Reduzir frequência de chamada (orientar a eventos em vez de polling)
• Mover o loop apertado para C/C++
• Cachear lookups (campos de tabela, globais) dentro do loop

Testes e básicos de build para assets de script

Trate scripts como código, não conteúdo. Rode testes unitários para módulos Lua puros (regras do jogo, matemática, tabelas de loot), além de testes de integração que iniciem um runtime mínimo e executem fluxos-chave.

Para builds, empacote scripts de forma previsível: ou arquivos simples (fácil de patchar) ou um archive bundlado (menos assets soltos). Seja qual for a escolha, valide em build time: checagem de sintaxe, presença de módulos obrigatórios e um smoke test simples “carregar todo script” para pegar ativos faltando antes do envio.

Se você está construindo ferramentas internas ao redor de scripts — como um “registro de scripts” web, dashboards de profiling ou um serviço de validação de conteúdo — Koder.ai pode acelerar prototipagem e entrega dessas apps acompanhante. Como ele gera aplicações full-stack via chat (comum React + Go + PostgreSQL) e suporta deploy, hosting e snapshots/rollback, é indicado para iterar em ferramentas de estúdio sem gastar meses de engenharia inicialmente.

Como Lua se compara a outras escolhas de script

Escolher uma linguagem de script é menos sobre “melhor no geral” e mais sobre o que se encaixa no seu motor, seus alvos de deploy e sua equipe. Lua tende a vencer quando você precisa de uma camada de script leve, rápida o suficiente para gameplay e fácil de incorporar.

Lua vs Python

Python é excelente para ferramentas e pipelines, mas é um runtime mais pesado para embutir em um jogo. Incorporar Python tende a puxar mais dependências e ter uma superfície de integração mais complexa.

Lua, em contraste, é tipicamente muito menor em footprint de memória e mais fácil de empacotar entre plataformas. Também tem uma C API projetada para incorporação desde o início, o que muitas vezes torna chamadas ao motor (e vice-versa) mais simples de raciocinar.

Em velocidade: Python pode ser suficiente para lógica de alto nível, mas o modelo de execução do Lua e os padrões de uso comuns em jogos frequentemente o tornam uma escolha melhor quando scripts rodam frequentemente (ticks de IA, lógica de habilidades, updates de UI).

Lua vs JavaScript

JavaScript atrai porque muitos desenvolvedores já conhecem e engines JS modernas são extremamente rápidas. A troca é o peso do runtime e a complexidade de integração: enviar um motor JS completo pode ser um compromisso maior, e a camada de binding pode virar um projeto por si só.

O runtime do Lua é muito mais leve, e sua história de incorporação costuma ser mais previsível para aplicações host estilo engine de jogo.

Lua vs C# (cenários tipo Unity)

C# oferece workflow produtivo, ótimas ferramentas e um modelo orientado a objetos familiar. Se seu motor já hospeda um runtime gerenciado, a velocidade de iteração e a experiência do desenvolvedor podem ser excelentes.

Mas se você está construindo um motor custom (especialmente para plataformas restritas), hospedar um runtime gerenciado pode aumentar tamanho binário, uso de memória e custos de startup. Lua frequentemente entrega ergonomia suficiente com um runtime menor.

Como escolher

Se suas restrições são apertadas (mobile, consoles, motor custom) e você quer uma linguagem embutida que fique fora do caminho, Lua é difícil de bater. Se sua prioridade é familiaridade de desenvolvedores ou você já depende de um runtime específico (JS ou .NET), alinhar com as forças da equipe pode superar as vantagens de footprint e incorporação do Lua.

Boas práticas para incorporar Lua em um motor de jogo

Incorporar Lua funciona melhor quando você o trata como um produto dentro do motor: uma interface estável, comportamento previsível e guardrails que mantêm criadores de conteúdo produtivos.

Projete uma superfície de API clara

Exponha um conjunto pequeno de serviços do motor em vez de internals crus. Serviços típicos incluem tempo, input, áudio, UI, spawn e logging. Adicione um sistema de eventos para que scripts reajam a gameplay (“OnHit”, “OnQuestCompleted”) em vez de ficar fazendo polling constantemente.

Mantenha acesso a dados explícito: uma visão somente-leitura para configuração e um caminho controlado para escrita de estado. Isso facilita testar, proteger e evoluir.

Mantenha o compute onde pertence

Use Lua para regras, orquestração e lógica de conteúdo; mantenha trabalho pesado (pathfinding, consultas de física, avaliação de animação, loops grandes) em código nativo. Uma boa regra: se roda todo frame para muitas entidades, provavelmente deve ficar em C/C++ com um wrapper amigável ao Lua.

Padrões e tratamento de erros

Estabeleça convenções cedo: layout de módulos, nomes e como scripts sinalizam falha. Decida se erros devem lançar, retornar nil, err ou emitir eventos.

Centralize logging e torne stack traces acionáveis. Quando um script falha, inclua id da entidade, nome do nível e o último evento processado.

Planeje para restrições reais de shipping

Localização: mantenha strings fora da lógica quando possível e roteie texto por um serviço de localização.

Save/load: versione seus dados salvos e mantenha estado de script serializável (tabelas de primitivos, IDs estáveis).

Determinismo (se necessário para replays ou netcode): evite fontes não determinísticas (tempo de parede, iteração sem ordem) e assegure uso controlado de RNG por seed.

Para detalhes de implementação e padrões, veja /blog/scripting-apis e /docs/save-load.

Conclusão e checklist de decisão

Lua ganha sua reputação em motores de jogo porque é simples de incorporar, rápido o suficiente para a maioria da lógica de gameplay e flexível para features orientadas a dados. Você pode enviá-lo com overhead mínimo, integrá-lo de forma limpa com C/C++ e estruturar fluxo de gameplay com corrotinas sem forçar seu motor a um runtime pesado ou uma toolchain complexa.

Checklist de decisão (Lua é adequado?)

Use isto como uma avaliação rápida:

• Necessidade de incorporação: Você precisa de um runtime de script que viva dentro do seu executável com controle apertado sobre memória e tempo de startup?
• Escopo de scripting: Scripts são principalmente para quests, lógica de UI, IA, triggers e tuning — não matemática pesada por frame?
• Expectativa de interoperabilidade: Você pode se comprometer a projetar uma fronteira clara entre código do motor (C/C++) e scripts (Lua), incluindo regras de ownership?
• Design orientado a dados: Você quer objetos de configuração flexíveis (tabelas) e capacidade de patch/estender comportamento sem rebuild do motor?
• Requisitos de segurança: Você precisa restringir acesso a arquivos/rede e expor apenas APIs whitelistadas do motor?
• Fluxo da equipe: Designers/technical designers se beneficiariam de iteração rápida, hot-reload e scripts pequenos?

Se a maioria das respostas for “sim”, Lua é um forte candidato.

Próximos passos sugeridos

1. Prototipe uma camada de binding para 5–10 features representativas do motor (entidades, transforms, eventos, hooks de UI). Mantenha a API pequena e consistente.
2. Construa um sistema de tarefas baseado em corrotinas (ex.: wait(seconds), wait_event(name)) e integre ao loop principal.
3. Adicione um workflow mínimo de empacotamento de scripts: recarregar um único arquivo, reportar erros com stack traces legíveis e logar performance de script.

Armadilhas comuns na primeira implementação

• Expor superfície demais do motor de uma vez (difícil de segurar e proteger).
• Regras de memória/ownership pouco claras entre objetos C++ e referências Lua.
• Permitir que scripts chamem operações caras do motor todo frame sem orçamento.
• Deixar para mais tarde sandboxing e controle de módulos (difícil de retrofitar).
• Não ter estratégia de versionamento para APIs expostas a scripts — quebrações se acumulam rápido.

Se quiser um ponto de partida prático, veja /blog/best-practices-embedding-lua para uma checklist mínima de incorporação que você pode adaptar.