Cette page contient des informations pour aider les développeurs Unity expérimentés à démarrer avec Roblox, y compris une orientation de base, une comparaison conceptuelle et les principales différences entre les deux plateformes.
S'orienter


La fenêtre Hiérarchie de Unity et l'Explorateur de Roblox Studio sont les fenêtres principales pour organiser les éléments dans les scènes 3D :
- Les deux vous permettent de gérer et d'organiser les objets (par exemple, les personnages et les actifs environnementaux).
- Les deux utilisent une structure arborescente pour les relations parent-enfant entre les objets.
Cependant, la fenêtre Hiérarchie n'a pas de structure prédéfinie, tandis que la fenêtre Explorateur a une structure stricte. Il peut être utile de penser à la fenêtre Explorateur comme une combinaison des fenêtres Hiérarchie et Projet de Unity, avec le dossier Workspace comme élément le plus reconnaissable.
De même, le Gestionnaire d'actifs de Roblox Studio et la Boîte à outils chevauchent la fenêtre Projet de Unity. Le Gestionnaire d'actifs vous permet de gérer tous les actifs de votre jeu, tandis que la Boîte à outils vous permet d'accéder à tous les actifs que vous avez publiés. La Boîte à outils vous permet également de rechercher dans le Créateur Store des actifs provenant de Roblox ou de la communauté, de la même manière que le Magasin d'actifs de Unity.
Différences philosophiques
Roblox est un "moteur de simulation" plutôt qu'un moteur de jeu traditionnel. Les GameObjects de Unity et les Parts de Roblox servent tous deux de blocs de construction fondamentaux pour créer des objets dans un environnement 3D, mais dans la pratique, les deux sont assez différents :
- Représentation : Les GameObjects dans Unity sont un concept plus élevé pour tout objet dans une scène, tandis que les Parts dans Roblox sont conçus pour représenter des objets physiques comme des blocs de bois et des sphères en plastique, plutôt que de la géométrie abstraite comme des objets primitifs dans Unity.
- Physique : Pour effectuer des simulations de physique dans Unity, vous attachez des composants comme Rigidbody et Collider à un GameObject. Dans Roblox, la physique est intégrée au type de donnée Parts; le moteur gère les interactions automatiquement.
Vous pouvez voir la différence immédiatement si vous créez un GameObject et une Part. Le GameObject n'a rien de plus qu'une position, une rotation et une échelle. La Part a cette même information—plus un matériau et une couleur, des valeurs pour la réflectance et la transparence, la masse et la forme, et bien plus encore. Transformer une Part en quelque chose de plus semblable à un GameObject vide signifie supprimer beaucoup de propriétés intégrées. Inversement, vous pouvez faire un GameObject qui ressemble beaucoup à une Part en ajoutant des composants MeshFilter, MeshRenderer, Collider et Rigidbody.
D'un point de vue script, GameObject est le plus similaire à la Instance de Roblox, la classe de base pour toutes les autres classes Roblox, mais comme vous ne pouvez pas (et ne devez pas) créer des objets de type Instance, la comparaison n'est pas très pratique.
Une autre comparaison est celle du GameObject de Unity par rapport au Model de Roblox. Les modèles agissent comme un conteneur pour une collection de parties interconnectées de la même manière que vous pourriez établir une relation parent-enfant entre plusieurs GameObjects dans Unity. Vous spécifiez une des parties du modèle comme sa partie principale pour définir le point de pivot. Les modèles contiennent également des scripts, des animations, des effets sonores, des invites, des contraintes, des émetteurs de particules, et plus encore.
Par exemple, un GameObject de Unity pourrait avoir des composants pour ParticleSystem, Physics3D, SpringConstraint, et un script. Dans la fenêtre de Hiérarchie, vous voyez un seul GameObject nommé SpringyFireball. La fenêtre Inspector montre la collection de composants et de propriétés.
Dans Roblox, un modèle SpringyFireball comparable dans la fenêtre Explorateur pourrait ressembler à ceci :
Model|- ParticleEmitter|- MeshPart|- SpringConstraint|- ClickDetector| |- Script
La philosophie de la physique par défaut de Roblox s'étend au processus de construction de modèles 3D. Dans Roblox, souder plusieurs parties ensemble en un assemblage est un excellent moyen de construire rapidement des choses, car Roblox considère les pièces soudées comme un seul corps rigide. Cette approche n'est pas disponible dans Unity.
Plutôt que d'utiliser des unités métriques standard pour la longueur et la masse, Roblox utilise des unités notionales appelées studs et des Unités de Masse Roblox (RMU). Pour des conversions métriques approximatives et des recommandations concernant l'utilisation, voir Unités.
L'emplacement compte
Les jeux Roblox sont multijoueurs par défaut, donc Roblox Studio inclut de nombreux emplacements de stockage différents avec des comportements spécifiques. Pour plus d'informations, voir runtime client-serveur et organisation des objets.
| Location | Description |
|---|---|
| Workspace | Représente le monde 3D du jeu. Cet emplacement fonctionne bien pour les scripts serveurs qui se connectent directement à des objets et contrôlent leur comportement. |
| ReplicatedFirst | Contient des objets qui se répliquent vers le client avant tout autre. Cet emplacement est idéal pour l'ensemble minimum absolu d'objets et de scripts clients nécessaires pour afficher un écran de chargement. |
| ReplicatedStorage | Contient des objets qui sont répliqués à la fois vers le client et vers le serveur. Cet emplacement est idéal pour les ModuleScripts que vous souhaitez utiliser à la fois sur le serveur et sur le client. Les LocalScripts ne s'exécutent pas depuis cet emplacement, mais les Scripts avec un RunContext de Client le font. |
| ServerScriptService | Contient des scripts serveurs. Cet emplacement est idéal pour les scripts qui ont besoin d'accéder à des fonctionnalités ou des objets côté serveur, tels que la logique de jeu et le stockage dans le cloud. |
| ServerStorage | Contient des objets côté serveur. Cet emplacement est idéal pour les objets volumineux qui n'ont pas besoin d'être immédiatement répliqués aux clients lorsqu'ils rejoignent un jeu. Les scripts ne s'exécutent pas depuis cet emplacement, mais vous pouvez y stocker des ModuleScripts côté serveur. |
| StarterPlayer ⟩ StarterCharacterScripts | Contient des LocalScripts qui s'exécutent lorsque le personnage apparaît. |
| StarterPlayer ⟩ StarterPlayerScripts | Contient des LocalScripts à usage général qui s'exécutent lorsque le joueur rejoint le jeu. |
| StarterGui | Contient des éléments GUI que le client affiche lorsqu'il charge le jeu. Les LocalScripts peuvent s'exécuter depuis cet emplacement. Cet emplacement est idéal pour les scripts qui modifient l'interface utilisateur du jeu, comme l'ajout de boutons, de menus et de pop-ups. |
| StarterPack | Contient généralement uniquement des Tools, mais peut également inclure des LocalScripts pour configurer les sacs à dos des joueurs. |
Script
Roblox games support three different types of Luau scripts:
Scripts client
Ces scripts s'exécutent sur le client, et le serveur n'a aucune visibilité sur leur comportement. Pour des raisons de compatibilité, ces scripts peuvent prendre la forme de LocalScripts ou Scripts avec une valeur de RunContext de Client. Les scripts client se trouvent généralement dans ReplicatedStorage, StarterPlayerScripts ou StarterCharacterScripts.
Scripts serveur
Ces scripts s'exécutent sur le serveur, et le client n'a aucune visibilité sur leur comportement. Les scripts serveur ont une valeur de RunContext de Server et se trouvent généralement dans ServerScriptService, dont le contenu n'est pas répliqué au client.
Scripts de module
Ces scripts sont des morceaux de code réutilisables qui renvoient exactement une valeur, généralement une fonction ou une table (ou une table de fonctions). Plutôt que de dupliquer le code dans les scripts client et serveur, utilisez des scripts de module pour partager le code et les données entre les deux. Les scripts de module se trouvent souvent dans ReplicatedStorage, mais peuvent se trouver ailleurs si vous souhaitez partager du code entre les scripts du même côté de la frontière client-serveur.
Unity n'a pas le concept de différents types de scripts. Si vous choisissez de faire un jeu multijoueur, Unity utilise ses bibliothèques de mise en réseau pour indiquer quand un GameObject (et ses scripts) doit être exclusif au serveur.
Dans Unity, beaucoup de fonctionnalités du moteur sont disponibles par les méthodes de MonoBehaviour. Par exemple, pour exécuter du code avant la boucle de rendu, vous ajoutez du code dans la méthode Update(). Pour gérer les événements de collision physique, vous ajoutez du code dans la méthode OnCollideEnter().
Les scripts Roblox sont plus axés sur les événements. Vous accédez à des fonctionnalités similaires en vous abonnissant à des services et en écoutant des mises à jour.
C# et Luau
Pour le script, Unity utilise C#. Roblox utilise Luau, un langage de script dérivé de Lua 5.1.
En comparaison avec C#, Luau est typé de manière progressive et a généralement une syntaxe moins verbeuse. Dans les projets plus importants, cependant, le typage progressif peut introduire des catégories de bogues que les langages fortement typés comme C# évitent, donc envisagez d'activer la vérification stricte des types dans les scripts Roblox.
Pour les différences de syntaxe de base entre les langages de script, voir Comparaison Luau et C#.
Exemple de code Luau
Le code Luau suivant démontre comment, après qu'un joueur a équipé une canne à pêche, écouter l'entrée utilisateur (dans ce cas, la touche E) et appeler des fonctions supplémentaires :
local ContextActionService = game:GetService("ContextActionService")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
-- Obtenir un script de module depuis ReplicatedStorage qui renvoie une seule fonction
local performSomeAction = require(ReplicatedStorage.performSomeAction)
-- Supposons que ce script est un enfant de la canne à pêche
local fishingPole = script.Parent
local ACTION_CAST = "Lancer"
-- Vérifie que la touche est enfoncée, puis appelle une autre fonction
local function castLine(_actionName, inputState, _inputObject)
if inputState == Enum.UserInputState.Begin then
performSomeAction()
end
end
-- N'activer l'action que lorsque le joueur équipe la canne à pêche
fishingPole.Equipped:Connect(function()
ContextActionService:BindAction(ACTION_CAST, castLine, true, Enum.KeyCode.E)
end)
-- Désactiver l'action lorsque le joueur déséquilibre la canne à pêche
fishingPole.Unequipped:Connect(function()
ContextActionService:UnbindAction(ACTION_CAST)
end)
Le script Roblox peut être relativement concis car Roblox a de nombreuses hypothèses intégrées : un Player avec un personnage Humanoid connecté au serveur et pouvant équiper des Tools. Ces hypothèses n'existent pas dans Unity, donc l'implémentation serait très différente.
Actifs
Unity et Roblox prennent tous deux en charge l'importation de maillages et de modèles personnalisés au format .fbx. Certains types d'actifs peuvent nécessiter des configurations et des paramètres d'exportation spécifiques de votre logiciel de modélisation tiers. Pour plus d'informations, consultez les pages suivantes :
Dans Unity, les objets sont importés dans votre répertoire Assets, visibles dans la fenêtre Projet. Dans Roblox, les actifs sont importés dans votre Workspace et dans la Boîte à outils ou le Gestionnaire d'actifs.
Roblox propose également un plugin Blender open-source pour rationaliser le processus d'importation.
Transformations
Les transformations de Unity et les CFrames de Roblox servent des objectifs similaires dans la représentation des transformations 3D des objets :
- Les transformations et les CFrames représentent tous deux la position et la rotation d'un objet dans l'espace 3D. Les transformations incluent l'échelle, tandis que Roblox utilise une propriété BasePart.Size qui ne fait pas partie du CFrame.
- Les deux prennent en charge la multiplication pour des transformations complexes et ont des méthodes intégrées pour d'autres manipulations.
Collaboration
Dans Unity, vous collaborez avec des systèmes de contrôle de version standard ou des services payants comme Unity Version Control.
Les fichiers Roblox vivent dans le cloud (bien que vous puissiez exporter des copies), donc Roblox Studio fournit des flux de travail de collaboration intégrés pour l'édition simultanée, la gestion de groupe, les autorisations, la rédaction de scripts, et plus encore. Voir Collaboration.
Plugins
De la même manière que les outils de Unity, Roblox Studio prend en charge les plugins, qui peuvent simplifier ou vous donner un contrôle supplémentaire sur divers aspects du processus de développement. Les plugins sont disponibles dans le Créateur Store, tout comme les actifs, beaucoup étant gratuits.
Glossaire
| Unity | Roblox | Notes |
|---|---|---|
| Scène | Place | |
| GameObject | Part ou Model | Voir Différences philosophiques. |
| Prefab | Package | |
| Transformation | CFrame | CFrame n'inclut pas les informations d'échelle. Voir Transformations. |
| Hiérarchie | Explorateur | |
| Inspecteur | Propriétés | |
| Vue de scène | Vue 3D | |
| Vue de jeu | Vue 3D | La vue de l'espace de travail se transforme en vue de jeu lorsque vous testez votre jeu. |
| Fenêtre projet | Gestionnaire d'actifs ou Boîte à outils | |
| Inspecteur de terrain | Éditeur de terrain | |
| Point d'apparition | SpawnLocation | |
| Console | Sortie | |
| Magasin d'actifs | Créateur Store | |
| Superpositions | Barre d'outils | |
| Outil | Plugin |