> If I type “Create an Orc,” then I don’t want to be asked 20 follow-up questions to exactly specify the nature of the Orc; I just want it to take a guess.
This is the exact point where everything falls apart. Good games have simple rules that combine in robust ways to allow for varied expression.
Each roll of the dice here is baking in assumptions that will not play nice with the last unit, or the next one.
> I don't want to be asked 20 follow up questions to exactly specify the nature of the Orc
This is the tell that these folks don't know enough about game design to be opining so strongly on "the future of AI driven game development". Game development is almost exclusively about the 20 follow up questions. Any moron can say "I want minecraft but in space with guns", but making that and, more importantly, making it feel good, are where all the juice lies in games. The details are the most important part, which is why I think all these attempts to put AI into the game development flow are ill advised at best. Copilot is okay at helping out with game code, but less so than for normal e.g. REST API or UI code, because game code tends to follow rules that don't exist anywhere else and every game is architected completely differently. Games are just...different.
I promise that we've made games of our own in the past and that we're not coming at this completely unaware :-)
Our thinking is that you can lay a base quickly, and then iterate on that to work on the details of your game. We want to avoid the analysis paralysis that comes from having to make all of the decisions upfront; you can instead rely on the AI's "common sense understanding" of the world [0] to get started, and then refine it to your desired vision.
Our initial "engine" is highly-constrained with a specific ontology and predefined behaviours. That will strongly restrict what can be built with it. That's what makes it tractable to use with today's AI; as we develop better techniques and the backing models get better, we hope to cover more and more of the game design space.
[0]: Yes, this is a contentious concept, but in practice it has a pretty good idea of what an orc is :-)
>Our thinking is that you can lay a base quickly, and then iterate on that to work on the details of your game
I'm not an AI engineer, but my understanding with current AI advances is that it is very good at "laying a base" and very bad at "iterate on that". Many models are essentially throw out 90% of the previous iteration and grabbing something else for the next prompt.
I am a dev, and usually it isn't as hard to "lay a base", from a technical perspective. There's plenty of mock assets to work with, and then later on we can use a early design mesh to fine tune. I don't necessarily need an "orc" to work out the posing and animations for a game unless I'm doing facial animations.
But hey, there's 2000 dev pipelines for every 1000 studios, so this isn't to discredit you. Just hoping to give another perspective on how some approach game dev.
(I'm the in-house AI engineer at Braindump, but I come from a gamedev background.)
Yes, we agree that doesn't scale. Braindump's designed to let you change those assumptions at any time; the AI works over the state of the entire game (for the most part), so it can change past assumptions to better meet the user's current requirements.
This is the exact point where everything falls apart. Good games have simple rules that combine in robust ways to allow for varied expression.
Each roll of the dice here is baking in assumptions that will not play nice with the last unit, or the next one.