> Why do you think that's true?
> These will get faster and they will get controllable.
Brother, you're preaching to the choir. I've been shilling generative tools for gamedev far harder than you are in your reply. :-)
But I'm just relaying to you what actual gamedevs working and writing code right now need and for the foreseeable future for which projects have been started or planned. As Mike Acton says, "the problem is the problem".
> These techniques can already mimic the physics of optics better than 80 years of doing it with math.
I encourage you to talk to actual gamedevs. When designing a game, you aren't trying to mimic physics: you're trying to make a simulation of physics that feels a certain way that you want it to play. This applies to fluid dynamics, lighting/optics, everything.
For example, if I'm making a saling simulator, I need to be able to script the water at points where it matters for gameplay and game-feel, not simulate real physics. I'm willing to break the rules of physics so that my water doesn't act or look like real water but feels good to play.
Movement may be motion captured, but animation is tweaked so that the characters control and play in a way that the game designer feels is correct for his game.
If you haven't designed a game, I encourage you to try to make a simple space invaders clone over the weekend, then think about the physics in it and try to make it feel good or work in an interesting way. Even in something that rudimentary, you'll notice that your simulation is something you test and tweak until you arrive at parameters that you're happy with but that aren't real physics.
I've written my own 2D and 3D game engines as well as worked in Unreal. I'm currently working on a controllable diffusion engine using Bevy.
I strongly disagree that you need to cater to existing workflows. There's so much fertile ground in taking a departure. Just look at what's happening with animation and video. People won't be shooting on Arri Alexas and $300,000 glass for much longer.
> I strongly disagree that you need to cater to existing workflows.
I didn't say that these tools need to though. :-)
I said that actual high-end game developers need precise control over every aspect of their game. A developer needs to be able to say something as simple as: "I want to make my particle system to run at 30ps, while my cloth animation is 120fps, while my logic is at 60fps."
> I've written my own 2D and 3D game engines as well as worked in Unreal. I'm currently working on a controllable diffusion engine using Bevy.
Then you know all that I'm suggesting already! You probably have a list of the typical problems that game engine programmers are trying to solve when they build their own engines or have to modify Unreal Engine itself. You could even just watch GDC[^0] or the Graphics Programming Conference[^1] and ask how these tools solve the problems discussed.
Generative tools will create a new way of making games or game assets, but they won't eliminate the current way of making games.
Since you're building these generative tools alongside your game, you can demonstrate how they solve the kinds of problems game engine programmers need to solve and there's no need for us to misrepresent either side of the equation. Just give a presentation or publish an essay showing engine problems being solved at the standard a typical studio needs.
Brother, you're preaching to the choir. I've been shilling generative tools for gamedev far harder than you are in your reply. :-)
But I'm just relaying to you what actual gamedevs working and writing code right now need and for the foreseeable future for which projects have been started or planned. As Mike Acton says, "the problem is the problem".
> These techniques can already mimic the physics of optics better than 80 years of doing it with math.
I encourage you to talk to actual gamedevs. When designing a game, you aren't trying to mimic physics: you're trying to make a simulation of physics that feels a certain way that you want it to play. This applies to fluid dynamics, lighting/optics, everything.
For example, if I'm making a saling simulator, I need to be able to script the water at points where it matters for gameplay and game-feel, not simulate real physics. I'm willing to break the rules of physics so that my water doesn't act or look like real water but feels good to play.
Movement may be motion captured, but animation is tweaked so that the characters control and play in a way that the game designer feels is correct for his game.
If you haven't designed a game, I encourage you to try to make a simple space invaders clone over the weekend, then think about the physics in it and try to make it feel good or work in an interesting way. Even in something that rudimentary, you'll notice that your simulation is something you test and tweak until you arrive at parameters that you're happy with but that aren't real physics.