Comment fonctionne Unity ?

[Flamingitte]

Bonjour à tous !

je viens de m'inscrire sur ce forum, c'est donc un plaisir de faire à tous votre connaissance !
voilà donc j ai commencé à utilisé ce moteur seulement hier. J ai suivi un ou deux tutos pour me mettre dans le bain, et après être arriver à terme de ces tutos, une questions me vint à l'ésprit : Comment tout ça fonctionne ?

Avant de me lancé là dedans je tiens à préciser que j'ai programmer en C, C++, java durant ces 5 dernières années, en autodidacte. J ai programmé dans ces différent langage quelque petit jeux 2D. Et c'est là que je bug... Car la manière de faire sur Unity est complètement différente ... Par exemple, pourquoi peut on mettre du code sur un objet modélisé ? c'est complètement bizarre... où je met mon code principale ?
En fait j'ai l impression ici que la programmation passe en second plan, et n'est plus du tout le coeur de mon "jeu".
Je me trompe peut être, même sûrement ! car je n'ai sûrement pas découvert plus de 2% du moteur en 3-4h de "test".

J'ai été voir dans la doc de unity, seulement j'ai beaucoup de mal avec l'anglais, du coup je me perd très vite et je trouve pas ce que je cherche ... Donc si quelqu un a de la documentation en français ou encore une explication pour les moteurs de jeu en général je suis preneur !

en vous souhaitant une bonne journée

[boubouk50]

Bon, par où commencer...
D'abord Unity utilise la POO (Programmation Orientée Objet, pour quelqu'un qui fait du Java, tu devrais connaître) avec Unityscript/C#/Boo. On recommande C#. Les objets de la scène contiennent les scripts car ils représentent les "objets" de la POO. (Bon, je ne suis pas programmeur, alors je dis comme je l'ai compris...)
Le doc d'Unity est en anglais, donc il va falloir faire un effort. D'ailleurs, je ne comprends pas comment à l'heure actuelle tous les programmeurs ne soient pas un minimum calés en anglais.
3/4h, c'est vraiment pas suffisant pour se faire une idée (c'est plutôt 0.02% que 2%), regarde les réalisations sous Unity et tu te rendras bien compte des possibilités.

[Flamingitte]

merci pour ta réponse !
ok je crois comprendre quand tu dis que ce sont les objets... Seulement je créais mes objets dans le code principal (je parle ici d'une instance de classes, ma classe se trouvait dans un autre fichier, je la fais courte ..), or ici le script à l'air d'agir alors que je l'appel nul part, je l'ai juste "assigné" à un cube sur la scène ..
Pour un cas plus concret, où mettrais je le code qui gère "l'histoire" de mon jeu ? je ne dois quand même pas assigner tout mes script à des objet sur la scène ? si ?
Pour l'anglais je comprend un minimum, je vais devoir me faire un petit peu violence tu as raison

[Iwa]

Salut à toi,

première chose : pour la doc en français, ça n'existe pas, mais google trad est ton ami et te permettra de traduire ce qu'il te faut. Même approximative, cette traduction fait souvent sens .

Sinon pour comment le bouzin fonctionne, Unity est un outil qui est basé sur la programmation par Composant ou Component dans Unity.

Il y a plus ou moins le même cycle de vie qu'un programme normal mais la façon d'accéder aux objets, de penser est différente.

En gros : tu peux toujours créer des classes qui ne sont pas MonoBehaviour, tu peux coder en C# normal (attention c'est que du C# 2.0) mais dés que tu as besoin de manipuler un objet 3D, un objet d'UI, de la physique ou autre, il faut utiliser une passerelle et cette passerelle c'est le script héritant de MonoBehaviour et situé sur le gameobject concerné.

Après tu peux faire des "manager" d'objets qui vont prendre plusieurs GameObject ou Component en paramètres et ça te permet de faire une unique passerelle avec des comportements similaires ou pas .

Je sais pas si c'est pleinement clair mais c'est un cycle de vie vraiment similaire avec une surcouche en gros.

Et je me suis encore fait grillée mais bon j'étais en réunion ce coup ci

[Oliver]

Salut,

Il fais des tutoriels en français qui sont de qualités sur Unity 3D et qui apprend aussi les bases, va voir : http://www.unity3d-dev.com/

[Flamingitte]

Re !
Merci beaucoup Iwa, J'ai été faire des recherches sur la programmation orienté composant, du coup je comprends un peu mieux le fonctionnement .. En fait l'utilisation de ce moteur (peut être des autres aussi ..) facilite grandement le développement en équipe ! Ne serait ce que pour le code, chaqu'un peut s'occuper de "composants" différent et ensuite le tout est de bien emboîter l'ensemble. du moins c'est ce que j'ai cru comprendre.

[nigel]

Unity, c'est en gros un éditeur qui te permet de faire tourner un moteur physique + un moteur de rendu de manière ultra simple, puisque toute la mécanique complexe est caché.
Un projet c'est un dossier dans lequel Unity vient chercher tout les éléments externes à donner au moteur de jeu.
Ce sont des fichiers comme des sons, des objet géométriques, des scripts, des gameObjets ou des scenes.

Le moteur de jeu c'est une grosse boucle qui distribue du temps de calcul environ 100 fois par seconde. tout ce qu'il fait, c'est d’exécuter et répéter des étapes ;
>>
-"regarder tout les éléments ayant un composant script"
-"calculs spatiaux de tout les éléments,"
-"calculs physique de tout les éléments ayant un composants physiques,"
-"regarder tout les élément ayant un composant script"
-"rendu de tout les éléments ayant un composant graphiques."
<<
Le but du développeur c'est d'exploiter cette boucle en créant une classe MonoBehaviour, et écrire du code dedans.

Car lorsqu'un élément de la liste passe dans une des étapes d’exécution, (par exemple physique) le moteur regarde si le gameObjet contient une classe "MonoBehaviour", et exécute le code à l’étiquette "physics"
Le développeur a ainsi accès à ces étapes, et le code exécuter peut alors appeler d'autres script ne contenant pas de classe MonoBehaviour.

Un gameObject c'est un des éléments traiter dans la boucle. Dans le code c'est une liste de numéro de série unique, sur lequel se sont greffés des composants (des propriétés sous forme de classe pour le développeur.)
Une scene c'est l'ensemble des éléments traiter dans la boucle. Une boucle ne peut traiter qu'une scene à la fois.
On peut avoir plusieurs scene dans un projet.

De base, un gameObjet possède au minimum un composant transform, qui en code est une classe donnant des propriétés spAtiales à un gameObect.
Donc tout les éléments de la liste possèdent une existence spatial dans le moteur.
La classe MonoBehaviour permet également d'hériter des propriété spatiales du gameObject associé.

Chacun gère tout ça à sa manière, mais pour résumer , ce sont par les activité des classes MonoBehaviour que le fil logique peut se dérouler. Son code peut appeler d'autres scriptes, et s’appuyer sur des script externe de data pour que le comportement des objet puisse s'adapter correctement à ton histoire.
Le reste c'est une question d'organisation, il y a de grosses différences d'un jeu à l'autre.
99% du code écrit par le développeur va sur les gameObjects.

Voila, alors j'ai jamais vraiment vérifié je suis pas un pro, tout ce que je raconte est basé sur ce que je crois savoir + le bon sens,
donc je suis peut être à corriger, mais ça doit ressembler à ça...