[maiybe]

A point of wild speculation. This is likely to be the slow decline of Godot.

As someone with 2 years of Godot experience (which seems like a lot given their lifespan), the underlying infra isn't strong enough to ward off the many competitors that will embrace AI at the heart of the engine. Ironically, the best engine right now for AI-assisted coding is Godot! It has plain text scene files, and Opus does a half decent design - screenshot - iterative flow to get things off the ground before artists clean it up.

Being an open source maintainer is HARD work I wouldn't wish on my worst enemy. However, the Godot team has very strong opinions that don't really drive especially better software. There is a small history of being confrontational in their github PRs, and a strong opinionated approach. They mostly inherited their current spot in the market from mistakes and commercial pressures of the top two engines (cough Unity per-install fees).

The removal of AI-generated contributions is pitched as helping them maintain a better core product, but in reality, (my prediction) it will end up massively hampering velocity over the next 3-5 year horizon.

At the same time, it used to be impractical to make your own game engine to make a game. Now, with AI-assisted coding, strong game devs have a viable option, despite the added complexity. Rust libraries like bevy provide the training wheels to a half decent dev + AI assistant that can build more bespoke smaller engines for indies. To gain Godot's level of indie marketshare, a single breakout engine project that embraces vibecoding could be enough. I expect that will gobble up eager /r/aigamedev Redditors and the new swarm of unemployed juniors fresh out of college.

[rschiavone]

This is exactly what will make Godot shine in 2 years while the rest of the world will be busy cleaning up inefficient code.

[jerf]

The people who hand write code for a game engine will beat the people who try to vibe code a game engine.

But they'll both be beaten by people using AI intelligently to generate code, but not letting it drive everything. Who look at every line and apply their experience to fixing what the AI generates until it outputs more or less what you would have, only more quickly.

The false dichotomy that some of you are trying to push between "just taking whatever the AI slops out" and "pristine hand-crafted code by dedicated, loving experts" doesn't exist.

[dofm]

> But they'll both be beaten by people using AI intelligently to generate code, but not letting it drive everything.

I mean, this remains to be seen. Is this actually much faster or better than coding by hand?

