[matsemann]

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]

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.

[BlargMcLarg]

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.

[nineteen999]

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]

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]

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++.

[tlarkworthy]

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.