Présentation
Bonjour chers lecteurs, dans l'article d'aujourd'hui, je voudrais m'attarder sur un tel phénomène dans le développement d'applications sur
Unity3d en tant que développement visuel ou, plus précisément, développement utilisant la représentation visuelle du code et de la logique. Et, avant de continuer, je veux clarifier tout de suite, nous ne parlons pas de programmation visuelle, du mot «absolument», il n'y a pas de variations de
Blueprint dans le monde Unity et pas de générations de code C #. Alors, qu'entend-on alors par un éditeur de logique visuelle? Si la réponse à cette question vous intéresse, bienvenue sous cat.
Articles de la série:
Visual Logic Editor, partie 2Qu'est-ce qu'un éditeur de logique visuelle
Très souvent, et certains affirment que toujours pendant le développement, les programmeurs écrivent beaucoup de code différent qui fait beaucoup de choses différentes, du système au mécanisme de jeu. Ce code, si le programmeur est «réel», est généralement rendu unifié et isolé pour pouvoir être réutilisé (au sein d'Unity, ce code est les composants, ils sont aussi les héritiers de
MonoBehavior ). Il n'est pas difficile d'imaginer qu'il puisse y avoir beaucoup de code, surtout si ce n'est pas le premier projet. Imaginez maintenant que nous démarrons un nouveau projet et que nous devons faire beaucoup de prototypes rapides et différents, et l'équipe de programmeurs est limitée, et l'ensemble est occupé par le ou les projets principaux. Les concepteurs de jeux sont indignés, ils doivent tester, vérifier, les producteurs courent autour des gestionnaires essayant de faire sortir un programmeur pour eux-mêmes, l'argent est limité, le temps presse, etc.
De l'autre côté de la médaille, nous (les programmeurs) avons écrit beaucoup de code sous forme de composants, ils sont accrochés dans une grande liste sur différents objets de la scène. Et donc nous élargissons l'équipe, avons embauché un nouveau programmeur, il ouvre la scène pour le trier et se noie dans un fouillis de questions: qui cause qui, dans quel ordre, quel composant est lié à quoi et comment, etc. Vous dites raisonnablement: - «Et documentation? " Il y a de la documentation (bien que ce ne soit pas du tout un fait), mais ici, il s'agit du seuil pour que les nouvelles personnes rejoignant l'équipe soient aussi basses que possible, et le temps pour ce processus aussi court que possible.
Comment résoudre les situations décrites ci-dessus? La réponse dans le titre de l'article est Visual Logic Editor. Qu'est-ce que c'est? Il s'agit d'un environnement qui vous permet d'opérer visuellement sur divers composants de la logique et de configurer leurs relations (dans la version «douce»), ainsi que de manipuler des objets de la scène indirectement à partir de la scène. Si vous le décrivez sous une forme fabuleusement simple, alors c'est comme dans l'enfance d'assembler différents modèles à partir de cubes (seulement dans notre cas, les cubes ne sont pas étroitement connectés, en enlevant le fond, notre conception ne tombera pas).
Donc, nous avons trouvé la définition, mais qu'est-ce que cela nous donne finalement?
- Vous pouvez assembler des conceptions universelles qui peuvent être réutilisées dans des projets, ce qui réduit la routine suivante. Imaginez une sorte de champ pur, qui est notre projet, nous prenons simplement la construction assemblée d'un autre jeu, la mettons sur le terrain et c'est tout.
- Vous pouvez créer une base de données de «cubes» isolés (mécaniques, logiques, fonctionnels) à partir desquels des personnes qui ne sont pas programmeurs pourraient construire des constructions par leurs propres moyens.
- Il est possible de remplacer les dessins à la volée par d'autres, modifiant ainsi le comportement de la logique.
- Vous pouvez utiliser des constructions en mode différé, par exemple, si le PNJ n'est pas présent dans le monde maintenant, alors aucune logique qui lui est associée n'existera sur notre «champ».
- Puisque nos cubes ne sont pas connectés par des relations rigides, nous pouvons les désactiver et les réactiver comme nous le souhaitons et implémenter des branchements conditionnels et inconditionnels complexes arbitrairement.
Eh bien, est-ce que ça sonne plutôt bien? Mais quoi en réalité? Si vous ouvrez
Asset Store et voyez la section
Visual Scripting , vous pouvez voir, en principe, un grand nombre de plugins différents. La plupart d'entre eux sont des variations sur le thème Blueprint du moteur Unreal, c'est-à-dire, essentiellement, la génération de code. Il n'y a pratiquement aucun système qui correspond aux concepts d'un éditeur de logique visuelle. Les sens les plus proches sont:
- Playmaker Oui, c'est un plugin FSM, mais néanmoins, il vous permet d'écrire vos propres actions. Ce n'est pas si pratique du point de vue de l'interface, mais pour certaines choses c'est très bien. Blizzard n'a pas été utilisé en vain à Hearthstone.
- Concepteur de comportement / MoonBehavior , etc. plugins d'arbre d'état. C'est plus proche de ce qui a été décrit ci-dessus, mais il y a beaucoup de limites, après tout, l'arbre d'état n'est pas une logique à part entière sur les composants.
- ICode Il s'agit d'un analogue du meneur de jeu, c'est-à-dire en fait également une machine d'État.
Y a-t-il une issue que vous demandez, chers lecteurs? Je n'en ai trouvé qu'un, j'ai écrit mon système, ce que j'ai fait, mais le chemin à parcourir était assez long et épineux.
Le chemin
L'idée de développer un plugin pour l'éditeur de logique visuelle pour
Unity3D est née il y a longtemps. Au début, ce n'était que des pensées que, si c'était le cas, ce serait cool. Ces pensées sont apparues dans le processus de travail sur un projet dans lequel il y avait beaucoup de jeux similaires, plus de 20 pièces qui devaient être faites très, très rapidement. La première implémentation a été terrible en termes d'interface, même si, bien sûr, elle nous a permis de développer avec succès l'ensemble des jeux à une vitesse donnée.
Pour le prochain projet, il a été décidé de créer un éditeur visuel à part entière, mais en conséquence, en raison du peu d'expérience, la mise en œuvre n'a pas réussi, tout était extrêmement lent, le nombre de connexions, etc., a tellement été mis à l'échelle qu'il était impossible de comprendre quoi et où (voir capture d'écran et n'ayez pas peur).

