Decoupling ?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Corbo

Hi everyone.

I’m contemplating using Godot, both for past and future projects; browsed all the doc, but I’m still missing general info. My first impression is that Godot is very artist focused. Maybe not the best tool to bridge between designers, artists and coders. We’ll see.

My main issue is about the apparent strong coupling of the tool. Let me try to clarify with 2 general aspects:

  1. How would we go to use Godot to add/replace an engine in an existing C++ project ? For example, replace Ogre with Godot. Can we use it as pure SDK ? A standard process would be start engine/integrate to our resources manager/build scenes from data files/let Godot do some of its thing in our loop (for example, input handling is in-house,) and so on. The logic is of course already coded, so GdScript is pretty much unneeded.

  2. For a new project, how would we go to separate game data from GdScript ? Game variables belong to the designers, not to the artists or coders, and are to be stored outside, in more or less complex, overridable, possibly binary packs. The packs would reference Godot scene files, but the latter wouldn’t necessarily be distributed as is. Basically, how would we go to build a rich resources manager that GdScript generator scripts would then call to fill the details of the game logic ?

:bust_in_silhouette: Reply From: Zylann

It looks like you already have a big engine/game made on your own. Godot doesn’t only features rendering and physics (they actually account only a few % of the engine), it also has its own resource manager, input and GUI system, scene system, importers, exporters and editors.

  1. Godot “can” be used as an SDK by directly forking the engine. It’s not intented to be used as a third-party library, but should be fairly easy to mod. If you really want to keep your systems, you can disregard all the modules you don’t need (modules folder). Scene functionality is split in two main layers, one of which being the scene folder containing resource types and scene tree node types. You might be able to ignore it completely, and use the low-level layer only, inservers. For more explanation, see this Introduction to Godot development — Godot Engine (3.0) documentation in English . Keep in mind that you will probably need more investigation to know which parts you really want to swap, depends on your project.

  2. For a big production project, you could perhaps continue with modding the engine with custom C++ modules of your own to suit your production flow, and see Godot as an interface, or “view”. Godot is a main purpose engine, so it exposes a general set of tools that are the most commonly used, and doesn’t necessarily go too deep in a specific direction, so it’s expected that developers adapt it for their needs, more or less heavily. If variables are better outside, so be it, many devs use JSON instead of script variables exposed through inspector, sometimes downloaded from web service. Some people even rewrote an entire editor to suit more specific needs ( In your case you could also have a C++ module to handle your custom binary resource packs, and if core game logic is also in C++ then you could have another module per game.

Thank you sir. That’s pretty much what I expected. We’ll have to analyse the code to evaluate the tasks.
Just one thing, is that normal that your fist link sends me to a page yet to be constructed ?

Corbo | 2018-11-27 06:10

Argh no, the website included the end period in the link, I “fixed” it now

Zylann | 2018-11-27 18:59