LLMs play a surprising role in a revival for language-based programming in game development, says Rocketwerkz CEO Dean Hall.

Rocketwerkz CEO Dean Hall and Floating Point Origin Interactive founder Felipe Falanghe sound downright giddy when they talk about the new C# framework named “Brutal.” During a recent call with Game Developer, the brains behind DayZ and Kerbal Space Program couldn’t stop making random asides to each other about what they’ve pulled off with the tool and how they’ve inspired each other’s work.

Their joy was infectious because once you understand how Brutal functions, you realize every new feature is a bona fide accomplishment even for this pair of seasoned developers. “It’s called Brutal for a reason,” Hall said after Felipe compared working with it to the experience of sitting on a bar stool while all your friends using engines like Godot are sitting on a comfy couch.

  • I Cast Fist@programming.dev
    1·
    1 month ago

    Visual scripting tools like Unity and Unreal Engine were supposed to speed up development and let designers think more about their game and less about blocks of code. Why would we go back to a world where everyone’s building their own game engines?

    A number of reasons I can think of.
    One: debloat and performance. Unreal and Unity are extremely bloated. As much as I enjoy Godot, the bare minimum executable that it produces is over 20MB. Less bloat means less code being shipped which typically translates into better performance.
    Two: better control of what’s going on. Sure, UE’s source is open for you to peek in and see what’s going on, but it has literal decades of baggage. Unity has its way of doing things and, other than plugins, you’re stuck with it. The point that Dean Hall makes of these engines all working based on scenes[1] and not every game needing that is spot on.
    Three: Visual scripting isn’t new and it leaves you stuck with the tool. There are several engines that offer visual scripting, some decades old (Clickteam Fusion, GameMaker, RPG Maker, Construct), being widely used for simpler games, but never for stuff that “thinks outside the box”, so to speak.

    Hall made a rather bold prediction: frameworks like Brutal, not game engines, will be the future of the game development.

    I wouldn’t go that far. A lot of big budget games will still use ready-made engines like UE and Unity simply due to cost and time, others will do things on their own “hard” way. CDProjekt ditched their own custom engine that powered Witcher 3 and Cyberpunk 2077 to work with UE going forward.

    The only thing the LLM does for Brutal developers is speed up access to information, letting them research without watching a 40 minute YouTube video. (…) You can boil down Hall’s theory about what he calls “the death of big engines” to this: if LLMs make language-based coding more accessible, than visual-based scripting loses its edge.

    Not going to be the “death” of big engines because he’s putting waaaay too much faith in people bothering to even search “how to do X using Y framework”.

    Hall’s vision of the future game industry is almost the polar opposite of the one pitched by UGC platforms and AI boosters. Instead of a world where game development becomes easier through simplified tools, it becomes more accessible through easier understanding of language-based programming through LLMs.

    In other words, it’s a StackOverflow that won’t berate you for “a stupid, repeated question” which should, in theory, help out with new stuff so long as it is properly documented, which seems to be the case with the Vulkan API

    1. “If you take Unity or Unreal, you have this editor scene and push play, it becomes a game scene and everything in it is relative to 0-0-0 of that scene,” said Hall. “That’s how you draw things, and it’s so ingrained that people have a hard time imagining something that’s different.” (…) The thinking wasn’t “Unity can’t do this, I need a tool that can do this.” It was “our game needs floating origin to work this way, how do we do it?” ↩︎