3 ms·
On the larger game teams I've worked on, most people using blueprints and schematics aren't the programmers but the content creators. The programmers are provid
by drakonka 5y ago
On the larger game teams I've worked on, most people using blueprints and schematics aren't the programmers but the content creators. The programmers are providing said blueprint elements/building blocks as well as extending (or modifying) the engine with other logic that content creators don't need access to via their visual tools.
For example: a level designer might want a specific type of entity in their level (let's say a floating platform). A programmer can extend the engine to provide the logic for said entity, which accepts parameters like how quickly the platform should move, what should trigger the movement, in which direction it is moving, etc. The programmer implements all of this and the final result is a new entity type said level designer can drag and drop into their level in the editor, and configure to their heart's content.
- vvanders 5y agoYep, and Kismet before that. The usual consumers are designers and tech artists, at least in the teams I was on. Previous to that we also heavily leveraged Lua coroutines as a form of literate programming/game "script". Since the coroutines would execute in a linear manner(with yield() where it handed execution back to the engine) it was really powerful for scripted sequences. Another interesting area is industrial/PLC programming. The parallels between what we did in gamedev and ladder programming was striking. Visual state representation, online edit-deploy-debug. I'm fairly confident you could give a designer a copy of a ladder editor connected to a game engine and they would have no problem scripting out a sequence.
- HWR_14 5y agoTo build on this, those parameters that are exposed require a ton of tuning, more tuning and retuning. As a game programmer, exposing those numbers to someone who cares a lot about it and whose job it is to monkey with them frees them up to iterate without you in the loop. They get better results (because more iterations) and you are out of the loop so you can work on teh next thing. This is vital because, unlike accounting software, there is no "right answer" to arrive at. There used to be junior programmer positions for people to listen to artists and modify/rebuild the source with different magic numbers. That's a waste of everyone's time.
- jayd16 5y agoThis explains why there's a simplified scripting layer but not why it's a graph based programming language. Unity has an example of configurable game objects without graphs but still the momentum is towards graph based systems in many places.
- dagmx 5y agoGraphs show logic flow. It's as simple as that. Monobehaviours in Unity alone can't show logic, they contain them, they're just components that don't describe an inherent execution order among themselves.