A GQEngine é uma engine experimental em desenvolvimento com foco na simplicidade e no desenvolvimento de jogos voltado exclusivamente para código.
O objetivo do projeto é criar uma ferramenta modular baseada em um sistema de plugins, escrita 100% em Lua. Neste artigo, você conhecerá este projeto que está sendo criado para facilitar a produção de conteúdos didáticos para o Game Quest Studio.
Como a GQEngine vai Funcionar?
A ideia é ter uma engine focada no desenvolvimento de jogos 2D usando um sistema de plugins com os recursos básicos que a maioria dos jogos utiliza, como:
- Máquina de Estados
- Gerenciador de Eventos (Signals)
- Câmera
- Sistema de Cenas
Todos os sistemas serão desenvolvidos usando LuaJIT e lua-sdl2, sem a necessidade do uso direto de linguagens mais complexas como C ou C++.
Por que usar Lua para o Projeto?
A linguagem Lua é amplamente reconhecida por ser extremamente rápida e eficiente, além de ser leve e fácil de aprender.
A performance do Lua pode ser ainda maior ao utilizar o seu interpretador Just-in-Time (LuaJIT), atingindo uma velocidade muito próxima à de linguagens nativas como C.
Ela também é uma das principais linguagens no ecossistema de desenvolvimento de jogos, sendo utilizada em ferramentas conhecidas como Love2D, Roblox Studio e Defold.
Conclusão
A GQEngine é um projeto que está em sua fase inicial de planejamento e desenvolvimento, por isso qualquer sugestão ou dúvida é sempre muito bem-vinda.
Tem alguma ideia para o projeto ou ficou com alguma dúvida? Acesse o repositório oficial no GitHub para acompanhar as novidades e participar das discussões!
📌 Este artigo foi publicado originalmente no blog do Game Quest Studio.
Top comments (3)
A escolha de utilizar Lua como linguagem principal para a GQEngine é interessante, especialmente com o uso do LuaJIT para melhorar a performance. Isso pode permitir uma grande flexibilidade e facilidade de desenvolvimento para os jogos 2D, além de manter a engine leve e fácil de aprender. No entanto, gostaria de saber mais sobre como os plugins serão gerenciados e distribuídos, e se há planos para implementar algum tipo de sistema de cache ou otimização para melhorar o desempenho em jogos mais complexos. Qual é o planejamento atual para a gestão de plugins e otimização de desempenho na GQEngine?
Olá! Agradeço pelo interesse e pelas ótimas perguntas.
A GQEngine tem como premissa ser uma ferramenta 100% escrita em Lua (utilizando LuaJIT e lua-sdl2), portanto todo o planejamento de arquitetura é pensado para funcionar dentro dessa proposta, sem a necessidade de recorrer a C ou C++.
Sobre os pontos que você citou:
Gerenciamento: A engine possui um PluginManager interno responsável por registrar os plugins habilitados e gerenciar seus ciclos de vida ao longo do jogo.
Distribuição: Nesta fase inicial, a distribuição será feita diretamente por módulos em Lua (arquivos ou pastas incorporados ao projeto). A ideia é manter o desenvolvimento enxuto, sem depender de ferramentas de compilação ou gerenciadores complexos.
No momento, o foco principal está em estruturar uma base inicial estável para colocar um primeiro jogo de exemplo em funcionamento.
A performance do LuaJIT já atende muito bem essa fase inicial para jogos 2D. Conforme o projeto amadurecer e a engine evoluir para jogos mais complexos, o gerenciamento de assets e eventuais otimizações na pipeline de renderização serão projetados conforme a necessidade real do ecossistema.
O objetivo principal da GQEngine é ser uma ferramenta simples, modular e voltada para o aprendizado por código.
Se tiver mais ideias ou sugestões, fique à vontade para acompanhar o projeto e participar das discussões no nosso repositório no GitHub!
Thanks for the detailed explanation! I really like the direction you’re taking with GQEngine — keeping the architecture simple, modular, and fully focused on Lua makes it a great learning-oriented project while still providing a solid foundation for 2D game development.
The PluginManager approach and lightweight module-based distribution strategy make a lot of sense for an early-stage engine. Building a stable core first and introducing optimizations based on real usage is often a better path than over-engineering too early.
I’d love to stay connected and follow the evolution of GQEngine. I’m also interested in exchanging ideas around game development, AI-powered tools, and software architecture. If you have any future projects or areas where you’re looking for collaboration, I’d be happy to explore how we can work together.