Imagination Technologies sat down with Clay John, Technical Director at Godot, to discuss the evolution of game engines, the realities of mobile performance, and what GPU vendors need to deliver to support the next generation of developers.
Godot has rapidly established itself as one of the most important graphics engines in today’s ecosystem. Free, open source, and increasingly capable across 2D, 3D, mobile, desktop, and beyond, it represents a philosophy that resonates strongly with modern developers.
In this conversation, Clay John—who leads Godot’s rendering team—shares how Godot thinks about performance, iteration, rendering innovation, AI, and hardware collaboration, and why those decisions matter more now than ever.
Godot’s Mission and Momentum
Godot’s growth is inseparable from its open‑source roots. For Clay, that foundation defines both the engine’s values and its long‑term resilience.
“Over the last few years we've really kind of solidified our place as the most popular free and open-source game engine. We can comfortably say that we've got a place in the top three multipurpose game engines. We're often compared to Unity and Unreal. Of course we don't swing as they do, they've got a lot more funding, they're a lot older projects and their communities are huge, but we're growing and we're growing very, very quickly.”
Their work is increasingly relevant in an industry where developers have grown wary of shifting business models.
“Importantly, most of the people that work on Godot believe that we should be able to own our own tools. Realistically, the only way to guarantee that is with open source. We have an MIT license, which means that when you download the source code, that's yours.”
Despite modest funding compared to commercial competitors, Godot’s development velocity is striking.
“We merge hundreds of pull requests per week, which is on a par with other large open-source projects like Visual Studio Code, Python and Tensorflow. The vast majority of the work on the project happens from volunteers who are working out of passion. We’ve had around 3,000 unique contributors overall, and each release has somewhere between 300 and 400 contributors.”
That momentum has helped solidify Godot’s position as a viable alternative to proprietary engines.
“We can comfortably say now that Godot has a place in the top three multipurpose game engines.”
Stability, Polish, and Real‑World Readiness
Following the major architectural shift of Godot 4, the team’s focus has been on reliability rather than novelty.
“Godot 4 was a massive overhaul. We modernized a lot of systems and broke a lot of things, as you do with a major version. The last couple of years have been about polishing and stabilizing so you can actually ship games across platforms and obscure hardware.”
For Clay, Godot 4.5 marks a turning point.
“After releasing 4.5, Godot feels very stable. It’s not perfect, and it never will be—that’s kind of the joke—but it’s become much more commercially viable, especially if you’re shipping on low‑end or older devices.”
Recent releases also introduced features aimed squarely at real developer needs, including accessibility and load‑time reduction.
“We added support for Accessibility Kit, including screen readers in the editor. That means blind or partially sighted developers can use Godot, and developers can make games that are accessible to blind players as well.”
On the performance side, the shader baker has made a dramatic difference.
“We’ve seen load times go from two or three minutes down to seconds. That’s a huge deal for a player’s first experience. It's a real win-win situation, especially on power constrained devices like mobile. You don't want to be running something on battery that you as a developer could run once on your super high power dev machine and then just ship that to users and have things run really quick.”
Rendering Philosophy: Practical Over Flashy
Asked about rendering features like ray tracing and super resolution, Clay is deliberately pragmatic.
“There's work ongoing to add foundational support for ray tracing. Godot doesn’t use hardware ray tracing yet. We’re a ways away from that. There are certain design decisions you have to make in a renderer in order to support ray traced reflections or ray traced global illumination or things like that. Our renderer wasn't designed with those things in mind. There’s a pretty good chance in in the next year or two we'd have ray traced ambient occlusion or ray traced shadows. But fully hardware ray traced reflections I think are a way away.”
Instead of chasing buzzwords, Godot focuses on quality improvements that deliver tangible gains.
“We’ve added specular occlusion in 4.5, which avoids weird reflective highlights in places where light shouldn’t exist. It’s one of those features where, if you do it right, people won’t notice—but if you turn it off, you really notice.”
Recent work on screen‑space reflections follows the same philosophy.
“We just merged a big overhaul of the way we handle screen space reflections. This is a pretty common technique that gives you those short range, finely detailed reflections. We completely overhauled screen‑space reflections to make them much faster and better looking. In 4.6, there will be games that ship using only screen‑space reflections, because it looks good enough that depending on your game content and depending on your scenes, it might be good enough to just use that.”
Iteration Speed as a Competitive Advantage
Godot’s lighter approach to tooling shapes how developers work—not just what they can ship.
“It's pretty common for equivalent graphics features in Godot just to have one or two settings, and then the same feature in Unity or Unreal having a bunch of settings, things you can tweak just to get the perfect balance between sliders exactly and get that perfect balance between quality and performance and making it work for your game. And in Godot we aim to just simplify all of that.”
“Our goal is that a single person could understand all of the systems in Godot that they need to make their game.”
The result of this simplification is an improvement in iteration time.
“One of our main selling points is iteration time. You're not going through long compile times, you're not going through slow things loading. You're not baking, lighting and shaders every single time you change one setting. You hit play and your game just runs immediately.”
That speed has made Godot useful even inside AAA studios.
“Godot is becoming popular as a prototyping tool, because you can test ideas quickly without friction.”
For smaller teams, that responsiveness can be decisive.
“A lot of indie teams value iteration time because they're not trying to make the flashiest looking game. They're not trying to push the limits in terms of making a huge open world game. They're trying to make a very refined core experience and a refined gameplay loop that's fun.”
AI: Useful, but Carefully
AI is one of the few areas where Clay is intentionally cautious. Many standardised AI features – think DLSS, FSR or XESS - are not open source and are a challenge to integrate into the engine. But Godot is optimistic about where AI adds value.
“AI is a very good tool for upscaling and for denoising. We're seeing other tools improve areas like asset optimization. If AI can automate things like LOD generation or mesh optimization and take menial work away from artists, that will be embraced very quickly”
Looking forward, Clay is especially interested in AI running locally.
“If I can offload denoising or upscaling onto another chip running in parallel, and get higher quality rendering for the same performance budget, that’s amazing.”
What Godot Needs from GPU Vendors
From Godot’s perspective, the most valuable GPU features aren’t always the most visible.
“The first thing we need is stability. That is so valuable for us because especially when drivers are updated, it is so difficult for us to identify exactly what needs to change when a game starts crashing on a new driver. We're making perfectly valid use of the API. So how do you track down that bug? Oftentimes we're doing this perfectly normal draw call and it just breaks. So what weird combination of things has led to this? It's very difficult for us to manage, so we want stability.”
API correctness and predictability are critical for an engine maintained largely by volunteers. Education is the other missing piece. All the GPU architectures are different and have their own quirks.
“They're all different and they all have things that you need to be aware of, and most of that information is not public. Most of that information you learn by talking to people from those companies, asking them questions, saying, hey, I've run into this weird performance issue on your hardware. What's up?”
That gap creates real problems for developers moving between platforms.
“The educational materials out there are GDC talks, which are focused on consoles, and then blog posts from hobbyist developers which are focused on desktop. And so if you’re just passively consuming what’s out there, you only understand consoles and desktops. And surprise, surprise, that is totally different than working on mobile.”
“As an example, on desktop these days, you really don't have to worry about vertex budgets as much. You still do, but on mobile, a vertex budget matters a whole lot more relative to screen resolution.”
Accessible guidance, not just tooling, would make a significant difference.
“High‑level advice like ‘minimize render passes’ is hugely valuable, but many new contributors just don’t know that’s important for mobile.”
“Importantly, you should be testing and profiling. Because it’s easy to default to a quick solution to low performance like lowering resolution textures. But when you actually look at a profile, you may find things like all of your time is spent on shadows. You can decrease your texture quality as much as you want, but shadows are where you should be spending your time.”
Check out Imagination’s comprehensive range of developer tools and developer documentation.
Godot has built in features to help developers with game optimisation.
“We create opportunities to decrease the cost of everything. For example, light count traditionally is a huge bottleneck in games. The more lights you have, the slower your game is. So we use more advanced lighting algorithms like cluster rendering, which really reduces the impact of a high light count. Or, for example, these days bandwidth is a huge cost from your geometry because we're having really dense geometry. So Godot will by default compress all your geometry to make it a smaller footprint so you can have more geometry in your scene.”
Looking Ahead
When asked about longer‑term trends for Godot, Clay is candid about what excites him most.
“What I would like to see in the next few years, maybe 5 to 10 years is having a fully ray traced renderer because for people who are making realistic or semi realistic looking games, that's the Holy Grail, right? You just use ray tracing for everything. Your lighting looks cohesive. It looks realistic.”
Such a renderer would sit alongside a traditional rendering pipeline for more stylised games style. AI may provide the missing link.
“Now AI feeds into hardware ray tracing because we can use it for denoising, we can use it for ray reconstruction, we can use it for upscaling, which are three things that make ray tracing a lot faster and allow you to do more with fewer rays. So that could be the final keystone that unlocks real-time ray tracing, but for me that's something I would love to see. But whatever the technology, Godot’s guiding principle remains unchanged. We stay behind the curve on purpose. We let others do the R&D, and once the industry agrees on the right way to do things, we adopt it in a simpler, more accessible form.”