Créer son jeu avec Unity3D !

[schouffy]

Oui vraiment c'est beaucoup plus dur que ce que j'imaginais. Le pire c'est de se dire que c'est un choix d'être parti sur un "jeu" et que c'est moi qui ai proposé l'idée. On aurait pu faire complètement autre chose, c'est libre.

Non mais accroche toi c'est normal d'avoir une courbe d'apprentissage un peu violente au début, mais ça va s'améliorer avec le temps. Faut juste que ça t'intéresse et te plaise.
Fais des tutos, c'est important, ça va tout démystifier.

Pour ton problème de scène intérieure/extérieure, contrairement à Gronours, je t'aurais conseillé de plutôt tout créer dans la même scène (à des endroits différents), et téléporter le joueur ailleurs dans ta scène quand il approche de certaines zones. C'est plus facile et t'as pas de temps de chargement à gérer, de contexte global à transférer entre tes scènes (même si il y a des outils simples our ça) etc...

[schouffy]

Pour ce qui est du plan sur lequel apparaissent les objets 2D, je te conseille de gérer ça via les Sorting layers, c'est fait pour. Regarde la doc Unity, c'est plutôt limpide comme fonctionnalité.

[Grosnours]

Pour ton problème de scène intérieure/extérieure, contrairement à Gronours, je t'aurais conseillé de plutôt tout créer dans la même scène (à des endroits différents), et téléporter le joueur ailleurs dans ta scène quand il approche de certaines zones. C'est plus facile et t'as pas de temps de chargement à gérer, de contexte global à transférer entre tes scènes (même si il y a des outils simples our ça) etc...

C'est vrai, mais l’inconvénient est d'avoir des scènes moins lisibles pour des débutants puisqu'elles seront polyvalentes. Lorsqu'on commence je conseillerais plutôt d'avoir une scène par niveau/environnement et d'utiliser du Don'tDestroyOnLoad et/ou des singletons si on a vraiment un problème de contexte global à transférer. Dans ce genre de projets les temps de chargement ne sont pas un problème.
Mais chacun ses préférences.

[Sariyah]

Oui effectivement les temps de chargement ne sont vraiment pas un problème d'autant plus qu'on n'aura pas le temps de faire une map immense. Globalement si on arrive à faire une quête de bout en bout (avec le concept de la geoloc IRL) je pense que ce sera bien.
Concernant les tutos, on a simplement fait le Creator Kit RPG, je l'ai pas trouvé extraordinaire et puis on s'est lancé.

Je vais regarder pour les sorting layers.

Franchement Unity c'est intéressant mais j'aurais préféré un autre contexte pour le découvrir comme me lancer dans un petit jeu basique solo sur mon temps libre. Là avec tous les autres projets à côté, je m'arrache les cheveux et ça rend pas le truc agréable du tout. Enfin bon, faut que j'arrête de pleurer et qu'on essaye d'avancer comme on peut.

Merci pour vos conseils en tout cas. =)

[schouffy]

Je suis en self isolation pendant une semaine, j'ai des trucs a faire mais je peux sûrement trouver un peu de temps par ci par là pour t'aider avec les problèmes que tu rencontres en faisant un peu de remote desktop avec toi si tu veux. Contacte moi en MP si tu veux.

[Sariyah]

Han merci schouffy je t'enverrai un MP.

Globalement je crois qu'on est arrivé à faire le switch de scène. On a le rendu du premier prototype ce soir à 17h qui pour rappel était :

Prototype 1 :
• Contenu : Page d’accueil / Carte simplifiée / Déplacement du joueur sur la carte / Portage sur mobile / Récupération de sa localisation.
• Objectif : Vérifier l'UX du jeu à travers les premières interactions basiques d’un joueur : utiliser la page d’accueil et placer correctement les commandes de déplacements. Se confronter dès le début aux parties les plus importantes du MVP.

Les objectifs sont globalement remplis, on fait un rendu en vidéo. Pour ma scène les soucis de profondeur sont réglés seulement à l'entrée du bâtiment donc ça donne l'illusion en y faisant quelques pas puis demi-tour pour montrer que le switch marche aussi quand on ressort.

Le prototype 2 m'inquiète surtout que c'est pour dans 1 mois.