(Not a facetious question: it's one I grapple with all the time)

[maiybe]

I'd put my estimates at 3x speed improvements. The amount of infra required upfront? 5x one time cost. These are estimates from Godot mobile app work. We have been trying out: no reviews under specific file sizes, except at design bottlenecks or large refactors. Number of PRs is probably up 3x with maybe 20% increase in regressions? Number of tests in our CI is up 500% (again, approximate), but this is absolutely required or we'd be awash in uncaught regressions with the velocity of code changes.

We have PR auditing skills, PR writing skills, testing conventions, etc that all need to be self-monitored for bullsh*t Claude ignorance (e.g. you apply them many times, then review your own PRs manually before merge). None of that is free, but we have shipped significantly more code as a result.

[eudamoniac]

Hearing about a Godot mobile app is hilarious to me. If there was ever a signal that Godot is not a serious tool to create releasable games, but rather a toy for beginners to mess around with, spending a bunch of resources on porting the engine to phones is it. Wowza

[roflcopter69]

Seeing what y'all write in the child comments here, I think there is a massive misconception. Games made with Godot can be deployed to mobile fairly easily. The recent "breakthrough" about Godot working on Android was about making the Godot editor (which itself is made with Godot) fully work on Android in the sense that it can actually build project there which is more about getting build tooling to work on an Android device than actually running the Godot engine on Android. Totally different things. For quite some time you can quite easily deploy your Godot game to mobile, it's not a real problem.

[maiybe]

I am struggling to understand the exact content of your message. I believe it's that Godot is unserious. Okay? Game engines serve a niche much smaller than broad consumer apps or SaaS platforms. Seems like a dunk I don't quite understand.

It's a game built in Godot that runs on mobile (a mobile game). Godot is C++, there is no porting of engine to run on mobile? Slay the Spire 2 is built in Godot and has 500k concurrent users.

[maiybe]

By all accounts, with the current curve of model improvement, I don't see strong evidence that aligns with that belief. Perhaps with a plateau in model improvement or a saturation of the tech (a la iPhone 2020s), one could argue the lack of growth. But right now with evidence at hand? I wouldn't take that bet.

[ryan_n]

> To gain Godot's level of indie marketshare, a single breakout engine project that embraces vibecoding could be enough.

What are you basing this off of? There are already plenty of game engine projects like what you describe here. Doesn't seem to have affected Godot thus far, unless I'm missing something.

[maiybe]

That's basically the same argument Unity made a few years ago.

There isn't, until there is. These things take time. The tech has to be adopted, the people have to integrate into game jams, indies percolate. Godot is young, my predictions are 3-5 years.

Regarding competition though, the question is about the unique selling points of Godot that would be hard to replicate. Before AI coding, there is a _lot of momentum_ for leaders in the game engine world. Everyone specializes and it takes many years of game cycles to make the switch to a new engine. Not anymore!

So we have yet to see a dog-eat-dog game engine world, and in that world, ejecting AI-coding could in fact be a net negative. That's what I am arguing at least.

Regarding the unique selling points of the engine: 1. Open-source 2. Node/Scene encapsulation design: Big! - Easily my favorite part of GDScript. Easy to replicate. 3. Scripting languages: GDScript, buggy C# - AI-coding doesn't care what language as long as it's popular

My suspicion: A competitor could use a known compiled language (Rust) and a scripting language (luau) and get the same mileage as Godot and replace every one of their selling points with more performant code. Because they waited so long to deploy a marketplace, they have very little sticky bits to their market share.

[roflcopter69]

A serious competitor wouldn't use Rust because it immediately disqualifies your engine from being shipped to consoles. At least at the moment. I know it's less of a technical limitation and more of a political one, but if you are serious about shipping your game to various platforms, you cannot use Rust. But things might be about to change, see https://akaganite.com

But honestly, as of today, you're probably having a better time taking a few days to work out clean C++23 guidelines for your AI agents by letting them churn through all the changes and deprecations that happened to C++ over the years, figure out good clang-tidy and clang-format rules, turn on all the compiler warnings and tell them to regularly use UBSAN, ASAN and TSAN and you're getting really close to a clean workflow similar to what Rust would give you but with the rich platform support of C++. It's just kinda sad that one has to go through so much ceremony while the Rust ecosystem gives you those things for free. But imo a well-crafted AI agent workflow gets really close here.

Mean edit: I was reading more of your comments in this post and I start to think you're a bit of bullshitter who's quite overconfident because you think AI makes you so much more productive. I say this because any seasoned game engine dev wouldn't have suggested Rust for a game engine that is supposed to compete with Godot, Unity, Unreal or whatever due to missing consoles support, but you just did, which makes me suspect that you have really shallow understanding and really, AI won't help here. You could have at least mentioned that if you only target dektop and mobile then Rust is a good choice, but you didn't. But don't get me wrong, I'm quite AI pilled as well, but I still know that some things require expert knowledge to properly steer the AI agents.

[bloomca]

> the underlying infra isn't strong enough to ward off the many competitors that will embrace AI at the heart of the engine

Who are the competitors? Something lower level like bevvy? The way I see it even with vibe coding you need to do a lot of infrastructure work to make editing easy, and anybody except Unity is far off from them.

[maiybe]

Godot has a few elements going for it.

GUI Editor is not one I'd list.

Internal tooling stood up a GUI Editor clone within a few weeks that was targeted towards our specific use case. Their editor isn't uniquely ergonomic. In fact, for about 3 releases, one of the highest requested objects was multiple tabs at the same time. A rather standard feature in an editor and especially a modern code editor.

My argument isn't totally about individual devs making engines (though it is actually feasible on a Max plan), I'm imagining a very small team competitor that embraces AI-assisted PRs, internally and externally, along with vibecoding directly baked into the app itself (MCP or more direct claude code scripting language integration). That would be able to match or exceed the functionality in Godot, probably with more common and performant scripting languages (Rust + Luau for example).

[IAmGraydon]

>As someone with 2 years of Godot experience (which seems like a lot given their lifespan), the underlying infra isn't strong enough to ward off the many competitors that will embrace AI at the heart of the engine.

Like who? Unity/Unreal? Those are completely different engines for a different audience. IMO, Godot has a unique market space and no real peers. I think this was a wise decision that only adds to their brand as something for creators rather than corporations.

[maiybe]

AI-assisted coding is good for creators. It happens to be good for corporations because it reduces costs, but it's actually much more powerful for creators with imagination. I don't know where that argument comes from.

If AI-assisted coding can help corporations make AAA games with 1/10th the resources, then it would stand to reason it also helps indies make AAA with 1/10th the resources? I have never understood this argument.

Godot has no peers because for the last 30 years in software, it's been hard for people to make their own game engines, which made open source engines totally impractical. W4 is a non-profit organization that happened to get just enough resources and traction to make it. That underlying assumption is not true anymore, making engines has never been easier in software history. Unreal/Unity are not the competitors I'm talking about.

[overgard]

You can use AI assisted coding in Godot though with addons and an MCP server. That's completely separate from AI pr's in the engine itself.

Also, slight tangent but I'm just going to point out that the new MCP server in Unreal Engine 5.8 totally sucks, so it's not like other engines are that far ahead there. The very first task I gave it was to cache a couple of values in a map, and it couldn't do it because it couldn't figure out how to set the key type to FName (basic stuff). But honestly, I'm not surprised, the surface area of Unreal Engine is HUGE and trying to explain it all to a general purpose agent through tool calls is going to hit limits.

[maiybe]

I have never found an MCP server that really crushed it. Totally agree. I think there's something required at a deeper level of integration to get AI coding working inside of engines. MCP is not it.

Yes, it's true, this is not a ban on AI coding with Godot. I didn't mean to conflate those, whoops. It stands to reason that there may be a small anti-AI perspective taking shape inside of the Godot engine team. This is one sign, but not confirmation of that suspicion.

[IAmGraydon]

>AI-assisted coding is good for creators. It happens to be good for corporations because it reduces costs, but it's actually much more powerful for creators with imagination. I don't know where that argument comes from.

>If AI-assisted coding can help corporations make AAA games with 1/10th the resources, then it would stand to reason it also helps indies make AAA with 1/10th the resources? I have never understood this argument.

We're talking about banning AI coding in the game engine itself, not game creators banning the use of AI to create actual games on top of the platform.

[maiybe]

> adds to their brand as something for creators rather than corporations

I'm responding to the idea that banning AI contributions is on brand for being "for creators."

What about their action is creator friendly? Yes, they reject all low quality AI slop, which has some indirect positive benefit. They also won't accept high quality PRs unless they are hand crafted. How does that benefit creators? Most arguments it's "for creators" likely conflate the idea that AI-coding is inherently slop. If so, then we can say that directly instead of implicitly.

[eudamoniac]

Monogame, Wicked, Defold, Gamemaker, Stride, Heaps, just off the top of my head

[Silamoth]

Funny enough, I see it the exact opposite. LLM slop code degrades software quality. While one person may appear to move quickly, the software quality suffers dramatically. It takes them (or other team members) more time to fix the issues than it would have to just do it right the first time.

I mean, even with the advent of “AI” agents, is software today any better than it was 3 years ago?

I think teams embracing too much LLM coding are going to see a continued decrease in quality and a massive drop in team productivity. Godot, on the other hand, is avoiding this. While it might not be as trendy, I think it’ll be a competitive advantage in the long term.

[maiybe]

I don't know about large teams or companies. I feel more confident with the conjecture: Conditioned on small teams, a team of seniors with AI coding beats a team of junior with AI coding by a wide margin, in my experience.

When accounting for "coding taste," I think there is equal or higher quality output over small teams, and if there is a decrease in software quality, it's nowhere near the implied amount (5-10% at most) with a massive gain in speed (approx 3x? 4x? hard to measure). Those numbers net out positive in the end, especially as the team starts to understand and ship with AI in the loop.

[nemomarx]

If the AI tools are that effective, the maintainers can just use them themselves? That way they would have the full oversight on how it's done.

PRs with just the results and final code doesn't seem better even if we assume ai coding will be much faster.

[maiybe]

Integrating AI-assisted PRs into an existing team is a skillset all in itself.

The team is taking a pretty strong stance against external AI-assisted PRs, which makes you think they'd take a weak stance against internal AI-assisted PRs? It's hard to draw the exact line, but maybe?

For our team, the outcome is the PR, and you have to set up _a lot of testing infrastructure_ to prevent regressions. It's a skillset like any other.

It would be consistent with their actions that my belief is they are slow to adopt workflows that will accelerate them. Thus velocity will decrease.

[overgard]

> Integrating AI-assisted PRs into an existing team is a skillset all in itself.

What exactly is this skillset? Why should AI created PR's be any different from other PRs?

To me this seems like a very sensible move.. they don't want to deal with bad code from uninvested contributors. I can't possibly see how that would harm them. If they want to use AI themselves, given their track record I trust they would do it tastefully.

[maiybe]

Quite simply, volume. Detailed human review is a serious bottleneck on code merging. Skillset includes how to make sure you can get quality code at speed without 100% in-depth human review. I wouldn't recommend merges without human eyes, but there is a spectrum of depth in review.

[nemomarx]

but their stated reasoning is that they do open PRs to train up new contributors and eventually get them into the community where they'll be more trusted. That doesn't suggest a hardline stance against the tools to me necessarily at least.

[maiybe]

On one hand, you could be right! I am making inferences on low data, judging the Godot team based on some of their _strong_ design choices. I would have a better argument if I spent the time tracking the Github issues that seemed quite wild that we encountered while building in Godot. Top of mind (low evidence, sorry) GDScript as a base scripting language (later reversed by C#), refusal to add async/await for GDScript, others that have escaped me.

What I am saying is squishy conjecture.

On the other hand, they're training new contributors to make internal AI-assisted PRs by requiring them to make non-assisted PRs? That sounds unlikely but I suppose possible.

[Fraterkes]

Any resources for getting better at that skillset (high-velocity but largely stable ai-enhanced coding, if I understand you correctly)? I’m always pretty skeptical of these claims but I wouldn’t mind being proven wrong

[gpm]

> Rust libraries like bevy

Notably bevy also bans AI contributions...

[maiybe]

A wicked irony I didn't know!

Most likely then a team that builds on top of bevy as infra and not bevy team itself.

[overgard]

You have to consider the market for Godot: indie developers. They don't need cutting edge features; they need a good workflow, ease of use, a good community, stability, etc. Unity is actually really annoying in this regard, because they're _constantly_ deprecating features in favor of new features that are half baked and poorly documented. It feels like a really unstable platform to build on because by the time you're done with a project most of the things you built now need to be thrown away because the underlying engine changed so much, or you're halfway through a feature and you have to decide if you want to rewrite a huge chunk of code to support something new that came out. Unreal Engine is also going through this at the moment (although they're better about backwards compatibility). Hearing that they're dropping blueprints in favor of verse has a lot of people stuck in "uh, should I bother learning the current engine right now". I don't think it'll hurt UE in the long run, but I could easily see them losing some short term adoption. Stability in a platform is a very important feature!

Building on an engine is a HUGE investment, and nobody serious picks a game engine because of its feature velocity, they pick it based on what it can do today.

Also in terms of marketing I think this is pretty clever. I know a lot of game developers (I used to work in the industry), and pretty much everyone I know despises AI on some level. HN is mostly business people who see dollar signs, but creatives just see destruction of art forms they care about, so none of their users are going to see this as a bad thing.

[maiybe]

For many years, it's been difficult to build game engines. It's never been easier today. A half-decently funded startup team could get to Godot feature parity within 6-12 months. There's no VC in games anymore (especially not middleware), so it's less unlikely, but they don't have a moat on features.

When you go to invest in an engine. One with Claude Code natively infused and another that says "meh" to AI. Which would you have your small indie dev team choose? Smart money says velocity. I suspect the Godot-slayer I am imagining will start getting buzz in /r/aigamedev subreddit as the only way to quickly code a game. A little better design and 3D work from Anthropic, and we are off to the races.

Regarding game dev hatred of AI, I've been to GDC for the last 3 years for the explicit purpose of talking about AI in games. The wall of hatred isn't holding strong. It used to be universal. Now, not so much. People on their laptops claude coding during presentations. 20% of talks being about AI in games, and _sponsored (!!!)_ talks about AI are getting the largest crowds at GDC this year. The times, they are a changin'. This is only a clever marketing move for a certain set of developers, which I totally agree are the (maybe?) majority today. I said 3-5 years though, not 6 months...

[overgard]

Oh god. If you really believe you can vibe code an engine in 6 months I challenge you to do it. I think you'll find you've wildly underestimated what goes into an engine.

[maiybe]

Well, this is fundamentally where we end up disagreeing. Within the timeframe of a single mobile app development cycle, the entire coding infrastructure of the world changed. Our collective day-to-day coding experience has morphed within 15 months.

Here, you're making a negative argument, it "can't" be done. Maybe. Historically, correct. I prefer to image what could be done. As insane a statement as it sounds just 15 months ago, a small dev team could get it done, I'll stand by that. Framing is up to you, to each their own!

[anonymousab]

Even getting through the discussions and negotiations with the 3 big game console companies to support their platforms can eat up so much of your time window. You can't really vibecode your way out of that - though I suppose you could generate your email responses or an AI meeting participant and risk blowing up the business relationship.

[overgard]

As a professional developer that's using these tools professionally and worked on multiple game engines and even written a few of my own... nope. Sorry, just, that's so much hype not grounded in anything. I'm guessing your job is to promote this stuff based on that being your purpose of going to GDC?

Also, you're really misunderstanding why people use Godot in the first place. They've always been way behind Unreal Engine and Unity on flashy features, that's not their value proposition. A lot of churn on half baked slop features would be counter to why people want to use it. Developers in a stressful industry want tools they can trust, not buggy unstable things that are constantly changing out from under their feet (a lot of teams freeze their engine version per-project for this very reason).

[maiybe]

> that's so much hype not grounded in anything.

Not grounded in anything? Really, anything? There's no evidence you've seen in the last three years that has had any impact on what you think is possible with AI coding?

I'm not a game dev by trade, I am AI researcher turned AI engineer (not the "AI engineer" of the modern era, like getting ML deployed in prod). That being said, I have tried and failed to make plenty of games over the years. Every mistake in the book. Making my own engine, trying to do 3D game as first approach, making mobile apps 2010, using Unity for personal projects, switching to Godot. I'm not at your level in game dev, but I've seen plenty at scale.

> I'm guessing your job is to promote this stuff based on that being your purpose of going to GDC

I'm not an AI hype maker, I'm a stunned observer. A person who has said "no way" AI will impact coding for the last 10 years. I am watching evidence in front of my very eyes and my workflow and simply adapting to the reality on the ground along with reasonable projection of capabilities into the future (based on velocity and reasonable assumptions). I don't need to convince you of anything, but I'm confident your beliefs won't hold up against the stockpile of evidence gathering now and in the near future.

Since you took a swing and miss on who I am, I'm going to guess that you are reluctant to incorporate these tools into your own workflow (perhaps having cast them off quickly after some frustrated probing) and have a deep-seated skepticism of the tech that doesn't really matter what I say.

Where's my inference coming from? The idea that you've conflated that AI coding by its very nature needs to be buggy and unstable. I wish you luck on holding the line as it slips past us on an exponential curve.

[charlie90]

https://github.com/charlesrw1/MultiplayerFps, its pretty easy. And this is just my hobbyist engine Ive been solo orchestrating agents with. If you had a team of ~10 AI-enabled devs, you could easily reach feature parity with Unity in a month or 2.

[strangecasts]

> Build: Let your agent figure it out

I'm sorry for going off on a random hobby project, but doing this in a C++ project - even if it is a standard Visual Studio solution - is "putting your whole mouth into the salsa dip"-level rude IMO, agent access should not be a prerequisite to build code!

[overgard]

If you really believe this, I highly encourage you to do it! Unity makes a lot of money, spread that among just 10 people and you'll be doing quite well, especially for a month of two of time spent. And more importantly you'll have the bragging rights of telling an internet commentator they're wrong!

The weird thing though is I see comments like this all the time, and I've yet to see anyone come back a month later as a billionaire so.. I'm going to keep my skepticism for the moment.

As an aside, bragging about lines of code as the first thing in your repo is a very weird flex. Lines of code are a cost, not an achievement, you (or your AI) has to maintain them and the more you have the more it costs.

FWIW good on you for making a thing, my goal isn't to trash your project, but from my perspective this does not look like a serious competitor to any game engine; it reminds me of projects I've seen from college students before AI (I don't meant that as an insult, I just don't find this as compelling evidence for your argument)

[eudamoniac]

You're missing that an AI ban is actually just a poor quality AI ban. No one can tell if you used AI in a quality way and write the description in quality English. All this ban does is filter out the worst slop that would never have worked. People can and will still submit quality PRs that used AI, but no one will know it used AI, because the author was conscientious.

[maiybe]

I don't know, once you ban AI-assisted coding outright, it's much higher likelihood this ban will cause the Godot team to spend time and energy being AI detectives, especially if they don't agree with the intent of the contribution.