Après cela, l'idée a été reportée pendant un certain temps. J'ai déjà fait les projets suivants sur du code pur, mais l'idée planait toujours dans ma tête. Peu à peu, en tenant compte des erreurs passées, la vision finale (comme il me semblait) et la liste des exigences ont été formées. Et en 2017, après l'achèvement du prochain projet indépendant, j'ai décidé que je pouvais me permettre de passer 6-7 mois à travailler sur ce plugin et essayer de le mettre dans
Asset Store (il ment toujours et s'appelle
Panthea VS ). Du point de vue de l'expérience de travail sur un projet aussi complexe, tout était très cool, le côté financier est hélas triste, pouvoir programmer et vendre sont deux choses différentes. C'était en novembre 2017, après quoi j'ai un peu perdu ma motivation, j'ai divorcé, changé ma ville, complètement changé ma vie, et afin de ne pas tomber dans le samoyédisme, j'ai décidé de regarder sous un angle différent sur le sujet de l'éditeur de logique visuelle. Le résultat a été
uViLEd , que j'ai décidé de publier gratuitement. Depuis que j'ai signé un contrat à temps plein, j'ai dû y travailler le week-end et les jours fériés et cela m'a pris tout 2018 et début 2019.
uViLEd est une grande refonte de
Panthea VS , une refactorisation complète du code du compilateur Roslyn (C # 7+), donc tout ne fonctionne qu'à partir de la version Unity3d 2018.3.
Remarque :
Panthea VS a lancé plusieurs projets (Android et iOS, en particulier Lev's Truck et les voitures), en principe, l'expérience de son utilisation a été réussie, mais le moment est apparu que c'est une chose d'écrire un éditeur, une autre chose est d'apprendre à l'utiliser correctement (peu importe à quel point cela peut paraître étrange) )
uViLEd et comment l'utiliser
Présentation
Donc, ce qui s'est passé à la fin, nous regardons d'abord l'image, puis continuons (il y aura plus de photos).

Sur quoi est basé l'éditeur de logique visuelle?

Ici:
- Composants - c'est notre code qui implémente l'un ou l'autre fonctionnel, en fait, un analogue de MonoBehaviour , seulement dans notre cas tous les composants sont hérités de la classe LogicComponent , qui à son tour est un ScriptableObject .
- Les variables sont de tels ScriptableObjects spéciaux qui sont autorisés à stocker des données (tout, y compris les structures et classes personnalisées, les références aux objets de scène, les préfabriqués et les actifs). Des variables sont nécessaires s'il est nécessaire de partager des données entre les composants, c'est-à-dire que chaque composant peut faire référence à une variable du type souhaité, et ce sera une.
- Les relations sont une description sous forme visuelle de quels composants, comment et dans quel ordre appellent les méthodes des autres. Les relations entre les composants sont déterminées à l'aide de deux champs spécialisés de types INPUT_POINT et OUTPUT_POINT . Un lien est toujours formé comme point de sortie d'un composant vers le point d'entrée d'un autre composant. Ces connexions ne sont pas rigides, c'est-à-dire qu'elles ne sont pas visibles pour le programmeur et elles ne sont pas non plus dans le code. Ils sont présents, uniquement dans l'éditeur, puis lorsque la scène démarre, le contrôleur logique lui-même comprend le code. Comment cela se produit, nous en parlerons dans un article séparé.
Tout dans le compartiment - composants, variables et relations - forme la
logique . En général, rien de super compliqué, le programmeur écrit le code des composants et des variables, et le concepteur de jeu ou un autre (ou le même) programmeur / scripteur forme la logique en plaçant ces composants dans l'éditeur et en configurant les connexions et les paramètres.
Caractéristiques clés d'uViLEd
- Exécution de la logique (un ensemble de composants, de variables et de relations) en mode différé, y compris à partir d'une source externe (disque dur ou serveur)
- Établir des connexions entre les composants (ordre d'appel, activation et désactivation)
- Intégration facile des composants et de tout autre code, y compris les descendants de MonoBehavior
- Substitution de l'apparence des composants dans l'éditeur (analogue à CustomPropertyDrawer)
- Configuration des paramètres des composants via l'inspecteur Unity3d
- Ajoutez facilement des composants à la logique via le fichier de script glisser-déposer ou via un répertoire
- Regroupement de composants dans l'éditeur logique
- Réglage de l'affichage des composants dans l'éditeur (inversion, minimisation, activation et désactivation)
- Ouverture de l'éditeur de code de composant directement à partir de l'éditeur logique
- Afficher les données de débogage directement dans l'éditeur logique lors du démarrage dans l'éditeur
- Éditeur de logique visuelle de mise à l'échelle
- Si soudainement un grand nombre de composants sont contenus dans la logique, il y a la possibilité de les rechercher avec focus lors de la sélection (ceci s'applique aux variables)
- Débogage étape par étape en mode de lancement de scène dans l'éditeur Unity3d avec suivi de toutes les données transmises entre les composants et les valeurs des variables
- Prise en charge des méthodes MonoBehaviour et définition de l'ordre de leur appel. Remarque : ici, nous voulons dire que par défaut dans SO, il n'y a pas de méthodes comme Démarrer, Mettre à jour, etc. par conséquent, leur support a été ajouté aux composants eux-mêmes. Dans le même temps, à l'aide de l'attribut ExecuteOrder, vous pouvez configurer l'ordre dans lequel les méthodes Start, Update, etc. sont appelées.
- Prise en charge de Coroutine, async / wait et de tous les attributs Unity3d pour l'inspecteur, ainsi que prise en charge de CustomPropertyDrawer
Travailler avec l'éditeur
Pour commencer à travailler avec l'éditeur, vous devez ouvrir la scène, puis démarrer l'éditeur lui-même.

Après avoir démarré l'éditeur, nous initialisons la scène (le bouton de mise à jour dans l'éditeur), après quoi il sera possible de créer ou d'ajouter une logique existante à la scène.
Après avoir créé la logique (un fichier qui décrira les composants, leurs paramètres, les relations entre les composants, les variables et leurs valeurs), vous pouvez le remplir de sens. Pour ajouter un composant ou une variable, faites simplement glisser le script correspondant dans la zone de l'éditeur logique. Une autre option consiste à utiliser un répertoire généré automatiquement à l'aide de l'attribut
ComponentDefinition .

Après avoir ajouté plusieurs composants à la logique, ils peuvent être déplacés, y compris en groupes ou combinés en un groupe visuel.

Examinons plus en détail ce que nous représentons le composant lui-même dans un éditeur visuel.

Ici:
- Le bouton de menu du composant ouvre un menu déroulant avec lequel vous pouvez:
- Activer ou désactiver un composant
- Minimisez le composant (cela peut également être fait en double-cliquant sur l'en-tête)
- Inverser le composant (permuter les points d'entrée et de sortie)
- Masquer ou afficher la zone d'options des composants
- Ouvrez l'éditeur de code du composant
- La zone des paramètres du composant est l'endroit où les valeurs des paramètres clés du composant sont affichées, dont la composition dépend du programmeur
Pour configurer les paramètres (champs publics ou champs avec l'attribut SerializeField), vous devez sélectionner le composant dans l'éditeur logique et ouvrir l'inspecteur Unity3d.

Ici:
- Dans le coin supérieur droit se trouve un bouton qui vous permet de changer la couleur de l'en-tête, qui s'affiche dans l'éditeur logique
- Nom - champ pour définir le nom de l'instance de composant
- Commentaire - un champ pour définir un commentaire sur l'occurrence du composant; il s'affiche dans l'éditeur logique lorsque vous survolez le composant
- Paramètres du composant - la zone où les paramètres du composant sont affichés (champs publics et champs marqués avec SerializeField)
- Liens de variables - une zone pour définir des références aux variables (plus à leur sujet sera discuté dans la section sur l'utilisation des variables).
Pour regrouper visuellement des objets, vous devez les sélectionner, puis appuyer sur le bouton droit et sélectionner l'élément correspondant dans le menu. Les groupes peuvent être renommés et changer leur schéma de couleurs.

Pour mettre à l'échelle la représentation visuelle des composants à l'aide de la molette de la souris, tout est assez simple.
Et la dernière chose à laquelle je veux faire attention est de travailler avec les connexions entre les composants.
Pour établir une connexion, il est nécessaire de connecter le point de sortie d'un composant avec le point d'entrée d'un autre.



Les relations sont établies en fonction de la règle de correspondance de type qu'un point transmet et reçoit. Des exceptions sont faites à un point d'entrée qui ne reçoit pas de données; n'importe quel point de sortie peut y être connecté. Lorsqu'une connexion est établie, le système vérifie automatiquement la correspondance de type et indique si cette connexion peut ou non être établie. Les points d'entrée et de sortie sont définis dans le code du composant à l'aide des classes suivantes:
INPUT_POINT OUTPUT_POINT INPUT_POINT<T> OUTPUT_POINT<T>
Les deux premières classes sont utilisées pour les points d'entrée et de sortie qui n'acceptent pas de paramètres, la seconde, respectivement, vice versa. T peut être de tout type.
public INPUT_POINT <float> InputFloatValue = new INPUT_POINT<float>(); public OUTPUT_POINT <float> OutputFloatValue = new OUTPUT_POINT<float>();
Pour appeler une chaîne de liens, vous devez utiliser la fonction Exécuter.
OutputFloatValue.Execute(5f);
Afin de traiter un tel appel, il est nécessaire de définir un gestionnaire pour le point d'entrée dans le code du composant (à propos de l'endroit exact où nous parlerons un peu plus tard).
InputFloatValue.Handler = value => Debug.Log(value);
Et enfin, je veux mentionner un point important sur les connexions. S'il y a plusieurs liens à partir d'un point, alors dans l'éditeur, il est possible d'ajuster l'ordre de leur appel.
Travailler avec des variables
Comme mentionné précédemment, les variables sont des objets spéciaux qui vous permettent de partager des données entre les composants via des liens vers eux. Les variables, comme les composants, sont créées par les programmeurs.
[ComponentDefinition(Name = "Float", Path = "uViLEd Components/Base/Variable/Base", Tooltip = "Variable for a floating-point number", Color = VLEColor.Cyan)] public class VariableFloat : Variable<float> { }
Comme vous pouvez le voir, la classe de base pour les variables est la classe générique Variable, où T est le type de données qui est inclus dans la variable, T peut être n'importe quel type qui peut être sérialisé.
Dans l'éditeur, les variables sont affichées comme suit:

Pour modifier l'affichage des valeurs des variables, redéfinissez simplement la méthode ToString dans le type T.
public struct CustomData { public readonly int Value01; public readonly int Value02; public CustomData (int value01, int value02) { Value01= value01; Value02= value02; } public override string ToString() { var stringBuilder = new StringBuilder(); stringBuilder.AppendLine("Value01 = {0}".Fmt(Value01)); stringBuilder.Append("Value02 = {0}".Fmt(Value02)); return stringBuilder.ToString(); } }
Ainsi, une variable de ce type ressemblera à:
public class VariableCustomData : Variable<CustomData> { }
Pour ajouter une référence à une variable dans un composant, vous devez utiliser une classe spéciale.
public VARIABLE_LINK<CustomData> CustomVariableLink = new VARIABLE_LINK<CustomData>();
Après cela, le lien peut être défini dans l'inspecteur, et dans le menu déroulant, seules les variables de type
CustomData seront affichées, ce qui simplifie considérablement leur utilisation.
Pour faciliter l'utilisation des variables, il existe des méthodes spéciales qui vous permettent de déterminer quand une variable a changé sa valeur ou quand des données y ont été définies.
CustomVariableLink.AddSetEventHandler(CustomDataSet); CustomVariableLink.AddChangedEventHandler(CustomDataChanged);
Il convient de garder à l'esprit que les travaux modifiés par la condition
Equals , par conséquent, si des structures et des classes sont utilisées, cette méthode doit être redéfinie pour garantir un fonctionnement correct.
Travailler avec des objets Unity
En raison de la nature du système uViLEd, les liens directs vers les objets Unity ne peuvent pas y être utilisés, car ils ne peuvent pas être restaurés lors du chargement de la logique. Pour résoudre ce problème, un shell
VLObject spécialisé a été créé, qui vous permet de créer de tels liens, ainsi que de les enregistrer et de les charger. Entre autres choses, ce shell possède un éditeur de propriétés spécial qui vous permet d'obtenir des composants à partir de n'importe quel objet de la scène (voir la figure ci-dessous) si vous souhaitez y accéder. Avec
VLObject, vous pouvez stocker des liens non seulement vers des objets de scène et leurs composants, mais aussi vers des préfabriqués et des fichiers de ressources, tels que des textures, des sons, etc.
Remarque : si la logique existante est utilisée dans une autre scène, les références aux objets seront perdues, y compris les références aux préfabriqués, car la scène fait office de stockage. Cela doit également être pris en compte si vous prévoyez d'utiliser la logique comme modèle, dans ce cas, la meilleure option est de lui transférer les références nécessaires de l'extérieur (par exemple, de la logique attachée à la scène).
Il est également possible de restreindre le type d'objet Unity qui sera installé dans
VLObject . Cela n'affecte que l'inspecteur Unity et est utilisé pour la commodité de travailler avec eux.
[SerializeField] [TypeConstraint(typeof(Button))] private VLObject _button;
Création d'un composant logique
Pour créer un composant logique, il suffit au programmeur d'ajouter un simple fichier de script C # au projet (vous pouvez également créer un composant ou une variable immédiatement via un menu spécial dans l'onglet Projet) et changer le code qu'il contient comme suit:
[ComponentDefinition(Name = "MyComponent", Path = "MyFolder/MySubfolder", Tooltip = "this my logic component", Color = VSEColor.Green)] public class MyLogicComponent : LogicComponent { }
Comme mentionné précédemment,
ComponentDefinition est un attribut qui vous permet de créer automatiquement un catalogue de composants, ici il convient de noter que la couleur (la couleur de l'en-tête) est définie dans la chaîne au format HEX.
LogicComponent est la classe de base de tous les composants, qui à son tour est un descendant de
ScripatableObject .
Voici un exemple simple d'un composant qui effectue une ramification par une valeur entrante de type bool:
public class IfBool : LogicComponent { public INPUT_POINT<bool> ValueToBeChecked = new INPUT_POINT<bool>(); public OUTPUT_POINT True = new OUTPUT_POINT(); public OUTPUT_POINT False = new OUTPUT_POINT(); public override void Constructor() { ValueToBeChecked.Handler = ValueToBeCheckedHandler; } private void ValueToBeCheckedHandler(bool value) { if(value) { True.Execute(); }else { False.Execute(); } } }
Ainsi, comme vous pouvez le voir dans le code, nous avons créé le point d'entrée du composant, qui prend une valeur de type bool et deux points de sortie qui sont appelés en fonction de la valeur que nous avons obtenue.
Peut-être que vous avez maintenant une question, quel genre de
constructeur est- ce? J'explique. Par défaut,
ScriptableObject ne prend pas en charge les méthodes telles que
Start ,
Update , etc., mais il prend également en charge les méthodes
Awake ,
OnEnable ,
OnDisable et
OnDestroy . Voici donc
Awake (comme
OnEnable ), au cas où
ScriptableObject est créé via la méthode
CreateInstance , il est toujours appelé, et c'est en fait le problème. En raison du fait que l'objet est créé en mémoire pour la sérialisation en mode éditeur, il était nécessaire d'exclure le code du composant de fonctionner à ce moment, donc l'analogue
Awake a été ajouté en tant que méthode
constructeur , il en va de même pour les méthodes
OnDisable et
OnDestroy lors de la suppression d'un objet dans l'éditeur. Si vous devez traiter correctement la suppression d'un composant (lors du déchargement d'une scène, par exemple), vous devez utiliser l'interface
IDisposable .
En général, comme vous pouvez le voir, il n'y a rien de difficile à créer des composants. Il s'agit d'une classe régulière, dans laquelle il peut y avoir n'importe quel code que vous souhaitez. Dans le cas particulier, les composants peuvent ne pas contenir du tout de points d'entrée et de sortie, mais communiquer à l'aide de messages globaux. Soit dit en passant, pour cela, dans
uViLEd, il y a une classe
GlobalEvent - c'est un système de messagerie basé sur les types de données (vous en trouverez plus à ce sujet dans mon article).
La dernière chose que je voudrais mentionner est la possibilité de configurer les points d'entrée et de sortie du composant en fonction des paramètres du composant.

Pour ce faire, dans le code du composant, il suffit d'implémenter une ou les deux
interfaces IInputPointParse et
IOutputPointParse . Vous trouverez ci-dessous un exemple de code de classe générique abstrait pour les composants de branche
Switch ; les points de sortie sont automatiquement créés ici, en fonction du paramètre
SwitchValues .
Code de classe SwitchAbstract public abstract class SwitchAbstract<T> : LogicComponent, IOutputPointParse { [Tooltip("input point for transmitting value, which should be checked")] public INPUT_POINT<T> ValueToBeChecked = new INPUT_POINT<T>(); [Tooltip("set of values for branching")] public List<T> SwitchValues = new List<T>(); protected Dictionary<string, object> outputPoints = new Dictionary<string, object>(); public override void Constructor() { ValueToBeChecked.Handler = ValueToBeCheckedHandler; } protected virtual bool CompareEqual(T first, T second) { return first.Equals(second); } protected virtual string GetValueString(T value) { var outputPontName = value.ToString(); #if UNITY_EDITOR if (!UnityEditor.EditorApplication.isPlaying) { if (outputPoints.ContainsKey(outputPontName)) { outputPontName += " ({0})".Fmt(outputPoints.Count); } } #endif return outputPontName; } private void ValueToBeCheckedHandler(T checkedValue) { foreach (var value in SwitchValues) { if (CompareEqual(checkedValue, value)) { ((OUTPUT_POINT)outputPoints[GetValueString(value)]).Execute(); return; } } } public IDictionary<string, object> GetOutputPoints() { #if UNITY_EDITOR if (!UnityEditor.EditorApplication.isPlayingOrWillChangePlaymode) { outputPoints.Clear(); } #endif if (outputPoints.Count == 0) { foreach (var value in SwitchValues) { outputPoints.Add(GetValueString(value), new OUTPUT_POINT()); } } return outputPoints; } }
Débogage logique
UViLEd propose plusieurs mécanismes de débogage de la logique:
- La possibilité d'afficher les variables internes et leurs valeurs dans l'éditeur logique en mode de lancement de scène. Pour ce faire, utilisez l'attribut ViewInDebugMode
- Possibilité d'afficher les valeurs des variables logiques en mode de lancement de scène
- Possibilité de débogage étape par étape des appels entre les composants et de visualiser les données qui sont transférées entre eux
UViLEd dispose d'un mode spécial pour le dernier élément, qui s'active au démarrage de la scène.

Ce mode, malheureusement, a certaines limites associées à la transition entre les scènes. Dans ce cas, les données de débogage de la scène et des logiques précédentes seront perdues et dans la nouvelle, elles ne commenceront à être affichées qu'à partir du moment où la logique est activée dans l'éditeur.
Conclusion
Dans cet article, j'ai essayé de vous présenter brièvement l'approche de développement que j'utilise dans mes projets en cours. Malgré le scepticisme initial (y compris le mien), la pratique montre de manière significative la commodité de son utilisation, en particulier lors du prototypage. Entre autres choses, le travail des concepteurs de jeux a été grandement simplifié, ils n'entrent pas dans la scène, ne poussent pas d'objets pour configurer le processus de jeu, une logique distincte est créée pour eux avec un ensemble de données de variables et de composants dans lesquels ils peuvent facilement tout configurer. Un autre grand avantage est le fait que dans mes projets, le contenu est souvent téléchargé de l'extérieur. En utilisant l'éditeur de logique visuelle, je peux mettre à jour l'équilibre du processus de jeu sans mettre à jour l'application principale, dans certains cas, la logique elle-même peut être modifiée.
Pour ma part, j'ai décidé qu'une telle approche du développement est tout à fait la place, bien sûr, elle ne s'applique pas aux grands projets, mais elle peut être utilisée là pour certains scripts de gameplay pour revitaliser le monde, dans la conception de niveaux, etc. Dans mon projets en cours (segment enfants), jusqu'à présent, il montre d'excellents résultats.
Et ensuite?
C'était la première partie d'une série d'articles sur l'éditeur visuel de logic uViLEd, puis il y aura des parties sur:
- Le cœur du système : comment la logique est-elle chargée, pourquoi ScriptableObject est-il sélectionné, comment l'API est-elle organisée, qui vous permet de faire, etc., quelles difficultés sont survenues et comment tout a été résolu.
- Editeur : comment il a été développé, comment il a été construit, quels problèmes et quelles solutions, etc. choses, que je referais maintenant.
Écrivez dans les commentaires si vous avez des questions spécifiques que vous aimeriez que je couvre dans les articles suivants.
PS : J'ai essayé de parler des points clés de
uViLEd , si vous avez un désir, vous pouvez vous familiariser avec celui-ci en téléchargeant le plugin depuis Asset Store, il y a une documentation complète (bien qu'en anglais): un manuel d'utilisation, un guide pour les programmeurs et les API.
Visual Logic Editor, partie 2Éditeur de logique visuelle UViLEdArticle sur la messagerie globale