Prototype 2 :
• Contenu : Prototype 1 / Gestion des interactions (Quêtes, combats, informations patrimoine).
• Objectif : Rendre le jeu interactif

Je ne sais pas encore quelle partie je vais récupérer.. Il y en a une qui serait plus simple qu'une autre ?
C'est un peu la merde dans notre groupe pour ne rien arranger.

[schouffy]

Ah, la vie étudiante

Avec ce niveau de détails difficile de savoir quelle serait la partie la plus complexe. Sans doute le combat mais sans une idée des systèmes que vous avez en tête, on peut pas te conseiller.

[Sariyah]

Détrompe toi je ne suis plus étudiant depuis 11 ans maintenant, je me fais vieux et j'ai eu envie de reprendre une année d'étude dans le cadre de ma reconversion.
Enfin il n'empêche que je ne suis pas très clair !

La scène d'un combat :
On rentre dans un bâtiment, ça switch de scène, on combat seul contre 1 mob unique, au tour par tour. (de côté comme dans des tas de rpg) Quelques chose de minimaliste avec un système de combat le plus simple possible à mettre en place.

La quête : Là aussi je pense qu'on va partir sur quelque chose de simple, aller parler à un pnj, ramasser X objets sur la map, le ramener etc. Ce n'est pas clairement définit.

Les infos sur le patrimoine : Il faudrait les inclure dans la quête peut être ou peut être en bulle d'info quand on est devant un bâtiment avec un genre de "panneau" qu'on vient lire. Idem c'est à définir.

On va devoir en discuter.

[Grosnours]

Votre idée de "simple" est à des années lumières de la mienne....
C'est obligé le moteur de combat ? Vous ne pouvez pas vous en tirer avec des dialogues plutôt ?
Vous êtes désorganisés, à la bourre, utilisant des technos que vous connaissez mal. Je sais pas pour vous, mais perso ce n'est pas le moment où je commence à promettre la lune. Je viserai plutôt le minimum vital qui répond aux specs donnés par les formateurs/enseignants.

[Sariyah]

Rien n'est obligatoire mais on a déjà avancé l'idée de combats/d'affrontements et que ça doit faire parti de notre prototype 2. La lune on l'a déjà promis dans un cahier des charges quelque part et c'est bien ce qui m'inquiète.

Je pensais qu'un système de combat de ce type serait facilement trouvable en fait... Quand je dis "simple", c'est dans le sens connu, déjà exploré et mis en place par un grand nombre. Maintenant si c'est extrêmement complexe à intégrer à notre projet alors oui on aura pas le choix que de laisser cette idée de côté c'est clair.

On doit faire un point ces jours.

[schouffy]

Regarde cet excellent tuto pour le système de combat: https://youtu.be/_1pz_ohupPs

[Grosnours]

