De Unity à Godot Engine

Ce guide fournit un aperçu de Godot Engine d’un point de vue d’un utilisateur de Unity, et vise à vous aider à transiter de votre expérience de Unity vers le monde de Godot.

Note

This article talks about older versions of Unity. Nestable prefabs (“Nested prefabs”) were added to Unity 2018.3. Nestable prefabs are analogous to Godot’s scenes, and allow a more Godot-like approach to scene organisation.

Différences

  Unity Godot
Licence Propriétaire, fermé, licence gratuite avec une limite de revenus et des restrictions d’usage Licence MIT, libre et open source sans aucune restriction
OS (éditeur) Windows, macOS, Linux (non-official and non-supported) Windows, macOS, X11 (Linux, *BSD)
OS (export)
  • Bureau : Windows, macOS, Linux
  • Mobile : Android, iOS, Windows Phone, Tizen
  • Web : WebAssembly or asm.js
  • Consoles : PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS
  • VR : Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, HoloLens
  • TV : Android TV, Samsung SMART TV, tvOS
Système de scène
  • Composant/Scène (GameObject > Composant)
  • Prefabs
Un arbre de scènes et des nœuds, permettant aux scènes d’être imbriquées ou d’hériter d’autres scènes
Outils de tierce partie Visual Studio ou VS Code
Notable advantages
  • Immense communauté
  • Grande boutique en ligne de ressources

L’éditeur

Godot Engine provides a rich-featured editor that allows you to build your games. The pictures below display the default layouts of both editors with colored blocks to indicate common functionalities.

../../_images/unity-gui-overlay.png ../../_images/godot-gui-overlay.png

While both editors may seem similar, there are many differences below the surface. Both let you organize the project using the filesystem, but Godot’s approach is simpler with a single configuration file, minimalist text format, and no metadata. This makes Godot more friendly to VCS systems, such as Git, Subversion, or Mercurial.

Godot’s Scene panel is similar to Unity’s Hierarchy panel but, as each node has a specific function, the approach used by Godot is more visually descriptive. It’s easier to understand what a scene does at a glance.

The Inspector in Godot is more minimal, it shows only properties. Thanks to this, objects can expose more useful parameters to the user without having to hide functionality in language APIs. As a plus, Godot allows animating any of those properties visually. Changing colors, textures, enumerations, or even links to resources in real-time is possible without needing to write code.

The Toolbar at the top of the screen is similar in both editors, offering control over project playback. Projects in Godot run in a separate window, rather than inside the editor (but the tree and objects can still be explored in the debugger window).

This approach has the disadvantage that in Godot the running game can’t be explored from different angles (though this may be supported in the future and displaying collision gizmos in the running game is already possible), but in exchange has several advantages:

  • Lancer le projet et le fermer est rapide (Unity doit sauvegarder, exécuter le projet, fermer le projet, puis recharger l’état précédent).
  • Le montage en direct est beaucoup plus pratique car les modifications apportées par l’éditeur prennent effet immédiatement dans le jeu et ne sont pas perdues (ni n’ont besoin d’être synchronisées) lorsque le jeu est fermé. Cela permet des flux de travail fantastiques, comme la création de niveaux pendant que vous les jouez.
  • L’éditeur est plus stable car le jeu s’exécute dans un processus distinct.

Finally, Godot’s top toolbar includes a menu for remote debugging. These options allow deployment to a device (connected phone, tablet, or browser via HTML5), and debugging/live editing on it after the game is exported.

Le système de scène

This is the most important difference between Unity and Godot and the favourite feature of most Godot users.

Working on a “level” in Unity usually means embedding all the required assets in a scene and linking them together with components and scripts.

Godot’s scene system is superficially similar to Unity. A “level” consists of a collection of nodes, each with its own purpose: Sprite, Mesh, Light, etc. However, in Godot the nodes are arranged in a tree. Each node can have multiple children, which makes each a subscene of the main scene. This means you can compose a whole scene with different scenes stored in different files.

Par exemple, pensez à un niveau de plateforme. Vous le composeriez avec plusieurs éléments :

  • Les briques
  • Les pièces
  • Le joueur
  • Les ennemis

