The worst pile of ___ I have seen built on Unreal in recent years was people using std:: namespace containers and std types to seriously build an online multiplayer game in Unreal with async slave threads for each player, then adding tons of spaghetti blueprints on top of all that.
It made my eyes bleed every morning.
Perhaps Verse being imposed could dramatically reduce things like that from happening. And help the engine lose this growing fame among gamers saying that it is an unoptimized engine (just like happened to Unity engine)
Verse would probably discourage such nonsense. But in its place we might get games with AI slop code where teh LLM overlord decided it needed 8000 lines of code to make a lightswitch so it could properly simulate alternating current oscillation, resistance, and voltage before it toggled on a point light. Not sure that would help the engine seem more optimized to the average player who’s just wondering why their fps hitches whenever they look at a switch in that game.
I tried searching for this but found no evidence for this claim. The thing that sounds closest to “regret” I found was that they chose Microsoft XNA framework and Microsoft axed it afterwards, so they ended up building the game on deprecated engine. That’s not an issue of the language though, that’s an issue of the framework, and Microslop being Microslop.
Engineers: “Designers should only move props.”
Also engineers: “Can you move that chair in the Outskirts Inn please?”
AFAIK, this division of roles is already lived to the bone in studios anyway. Daily abuse of tiny teenie powers
Give me responsibility over a chair, and I will use that power to its limits.
Joke aside, production bottlenecks is a concern, I see both sides to be honest. People should probably learn some coding through Verse, maybe a safer language like Verse is best for both sides in that terms. Maybe a bit painful change but in the long term can decrease level designer’s need for an engineer thus an engineer can go fix bigger/lower level problems and do REAL engineering rather than scripts.
Telling us we can use AI as if it will save you isn’t realistic.
many users won’t use AI in the first place. For small projects, AI is okay, but it isn’t cheap, and the token cost is high.
From my experience using AI to build an app, every time it needs to fix code, it takes around 30 to 40% of my limit, and then I have to wait for hours. The AI also produces a lot of incorrect code.
If the Verse system had a similar or easy to learn visual system that could do everything and was as fast or faster than Blueprint, then I would be okay with it.
Classically, they are level/map, 2/3D artists, animators, modelers, texture artists, shader coders etc.
Engineers: Sr/Jr programmers, network, and scripters. Typically the Jr’s handle scripting.
Sr GD/programmers define the logic and mechanic scope. They’d also handle the low level core coding and tooling. Setting up the base functionality that Jr’s would use to finish up the mechanics or functionality.
E.g. Sr codes CMC, PMC. Jr configures and scripts them in application.
Jr would also handle creating common assets like doors, elevators, interaction code, light poles with switches.
Jr would then show the LD how to use and configure them.
There shouldn’t be a need for a level designer to have to code/script anything. If they have the skill set for it sure, but they have to communicate with the Sr on the projects architecture and foundation, schema etc.
Yeah, that’s not easy. I can’t define myself. I was joking btw pointing about production problems.
You are correct, in short that is how it should be in an optimum environment, besides render programming maybe.
If somebody can do something beyond the “average” scope of their role, there is usually a place for it. That is what I have seen, and to be honest I don’t care anymore “Free Agent” is probably my best role.
Self-sustaining is good, unless it becomes somebody else’s problem.
I don’t want to dilute the thread. My point is just that Epic / engine teams / we shouldn’t look at everything only technically. Visual programming and Blueprints are something nice because they unlock many people to evolve, learn, grow, and become better versions of themselves. As you know I don’t defend or attack on bp / verse.
Letting juniors make mistakes is what makes us true seniors. Hope with verse we don’t have to untangle stupid redundant LLM codes.
Yeah render programming (pipeline) is definitely on the engineer team. The material designer I would lump in with designers, just a different tier. They are the ones handing out jobs to texture artists.
I’d categorize myself as a GD/programmer, Network engineer. I’ve touched just about every domain. Some a lot more than others, but all enough to understand and communicate.
LLM codes … Not sure what you are talking about here.
By LLM code, I mean badly designed, redundant, or nonsense boilerplate code generated by AI. With Verse, I worry we will see more of that on forums, and eventually in professional teams too.
I don’t care if code is LLM generated as long as it is designed well by someone who knows what they are doing. I just don’t think that will be the common case. that knows what are they doing but I don’t think that is what we are mostly going to see.
Ahhh, well we already see that garbage with BP daily. There’s a mountain of YT BP tutorials published daily too with garbage approaches and coding practices.
“I was following this tutorial, or Claude told me this/that”
I really wish more people would hit the docs though. It’s wild seeing people treat game dev like it’s Fallout 4 base building. “If it isn’t that easy all the time I should complain”.
Something like this would be nice to have directly from Epic, so that we would not have to rely on a third party.
Visual scripting with nodes is all many are asking for, its the nodes themselfes, and connecting them with lines, not necessarily actors.
Epic could lower their standards for this, just like they did for f.e. their Paper2D plugin But for me its good to know, that Node editors are already in the works, even if they are third party.
I don’t see that as a plausible possibility. ECS is about performance first. Anything that complicates it is probably going to be a no-go. See what 6.5 brings.
How would a “Visual Verse Node to Verse text” converter slow anything down? The Engine can and should run the pure Verse code, that editor is just there to display that code in a more artistic friendly way. But all these nodes get converted to your Verse code.
Just like BP does now. Only way around that is a pure non-integrated editor. You do your node thing, then copy paste the result to verse, compile. Manually entering class/function references.
Referencing other classes requires a VM. Tracking nodes requires a VM. Contextual options based on current selection requires a VM. All of that it overhead that needs to be integrated at a low level.
Take that same tool and drop two tick event nodes on the graph. It will let you do that. To prevent that you need application layer oversight.
You should really dig into how BP works at the application layer. There’s a hella lot of dependencies.
But for me its good to know, that Node editors are already in the works, even if they are third party.
