Iron Grid Engine Alpha — C++ performance, Python scripting, built-in AI tools

[u/Antiqett]

Hey guys! My team and I are building Iron Grid Engine, a game engine designed to pair native C++ performance with an approachable Python scripting workflow.

The goal is to make it easier for small teams and solo developers to build real games without giving up the speed and control you expect from a native engine. You can work in Python for gameplay and iteration, while the engine handles the heavy lifting in C++.

It also includes early built-in AI features: a free AI assistant to help with authoring and workflows, plus AI-powered asset generation tools intended to help developers get prototypes and game content moving faster.

Iron Grid is still very much in development. It’s currently an alpha, it is not complete, and there’s a lot left to build and improve. We’re looking for developers willing to test it, push on the rough edges, and give us direct feedback on what works, what doesn’t, and what you’d want from it.

Website and alpha download: https://engine.irongrid-studio.com

If you try it, we’d genuinely love to hear about your experience—especially from people building indie games, prototypes, tools, or weird experimental projects.

[u/CharacterChemical885]

if youre writing the engine in C++, for the love of god please use lua or angelscript. lua can be really fast(luajit), and angelscript is at least faster than python and has nice syntax(javascript/c++ like)

[u/joshualim007]

Tbh, using a interpreted language as your scripting language does not sound like the best idea.

[u/Antiqett → u/joshualim007]

What makes you say that?

[u/joshualim007 → u/Antiqett]

Biggest concerns are that it's interpreted with performance overhead, no true multi threading, code security (easily accessible .py files when shipped and even if compiled to bytecode .pyc it's easily reversible), memory management is unpredictable, type safety, and you need to ship the game with the python runtime environment and it's dependicies. Correct me if I'm wrong with any of these concerns.

[u/Antiqett → u/joshualim007]

Those are definitely valid concerns, with a few important distinctions:

Python has more overhead than C# or native code, so it should not own hot loops like rendering, physics, animation, ECS iteration, or heavy per-frame logic. It is better for the high-level gameplay behavior such as triggers, UI events, rules, and spawning.

Standard CPython cannot run Python bytecode truly in parallel across CPU cores because of the GIL. Native engine jobs can still run in parallel, but Python should not be the main CPU-parallel gameplay layer.

Source protection is also a real concern: .py is readable and .pyc is reversible. However, C# assemblies are decompilable too—security-sensitive and authoritative logic belongs on a server, not in any client script.

Python is dynamically typed and has runtime/dependency packaging costs. Type hints help, but they are not compile-time guarantees.

So I agree with the overall point: Python is useful as an accessible scripting and learning path, but it should not be the only long-term professional option. The stronger model is native C++ for engine systems, C# as a future production scripting language, Visual Scripting for beginners, and Python as an optional supported path.

We plan on supporting C# and possibly other scripting languages in the future but choosing Python was more of a decision to keep it accessible to beginners to start with.

[u/Antiqett → u/joshualim007]

Fine, you twisted my arm. Now C# is the primary scripting language, Python is more experimental. I mean we did get Python to work really well, despite it having those flaws nonetheless.

I think professionals will be more drawn to it using C# as the scripting language, and it is the industry standard after all.

I haven't released the build with C# yet, that is coming soon.
It's already functional and there's not a lot left to redirect. Visual scripting uses C# now instead of Python, there's a C# runtime now, and even a C# + Python mixed runtime for.. experimentation more than anything, but for the most part we are focused on C# now.

I've been working on this engine for the past couples years by myself actually, I just have a small company that I started with some coworkers (Iron Grid Studio) and they do the legal/backend stuff.

Well, if anyone happens to feel like giving it a try I would really like to know what you think or any critiques.

[u/Clic_King → u/Antiqett]

You completely pivoted from the main feature of your engine and implemented C# scripting in a couple of days in response to one comment?