I don’t know, but Unity is already pretty much point and click game building. I spent a few weeks building a card game with it during lockdown, and without a lot of code, I had an ugly, and basic, but totally playable game.
The hardest part to a game is building something fun yes, but it also has to meet some level of quality bar and work on any platform.
Unity is by far the most used engine in the world and tons of extremely different games were made with it. Subnautica, Rimworld, Hollow Knight, Beat Saber, the Ori games, Disco Elysium - none of them seemed to face any issues with being made in Unity. The "Unity games are bad" stereotype annoys me - it's bound to have a bunch of shovelware made on it with how many resources there are for learning it (and Unity being free), but it's popular for a reason.
I'm sure they did. But I wager there is no such thing as "smooth development". Every engine has its quirks, every team has its odd dynamics and clashes.
engines are there to make development smoother, not smooth.
>it's bound to have a bunch of shovelware made on it with how many resources there are for learning it (and Unity being free), but it's popular for a reason.
To be fair, that one is more on Unity. You had to pay to remove the splashscreen, so that meant low effort titles would have "MADE WITH UNITY" front and center, where higher budget titles could remove the logo. It was great for awareness, but it completely reversed the perception of the engine quality as a result.
(disclaimer: I used to work at unity)
That's not really what I wanted to convey. I'm not saying that their development process became spotless as a result of using Unity, but that these developers don't appear to be constrained by the engine in this extreme fashion like what the top commenter was suggesting - they successfully used it to make wildly different (and sometimes boundary-pushing) products.
> You had to pay to remove the splashscreen, so that meant low effort titles would have "MADE WITH UNITY" front and center, where higher budget titles could remove the logo.
Yeah, I agree with this. Almost all people have no idea what engine any given game runs on (if any), and professional developers will only put that in the credits, if at all. Admittedly, I can't think of any better ways of introducing some limitation for free users that wouldn't get overbearing - interfering with gameplay or other interactive stuff is probably a no-no, so a splash screen is one of the few viable options.
If your game doesn't do anything complicated so you don't need to code a lot, then sure unreal could work since by far the biggest problem is iterating on code for the different components and actors. Adding or removing or renaming fields or refactoring folder structure and then go and update them in the blueprints takes forever while in unity that is really easy.
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.
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.
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 :-)
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.
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.
We experimented with a few different form factors, including integrating into existing game engines, before taking this path. Our rationale was that we wanted to go beyond the existing engine integrations (i.e. Unity already has an AI assistant) and reimagine the entire game creation experience with AI and multiplayer in mind.
Our platform's entirely on the web, so you can link your current game/game creation session to someone else and have them join you. This works on most modern browser, making it easy to build and share games.
That being said, you're not wrong that the current scope of games is limited. That's OK with us for now - we'd like to focus on getting the core experience as good as possible with the current scope and then expand outwards, instead of trying to build something that attempts to solve everything and works for nothing.
How does that pan out?
There's hundreds of millions of dollars of product development in Unity and Unreal specifically for game design. How will you ever catch up?
Godot got $8m, for the people who authored it, what does it have to show for it? It seems like hopelessly little money.
Maybe you said to the investors, "You don't want to be locked in" or whatever. The browser still an engine. Mobile Safari and Chrome are also moving targets. You're still playing in someone else's back yard. There are no games that are designed to be played in Mobile Safari and also make money. I mean the browser also has AI assistants.
Obviously I want you to succeed but this sounds more like a good story than a good strategy. It doesn't hold up to an ounce of scrutiny. Right now it sounds like it's not interesting to develop the toolset for Unity because they are already doing it.