7 ms·

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 li

by maiybe 3mo ago

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 3mo ago
This is exactly what will make Godot shine in 2 years while the rest of the world will be busy cleaning up inefficient code.
- maiybe 3mo ago
  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.
- deleted 3mo ago
  [deleted]
- jerf 3mo ago
  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 3mo ago
    > 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 3mo ago
      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 3mo ago
        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
ryan_n 3mo ago
> 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 3mo ago
  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 3mo ago
    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 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 3mo ago
> 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 3mo ago
  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).
nemomarx 3mo ago
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 3mo ago
  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.
  - nemomarx 3mo ago
    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 3mo ago
      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 3mo ago
IAmGraydon 3mo ago
>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 3mo ago
  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.
  - IAmGraydon 3mo ago
    >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 3mo ago
      > 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.
Silamoth 3mo ago
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 3mo ago
  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.
overgard 3mo ago
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 3mo ago
  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...
eudamoniac 3mo ago
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 3mo ago
  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.
gpm 3mo ago
> Rust libraries like bevy Notably bevy also bans AI contributions...
- maiybe 3mo ago
  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.

by maiybe 3mo ago

rschiavone 3mo ago

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

maiybe 3mo ago
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.
deleted 3mo ago
[deleted]
jerf 3mo ago
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 3mo ago
  > 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 3mo ago
    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 3mo ago
      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

ryan_n 3mo ago

> 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 3mo ago
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 3mo ago
  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 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 3mo ago

> 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 3mo ago
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).

nemomarx 3mo ago

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 3mo ago
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.
- nemomarx 3mo ago
  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 3mo ago
    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 3mo ago

IAmGraydon 3mo ago

>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 3mo ago
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.
- IAmGraydon 3mo ago
  >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 3mo ago
    > 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.

Silamoth 3mo ago

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 3mo ago
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.

overgard 3mo ago

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 3mo ago
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...

eudamoniac 3mo ago

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 3mo ago
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.

gpm 3mo ago

> Rust libraries like bevy Notably bevy also bans AI contributions...

maiybe 3mo ago
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.