6 ms·

As someone used to living in my editor, I have a hard time grasping the workflow that combines configuring lots of stuff via UI, and then having code in some fi

As someone used to living in my editor, I have a hard time grasping the workflow that combines configuring lots of stuff via UI, and then having code in some files in addition. When making "real" games (something bigger than a demo/prototype) in Godot , Unity etc., is the UI used much? Seems constraining, or how does it play together with lots of code? Asking because I'm interested in learning, but when experimenting myself I end up with the worst from both somehow.

m_t 7y ago
Yes, using the UI is very important. In Unity, having a good UI in your inspector will let you, the programmer, empower the other team member to use what you've created. Designer, artists, etc. will be able to tune, tweak and modify a lot of things without dealing with the code, or having you deal with the code.
- matsemann 7y ago
  Yeah, my problem may be I'm used to working with frameworks and not engines, so I try to do everything in code. Which means reinventing some stuff or doing grunt work (placing tiles manually), and not being able to use the UI properly (attaching behaviour to entities). But it's hard figuring out what should be done where, and how to utilize the strengths of both parts. Would be happy if someone had nice tips / readings to share.
  - lentil_soup 7y ago
    I think ideally you should start with the editor and only move to code once you have a need the editor can't provide. Think of Photoshop. You'd never want to code your own effects or workflows if they're already there. In the case of an game editor you'll eventually need to code some behaviours or interactions between entities, and even then you might be able to do those with a visual editor which a few engines come with. In a way, code should almost be your last resource when making a game. Also think that making a game is a heavily iterative process, you want to reduce the friction between iterations as much as possible. So even code should be targeted at exposing options that you can edit on the fly within the editor. The benefit of a good editor is that it is WYSIWYG. So if say, an object is not lining up, has the wrong colour, particle effects are staying for too long, etc you can quickly pause and adjust the values in the editor and see the result immediately, no need to be tweaking values in a file.
    - deleted 7y ago
      [deleted]
  - tlarkworthy 7y ago
    Use the UI for level design, use code is for features. So placement of opponents, spawn location and configuration of opponents is all in the UI as its primarily artistic and subjective. You can judge what it looks like from the editor, unlike code. Code is used to create the infrastructure to support the level design.
  - BlargMcLarg 7y ago
    Do what works for you. Make things data-driven through the editor when it suits you more. Do it in code when it suits you more in code. Only in teams do you really have to worry about where something is beyond personal preference. Example: You can use Node.GetChild(index) in Godot to get a node in the code, or you can expose a nodepath variable in the editor to hook the node to. The first method is code-based, the second one is data-based and more accessible for users. I doubt the performance difference is very significant (and its only done once, anyway). Other than that, avoid using volatile structures when things need to be solid (above examples easily break when the structure of the children changes, the name changes, etc. whereas a more sophisticated, code-based construction wouldn't), and avoid rigid implementations when you need flexibility.
  - deleted 7y ago
    [deleted]
  - nineteen999 7y ago
    UE4 has a really nice balance here; you can create your own C++ classes, either by inheriting from UObject (lowest common denominator class), or higher level classes like UActor, UPawn, UCharacter, UTexture etc. There are component classes that can then be attached to these to give you a composition based approach, rather than just pure inheritance. With C++ you have a very fine grained control over everything, however the compile/link/dynamic reloading cycle can be quite slow and you don't get much in the way of instant visual feedback. This is where Blueprint classes come in; they can inherit from both C++/Blueprint classes, and can be extended very quickly in the editor using a node editor similar to what you'd find in the UE4 Material Editor and Animation Graphs, Blender, Substance Designer, Nuke etc. The feedback loop is much tighter and you can see the results on screen much more quickly. Downside is that not all API's are exposed to Blueprint, and they are a little slower than C++ classes. This can be mitigated somewhat by compiling Blueprint classes to C++ in recent versions.
    - pjmlp 7y ago
      I am more into the managed languages side of game engines, but as far I know from UE presentations, dynamic re-loading of C++ should be quite ok nowadays.
      - nineteen999 7y ago
        As I think we have discussed before, it had difficulties at least as recently as 4.18 or 4.19 when you added or removed variables/members into classes or structs other than at the end, which is not totally unexpected. It does mean you have to restart the UE4 editor which can be slow. Also compiling UE4 C++ code in general can be extremely slow. Is is extremely tempting sometimes to prototype some new feature in Blueprint because of this, as a result you can end up with a lot of unwieldly Blueprint code that you never rewrite in C++.
gambiting 7y ago
>>When making "real" games (something bigger than a demo/prototype) in Godot , Unity etc., is the UI used much? Seems constraining, or how does it play together with lots of code? Well, I work at a AAA studio where we use different engines, and at least some of the workforce is not actually familiar with programming, or has only very basic understanding of it(think level designers, gfx people etc). Being able to build most of the game in the editor without touching any code is very beneficial to this. Usually the flow looks like this: level designers request feature X, then programmers provide feature X using the built-in code editor, if that is impossible for any reason then it goes down to engine programmers who add the required feature directly into the editor.
- dijit 7y ago
  Which engine(s) are you using? I thought only Snowdrop was this way.
  - gambiting 7y ago
    Well, you do know it's Snowdrop ;-) But we use other internal engines too, the flow is pretty much the same as far as I can tell. Not when people are using Unity/UE for obvious reasons.
rahkiin 7y ago
Making games is very visual. So yes, you do a lot in the editor. And as someone who also uses code to give initial positions and rotations: it is easier to get an idea how things look in a visual editor than with code. We tend to make visuals, visually. See Photoshop, Illustrator, Blender. There are others such as Substance and Houdini that use visual programming. Also visual, but also coding (much like UE4 blueprints) but you can see results throughout the code which is something that coding has a harder time with.
mwill 7y ago
Most "real" games (Not what I'd call it, I'd say larger/complex games) are made by teams of different disciplines, not just programmers. The UI of Godot/Unity/Unreal, and most other engines is catered towards that, teams with all different specialties collaborating.
meheleventyone 7y ago
Even if you're primarily making a game and not a general purpose engine it's really helpful to get some things out of text and into a visual medium. Usually in that case the tools are built into the game or a specific game editor. Examples are level editing, putting together animation, setting up assets for example transforms for character customisation and the biggie I've never not seen in a game runtime inspection of the game in progress. All of this can be edited as text but it becomes laborious and error prone. Even setting up stats for something like an RPG is often better done in a spreadsheet where the results can be modeled.
correct_horse 7y ago
I had a similar experience going through the Godot "Your first game" tutorial [1]. I have little experience with game engines, but attaching signals in GDScript seemed like it required GUI interaction, then it was difficult for me to understand when the signal code actually was run. [1] https://docs.godotengine.org/en/3.1/getting_started/step_by_step/your_first_game.html https://docs.godotengine.org/en/3.1/getting_started/step_by_...
- BlargMcLarg 7y ago
  https://docs.godotengine.org/en/3.1/classes/class_object.html#method-descriptions https://docs.godotengine.org/en/3.1/classes/class_object.htm... Each Node has access to add_user_signal() for creating signals in code, connect() and disconnect() for subscribing to the signals, and emit() to emit a signal outside of Godot's predefined framework (along with other methods). Generally, anything you can do in Godot's editor can be done in code.
mysterydip 7y ago
I'm with you, 20+ years of staring at an editor is hard to overcome :) I could see how a scene editor would be useful for a game like super mario bros, but how do I use it when my levels are procedurally generated?
- matsemann 7y ago
  Exactly, it's those kind of questions nagging at me :)
- MH15 7y ago
  Unity lets you execute scripts in the editor, so I usually execute level generation scripts on the editor and player/effects scripts when the game is playing.
- fenwick67 7y ago
  Scenes aren't just levels. Let's say you're making a bomb item for your game, in Godot you would probably make a bomb scene with a particle emitter and a model and a collider. You could then use the scene editor to configure these components instead of having then all in code. Tweaking certain parameters is much faster with the UI than using code and a debugger. Imagine trying to line up a sphere collider with a model using code and a debugger, vs just dragging the handles around. The scene editor also works as an inspector, so you can fly around your scene and inspect properties and the scene graph while the game is running.
deleted 7y ago
[deleted]
corysama 7y ago
Artists and designers are accustomed to Maya-style GUIs. As a counter-example however, I worked at a game studio where we made our own engine. We didn’t have the time to make GUI-based tools. So, instead we focused on text-based configuration, Lua scripting, fast asset baking and hot-reloading of everything mid-game. When we switched to Unity for business reasons most people thought it was a productivity reduction.
hombre_fatal 7y ago
Your comment reminds me of when I started OSX/iOS client development. It frankly gave me some sort of anxiety how much a single checkbox on some UI pane with some element selected in Xcode could change everything. It at least would show up in your git diffs as a change in the generated XML, but I always felt like I was credentializing in a bunch of trivia knowledge as I leveled up in the Xcode's controls. Much like managing your database in phpmyadmin instead of maintaining a simple schema.sql file.
gentleman11 7y ago
Unreal is the worst here because their C++ API documentation is unusable, and all their official, fleshed out docs are for a visual node-based scripting system called blueprints. Those blueprints seem to be their main focus and I just hate programming via click and drag. In unity/Godot, at least you can still write a program mostly in code
- friendlybus 7y ago
  Blueprints aren't for programming, they are for scripting and the material editor. As soon as you want a data structure more complicated than a map, or to do for loops inside the blueprints, it gets unpleasant. Unreal is designed to integrate with a hot reloading visual studio setup in c++. Extending and sharing code is a breeze with plugins and many people fork the whole engine itself to make significant changes. One team reimplemented source style movement in their fork and shared it.
jokoon 7y ago
I never managed to like unity or godot because they remove freedom from the developer. Your code becomes a second class citizen. Apparently level design people and artists like it, which makes sense, of course, since indie gamedevs and small teams who are full of ideas and content, want to work as quickly as possible. But as a developer, I just loathe those tools. They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible while getting bleeding edge graphics. In reality it just enables unambitious projects so that "anybody can make games". It's like comparing LEGO to mechanical engineering. Of course, if you're pedantic, a LEGO car fits the definition of a car. You can sell a lego car, and then you realize how twisted the indie video game market is right now. But if you want to make a game, those WYSIWYG things are horrible. They're viable, but if you have some issue or limitation with the tool, you're really stuck. If there's a performance problem, it becomes more difficult. If you want to release on console, there are additional steps and work to do. You cannot "use what you want", because it's a huge generic blob of things that you cannot really understand how it's made. I watched a video about the internals of godot and was not convinced at all. Of course it's open source but it's a giant mess. Unity is not even open source. I will always show this video each time those WYSIWYG tools are talked about: https://www.youtube.com/watch?v=tInaI3pU19Y https://www.youtube.com/watch?v=tInaI3pU19Y It's the 40 years old debate "should I use this feature rich framework to make the website of my grandma?". The answer is "you either care about your ability to write code, or you don't.". Simple as that. Another result is a large bubble in the video game market. There are just too many games. In a way, it helps people gaining experience, but even many of the great games are often very short lived. I think it will give a bad reputation to platforms like Steam etc.
- prophesi 7y ago
  These visual editors are a godsend when developing a videogame. Even with ThreeJS, which is still an abstraction of OpenGL, I've had a lot of issues with really simple visual problems, like getting my models placed at correct locations at correct scales with the correct rotation. Trigger box placement. Enemy spawn locations. Their visual fields. I ended up having to essentially script my own visual editor to debug these issues. God forbid I have to implement any sort of networked multiplayer. And yes, there are a _lot_ of games. Steam is already suffering from the lack of quality assurance. But allowing creativity to flourish like this is good for society in the end. Personally, I think UE4 has the right idea. You can have your first-class citizen code (C++ components) which you can hand off to be used by the more design-oriented team members (Blueprint scripting + visual editor).

m_t 7y ago

Yes, using the UI is very important. In Unity, having a good UI in your inspector will let you, the programmer, empower the other team member to use what you've created. Designer, artists, etc. will be able to tune, tweak and modify a lot of things without dealing with the code, or having you deal with the code.

matsemann 7y ago
Yeah, my problem may be I'm used to working with frameworks and not engines, so I try to do everything in code. Which means reinventing some stuff or doing grunt work (placing tiles manually), and not being able to use the UI properly (attaching behaviour to entities). But it's hard figuring out what should be done where, and how to utilize the strengths of both parts. Would be happy if someone had nice tips / readings to share.
- lentil_soup 7y ago
  I think ideally you should start with the editor and only move to code once you have a need the editor can't provide. Think of Photoshop. You'd never want to code your own effects or workflows if they're already there. In the case of an game editor you'll eventually need to code some behaviours or interactions between entities, and even then you might be able to do those with a visual editor which a few engines come with. In a way, code should almost be your last resource when making a game. Also think that making a game is a heavily iterative process, you want to reduce the friction between iterations as much as possible. So even code should be targeted at exposing options that you can edit on the fly within the editor. The benefit of a good editor is that it is WYSIWYG. So if say, an object is not lining up, has the wrong colour, particle effects are staying for too long, etc you can quickly pause and adjust the values in the editor and see the result immediately, no need to be tweaking values in a file.
  - deleted 7y ago
    [deleted]
- tlarkworthy 7y ago
  Use the UI for level design, use code is for features. So placement of opponents, spawn location and configuration of opponents is all in the UI as its primarily artistic and subjective. You can judge what it looks like from the editor, unlike code. Code is used to create the infrastructure to support the level design.
- BlargMcLarg 7y ago
  Do what works for you. Make things data-driven through the editor when it suits you more. Do it in code when it suits you more in code. Only in teams do you really have to worry about where something is beyond personal preference. Example: You can use Node.GetChild(index) in Godot to get a node in the code, or you can expose a nodepath variable in the editor to hook the node to. The first method is code-based, the second one is data-based and more accessible for users. I doubt the performance difference is very significant (and its only done once, anyway). Other than that, avoid using volatile structures when things need to be solid (above examples easily break when the structure of the children changes, the name changes, etc. whereas a more sophisticated, code-based construction wouldn't), and avoid rigid implementations when you need flexibility.
- deleted 7y ago
  [deleted]
- nineteen999 7y ago
  UE4 has a really nice balance here; you can create your own C++ classes, either by inheriting from UObject (lowest common denominator class), or higher level classes like UActor, UPawn, UCharacter, UTexture etc. There are component classes that can then be attached to these to give you a composition based approach, rather than just pure inheritance. With C++ you have a very fine grained control over everything, however the compile/link/dynamic reloading cycle can be quite slow and you don't get much in the way of instant visual feedback. This is where Blueprint classes come in; they can inherit from both C++/Blueprint classes, and can be extended very quickly in the editor using a node editor similar to what you'd find in the UE4 Material Editor and Animation Graphs, Blender, Substance Designer, Nuke etc. The feedback loop is much tighter and you can see the results on screen much more quickly. Downside is that not all API's are exposed to Blueprint, and they are a little slower than C++ classes. This can be mitigated somewhat by compiling Blueprint classes to C++ in recent versions.
  - pjmlp 7y ago
    I am more into the managed languages side of game engines, but as far I know from UE presentations, dynamic re-loading of C++ should be quite ok nowadays.
    - nineteen999 7y ago
      As I think we have discussed before, it had difficulties at least as recently as 4.18 or 4.19 when you added or removed variables/members into classes or structs other than at the end, which is not totally unexpected. It does mean you have to restart the UE4 editor which can be slow. Also compiling UE4 C++ code in general can be extremely slow. Is is extremely tempting sometimes to prototype some new feature in Blueprint because of this, as a result you can end up with a lot of unwieldly Blueprint code that you never rewrite in C++.

gambiting 7y ago

>>When making "real" games (something bigger than a demo/prototype) in Godot , Unity etc., is the UI used much? Seems constraining, or how does it play together with lots of code? Well, I work at a AAA studio where we use different engines, and at least some of the workforce is not actually familiar with programming, or has only very basic understanding of it(think level designers, gfx people etc). Being able to build most of the game in the editor without touching any code is very beneficial to this. Usually the flow looks like this: level designers request feature X, then programmers provide feature X using the built-in code editor, if that is impossible for any reason then it goes down to engine programmers who add the required feature directly into the editor.

dijit 7y ago
Which engine(s) are you using? I thought only Snowdrop was this way.
- gambiting 7y ago
  Well, you do know it's Snowdrop ;-) But we use other internal engines too, the flow is pretty much the same as far as I can tell. Not when people are using Unity/UE for obvious reasons.

rahkiin 7y ago

Making games is very visual. So yes, you do a lot in the editor. And as someone who also uses code to give initial positions and rotations: it is easier to get an idea how things look in a visual editor than with code. We tend to make visuals, visually. See Photoshop, Illustrator, Blender. There are others such as Substance and Houdini that use visual programming. Also visual, but also coding (much like UE4 blueprints) but you can see results throughout the code which is something that coding has a harder time with.

mwill 7y ago

Most "real" games (Not what I'd call it, I'd say larger/complex games) are made by teams of different disciplines, not just programmers. The UI of Godot/Unity/Unreal, and most other engines is catered towards that, teams with all different specialties collaborating.

meheleventyone 7y ago

Even if you're primarily making a game and not a general purpose engine it's really helpful to get some things out of text and into a visual medium. Usually in that case the tools are built into the game or a specific game editor. Examples are level editing, putting together animation, setting up assets for example transforms for character customisation and the biggie I've never not seen in a game runtime inspection of the game in progress. All of this can be edited as text but it becomes laborious and error prone. Even setting up stats for something like an RPG is often better done in a spreadsheet where the results can be modeled.

correct_horse 7y ago

I had a similar experience going through the Godot "Your first game" tutorial [1]. I have little experience with game engines, but attaching signals in GDScript seemed like it required GUI interaction, then it was difficult for me to understand when the signal code actually was run. [1] https://docs.godotengine.org/en/3.1/getting_started/step_by_step/your_first_game.html https://docs.godotengine.org/en/3.1/getting_started/step_by_...

BlargMcLarg 7y ago
https://docs.godotengine.org/en/3.1/classes/class_object.html#method-descriptions https://docs.godotengine.org/en/3.1/classes/class_object.htm... Each Node has access to add_user_signal() for creating signals in code, connect() and disconnect() for subscribing to the signals, and emit() to emit a signal outside of Godot's predefined framework (along with other methods). Generally, anything you can do in Godot's editor can be done in code.

mysterydip 7y ago

I'm with you, 20+ years of staring at an editor is hard to overcome :) I could see how a scene editor would be useful for a game like super mario bros, but how do I use it when my levels are procedurally generated?

matsemann 7y ago
Exactly, it's those kind of questions nagging at me :)
MH15 7y ago
Unity lets you execute scripts in the editor, so I usually execute level generation scripts on the editor and player/effects scripts when the game is playing.
fenwick67 7y ago
Scenes aren't just levels. Let's say you're making a bomb item for your game, in Godot you would probably make a bomb scene with a particle emitter and a model and a collider. You could then use the scene editor to configure these components instead of having then all in code. Tweaking certain parameters is much faster with the UI than using code and a debugger. Imagine trying to line up a sphere collider with a model using code and a debugger, vs just dragging the handles around. The scene editor also works as an inspector, so you can fly around your scene and inspect properties and the scene graph while the game is running.

deleted 7y ago

[deleted]

corysama 7y ago

Artists and designers are accustomed to Maya-style GUIs. As a counter-example however, I worked at a game studio where we made our own engine. We didn’t have the time to make GUI-based tools. So, instead we focused on text-based configuration, Lua scripting, fast asset baking and hot-reloading of everything mid-game. When we switched to Unity for business reasons most people thought it was a productivity reduction.

hombre_fatal 7y ago

Your comment reminds me of when I started OSX/iOS client development. It frankly gave me some sort of anxiety how much a single checkbox on some UI pane with some element selected in Xcode could change everything. It at least would show up in your git diffs as a change in the generated XML, but I always felt like I was credentializing in a bunch of trivia knowledge as I leveled up in the Xcode's controls. Much like managing your database in phpmyadmin instead of maintaining a simple schema.sql file.

gentleman11 7y ago

Unreal is the worst here because their C++ API documentation is unusable, and all their official, fleshed out docs are for a visual node-based scripting system called blueprints. Those blueprints seem to be their main focus and I just hate programming via click and drag. In unity/Godot, at least you can still write a program mostly in code

friendlybus 7y ago
Blueprints aren't for programming, they are for scripting and the material editor. As soon as you want a data structure more complicated than a map, or to do for loops inside the blueprints, it gets unpleasant. Unreal is designed to integrate with a hot reloading visual studio setup in c++. Extending and sharing code is a breeze with plugins and many people fork the whole engine itself to make significant changes. One team reimplemented source style movement in their fork and shared it.

jokoon 7y ago

I never managed to like unity or godot because they remove freedom from the developer. Your code becomes a second class citizen. Apparently level design people and artists like it, which makes sense, of course, since indie gamedevs and small teams who are full of ideas and content, want to work as quickly as possible. But as a developer, I just loathe those tools. They sort of make sense for non-developers who want to make a prototype game and "tweak" things by writing as little code as possible while getting bleeding edge graphics. In reality it just enables unambitious projects so that "anybody can make games". It's like comparing LEGO to mechanical engineering. Of course, if you're pedantic, a LEGO car fits the definition of a car. You can sell a lego car, and then you realize how twisted the indie video game market is right now. But if you want to make a game, those WYSIWYG things are horrible. They're viable, but if you have some issue or limitation with the tool, you're really stuck. If there's a performance problem, it becomes more difficult. If you want to release on console, there are additional steps and work to do. You cannot "use what you want", because it's a huge generic blob of things that you cannot really understand how it's made. I watched a video about the internals of godot and was not convinced at all. Of course it's open source but it's a giant mess. Unity is not even open source. I will always show this video each time those WYSIWYG tools are talked about: https://www.youtube.com/watch?v=tInaI3pU19Y https://www.youtube.com/watch?v=tInaI3pU19Y It's the 40 years old debate "should I use this feature rich framework to make the website of my grandma?". The answer is "you either care about your ability to write code, or you don't.". Simple as that. Another result is a large bubble in the video game market. There are just too many games. In a way, it helps people gaining experience, but even many of the great games are often very short lived. I think it will give a bad reputation to platforms like Steam etc.

prophesi 7y ago
These visual editors are a godsend when developing a videogame. Even with ThreeJS, which is still an abstraction of OpenGL, I've had a lot of issues with really simple visual problems, like getting my models placed at correct locations at correct scales with the correct rotation. Trigger box placement. Enemy spawn locations. Their visual fields. I ended up having to essentially script my own visual editor to debug these issues. God forbid I have to implement any sort of networked multiplayer. And yes, there are a _lot_ of games. Steam is already suffering from the lack of quality assurance. But allowing creativity to flourish like this is good for society in the end. Personally, I think UE4 has the right idea. You can have your first-class citizen code (C++ components) which you can hand off to be used by the more design-oriented team members (Blueprint scripting + visual editor).