De manière générale les tutos Unity de Brackeys (qu'il a arrêté je crois) sont excellents.

[Sifr]

Je pensais qu'un système de combat de ce type serait facilement trouvable en fait...

On doit faire un point ces jours.

C’est bizarre cette approche.
Du coup votre Projet, l’idée c’était d’assembler des trucs inspirés ou hérités de l’existant ou faire un vrai codage ?
Parce que si tout le contenu était pensé pour faire de l’assemblage de contenus existants, les frankensteins ça marche jamais.
Ça donne juste l’impression de pouvoir faire et de savoir faire mais sans rien maitriser en fait.

Si rien que le système de combat doit être pompé, alors que cela se résume à de la gestion pure d’addition et de soustraction sur des variables avec un peu d’aléatoire si vous voulez rigoler un coup pour faire des miss à 90%, c’est mal barré.

- - - Mise à jour - - -

De manière générale les tutos Unity de Brackeys (qu'il a arrêté je crois) sont excellents.

Oui il a tourné la page suite à sa dernière vidéo retrospective... c’était bien marrant de voir l’évolution.

[Molina]

C’est bizarre cette approche.
Du coup votre Projet, l’idée c’était d’assembler des trucs inspirés ou hérités de l’existant ou faire un vrai codage ?
Parce que si tout le contenu était pensé pour faire de l’assemblage de contenus existants, les frankensteins ça marche jamais.
Ça donne juste l’impression de pouvoir faire et de savoir faire mais sans rien maitriser en fait.

Si rien que le système de combat doit être pompé, alors que cela se résume à de la gestion pure d’addition et de soustraction sur des variables avec un peu d’aléatoire si vous voulez rigoler un coup pour faire des miss à 90%, c’est mal barré.

- - - Mise à jour - - -



Oui il a tourné la page suite à sa dernière vidéo retrospective... c’était bien marrant de voir l’évolution.

Ca me choque pas de repomper ou de prendre un asset "autre" pour économiser quelques jours de travail. Enfin... même les pros font la même chose (qui parle d'Ubi ? ). Alors oui, après, au final, on ne gagne pas tant de temps que ça parce qu'il faut souvent modifier des petits trucs par ci par là, et comprendre le programme initiale. Mais finalement, l'avantage c'est de pouvoir le faire au fil de l'eau.

[Sifr]

Je parlais pas d’assimiler un concept et le remettre à sa sauce ou prendre un tuto et ensuite l’ajuster à son besoin une fois intégrées les best practices.

Là c’était plus concernant reprendre du bon gros morceau à la sauce librairie qui te donne dix fonctions et ensuite tu te débrouilles pour connecter tout ça...

Pour moi, assembler des trucs déjà faits en espérant que ça réponde au besoin, c’est une voie sans issue. Y’a un demi apprentissage pas sain alors que assimiler le concept et ensuite le dérouler en programmation ça ouvre toutes les portes du possible.
Même dans un proto.

J’ai essayé de prendre des bouts aussi par ci par là mais j’ai vite lâché - jamais optimisé, souvent compliqué pour rien, toujours une contrainte qui limite un autre truc... y’a que le code pur jus qui roule sans accro et qui apporte la compétence.

[schouffy]

Pas du tout d'accord, réinventer la roue c'est le meilleur moyen de perdre son temps.
Savoir réutiliser des briques existantes (qui par ailleurs peuvent aussi t'informer sur comment architecturer correctement ce que tu fais) c'est aussi une compétence de programmeur, et a mon sens bien plus importante que tout savoir coder tout seul.
Et puis dans ce cas où est la limite ? Tu utilises déjà des API graphiques, audio, un moteur de jeu,... Et tu apprends à travailler dans la logique de tous ces outils. Pourquoi pas l'étendre aux assets ?

C'est d'ailleurs dans cet esprit que je recommandais rpg maker initialement, qui me parait avec le recul toujours un choix pertinent.

[Sifr]

On réinvente rien, on assimile des concepts et ensuite on refait son code, sauf dans le cas de librairies du monde python et consorts qui assurément n’amènent aucun intérêt à recoder ce que des gens ont mis des années à affiner - c’est un exemple large qu’on peut bien sûr alimenter avec tout ce qui tourne correctement.
Faut pas être extrême...
Là je parle de bouts de codage pseudo basiques qui permettent de comprendre.

Mais dans le contexte de Unity par exemple, jamais pu pour ma part faire un truc sur la base d’assets en dehors du graphisme et de l’audio.
Que ce soit des systèmes de génération de mondes, des systèmes de targeting, des algo de path findings ou autres, c’est toujours la même chose : des failles, des bugs, des problèmes pour répondre au besoin et des fonctions basiques pourtant jamais présentes.

Rien qu’un exemple : le fameux A star d’Aaron. Je pensais que cela valait le coup par rapport à la base présente dans Unity et finalement passé le wow marketing c’est trop bien, quel bazar pour faire ce que Unity fait très bien avec un peu de code complémentaire.
Je me rappelle un asset testé pour gérer du fog of war. Un vrai bazar en terme de performance.
Le RTS engine dans l’asset store est plus un outil de modding d’un jeu publié par ce biais qu’un véritable game engine.

Après quand tu parles de Rpgmaker, ça pose le curseur là où l’outil pose le contexte, et donc la liberté associée et ceci n’est pas antagoniste avec ce que je dis.
Juste que assembler, pour l’idée d’assembler et proposer quelque chose ça n’a pas vraiment de sens sans comprendre ce que cela sous tend.

[Sariyah]

Hello,

Merci pour tutos.

Honnêtement il y a une telle charge de travail sur cette fin de formation que même un frankensteins potable ça irait. On en est à sauver les meubles et je crois pas qu'on puisse atteindre quelque chose d'harmonieux. On commence à discuter de ce qu'on doit impérativement faire pour le proto 2.

On commence à en discuter ce soir et ensuite on va découper les tâches. J'ai mis en garde sur la difficulté du système de combat. J'aimerais l'enlever pour qu'on puisse se concentrer sur la fonction "cool" qui est la géolocalisation.

C'était pas l'approche de départ c'est sur mais là pour ma part on est au stade ou c'est plus cool et agréable du tout donc je me focalise sur la notation uniquement. Il reste encore 4 notes sur ce projet pour un coeff de 6,5 restant et c'est pas rien. Franchement reprendre des études à 36 ans pour me gaufrer à cause d'un choix foireux de projet ça me ferait tellement mal !

Pour RPG Maker c'est trop tard mais pour avoir jeté un oeil oui ça aurait été un meilleur choix même si encore une fois je suis pas sur à 100% que ça aurait été accepté. (et j'ai même pas envie de poser la question vous devinez pourquoi )

[Grosnours]

Mais dans le contexte de Unity par exemple, jamais pu pour ma part faire un truc sur la base d’assets en dehors du graphisme et de l’audio.
Que ce soit des systèmes de génération de mondes, des systèmes de targeting, des algo de path findings ou autres, c’est toujours la même chose : des failles, des bugs, des problèmes pour répondre au besoin et des fonctions basiques pourtant jamais présentes.

Oui, mais surtout non en fait.

J'ai un peu moins de 200 assets dans la besace et plus de 6 ans d'Unity au compteur. Je diviserais ma bibliothèque d'assets en plusieurs grandes catégories :

- les assets graphiques, sonores ou visuels (shaders, SFX, particules, animations, UI, icones, etc) qu'aucun membre de mon équipe ne serait capable (ou aurait le temps dans le cas des shaders) de réaliser. On en a besoin, point.

- les outils de créations de monde : CTS, Gaia, RAM, Sectr, Vegetation Studio, Path Painter, Polaris, etc... Je vois mal comment t'en passer quand tu en as besoin. Ou plutôt comment tu obtiendrais à la pogne un résultat aussi bon aussi vite. Des fois ces outils sont particulièrement lourds/capricieux/pénibles, oui.

- les assets de QOL pour l'éditeur Unity lui-même sans lesquels je ne vis plus : Inspecteur Gadget, Editor Console Pro, Rainbow Folder, Odin, etc...

- les outils standalone. Mesh Baker pour fusionner les meshs, Bakery pour le baking de lightmap dans les prefabs, Embedded Browser pour un Chromium dans Unity, Enviro pour les cycles jour/nuit et saison, SimpleSQL, Rayfire, Amplify Shader etc.. Des outils complexes que jamais je n'aurais eu le temps de développer et qui sont cruciaux pour un aspect particulier de mes jeux.

- les outils d'optimisation : GPU Instancer, Pool Manager, Performance Tools, Amplify Impostors, etc... dont je vais utiliser un aspect ou l'autre en fonction du type de jeu que je développe. C'est faisable à la main, mais bonne chance.

Mes assets mon fait gagner un temps fou et ont démultiplié les possibilités de fonctionnalités qui s'offraient à moi pour mes jeux. Jamais je n'aurais pu faire sans. Oui effectivement, il est tout à fait possible de gérer à la main ou de développer soi-même la plupart des possibilités offertes par certains assets, mais d'un il faut être une sacré bête en code et deux, qui a le temps ?

Pas moi. Bien entendu la vie n'est pas un long fleuve tranquille et la gestion des assets c'est surtout savoir quand les utiliser ou non, comment ils fonctionnent ensemble et essayer de réduire leur nombre autant que possible. Et surtout connaître leur limite et ce qu'ils savent faire ou pas. Un asset n'est pas un objet miracle (enfin rarement, certains le sont comme Bakery) et les utiliser induit des contraintes. Mais les contraintes sont bien inférieures aux gains.
S'il y a une chose que j'ai appris avec le temps c'est que chaque aspect d'un jeu peut se transformer en rabbit hole que tu va passer des heures indues à explorer. Les assets te permettent de réduire la dimension de ces terriers à quelque chose de bien plus petit et raisonnable.

EDIT : soyons clair, des mauvais assets, cela existe il y en a plein dans le store. J'en ai quelques uns dans ma bibliothèque. Mais avec l'expérience on peut en éviter la plupart.


Pour le cas de Sariyah, vu les circonstances très spéciales (zéro support enseignant, zéro connaissance préalables, zéro tutos, équipe en bois, délais courts) j'ai tendance à être d'accord avec schouffy, un outil bien plus limité et moins performant mais plus simple aurait été un meilleur choix. Ou alors rester sur Unity mais avoir un putain de reality check pour ramener leurs ambitions à des dimensions plus raisonnables.

[Sariyah]

Pour le cas de Sariyah, vu les circonstances très spéciales (zéro support enseignant, zéro connaissance préalables, zéro tutos, équipe en bois, délais courts) j'ai tendance à être d'accord avec schouffy, un outil bien plus limité et moins performant mais plus simple aurait été un meilleur choix. Ou alors rester sur Unity mais avoir un putain de reality check pour ramener leurs ambitions à des dimensions plus raisonnables.

Le reality check est en cours je voudrais vraiment virer ce système de combat et tout revoir à la baisse. Je suis un peu le seul dans le groupe à voir les choses ainsi. J'ai l'impression que personne ne se rend compte que ça va pas donner un truc bien terrible et qu'on n'a ni les compétences, ni le temps pour les acquérir.

Mon avis c'est que si on arrive à créer au moins 2 quêtes simples impliquant la géolocalisation ce sera déjà bien. Le reste j'ai proposé d'afficher les informations liées au patrimoine avec un panneau devant chaque bâtiment significatif qui déclencherait un genre de "pop up" avec une zone d'affichage de texte plus importante qu'un pnj qui parle dans une bulle. Ça permettrait de cocher la case "renseigner les plus jeunes sur le patrimoine de la ville".

[Grosnours]

Ce serait déjà pas mal.
Parce que je n'ai toujours pas compris la pertinence de jumeler la géoloc et le système de combat ensemble, pour moi cela ressemble plus à du "mettons tout ce qu'on peut dans le jeu, secouons et voyons ce qui ressort" ce qui est une méthode pour le moins douteuse de design.

[Sariyah]

Ce serait déjà pas mal.
Parce que je n'ai toujours pas compris la pertinence de jumeler la géoloc et le système de combat ensemble, pour moi cela ressemble plus à du "mettons tout ce qu'on peut dans le jeu, secouons et voyons ce qui ressort" ce qui est une méthode pour le moins douteuse de design.

C'était pour apporter de la variété dans les quêtes au départ mais clairement ça ne doit plus être une préoccupation du tout maintenant.

[Sariyah]

Salut,

Bon on a fait le point, ils veulent une quête avec un combat mais c'est pas moi qui m'en occupe.

Ce que j'ai pris c'est de mettre en place un panneau devant un bâtiment : Le personnage clique dessus, ça ouvre une pop-up avec à l'intérieur un descriptif du bâtiment (info patrimoine/histoire) devant lequel on se trouve.
L'idée c'est que je travaille sur une scène à part, que je mette en place la fonctionnalité et après on va regarder ensemble pour intégrer tout ça devant chaque bâtiment.

[Sifr]

J'aimerais éclaircir un truc qui me pose problème depuis un certain temps.

Sur l'image ci-dessous, un petit sous-marin avec derrière une trainée via un particle system histoire d’agrémenter le visuel de déplacement :



J'ai la surface d'eau avec un shader graph qui représente l'eau en mouvement, c'est un shader transparent.

Et je galère systématiquement à trouver une option pour faire apparaitre la trainée qui est SOUS la surface transparente.
La seule option que je trouve c'est de mettre le matériau en HDRP UNLIT en LOW RESOLUTION.

Si je mets autre chose la surface déformée de l'eau me coupe ma trainée en fonction du fait que cela soit au-dessus (visible) ou au-dessous(masqué).

Même les ordres d'affichage ne semblent pas changer grand chose.

Il a quoi de spécial ce paramètre LOW RESOLUTION pour afficher correctement les effets sous une surface transparente ?

[schouffy]

Je ne m'y connais pas assez pour te répondre, mais je suis étonné que pour un STR tu déformes l'eau. Des normal maps ne suffiraient pas? Peut-être que ton problème serait plus simple à gérer si toute ton eau était de niveau.

[Grosnours]

A vue de nez je dirais que c'est un problème d'ordre (comme d'hab avec les transparences) ou un truc à gérer dans le shader lui-même, mais je ne fais d'HDRP, uniquement de l'URP donc je ne suis pas compétent du tout.
Un thread que tu as sans doute déjà vu à ce sujet : https://forum.unity.com/threads/hdrp...abpass.568585/

[Sifr]

Je ne m'y connais pas assez pour te répondre, mais je suis étonné que pour un STR tu déformes l'eau. Des normal maps ne suffiraient pas? Peut-être que ton problème serait plus simple à gérer si toute ton eau était de niveau.

J'ai gardé le principe du shader de base de Unity + deux trois biblios techniques à droite à gauche pour recréer le shader océan dans shader graph.
Et c'est pas mal car j'ai les variations de hauteur d'eau sur les plages et les falaises + piliers des bâtiments, ça permet d'avoir des bonnes visus si j'accentue le zoom et les vagues sont sympas.

J'ai des normales maps pour les vaguelettes locales.

Sous mes tourelles j'ai un champ de force en particules (pour logique d'avoir des tourelles qui flottent sur l'eau ) qui disparait partiellement en fonction de l'inclinaison de la surface de l'eau, du coup, mis aussi avec LOW_RESOLUTION mais c'est moins joli. Je chipote.

- - - Mise à jour - - -

A vue de nez je dirais que c'est un problème d'ordre (comme d'hab avec les transparences) ou un truc à gérer dans le shader lui-même, mais je ne fais d'HDRP, uniquement de l'URP donc je ne suis pas compétent du tout.
Un thread que tu as sans doute déjà vu à ce sujet : https://forum.unity.com/threads/hdrp...abpass.568585/

Oui, y'a plusieurs personnes qui leur demandent de traiter la question de la transparence dans l'HDRP.
C'est pas très clair.

J'assume toujours d'être parti sur de l'HDRP pour le fun et les effets de lumière. Avec les difficultés inhérentes

Bon tant que l'option permet de faire ce que je veux je vais pas chercher plus loin - ça pétera un jour dans une update et faudra trouver un autre truc

[Sifr]

J'ai recyclé un vieux bout de code théorique trouvé sur le net pour les splatmap pour faire de l'auto texturing parce que je suis fainéant à faire des maps

Un coup de bruit simplex sous Gimp et j'obtiens ma heightmap et je pousse ça dans Unity sur le terrain + exécution du script et ça me donne ceci que j'ai fait évolué pour mon besoin :

(Il neige, y'a du brouillage et des nuages qui passent d'où le côté temps écossais du fin fond de la campagne nordique...)



Par contre je me demande pourquoi on a l'impression que ça fait des petits carrés, d'autant plus visible sur la neige.
C'est certainement une question de discrétisation.
Mais quand on texture à la main, c'est tout fin forcément.

Quelqu'un a déjà joué avec cette méthode ? Trouvé une façon plus fine de texturer en automatique ?
Je chipote parce que le rendu est déjà assez sympa mais j'ai bien pousser à l'extrême ce que je mets en place
D'ailleurs j'aimerai aussi pouvoir faire pivoter la texture sur les petits graviers sous la neige mais aucune idée de quelle fonction on doit jouer

[Grosnours]

Si tu veux des bordures bien harmonieuse entre tes textures un lerp pour obtenir l'interpolation de celles-ci fonctionne bien , surtout si tu te base sur la heightmap.
Cela t’éliminera ces carrés qui correspondent aux faces de ton mesh.

[Sifr]

L’idée se serait de remplacer le script par un shader comme celui présenté dans la vidéo ?

J’ai l’impression que le shader ne gère pas les pentes du terrain, qu’il se base que sur le Y, et ça a l’air galère de sortir la pente dans shader graph.

Le script que j’ai permet d’influer sur la texture en fonction du Y et de la pente du terrain ce qui le rend plus réaliste dans les zones avec de fortes variations.