Dans Unity, vous placeriez tous les GameObjects dans la scène : le joueur, plusieurs instances d’ennemis, des briques partout pour former le sol, puis plusieurs instances de pièces sur tout le niveau. Vous ajouteriez alors différents composants à chaque élément pour les lier et ajouter de la logique au niveau : Par exemple, vous ajouteriez un BoxCollider2D à tous les éléments de la scène pour qu’ils puissent entrer en collision. Ce principe est différent dans Godot.

In Godot, you would split your whole scene into three separate, smaller scenes, and instance them in the main scene.

  1. A scene for the Player alone.

Consider the player as an element we’d like to use in different parent scenes (for instance “level” scenes). In our case, the player element needs at least an AnimatedSprite node. This node contains the sprite textures necessary for various animations (for example, a walking animation).

  1. A scene for the Enemy.

An enemy is also an element we’d like to use in several scenes. It’s almost the same as the Player node. The only differences are the script (it needs “AI” routines to generate the enemy’s behaviour) and the sprite textures used by the AnimatedSprite node.

  1. A Level scene.

A Level scene is composed of Bricks (for platforms), Coins (for the player to collect) and a number of instances of the Enemy scene. Each instance is a node in the Level scene tree. These instances are separate enemies, which initially have shared behaviour and appearance as defined in the Enemy scene. You can set different properties for each Enemy node (to change its color, for example).

4. A Main scene. The Main scene would be composed of one root node with 2 children: a Player instance node, and a Level instance node. The root node can be anything, generally a « root » type such as « Node » which is the most global type, or « Node2D » (root type of all 2D-related nodes), « Spatial » (root type of all 3D-related nodes) or « Control » (root type of all GUI-related nodes).

Comme vous pouvez le voir, chaque scène est organisée en arborescence. Il en va de même pour les propriétés des nœuds : vous n’ajoutez pas un composant de collision à un nœud pour le rendre réactif aux collisions, contrairement à Unity. Au lieu de cela, vous faites de ce nœud un enfant d’un nouveau nœud spécifique possédant des propriétés de collision. Godot propose différents types de nœuds de collision, en fonction de l’utilisation (voir: ref: Introduction à la physique <doc_physics_introduction>).

  • What are the advantages of this system? Wouldn’t this system potentially increase the depth of the scene tree? And doesn’t Unity already allow you to organize GameObjects by putting them inside empty GameObjects?

    • Godot’s system is closer to the well-known object-oriented paradigm: Godot provides a number of nodes which are not clearly « Game Objects », but they provide their children with their own capabilities: this is inheritance.
    • Godot allows the extraction of a subtree of a scene to make it a scene of its own. So if a scene tree gets too deep, it can be split into smaller subtrees. This is better for reusability, as you can include any subtree as a child of any node. Putting multiple GameObjects in an empty GameObject in Unity does not provide the same functionality.

Organisation du projet

../../_images/unity-project-organization-example.png

There is no perfect project architecture. Any architecture can be made to work in either Unity and Godot.

However, a common architecture for Unity projects is to have one Assets folder in the root directory that contains various folders, one per type of asset: Audio, Graphics, Models, Materials, Scripts, Scenes, and so on.

Since Godot allows splitting scenes into smaller scenes, each scene and subscene existing as a file in the project, we recommend organizing your project a bit differently. This wiki provides a page for this: Organisation du projet.

Où sont mes prefabs (préfabriqués) ?

A prefab as provided by Unity is a “template” element of the scene. It is reusable, and each instance of the prefab that exists in the scene has an existence of its own, but all of them have the same properties as defined by the prefab.

Godot does not provide prefabs as such, but the same functionality is provided by its scene system: The scene system is organized as a tree. Godot allows you to save any subtree of a scene as a scene file. This new scene can then be instanced as many times as you want, as a child of any node. Any change you make to this new, separate scene will be applied to its instances. However, any change you make to the instance will not have any impact on the “template” scene.

../../_images/save-branch-as-scene.png

To be precise, you can modify the parameters of an instance in the Inspector panel. The nodes that compose this instance are initially locked. You can unlock them if you need to by right-clicking the instance in the Scene tree and selecting « Editable children » in the menu. You don’t need to do this to add new child nodes to this node. Remember that any new children will belong to the instance, not to the “template” scene on disk. If you want to add new children to every instance of your “template” scene, then you should add them in the “template” scene.

../../_images/editable-children.png

Correspondance de glossaire

  • GameObject -> Node
  • Ajouter un composant -> Hériter
  • Prefab -> Reusable Scene file

Scripting: GDScript, C# et Visual Script

Conception

Unity supports C#. C# benefits from its integration with Visual Studio and has desirable features such as static typing.

Godot provides its own scripting language, GDScript as well as support for Visual Script and C#. GDScript borrows its syntax from Python, but is not related to it. If you wonder about the reasoning for a custom scripting language, please read the GDScript basics and Foire aux questions pages. GDScript is strongly attached to the Godot API and doesn’t take long to learn: Between one evening for an experienced programmer and a week for a complete beginner.

Unity vous permet d’attacher autant de scripts que vous voulez à un GameObject. Chaque script ajoute un comportement au GameObject : Par exemple, vous pouvez attacher un script pour qu’il réagisse aux commandes du joueur, et un autre qui contrôle sa logique de jeu spécifique.

Dans Godot, vous ne pouvez joindre qu’un seul script par nœud. Vous pouvez utiliser un fichier GDScript externe ou inclure le script directement dans le nœud. Si vous avez besoin d’attacher plus de scripts à un nœud, vous pouvez envisager deux solutions en fonction de votre scène et de ce que vous souhaitez réaliser :

  • soit ajouter un nouveau nœud entre votre nœud cible et son parent actuel, puis ajouter un script à ce nouveau nœud.
  • ou, vous pouvez diviser votre nœud cible en plusieurs enfants et joindre un script à chacun d’eux.

As you can see, it can be easy to turn a scene tree to a mess. Consider splitting any complicated scene into multiple, smaller branches.

Connexions : groupes et signaux

Vous pouvez contrôler les nœuds en y accédant à l’aide de scripts et de fonctions d’appel (intégrées ou définies par l’utilisateur). Vous pouvez également les placer dans un groupe et appeler une fonction sur tous les nœuds contenus dans ce groupe! Ceci est expliqué dans :ref: cette page <doc_scripting_continued>.

Certains nœuds peuvent émettre des signaux lorsque certaines actions se produisent. Vous pouvez connecter ces signaux pour appeler une fonction spécifique lorsqu’ils se produisent. Notez que vous pouvez définir vos propres signaux et les envoyer quand vous le souhaitez. Cette fonctionnalité est documentée ici.

Sérialisation de scripts

Unity peut gérer la sérialisation de scripts de deux manières :

  • Implicite : Tous les champs publics de la classe sont automatiquement sérialisés si le type est sérialisable (Dictionary n’est pas sérialisable).
  • Explicite: Les champs non-publics peuvent être sérialisés en utilisant l’attribut [SerializeField].

Godot a également un système intégré de sérialisation de scripts, mais il ne fonctionne qu’explicitement. Vous pouvez sérialiser n’importe quel type sérialisable (intégrés et de nombreux types du moteur, y compris class_Array et class_Dictionary) en utilisant le mot-clé export. Ce fonctionnement est expliqué ici.

Unity possède également un type de données appelé ScriptableObject utilisé pour sérialiser les objets ressources personnalisés. Son équivalent dans Godot est la classe de base pour toutes les ressources : ref:class_Resource”. Créer un script qui hérite de :ref:`class_Resource vous permettra de créer des objets sérialisables personnalisés en série. Plus d’informations sur les ressources peuvent être trouvées ici.

Utiliser Godot en C ++

Godot vous permet également de développer votre projet directement en C ++ en utilisant son API, ce qui n’est pas possible avec Unity pour le moment. Par exemple, vous pouvez considérer l’éditeur de Godot Engine comme un « jeu » écrit en C ++ à l’aide de l’API Godot.

Si vous êtes intéressé par l’utilisation de Godot en C++, vous pouvez commencer à lire la page Développer en C++.