# Jeux vidéo > Jeux vidéo (Discussions générales) > Le coin des développeurs >  Créer son jeu avec Unity3D !

## krys64

A l'occasion de la sortie de Unity en version free, j'ai décidé d'ouvrir le site non officiel de la communauté Unity française.
Unity est un logiciel middleware dans le style de flash vous permettant d'intégrer des modèles 3D et de scripter le tout pour créer des jeux PC, Mac ou Iphone.
Au programme donc, des news, des tutos, des sources, des scripts et le tout exclusivement sur Unity à l'adresse suivante :
Unity3D-France

Venez nombreux apprendre à créer votre propre jeu.  :;):

----------


## Jean Pale

Je ne connaissais pas, pas mal.  ::): 

(Joli Interstellar Marines)

----------


## Erkin_

La version Iphone est toujours payante non ?

----------


## Jean Pale

Hrhr, l'arme de interstellar marines a un meilleur feeling que les armes source.

 ::ninja::

----------


## MetalDestroyer

Hmm, je ne savais pas que Interstellar Marines est devenu un jeu web. Je go le tester.

Commebnt j'adore le concept de jouer en web. Bon, on avait bien Quake Live. Mais là, c'est beau même si on peut rien faire à part shooter des cibles. Mais c'est super fluide.

----------


## Froyok

Mais, l'UDK c'est mieux.  ::ninja:: 
--->[]

En tout cas niveaux features par rapport à la version gratuite, dommage qu'unity est pas mal bridé certains truc, comme les ombres dynamiques, ça enlève toujours un plus.

----------


## botu

J'ai déjà réalisé ça avec la version gratos :

le web player : http://game.irilys.eu/olivier/zone01.html
(fleche pour avance et space pour sauter)
J'en suis au tout debut de cette zone, encore bcp de choses a faire  ::): 
En tout cas, Unity ça rox du poney mort !

----------


## Jean Pale

C'est vraiment balèze, y'a des petits jeux sympas déjà connus ?

Edit : Apparemment oui, le forum officiel est pas mal rempli.

----------


## RUPPY

Incroyable ce truc  ::O:  Phoenix final a l'air bluffant  ::o:

----------


## IrishCarBomb

> J'ai déjà réalisé ça avec la version gratos :
> 
> le web player : http://game.irilys.eu/olivier/zone01.html
> (fleche pour avance et space pour sauter)
> J'en suis au tout debut de cette zone, encore bcp de choses a faire 
> En tout cas, Unity ça rox du poney mort !
> 
> http://game.irilys.eu/olivier/w19.jpg
> http://game.irilys.eu/olivier/w16.jpg
> ...


Pinaise, c'est bluffant !!! ::O:

----------


## thomzon

Installé, regardé les 2 premiers tutos sur ton site, ça a l'air génial. J'ai pas mal bosser avec Flash jadis, et si j'avais le temps et la motivation nécessaire, je me lancerais dedans.
Plus tard peut-être, en attendant je suis les réalisations de près.

----------


## krys64

Hey Botu, t es français ? Je te suivait sur le forum officiel et j'ai mis une news sur ta création sur le site  :;):

----------


## botu

Je suis de Belgique, merci pour  la news  ::):

----------


## Froyok

> J'ai déjà réalisé ça avec la version gratos :
> 
> le web player : http://game.irilys.eu/olivier/zone01.html
> (fleche pour avance et space pour sauter)
> J'en suis au tout debut de cette zone, encore bcp de choses a faire 
> En tout cas, Unity ça rox du poney mort !
> 
> http://game.irilys.eu/olivier/w19.jpg
> http://game.irilys.eu/olivier/w16.jpg
> ...


 ::O:  Whoaw.
Bon bah unity c'est pas mal au final...
Un peu étiré les texture des falaises, ça manque de poly aussi, mais très réussi !

----------


## krys64

Les terrains ou les sols sont très faciles à générer, il y a un outil intégré qui permet d'élever  ou creser les endroits désirés et de peindre directement dessus avec une brosse à la photoshop. Très simple en fait.

----------


## Guybrush_SF

C'est fou ce qu'on peut faire aujourd'hui avec ce type d'outil  ::o: 

et dire que je trouvais déjà génial Klick'n Play il y a 15 ans  ::):

----------


## Black Wolf

Ahhh Klick'n Play... j'ai encore le CD de sa "suite" : Game Factory. Dommage qu'il manquait juste un mode "expert" pour pousser les choses un peu plus loin en écrivant des scripts ou autre, on était vite limité. Faudrait que je teste cet Unity3d mais étant un peu plus "codeur" dans l'âme je m'oriente plus vers l'UDK.

----------


## krys64

Unity 3D est un peu comme flash, tu as une partie designer mais aussi une grosse partie codeur. Unity supporte 3 langages, le javacript, le C# et lo Boo (un python like), et tu peut intégrer des scripts dans les 3 langages sur un même projet si tu le désires car au final l'ensemble est compilé en Mono.

----------


## Lord_Braathen

Tenez je me suis éclaté pendant une heure sur celui là :
http://www.interstellarmarines.com/

Tout d'abord c'est une bonne claque graphique pour ce moteur 3D et deuxio le feeling de l'arme est vraiment superbe.

Pour résumer, c'est une sorte d'entraînement à l'arme automatique sur des cibles mouvantes ou non. Ca utilise la vue FPS, mais on est immobile.
Le décor se transforme en fonction des situations. 

Vraiment une bonne pioche!

----------


## krys64

Oui, le jeu se décline en chapitres qui sont développés avec la communauté

----------


## Tamppus

Hey mais c'est génial, moi qui cherchais autre chose que rpg maker et autre, pour faire un petit jeu.

----------


## krys64

L'avantage est que tu génère ton jeu en exe sans install. Très pratique  ::):

----------


## botu

J'ai mis a jour ma petite zone, pour ceux que ça intéresse, ça se passe ici :

http://game.irilys.eu/olivier/zone01.html

----------


## Raphi Le Sobre

Putain, t'assure niveau conception graphique.

----------


## botu

> Putain, t'assure niveau conception graphique.


Merci  ::P: 
La semaine prochaine, entre le temple  (qui est en fait l'entrée de la ville) et le jardin suspendu, il y aura un escalier de transition pour ne plus voir l'apparition des zones.

----------


## hommedumatch

> Merci 
> La semaine prochaine, entre le temple  (qui est en fait l'entrée de la ville) et le jardin suspendu, il y aura un escalier de transition pour ne plus voir l'apparition des zones.


Le clipping n'est pas grotesque ça va... Je n'ai pas pu résister à l'envie d'escalade. Constatation : On ne traverse pas le décor, c'est un bon point.


ça a l'air plaisant comme logiciel...
Si je comprends bien, en achetant la license, on peut commercialiser notre création.. Hmmm ...Faut que j'en parle à mon frerot... Interessant.

----------


## krys64

> ça a l'air plaisant comme logiciel...
> Si je comprends bien, en achetant la license, on peut commercialiser notre création.. Hmmm ...Faut que j'en parle à mon frerot... Interessant.


Unity est GRATUIT dans sa version normale avec autorisation de vendre ses créations, Unity Pro est payant mais permet des fonctions supplémentaires comme les ombres dynamiques, le stream audio et vidéo et quelques broutilles. Les screens du dessus sont sous Unity gratuit.  :;):

----------


## MeKa

Impressionnant, c'est hyper sympa ces créations!

----------


## botu

Mon monde avance petit a petit, voici ou j'en suis :



le lien de la demo online (26megas) : http://game.irilys.eu/olivier/zone01.html

Puis 2 chtites images aussi:

----------


## Cyrop

Ah my gaud, botu, tu devrais être engagé par bethesda pour faire le prochain elder scrolls  :Bave: 

Pour la peine j'l'ai aussi téléchargé, j'vais voir le bouzin!

----------


## Sylvine

C'est pas mal du tout!

Tu compte en faire un vrai jeu où c'est juste comme ça?

----------


## botu

non, c'est juste comme ça, ma connaissance de la programmation étant proche du néant absolu  ::):

----------


## Jean Pale

En effet, c'est très sympa.  ::):

----------


## botu

Un ptit up pour vous montrer l'avancement de mon projet:

Une nouvelle zone dans le monde que je viens de terminer : 
http://www.youtube.com/watch?v=lP_y6F_Hvy4

Puis un test de nuages:
http://www.youtube.com/watch?v=O3YKvEZhIJA

----------


## alegria unknown

> Puis un test de nuages:
> http://www.youtube.com/watch?v=O3YKvEZhIJA


 ::o: 

Impressionant !

----------


## botu

Nouveau web player et exécutables disponibles !

Le nouveau  web player est ici: http://game.irilys.eu/olivier/zone01.html
(30  megas, en peu lent, faut être patient)

L'exécutable  pour  windows ici :

http://game.irilys.eu/olivier/FW_PC.rar

L'exécutable  pour Mac ici:

http://game.irilys.eu/olivier/FW_MAC.rar



Voilà,  j'attends vos retours, explorez et dites moi les endroits que vous  préférez (un petit screenshot serait cool  ::):  )

----------


## alegria unknown

::o:

----------


## JulLeBarge

Excellent, je teste ça ce soir !

----------


## AgentDerf

J'ai testé ce soir, très très bien fait!

Je suppose que c'est évident mais cela me fait bcp penser au Seigneur des anneaux.

J'ai pas eu le temps de faire le screen de l'endroit que je voulais car au moment de me poser mon perso à glissé au fond d'un gouffre j'arrivé plus a remonter.
Et comme il y a pas de touche pour courir j'avais la flemme de tout re-parcourir...

Déjà j'avais essaye de monter sur les deux grandes tour en haut de la montagne, mais le mur de la tour n'est pas escaladable.
Du coup je suis allez dans le petit village elf, j'ai exploré un peu les souterrain très sympa.

Je suis ensuite monter près du pont qui va jusqu'a la cascade, j'aller me positionner en 3/4 pour prendre un screen avec le pont, la cascade et les grandes tour au loin, quand trop prés du bord j'ai glissé au fond du gouffre....

EDIT : Bon allez 2ieme exploration! Car bon tu le mérites! 

J'adore la grande porte dans la prairie, la prairie est super belle, et avec la grande porte c'est super classe :



Ensuite je monte au dessus village elf, je fait attention au "pierre molle" ou on peut pas marcher cette fois :



Autre vue :



Après un long effort pour monter, ca fait plaisir les arbres enneigé à l'arrivé.
On le resent pas sur le screen mais on a le vide dans le dos ca donne une impression sympa :



Enfin petit screen sur la vue du haut des tours, la on vois un peu les limites du moteur, la texture des nuages qui continue pas, et le tout un peu trop blanc. Mais bon c'est quand même super sympa comme petit moteur gratuit!



Bon sinon le temple du début j'accroche pas, pas assez grandiloquant ou bucolique. 

Mais tout ce qui ruine dans la prairie, petit mont enneigé et autre monument démesuré ca le fait!  :;):  Continue c'est au top!

PS : Petite remarque sur le moteur de visionnage, je suis comme 50% des joueurs je joue en souris inversé, dommage qu'on puisse pas changer ce détail dans les contrôles.

----------


## Euklif

Petite question : c'est plutôt facile à appréhender pour un noob total en programmation ou faut se mettre ardemment à consulter une doc quelconque pour arriver à quelque chose? Et si c'est le cas, vous conseilleriez quel langage pour aborder ce moteur dans un premier temps? J'ai une idée en tête et j'ai vraiment envie de la mettre à exécution.

----------


## Froyok

> Enfin petit screen sur la vue du haut des tours, *la on vois un peu les limites du moteur*, la texture des nuages qui continue pas, et le tout un peu trop blanc. Mais bon c'est quand même super sympa comme petit moteur gratuit!


Heu, rien à voir non ?
C'est juste le sky qui descend pas assez bas non ?

----------


## botu

Merci d'avoir pris le temps de visiter ! En effets, certains rochers ne generent pas de collisions pour gagner en peu en temps de calcul (normalement ce sont des zones  inaccessibles) Si tu tombes, en spammant la barre d'espace tu sais sauter et monter les pentes. Le skybox qui entoure le monde n'est pas definitif, le plus chaud va etre d'en realiser un qui tienne compte de la position du soleil. Je dois aussi prolonger la distance de vue en y incluant des montagnes.
La zone du temple dans la foret n'est pas entierement finalisee, je dois retravailler la vegetation et ajouter une porte au batiment. J'avais envie de rajouter un tapis de fleur dans le petit ravin qui entoure celui-ci.

Je compte aussi entierement refaire la zone autour du pont avec la cascade. Plutot realiser des terrasses avec des plantations + des petites maisons, plutot que les batiment suspendus qui je n'aime plus trop en fait (en peu trop froid pour mon gout)

@Euklif : je ne programme pas non plus sur unity, je ne fais que utiliser le moteur graphique. Pour les bouts de code je demande a gauche et a droite. Mais il me semble qu'en java c'est peu etre en peu plus facile pour commencer.

Sinon, voici une nouvelle video: Les Grazers, une sorte de grosse vache locale, melange entre un singe, un ver de terre et en peu d'araignee  ::): 

Le script d'AI est presque termine, et l'anim est a cleaner (ya pas a dire, l'animation.. c'est un metier ! )

----------


## Hereticus

Sympa , je ne connaissais pas Unity 3D ! Je vais suivre cela de plus près.

En tout cas botu tu es doué en level-design et je sais de quoi je parle j'ai suiis des cours de jeux vidéos à l'heaj de namur  ::): .

Continue comme ça !

----------


## botu

> Sympa , je ne connaissais pas Unity 3D ! Je vais suivre cela de plus près.
> 
> En tout cas botu tu es doué en level-design et je sais de quoi je parle j'ai suiis des cours de jeux vidéos à l'heaj de namur .
> 
> Continue comme ça !


Merci  ::): 

Bon j'ai continue a travailler la zone du sanctum pour rendre la zone en peu plus agreable et donner une ambiance plus feutree, voici une image:

----------


## NeoOoeN

Vraiment magnifique.

A quand la version jouable/explorable avec toutes tes nouveautés ?

----------


## - Silence -

Franchement impressionnant, botu.
Je m'éclate bien sur ta démo, les graphismes sont superbes.
Ca doit être un travail considérables !
Encore bravo.

Vous savez s'il y a des projets de ce genre avec un univers plus... western contemporain et post-apo ?

edit : Celui-ci m'a pas mal plu, aussi, il dégage une très bonne ambiance et les graphismes sont encore époustouflants.

----------


## Flibustier

http://www.interstellarmarines.com/game/bullseye/

hop un petit jeu fait avec. Installez le UnityWebPlayer .

Unity c'est très sympa, ce n'est pas le truc ultime mais l'environnement est presque complet. Super pour prototyper.
Manque plus que leur dérivé de raknet soit opérant et plus complet et qu'ils permettent du code externe en Cpp pour que ça soit parfait.
Par contre, à cause d'Apple qui veut imposer son framework uniquement, Unity risque de ne plus gérer l'iphone.

----------


## NeoOoeN

Botu, des nouvelles !

----------


## madininawolf

Je voudrais poser la question suivante
Pour un débutant qui ne connait rien du tout en programmation 3d qui souhaite apprendre en autodidacte vous recommandez unity ou udk ?

----------


## Valenco

> Je voudrais poser la question suivante
> Pour un débutant qui ne connait rien du tout en programmation 3d qui souhaite apprendre en autodidacte vous recommandez unity ou udk ?


Je n'ai pas testé les deux (uniquement Unity), mais je me suis pas mal renseigné. Unity semble plus simple. Beaucoup de manipulations peuvent se faire par des glissés déplacés et la plupart des actions basiques ne nécessitent pas de code. Cela dit, n'espère pas te lancer sans prendre un peu de temps pour lire la doc (très bien faite mais en anglais) et suivre quelques tutos. Tu dois aussi maîtriser un minimum l'utilisation de softs 3D pour créer tes modèles, leurs textures et éventuellement les animer.

----------


## Jasoncarthes

Tiens d'ailleurs, unity support le java script le c# et le boo et comme je ne connais aucun autre que sexp je suis marron, donc avant de me mettre a unity faut que je m'attaque à l'un des trois, donc question de noob, lequels est le plus abordable des 3?

(ou le mieux documenté )

----------


## Froyok

Le boo je connais pas, mais les deux autres tu trouveras facilement des cours dessus.

----------


## Mysterius

A partir du C, tu peux faire n'importe quoi et, surtout, aborder beaucoup d'autres langages très rapidement.

----------


## war-p

Tu ne dirais pas ça si tu avais déjà fait du caml... LE langage qui a traumatisé des millions d'élèves...

----------


## Mysterius

Ah bah... j'ai dit beaucoup, pas tous  ::P:

----------


## MorK

> Merci 
> 
> Bon j'ai continue a travailler la zone du sanctum pour rendre la zone en peu plus agreable et donner une ambiance plus feutree, voici une image:
> 
> http://game.irilys.eu/olivier/w77.jpg


Très sympa ton travail.

Par contre, si je peux me permetre une critique, tu as un problème d'échelle, à moins que ça ne soit volontaire d'avoir fait des batiments pour géants. Ca a son charme mais ça fait un peu bizarre par moment.


Tu m'as donné envie de me mettre à Unity. Par contre, les tutos du site officiel ont été mis par un idiot (ou alors je n'ai pas le bon lecteur): la lecture se fait avec quick-time, pas de streaming (super pratique quand on est en 512), impossible d'enregistrer la vidéo sur son PC pour la regarder sans navigateur et surtout, sans devoir la recharger à chaque fois qu'on le ferme, le player est mal cadré et on ne peut pas zoomer sur la vidéo ou la mettre en plein écran.

Donc si tu as trouvé une bonne source de tutos fais moi signe  :;): 

---------- Post ajouté à 12h48 ----------




> Tu ne dirais pas ça si tu avais déjà fait du caml... LE langage qui a traumatisé des millions d'élèves...


Je ne connais pas le caml, mais j'ai fait du Motorola quand j'étais en élec. Que de bons souvenirs  ::sad::

----------


## Janer

J'ai téléchargé le moteur de jeu, par contre j'aimerais savoir par où commencer! J'ai fait des recherches et c'est pas très clair pour moi. Y'a pas un moyen d'apprendre pas à pas comment faire?

----------


## Alexis

Intéressé par de bons conseils aussi, j'ai bien envie de tester.

----------


## JulLeBarge

Ce topic aurait bien sa place dans la nouvelle section le coin des  développeurs, non ?

----------


## Janer

http://answers.unity3d.com/questions...t-of-tutorials

Comme personne ne veut nous aider, je nous aide moi même. Voilà comment procéder pour apprendre à utiliser Unity, enfin pour se lancer dans autre chose que de la déco.

----------


## botu

Quelques liens pour debuter:

Tuto video (une partie est gratos)  http://www.vtc.com/modules/products/...e=VTC-WhizzKit

Guide newbie pour javascript dans unity: http://forum.unity3d.com/threads/340...highlight=loop

tuto scripting : http://download.unity3d.com/support/...20Tutorial.pdf

Sinon le manuel et le forum aussi,

----------


## krys64

y a ce site : http://www.unity3d-france.com/unity/
et ces tutos : http://www.unity3d-france.com/trainingPack1/player.html
et en français  ::):

----------


## Dorak

Failed to download blabla.

Dommage.

----------


## Black Wolf

Je fais remonter ce post pour signaler qu'Unity offre ses licences basiques iPhone et Android jusqu'à début avril (valeur 400$ par licence en temps normal sauf erreur). Il suffit de passer par cette page https://store.unity3d.com/index.html et choisir les versions désirées.

----------


## MorK

> Je fais remonter ce post pour signaler qu'Unity offre ses licences basiques iPhone et Android jusqu'à début avril (valeur 400$ par licence en temps normal sauf erreur). Il suffit de passer par cette page https://store.unity3d.com/index.html et choisir les versions désirées.


Merci beaucoup pour l'info Black Wolf. Je viens d'activer les licences en question, ça m'a pris quelques minutes.

Je redoutait juste de devoir utiliser un moyen de paiment pour ma facture de $0 mais il n'y a eu aucun problèmes. Je conseille à tous d'en profiter.  :;):

----------


## botu

ha ben j'en profite du déterrage de topic pour vous montrer un nouveau monde sur lequel je passe mon temps. Son nom est "After" et sera un mélange entre monde futuriste a l'abandon dans lequel une population très jeune et sans connaissance technologique tente de survivre. J'en suis au début mais je m'amuse bien  ::): 
J'en suis a la zone du pont.

ps: le pont mènera a une grande muraille derrière laquelle se trouvera la ville.















La carte de la zone:

----------


## MorK

J'ai beau être à l'aise avec Unity, je suis toujours impressionné par la qualité de ton travail.  ::):

----------


## Froyok

Ouais, c'est très impressionnant, bravo !  ::o:

----------


## beuargh

Toujours aussi impressionnant, Botu  ::O:

----------


## Black Wolf

Superbe ! T'as peut être déjà répondu à la question sur un autre topic mais quels outils utilises-tu à part Unity (tu as unity pro ? Des plugins ?) ?

----------


## botu

oui, unity pro, puis maya, photoshop,mud box, world machine et crazy bump a mon taf pendant le temps de midi.
J'utilise l'advanced terrain shader 2.0 trouvable sur unity store et easyroad pour recuperer les splatmaps qui sortent de world machine.

----------


## znokiss

C'est vraiment prometteur... As-tu un site, un blog ou un topic ici sur le fofo ? J'aimerais en savoir plus, parce que là je bave déjà devant de simples screens...

----------


## Darkath

T'as bien progressé depuis le casse brique bizarre :D

----------


## botu

J'ai un post sur le forum officiel et une chaine youtube sur laquelle j'upload régulièrement des vidéos.

----------


## JulLeBarge

C'est superbe !

----------


## Okxyd

Ça claque, l'idée de l'autoroute suspendue est vraiment cool.

----------


## znokiss

Oh route, suspend ton vol...

----------


## beuargh

Tu vas aussi le vendre, ce terrain ?  ::): 

C'est quoi ta chaîne youtube ?

----------


## botu

Non, c'est pour mon plaisir.

Voici le lien pour le channel youtube  http://www.youtube.com/user/botumys?feature=mhee

----------


## botu

Bonjour, voici une nouvelle video de ma nouvelle zone, ca avance lentement mais surement. J'avais envie de presenter quelques endroits en
utilisant une camera statique et juste voir l'effet du vent.
J'ai encore bcp de boulot!
(1080p sur youtube)

----------


## Black Wolf

Magnifique, vraiment ! Ca me fait doucement rigoler en pensant à tous ceux qui pleurent sur les forums et facebook d'unity pour avoir Unity4 et son renderer dx11 parce que "ouiiiiiin on peut pas faire des jeux de bonne qualité graphique avec Unity3, "mon supayr jeu il seura tro bo avék déix onze, sil é pa bo cé pask cé déix 9 seulmen".

C'est dommage Unity est franchement capable de faire des trucs superbes, tu viens encore de le prouver, mais il est tellement accessible que 99% de ce qu'on voit c'est des trucs moches bricolés à l'arrache, ça leur fait presque plus une mauvaise pub qu'autre chose.

----------


## beuargh

Franchement magnifique, Botu, comme d'hab !

Bon, c'est quand qu'une boîte t'engage en fixe ?  :;):

----------


## botu

Merci  ::): 
Pour la boite, je ne sais pas, mais il y a un début a tout, j'ai ete chargé de créer le jeu issu du film sur lequel on bosse
actuellement :D (bon ca sera des minis-jeux, mais c'est deja super)

----------


## deathdigger

Je suis en train de tester cette petite chose, et c'est vraiment pas mal, super simple à mettre en place.
Le seul souci je trouve, c'est que 99% des tutos sont sur Java et que je bosse en C#, mais bon, l'adaptation est pas très compliquée  ::):

----------


## botu

n'hésites pas a nous montrer tes créations !

----------


## deathdigger

J'en suis encore au stade où je teste le côté "physique" du truc ^^

----------


## botu

J'avais déjà présenté mon p'tit jeu "Xzyu". Mais je ne pense pas avoir distribué la dernière version pour windows. Voici donc le lien pour télécharger le jeu : 
http://game.irilys.eu/unity3d/xzyu.rar
(26 megas, passé par antivirus)

Pour rappel, Xzyu est un mix entre  golf, de billard et jeu de réflexion. Il y a 18 niveaux. (faut s'accrocher pour les terminer)

voici qq screenshots:

 



Et une video toute fraîche:

----------


## Froyok

J'ai vu la vidéo passer dans mon flux twitter hier, très sympa !  :;):

----------


## botu

merci  ::):

----------


## SeanRon

excellent  ::):

----------


## edenwars

Excellent


Vais me pencher sur unity un peu.


Mais je continue sur le cryengine quand même.


En ce qui concerne le son, tu l'a choper ou la banque audio?


Merci

----------


## botu

pour les sons je vais la :
www.freesound.org/ 
www.findsounds.com/

La musique, elle vient d'un collegue musicien.

----------


## edenwars

Merci 


Vais voir ça

----------


## Adu

j ai passé deux nuit dessus avec un eBook pour apprendre un peu Unity, ça reste quand même pas non plus à la portée de n'importe qui de faire un truc potable, voir réussir à faire un truc tout court  :tired: 

Mais bon, je persiste, je veux apprendre, je continue à écumer forums et autres chaines youtube de tutoriaux, et un jour peut-être j'arriverai à faire un truc qui ressemble à quelque chose  :^_^:

----------


## JulLeBarge

> j ai passé deux nuit dessus avec un eBook pour apprendre un peu Unity, ça reste quand même pas non plus à la portée de n'importe qui de faire un truc potable, voir réussir à faire un truc tout court 
> 
> Mais bon, je persiste, je veux apprendre, je continue à écumer forums et autres chaines youtube de tutoriaux, et un jour peut-être j'arriverai à faire un truc qui ressemble à quelque chose


Je suis arrivé au même constat que toi: faire un petit fps bien moche, ça va encore, mais dès qu'on veut innover, c'est quand même assez compliqué.
Et puis autre élément important: faut savoir modéliser et animer un minimum pour faire de la 3D... et là c'est une autre histoire !

----------


## Janer

LA 3D. The truc qui m'a empêché d'aboutir à un truc correct dans les temps et m'a obligé à mettre en pause mon projet pendant la rentrée...

----------


## botu

re!

Pour aider un gars qui développe son jeu, je lui ai proposé de réaliser la première zone.

J'ai lancé un sujet sur le forum officiel avec un wip régulier. Il y a aussi des infos sur certains programmes ou paramètres.

Si ça vous intéresse c'est ici : 
http://forum.unity3d.com/threads/154...rk-in-progress

Voici la première image, c'est le tout tout tout début, en gros c'est juste la heigtmap brute de décoffrage importée dans unity.

Pour la voir en full rez:  http://forum.unity3d.com/attachment....1&d=1350473752

----------


## botu

Salut, voici 2 nouvelles images pour mon nouveau terrain.
Je suis en train de placer les rochers et je tente d'unifier le tout.

----------


## Froyok

Ça poutre !  ::o: 
Beau boulot !

----------


## war-p

Ouah, les arbres, les plantes, les rochers... Tout est génial!

----------


## JulLeBarge

ça me fait penser à Skyrim, joli travail !

----------


## botu

merci, je dois juste preciser que cette fois-ci j'utilise des assets achetes sur l'asset store de unity, j'avais vraiment envie de me focaliser sur la mise en place des elements plutot que sur le modeling (a part pour le terrain)

----------


## botu

Salut !
Voici la video de mon dernier monde : scardeep.

----------


## airman4

interessant !!

La prog sur unity est t'elle compliquée ?

Combien de temps met tu pour faire ce genre de monde ?

quel genre de jeu peut tu faire au final ?

----------


## Black Wolf

Superbe boulot !  ::): 

Airman en ce qui concerne Unity : La programmation n'est pas compliquée, tu as le choix de coder tes scripts en javascript, C# avec .Net 2.0 (Mono), ou Boo (une sorte de Python maison si je me souviens bien). De nombreuses fonctions et classes aident souvent à faire ce que tu veux faire, il faut juste s'habituer à aller fouiller un peu dans l'aide en ligne et l'API avant de réinventer la roue. De plus si il manque une fonctionnalité ou que tu ne veux pas tout coder toi même, il y a la possibilité d'acheter de nombreux outils ou scripts pré-conçus sur l'Asset Store d'Unity3D.

Pour les scènes de Botu je le laisse te répondre mais j'imagine qu'il s'agit d'un sacré boulot. Si il a pu économiser du temps en achetant les modèles sur l'asset store, il reste la création du terrain qui peut prendre beaucoup de temps sans compter le placement des objets. Si je me souviens bien il ne passe par par Unity pour la création du terrain (même si il est possible de le faire, mais l'éditeur n'est pas forcement top).

Pour les genres de jeux tu peux à peu de choses près tout faire. Il n'y a rien de prévu "out of the box" par contre pour faire des jeux purement 2D avec sprites animés ou ce genre de choses, mais à nouveau tu trouve des packages gratuits ou payants pour le faire, ou sinon tu peux facilement bricoler par toi même.

----------


## airman4

Merci des precisions Black wolf

La ps4 s'alliant avec unity , j'espère qu'il y aura d'autre framework qui vont le faire

Je vais redonner une seconde chance a unity , même si je suis un dessineux surtout , je veux mettre mes doigts dedans un peu , voire ce que ca donne.

Pour les jeux 2d pures,ouais je sais je vais chercher comment le faire ,mais la 3d m'interesse vraiment

le taff de Botu est dingue , ca donne vraiment envie

----------


## Ariath

> Salut !
> Voici la video de mon dernier monde : scardeep.


Salut, je suppose que tout est fluide ? *Est ce que tu pourrais en dire plus sur l'optimisation ?*
Tu utilises les LOD / le Streaming / les différentes méthodes de culling ?

En tout cas jolie boulot ! Vraiment chapeau pour tout le travail déjà accompli !

----------


## beuargh

Botu, c'est à chaque fois des claques !

Superbe... ::mellow::

----------


## botu

Merci a tous!
@airman4 : J'utilise mudbox et worldmachine pour generer la heightmap que j'utilise ensuite dans unity. Apres, tout le travail
est realise dans unity, jusqu'a placer une a une les plantes pour ne pas exploser les fps.

@ Ariath : je tourne a +- 40 f/s sur ma 580. 
J'utilise entre 2 et 3 niveaux de LOD selon la taille de l'obj. Pour l'occulsion, j'ai calcule une passe dans umbra. Il n'y a pas de streaming, tout est chargé en une fois. 
J'ai tenté beast pour les lightmaps, mais j'ai un soucis avec les arbres et les normals maps qui ne sont pas correctement gerées a distance. Du coup, j'explose en peu mes drawcalls et diminue mes fps a cause des ombres en realtime qui sont calculees jusqu'a 300 unitees (au lieu des 50 qu'il faudrait).

----------


## Adu

AFK me pendre devant une telle réalisation par rapport à mes oeuv..... choses

----------


## Djal

Bravo pour ce que tu fais Botu tu as un sacré talent..

Pour ceux qui veulent un bon tuto, je trouve que celui-çi n'est pas mal:

http://www.burgzergarcade.com/hack-s...ngine-tutorial

Contrairement aux autres tutos Unity il ne fonce pas tête baissée dans les graphismes, et traite de l’implémentation des mécanismes de jeu d'un H&S. A l'heure où j'écris ces lignes il y a plus de 260 vidéos.

Ah, et les scripts sont en C#

----------


## botu

Salut a tous, je viens a vous pour vous demander comment tourne la démo de mon monde (scardeep)
C'est juste une visite a pied de la zone, mais j'ai quand même ajouté quelques petits bruitages (à jouer la nuit en 5.1  ::):  )

au niveau des trucs a corriger : 
-les bruits de pas (variation + les supprimer lors d'un saut)
-mouvement de tête
-checkpoints
-peut-être pouvoir courir, mais bon, ce n'est pas un jeu alors je ne sais pas  :;): 
-Optimiser 

Vous pouvez configurer les touches ds le launcher.
Escape pour quitter, et la touche r pour respawn si vous etes bloqué.

ps: il faut quand même une bonne machine pour que ça soit fluide.

voici 2 liens où vous pouvez trouver la démo. (316 megas quand même)

http://sdrv.ms/1bZEWSR
ou
http://game.irilys.eu/unity3d/scardeepDemo.zip

merci d'avance

----------


## Djal

> Salut a tous, je viens a vous pour vous demander comment tourne la démo de mon monde (scardeep)
> C'est juste une visite a pied de la zone, mais j'ai quand même ajouté quelques petits bruitages (à jouer la nuit en 5.1  )
> 
> au niveau des trucs a corriger : 
> -les bruits de pas (variation + les supprimer lors d'un saut)
> -mouvement de tête
> -checkpoints
> -peut-être pouvoir courir, mais bon, ce n'est pas un jeu alors je ne sais pas 
> -Optimiser 
> ...


Ca tourne pas trop mal en full detail sur ma machine 8Go RAM + Radeon 7850 + Pentium e8500 (pas moyen d'afficher un compteur de FPS pour te donner une réponse plus précise?)

Sinon, c'est magnifique. Quand je vois ce que je fais avec Unity j'ai du mal à croire qu'on fait joujou avec le même logiciel... 
Tu les fais toi même les Assets? Tu devrais essayer de l'adapter pour qu'elle fonctionne avec l'Oculus Rift.

----------


## botu

Merci  ::):  
Pour ce projet, les assets proviennent de l'asset store ainsi que le shader du terrain. Je voulais me concentrer sur la composition plutot que passer
des mois a modelider et texturer. Vu que je fais ca durant mon temps libre, c'etait la solution la plus rapide qui s'offrait a moi. Mais j'ai
quand meme passe plus de 50 heures a creer le terrain et placer les assets un a un. 

Sinon l'oculus rift est commandé, une version speciale pour celui-ci sera disponnible aussi (quand le kit arrivera, cad d'ici 3 ou 4 mois )

----------


## Ariath

> Salut a tous, je viens a vous pour vous demander comment tourne la démo de mon monde (scardeep)
> C'est juste une visite a pied de la zone, mais j'ai quand même ajouté quelques petits bruitages (à jouer la nuit en 5.1  )
> 
> au niveau des trucs a corriger : 
> -les bruits de pas (variation + les supprimer lors d'un saut)
> -mouvement de tête
> -checkpoints
> -peut-être pouvoir courir, mais bon, ce n'est pas un jeu alors je ne sais pas 
> -Optimiser 
> ...


*Ultra fluide en 1920/1200 full detail avec :
i5 3500k
8go ram
660gtx ti*

Qu'est ce que j'aurai aimé que skyrim est autant d'inspiration (oui j'ose)...y'a pas photo, malgré les limitations du moteur tu t'en tire vraiment bien, comme quoi le design est tout aussi important que des textures 4092 par 4092...et c'est pas si évident que ca de créer un monde en brisant la linéarité des décors.

Par contre *le défaut d'unity ca serait plutôt l’éclairage non ?* 

A cause de toi et de tes bruitage de corbeaux et autre vol d'oiseau, mon chat est en panique...il cherche dans tout l'appart d'ou vienne les bruits...
Le changement des bruits de pas quand on passe des pierres au bois est sympa aussi. 

Par contre recommencer du début (bah j'y peux rien je me suis trop approché d'une falaise...)c'est un peu casse bonbon (m'enfin c'est pas dramatique non plus...).

----------


## botu

> *Ultra fluide en 1920/1200 full detail avec :
> i5 3500k
> 8go ram
> 660gtx ti*
> 
> Qu'est ce que j'aurai aimé que skyrim est autant d'inspiration (oui j'ose)...y'a pas photo, malgré les limitations du moteur tu t'en tire vraiment bien, comme quoi le design est tout aussi important que des textures 4092 par 4092...et c'est pas si évident que ca de créer un monde en brisant la linéarité des décors.
> 
> Par contre *le défaut d'unity ca serait plutôt l’éclairage non ?* 
> 
> ...



Merci, Skyrim est un de mes jeux prefere en terme de monde sandbox. 
Bien moddé, il reste incomparable pour la taille de la zone proposée. Il m'a bien inspiré je dois dire.

Pour les lumieres, en gros, j'aurais du générer une lightmap pour bénéficier du light bouncing et de l'ambient occlusion, ce qui 
aurait relevé le niveau, mais j'ai ete confronté a un probleme d'integration de la vegetation. 
Du coup j'utilise une simple directionnal + shadow et l'ambient light de base (+ des points light pour les sources de lumieres locales). 

Par contre l'effet sombre est voulu, c'est un fog en Y qui assombrit le fond du ravin. J'ai peut-etre exagéré aussi sur le bloom en peu trop présent.
Si tu as des screens ca m'aiderait a corriger le tir.

Je vais ajouter des checkpoints.

Merci de ton test!

----------


## Ariath

> Merci, Skyrim est un de mes jeux prefere en terme de monde sandbox. 
> Bien moddé, il reste incomparable pour la taille de la zone proposée. Il m'a bien inspiré je dois dire.
> 
> Pour les lumieres, en gros, j'aurais du génerer une lightmap pour beneficier du light bouncing et de l'ambient occlusion, ce qui 
> aurait relevé le niveau, mais j'ai ete confronté a un probleme d'integration de la vegetation. 
> Du coup j'utilise une simple directionnal + shadow et l'ambient light de base (+ des points light pour les sources de lumieres locales). 
> 
> Par contre l'effet sombre est voulu, c'est un fog en Y qui assombrit le fond du ravin. J'ai peut-etre exagéré aussi sur le bloom en peu trop présent.
> Si tu as des screens ca m'aiderait a corriger le tir.
> ...


Pour les lumières je visais pas particulièrement ta démo, c'etait juste une question qui visait à combler mon vide intellectuel en la matière  ::P: 

*D'ailleurs est ce que tu vas faire une démo de nuit ?*

Pour les screens j'ai pris que celle la, parce qu'elle reflète bien le travail accompli :

Mais du coup rien a voir avec la lumière.Mais pour te répondre, le bloom ne m'a pas particulièrement choqué.

J'aime beaucoup skyrim également, mais depuis que je m'interesse à la création de jeux vidéo, je me dis qu'ils auraient pu faire mieux...quand tu regardes bien toutes les villes sont plates, ca manque cruellement de détail...aprés peut être que c'est le prix à payer pour un openworld...mais on verra bien que non quand Enderal ou Andoran sortiront, comme à l'époque d'oblivion qui a été enterré par Nehrim (graphiquement j'entends).

----------


## botu

ha ok  ::):  Mais pour repondre vraiment a ta question : unity peut tres bien gerer la lumiere.
Il y a beast intégré qui permet deja de belles choses. Et sur le store commencent a sortir
des plugs de global illumination en temps reel + hdr. 
Le soft est ouvert au point de pouvoir en faire ce qu'on veut.

Pour skyrim, je pense que si il n'avait ete developpé que pour le pc, sans tenir compte de la
limitation des consoles, il aurait ete encore plus impressionnant. 
Mais tout ca, c'est deja le passé, l'avenir c'est ce que SOE est en train de faire avec Everquest next, du open world en voxel/ marching cubes.
Ce n'est que le debut, mais pour moi, ca va se generaliser de plus en plus.

http://procworld.blogspot.be/
http://nerdkingdom.com/
http://www.youtube.com/user/DubstepCoder/videos

----------


## Poussin Joyeux

Je viens de tester ta démo et c'est super joli, touffu et immense! Je ne pensais pas qu'on pouvait faire ce genre de décors aussi complexes avec Unity :-)

C'était bien fluide chez moi mais j'étais en "good" quality (du coup, certaines ombres étaient en dents de scie). Ma config: Q6600 + Geforce 6600 GT + 4 Go ram.

Au niveau des petites remarques constructives  ::):  : 
- Je trouve que le mouvement de la souris est trop rapide quand on regarde sur le côté mais ça doit se changer facilement (si ça se trouve, c'est même à moi de le changer avec les inputs...).
- C'est dommage de passer à travers les arbres  ::P:  Par exemple, à un moment, il y a un arbre entre deux barrières et je m'approche pour admirer le paysage en bas et hop, je passe à travers l'arbre! Tu n'as pas mis de détection de collision sur les arbres pour gagner en fluidité?

Mis à part ça, c'était un plaisir de se balader dans ton monde!  :;):

----------


## JulLeBarge

Tu as utilisé quoi comme assets ? J'imagine que c'est des trucs payants, non ?

----------


## botu

> Je viens de tester ta démo et c'est super joli, touffu et immense! Je ne pensais pas qu'on pouvait faire ce genre de décors aussi complexes avec Unity :-)
> 
> C'était bien fluide chez moi mais j'étais en "good" quality (du coup, certaines ombres étaient en dents de scie). Ma config: Q6600 + Geforce 6600 GT + 4 Go ram.
> 
> Au niveau des petites remarques constructives  : 
> - Je trouve que le mouvement de la souris est trop rapide quand on regarde sur le côté mais ça doit se changer facilement (si ça se trouve, c'est même à moi de le changer avec les inputs...).
> - C'est dommage de passer à travers les arbres  Par exemple, à un moment, il y a un arbre entre deux barrières et je m'approche pour admirer le paysage en bas et hop, je passe à travers l'arbre! Tu n'as pas mis de détection de collision sur les arbres pour gagner en fluidité?
> 
> Mis à part ça, c'était un plaisir de se balader dans ton monde!


Merci c'est bien cool d'avoir testé!
Le mouvement de la souris est facilement ajustable (mais pourquoi seulement sur le cote?)
Je dois en effet encore ajouter les colliders aux arbres, c'est dans ma TODO list  ::): 





> Tu as utilisé quoi comme assets ? J'imagine que c'est des trucs payants, non ?


Oui, comme je l'avais expliqué plus haut ce sont des assets qui proviennent de l'asset store (big env pack, medieval env, mountain pack, ect..)

----------


## Zevka

Plop les canards qui bossent avec Unity 3D.

Petite question pratique : j'ai un projet fourre-tout que j'utilise pour tester un peu tout et n'importe quoi, voir ce que j'arrive à faire et apprendre, sans pourrir mes projets plus "sérieux". Autant dire que c'est le bordel le plus total là dedans.

Sauf que récemment j'ai ajouté et crée plein de scripts et d'assets qui collerait bien ensembles pour un projet indépendant. Se pose donc la question de comment récupérer tout ça. L'idée étant évidemment de garder les "originaux" dans mon projet test des fois que (et parce qu'il est là pour ça).

Comme solutions j'ai pensé à :

- Faire tout bêtement une copie du dossier et de tout ses fichiers, puis "nettoyer" le tout, virer les assets qui n'ont aucun rapport, reclasser les autres et cie. L'avantage c'est que ça serait opérationnel très vite et pas trop chiant, l'inconvénient est que c'est un peu crade
- Recréer un projet de zéro, bien organisé et tout, et ajouter/recréer au fur et à mesure les assets et script : le plus propre, mais sûrement le plus fastidieux
- Faire un package unity : j'ai jamais fait, et je suis pas sûr que ça ait un sens ou que ça soit pratique, donc dur à dire si ça s'applique à ma solution

Je précise qu'il n'y a pas de soucis de poids, le dossier compressé fait quelques ko, vu que c'est surtout du script, des assets basiques ou des primitives, et 3/4 textures placeholder.

Z'en pensez quoi ?

----------


## MorK

> Se pose donc la question de comment récupérer tout ça. L'idée étant évidemment de garder les "originaux" dans mon projet test des fois que (et parce qu'il est là pour ça).


 Dans l'onglet "project", un clic droit sur un objet ou dossier te donne l'option "export unitypackage" ou un truc du genre. Unity s'occupe de récupérer les éléments dépendant de cet objet.

Exemple, tu veux exporter le prefab d'un objet 3D: unity va prendre le prefab, le modele 3D, son matériaux, ses textures, ses scripts... même s'ils sont éparpillés n'importe où.

Par contre attention, quand tu vas l'importer dans un nouveau projet, il va recréer les dossiers de ton premier projet contenant les éléments donc le mieux c'est d'importer dans un projet vierge, tout ranger correctement et réexporter pour éviter que ce soit le bordel.

---------- Post added at 19h10 ---------- Previous post was at 18h31 ----------




> Salut a tous, je viens a vous pour vous demander comment tourne la démo de mon monde (scardeep)
> C'est juste une visite a pied de la zone, mais j'ai quand même ajouté quelques petits bruitages (à jouer la nuit en 5.1  )
> 
> voici 2 liens où vous pouvez trouver la démo. (316 megas quand même)
> 
> http://sdrv.ms/1bZEWSR
> ou
> http://game.irilys.eu/unity3d/scardeepDemo.zip
> 
> merci d'avance


 Salut Botu. Je passais ici par hasard et je suis content de tomber sur ton projet.  ::): 

Chez moi ça tourne bien sur ma machine: i7 930, 12Go de ram, GTX460. Le chargement est très rapide même sans SSD.

Je te conseille de laisser tomber Skydrive: il m'a demandé des identifiants Microsoft  ::|:  alors que ton second lien marche sans problème.

Graphiquement c'est très bien, je pense que nous sommes unanimes. J'ai juste remarqué une texture étirée sur le pont au tout début, celle du sol qui n'est peut être pas carrée.

Je rejoins Poussin Joyeux sur la souris trop sensible: le réglage que fourni Unity par défaut est trop élevé. Je te conseille Sensitivity X à 5 pour le Mouse Look du First Person Controller. Même chose pour le Y du Mouse Look de Main Camera. Ca correspond au réglage par défaut que j'ai vu dans les jeux et je n'ai jamais eu de mauvais retour à ce niveau.
A propos de Main Camera, mets le Near Clipping Planes à 0.01, soit le minimum, ça évitera de voir à travers certains objets quand on se colle le nez dessus.  :;): 

Pour le curseur, il faut que tu le masques et le verrouille. Voilà un script à enregistrer en .js .



```

#pragma strict


function Start(){
    Screen.showCursor = false;
    Screen.lockCursor = true;
}



//Fonction pour webplayer car le Screen.lockCursor n'y marche qu'avec un clic de la part du joueur
function Update(){    
                        
    if (Input.GetMouseButton(0)){
          Screen.lockCursor = true;
        }        
}
```



---------- Post added at 19h16 ---------- Previous post was at 19h10 ----------




> *Qu'est ce que j'aurai aimé que skyrim est autant d'inspiration (oui j'ose)*...y'a pas photo, malgré les limitations du moteur tu t'en tire vraiment bien, comme quoi le design est tout aussi important que des textures 4092 par 4092...et c'est pas si évident que ca de créer un monde en brisant la linéarité des décors.


 Tu n'es pas le seul à le penser.

Bethesda c'est comme le Macdo, ils sont connus car ils font de la quantité destinée au grand public mais ce sont loin d'être les meilleurs en monde ouverts.

----------


## Zevka

> Dans l'onglet "project", un clic droit sur un objet ou dossier te donne l'option "export unitypackage" ou un truc du genre. Unity s'occupe de récupérer les éléments dépendant de cet objet.
> 
> Exemple, tu veux exporter le prefab d'un objet 3D: unity va prendre le prefab, le modele 3D, son matériaux, ses textures, ses scripts... même s'ils sont éparpillés n'importe où.
> 
> Par contre attention, quand tu vas l'importer dans un nouveau projet, il va recréer les dossiers de ton premier projet contenant les éléments donc le mieux c'est d'importer dans un projet vierge, tout ranger correctement et réexporter pour éviter que ce soit le bordel.


Ok merci, mais il n'y a pas moyen d'importer plusieurs objets d'un coup ?

Parce que là, vu ce que tu me décris, ça revient à faire la première méthode (tout copier et nettoyer ce dont je n'ai pas besoin).

----------


## Black Wolf

Tu peux sélectionner plusieurs objets avec CTRL-click sauf erreur puis faire l'export vers le package. En gros oui ça revient à peu de choses près au même que de nettoyer ton projet, sauf que comme dit plus haut, ça te permet de pas faire de connerie en supprimant une dépendance vu que tu sélectionne que tes objets de base et que lui s'occupe d'en récupérer les dépendances.

----------


## botu

Meci a tous!
@ MorK : je vais integrer ca et modifier la vitesse de la souris. Je vais aussi ajouter un compteur fps. En fait j'ai pas mal d'ajustements a faire encore :D

----------


## MorK

> Meci a tous!
> @ MorK : je vais integrer ca et modifier la vitesse de la souris. Je vais aussi ajouter un compteur fps. En fait j'ai pas mal d'ajustements a faire encore :D


Y'a toujours des choses à améliorer sur les projets, on est jamais satisfaits.  ::P: 

Je te fais suivre un script que l'on m'avais donné pour le compteur de FPS:

Là aussi c'est du .js


```

#pragma strict

    @script ExecuteInEditMode

    private var gui : GUIText;

    private var updateInterval = 0.5;
    private var lastInterval : double; // Last interval end time
    private var frames = 0; // Frames over current interval

    function Awake ()
    {
       Application.runInBackground = true;
       Application.targetFrameRate = -1;

       QualitySettings.vSyncCount = 0; // No VSynch
    }


    function Start()
    {
        lastInterval = Time.realtimeSinceStartup;
        frames = 0;
    }

    function OnDisable ()
    {
       if (gui)
          DestroyImmediate (gui.gameObject);
    }

    function Update()
    {
        ++frames;
        var timeNow = Time.realtimeSinceStartup;
        if (timeNow > lastInterval + updateInterval)
        {
          if (!gui)
          {
             var go : GameObject = new GameObject("FPS Display", GUIText);
             go.hideFlags = HideFlags.HideAndDontSave;
             go.transform.position = Vector3(0.0,0.85,0);
             gui = go.guiText;
    //         gui.pixelOffset = Vector2(0,0);
             gui.pixelOffset = Vector2(5,55);
          }
            var fps : float = frames / (timeNow - lastInterval);
          var ms : float = 1000.0f / Mathf.Max (fps, 0.00001);
          gui.text = ms.ToString("f1") + " ms        " + fps.ToString("f2") + " FPS";
            frames = 0;
            lastInterval = timeNow;
        }
    }
```

----------


## Ornithorix

Petite question pour ceux qui ont travaillé sur ca: J'ai une balle à qui j'applique un transform.translate sur un axe et je lui ai attaché un box collider + une rigidbody. J'ai attaché les script oncollisionenter et oncolliderenter. En switchant en collider ou collision, si la balle va pas trop vite ca marche niquel,la collision ou détection se fait. Cependant quand le transforme.translate est trop grand ca ne marche pas. C'est du au fait que la hitbox ne touche pas l'objet entre deux frames. J'ai essayé d'activer le interporlate sur le rigidbody mais je continue à avoir des cas où les balles qui vont trop vite traverse les objets. 
Des idées pour régler ce genre de problème? J'avais pensé a changer le transform.translate par l'autre truc du rigidbody.addforce, mais est ce que ca réglera pour autant la question? Surtout que bon, parfois, le moteur physique de unity fait des trucs bizarres....

----------


## Zevka

Le raycast est indispensable pour les collisions dès que ça va un peu vite. L'interpolate ou autre ça ne marchera pas, j'ai tout testé, crois moi !

Je suis globalement pas fan de la détection des collisions sous Unity, la plupart du temps, tu finis par en rajouter une couche par toi même de toute façon.  ::P:

----------


## botu

Tu sais aussi modifier certaines valeurs dans les preferences pour la physique, parfois ca aide en peu.

----------


## Ornithorix

J'avais bidouillé les rigidbody sans obtenir de résultat satisfaisant... Je re bidouillerais ce soir.
Quand tu parle de mettre un raycast, j'avais tester le raycast en tir direct (un peu comme le fait le moteur source), mais c'est pas trop ce que je veux... ou alors tu parle de mettre un raycast sur la balle qui fait une vérification de la distance entre la balle et l'objet et qui set la collision au moment où la distance est à zéro ,ou une astuce de ce genre?


EDIT: Pour ceux que ça intéresserait, je viens de trouver ce script
http://wiki.unity3d.com/index.php?ti...oThroughThings
Je le testerais et je dirais si ça fonctionne bien

----------


## Zevka

> J'avais bidouillé les rigidbody sans obtenir de résultat satisfaisant... Je re bidouillerais ce soir.
> Quand tu parle de mettre un raycast, j'avais tester le raycast en tir direct (un peu comme le fait le moteur source), mais c'est pas trop ce que je veux... ou alors tu parle de mettre un raycast sur la balle qui fait une vérification de la distance entre la balle et l'objet et qui set la collision au moment où la distance est à zéro ,ou une astuce de ce genre?
> 
> 
> EDIT: Pour ceux que ça intéresserait, je viens de trouver ce script
> http://wiki.unity3d.com/index.php?ti...oThroughThings
> Je le testerais et je dirais si ça fonctionne bien


Tu peux faire un raycast sur une direction limitée, c'est parfait pour du translate.
Avant chaque translate, tu fais un raycast entre la position actuelle, et celle à venir avec le translate. Si tu touches un truc entre temps, tu corriges la distance. Tu même peux le faire pour du FPS avec un minimum de ballistique (donc pas de "laser" avec raycast direct), ça marche très bien.

Dans certains cas très rapide, j'avais même du faire un raycast en avant et en arrière.  ::P: 



PS: J'ai regardé vite fait ton lien, c'est tout à fait le même genre d'astuce




> Tu *PEUX* aussi modifier certaines valeurs dans les preferences pour la physique, parfois ca aide en peu.


Non mais oh.  ::P:

----------


## war-p

Pour en revenir au raycast pour une balle, il faut que celui-ci soit au minimum aussi long que la distance parcourue entre deux frames par la balle.

----------


## botu

Salut a tous,

Grace a vos conseils et aux scripts de Mork, j'ai continué ma démo.
Elle existe maintenant pour pc, mac et linux

pc version : http://game.irilys.eu/unity3d/scardeepDemo.zip
mac version : http://game.irilys.eu/unity3d/scardeepDemoMac.zip
linux version : http://game.irilys.eu/unity3d/scardeepDemoLinux.zip

-Vous pouvez placer un waypoint avec  "p" et y revenir avec "r"
-Il y a un léger mouvement de la tête et des nouveaux sons pour les pas
-J'ai updaté unity et j'ai donc utilisé des nouveaux filtres.



-il y a un compteur de fps.

Normalement c'est aussi en peu plus rapide.

----------


## Ornithorix

Bon ben le petit script http://wiki.unity3d.com/index.php?ti...oThroughThings marche au poil. Je met un max de vitesse, la collision marche niquel




> Salut a tous,
> 
> Grace a vos conseils et aux scripts (...)


Petits bug: en se collant a certaine porte, la caméra voit a travers et on voit que c'est un bout de bois collé sur du mur (changer la distance de vision mini de la caméra ou coller une collision sur le mur plus grande)
Je me suis jeté dans le vide, je devais rebondir sur un caillou dans un ravin sur une paroi verticale mais je suis passé au travers

----------


## Poussin Joyeux

Coucou!

Je ressors un "vieux" topic car il me prend l'envie de rejouer avec Unity ou un autre moteur genre UDK, etc...  Mon but serait de faire se promener de petits bonhommes en vue à la 3eme personne et de les faire un peu interagir entre eux (pour commencer).
J'avais déjà un peu touché à Unity par le passé donc je me dis autant repartir sur ce moteur plutôt que d'en réassimiler un autre. Par contre, un truc m'avait gêné à l'époque, c'était le fait de ne pas pouvoir avoir d'ombres dynamiques avec la version gratuite. Ca gâche beaucoup l'immersion quand on voit un élément se déplacer sans son ombre qui le suit.
D'où ma question: est-il possible de réaliser ça avec Unity de manière gratuite, avec un peu de code supplémentaire? Ou bien il faut obligatoirement passer par la version payante?

----------


## Tildidoum

Pour les ombres dynamiques, la version gratuite permet d'en avoir mais uniquement pour les lumières directionnelles : typiquement tu pourras avoir une lumière type soleil qui projette des ombres temps réel dans des zones extérieures. 
Les ombres dynamiques de point lights et spot lights sont toujours réservées à la version pro, payante.

Pour ce qui est de bidouiller avec du code pour contourner le problème, je sais pas du tout. 
Si tu trouves des infos là dessus ça m'intéresse cela dit  ::): 

Par contre faut savoir que Unity se fait un peu sauter à la gorge par Epic et son Unreal Engine 4, c'est tout récent, et la team Unity a beaucoup de mal à réagir.

Ca dépend de ce que tu veux faire  : projet commercial ou non, besoin de solides features graphiques, maîtrise du c++ ... Perso je te conseillerais vivement d'au moins jeter un oeil du côté de l'UE4 avant de t'embarquer pour un nouveau projet sur Unity.

----------


## Poussin Joyeux

Merci pour ta réponse Tildidoum!
Je savais pas qu'on avait quand même des ombres temps réel avec des lumières directionnelles. C'est bien ça! Par contre, le fait qu'il n'y ait pas pour les spots lights peut être également bien gênant.

Le C++ ne me dérange pas et pour ce qui est du projet "commercial", je préfère ne pas y penser pour l'instant vu le nombre de projets de jeux que j'ai commencé et abandonné quelques mois après  ::):  donc j’espérerais que ça en soit mais rien n'est sûr  ::P: 

L'UE4 peut me plaire mais payer 19$ par mois dès maintenant me dérange (mais faut que je regarde car il y a peut-être une version gratuite pour commencer). J'ai aussi vu que Torque3D commençait à prendre un peu d'importance...

En tout cas, si je trouve un bout de code gratuit pour faire les ombres dynamiques quelque soit la source lumineuse, je te ferai signe  :;):

----------


## JulLeBarge

> Par contre faut savoir que Unity se fait un peu sauter à la gorge par Epic et son Unreal Engine 4, c'est tout récent, et la team Unity a beaucoup de mal à réagir


Qu'est ce que tu veux dire par là ? Que l'UE4 est bien plus "intéressant" que Unity 3D ? Tu peux détailler stp ?

----------


## Saito Gray

> Qu'est ce que tu veux dire par là ? Que l'UE4 est bien plus "intéressant" que Unity 3D ? Tu peux détailler stp ?


Après avoir été longtemps fan d'Unity je suis passé à UE4 à mon plus grand bonheur.

UE4 est un moteur next gen, graphiquement, il déchire vraiment (exemple: http://i.imgur.com/EEi4SQf.jpg Ca tourne en temps réel sur mon PC i7/8GO/660).

Mais, surtout, bien que la communauté ne soit que naissante, le moteur a un bien meilleur support qu'Unity. La chaine Youtube déborde de tuto, la documentation est de bonne qualité, il y a des exemples de code fournis et le suivi des bug est vraiment super rapide.
UE4 bénéficie également d'une bonne prise en mains (c'est un peu déroutant au début, mais en multi écran c'est un vrai plaisir).

Mais, surtout le prix est un énorme avantage. Pour 20€/mois, j'ai accès au moteur, au support ainsi qu'aux mises à jour. Je peux également annuler mon abonnement, j'aurais toujours accès au moteur et à la doc, mais plus aux mises à jour.

Et c'est un énorme avantage comparé à Unity5 (qui n'est pas encore sortie) avec son prix bien trop haut (1500$ de base auquel il faut ajouter le prix de tout les plug in d'export...) et son abonnement à 75$/mois.
D'autant plus que les geatures d'Unity 5 n’ont rien de supérieur à l'unreal Engine, bien au contraire.
Alors, oui Unity dispose bien d'une version gratuite, mais ses limitations sont une vraie blague.

Le système de visual scripting d'UE est aussi très bon et super pratique pour débugger, mais il faut avouer que ça devient vite le bordel.

Ce qui manque a UE pour surpasser clairement Unity c'est un asset stores bien remplit (les gens que chez Epic sont en train de bosser dessus) et un système de script pour rendre le développement plus facile qu'en C++, mais moins bordélique qu'en Blueprint (c'est en cours de développement par la communauté).

Si l'équipe d'Unity3D ne réagit pas, les temps risquent d'être plus difficiles pour eux à l'avenir.

----------


## Louck

Le système d'entité/composant/scripting n'est pas complexe sous UE4 ? (à part que c'est du c++)

----------


## Tildidoum

Au sujet de Unity / UE4, Saito Gray a bien résumé la situation. Quelques précisions supplémentaires :

L'abonnement à 75$ par mois d'Unity Pro se fait pour une durée d'un an minimum. Et ça dépend des plateformes cibles : PC / Max / Linux ça compte pour une seule license Pro, si on veut publier sur Android c'est une licence Pro en plus à payer, et pour iOS encore une licence supplémentaire.
UE4 avec son abonnement à 20$ pour toutes les plateformes résiliable quand on veut est franchement séduisant en comparaison.

Il faut préciser que du côté Unity, il n'y a pas de royalties à payer en cas de projet commercial, que ce soit avec la version pro ou free du moteur.
Epic prend 5% sur la monétisation de jeu fait sous UE4. 
Les royalties ne commencent qu'après les premiers 3000$ de bénéfice chaque trimestre.

Donc sur le long terme, en cas de jeu commercial qui rapporte du pognon par brouettes, Unity pourrait rester plus avantageux d'un point de vue économique.

Sauf que voilà, même dans l'espoir de rentabiliser à long terme ça reste un investissement incertain et concrètement tout le monde ne peut pas se permettre d'acheter la licence pro ou de souscrire un abonnement d'un an à 75$ par mois et par plateforme.

L'aspect économique séduisant et la méchante avance du moteur graphique pour l'Unreal Engine 4 en font un très sérieux concurent d'Unity.
Si Epic tire de toute façon son épingle du jeu avec toutes les grosses licenses AAA qui utilisent son moteur, je ne sais pas si la team Unity qui vise avant tout les indés et les amateurs est en mesure d'adapter son modèle économique.

Je pense que malgré tout ça Unity reste encore intéressant pour le moment :
Pour sa communauté et le contenu de son asset store, sa version gratuite reste largement suffisante dans pas mal de cas (j'pense notamment à la 2D), et parce que l'UE4 n'est pas encore tout à fait mûr.




> Le système d'entité/composant/scripting n'est pas complexe sous UE4 ? (à part que c'est du c++)


Là dessus aucune idée, les trucs compliqués à base de ligne de code j'y connais rien  ::P:

----------


## Saito Gray

> Le système d'entité/composant/scripting n'est pas complexe sous UE4 ? (à part que c'est du c++)


Non, c'est relativement simple à utiliser, après tout dépend ce que tu veux faire.

En gros pour créer un component tu crées un blueprint => tu ajoutes à l'intérieur du blueprint, si besoin, des modèles 3D, de la lumière, etc... => tu places ton blueprint dans ton niveau comme n'importe quel modèle 3D.

Le moteur est conçu pour être utilisé avec les blueprint, tout tourne autour de ça, les matériaux, l'animation, les cinématiques et le gameplay.
Le C++ ne sert qu'a créer les cores feature du jeu, le genre de chose qui serai complètement incompréhensible avec du visual scripting.

Globalement leur système de visual scripting est super cool, notamment pour le débogage, car tout se fait en visuel ( http://i.imgur.com/e0zzL7O.jpg sur le screen on peu voir que les liaisons s'illuminent quand elles sont utilisées en jeu, ça permet de voir directement quel morceau de code déconne), c'est vraiment top pour les designers qui pourront prototyper leur jeu sans avoir à coder beaucoup. 
Néanmoins, je pense qu'ajouter un petit système de script qui s'exécute à l'intérieur des blueprint pourrait être bénéfique à la compréhension et rendrai le développement de grosse fonctionnalité beaucoup plus simple pour les quiches comme moi...

----------


## Djal

> Globalement leur système de visual scripting est super cool, notamment pour le débogage, car tout se fait en visuel ( http://i.imgur.com/e0zzL7O.jpg sur le screen on peu voir que les liaisons s'illuminent quand elles sont utilisées en jeu, ça permet de voir directement quel morceau de code déconne), c'est vraiment top pour les designers qui pourront prototyper leur jeu sans avoir à coder beaucoup. 
> Néanmoins, je pense qu'ajouter un petit système de script qui s'exécute à l'intérieur des blueprint pourrait être bénéfique à la compréhension et rendrai le développement de grosse fonctionnalité beaucoup plus simple pour les quiches comme moi...


A noter qu'il existe un plug in similaire pour unity: http://www.hutonggames.com/

Vous m'avez bien donné envie d'essayer UE alors que je suis à 2 doigts de me mettre à Unity :/

----------


## Saito Gray

> A noter qu'il existe un plug in similaire pour unity: http://www.hutonggames.com/
> 
> Vous m'avez bien donné envie d'essayer UE alors que je suis à 2 doigts de me mettre à Unity :/


Oui, mais Playmaker ne fait clairement pas le poids face aux blueprint. Le système de blueprint d'UE est profondément intégré dans le moteur et démonte clairement Playmaker en termes de fonctionnalités et de vitesse d'exécution.
Très honnêtement, si le développement t’intéresse jette un oeil à UE4, ça vaut clairement les 20€ d'investissement, même si au début il faut s’accrocher (mais avec les tuto vidéo ça va tout seul).

----------


## Louck

> Vous m'avez bien donné envie d'essayer UE alors que je suis à 2 doigts de me mettre à Unity :/


A mon unique avis, les deux gros plus d'UE, c'est son moteur graphique et son côté pro (et vendeur).

Maintenant si tu cherches à faire un jeu simple et rapide, Unity en version gratos reste une bonne solution, à mon goût  ::): .

----------


## JulLeBarge

Merci pour ces explications.

UE4 semble intéressant en effet, mais y'a pas de version complètement gratuite pour voir ce que ça donne ? Moi je m'amuse avec ces outils mais sans vouloir faire un vrai jeu que je vais vendre, je me vois mal m'abonner pour utiliser UE4 !
et quelle différence avec l'UDK (qui lui était gratuit quand je l'avais testé) ?

----------


## Black Wolf

Comme dit plus haut tu peux toujours payer pour un mois et résilier tout de suite le temps d'évaluer tranquillement le moteur, après faut juste espérer que la version dispo au moment où tu t'abonnes n'ait pas de gros bugs gênant (je me rappelle encore de posts sur l'UDK ou certaines releases avaient des gros bugs et étaient difficilement utilisables).

Perso je n'ai pas encore fait le pas, ça fait 3 ans que je bosse avec Unity, je commence à avoir une collection bien remplie sur l'assetstore (payant et gratuit)... Si les modèles 3d et packs de décors peuvent certainement être facilement importés de l'un à l'autre, cela reste un "point d'attache" assez fort pour les utilisateurs d'Unity de longue date. En même temps tu as AMPLEMENT de quoi faire avec la version gratuite d'unity, il ne manque aucune fonctionnalité niveau création de contenu et gameplay, tu peux publier sur toutes les plateformes gratuitement depuis environ 1 an. Les limitations se trouvent toutes au niveau graphique comme dit plus haut, au niveau des ombres, et point un peu plus gênant je trouve, pour tout ce qui est post-effects et le rendu dans des textures.

Mais il faut bien avouer que la politique tarifaire pour l'Unreal Engine est très tentante, et l'aspect "j'utilise le même moteur que les gros studios" fait toujours envie à notre côté geek, même si, si j'ai bien compris, la version disponible avec l'abonnement est quand même amputée d'une partie des fonctionnalités pour des raisons de licences (le moteur d'éclairage Enlighten (qui sera intégré à Unity 5, mais pro seulement j'imagine), Speedtree (pareil) et peut être Scaleform mais j'ai un doute).

Par contre, le fait que tu dises que tout est articulé autour du système blueprint serait plutôt un défaut pour moi, étant codeur, il m'attirait justement pour son aspect "accès au source et code en C++". Enfin je suis curieux de voir comment cela va évoluer dans les prochaines années. A l'annonce de la sortie publique de l'UE4, t'as pas mal de beta testeurs qui disaient être rapidement revenu sous unity pour des petits projets "amateurs", car l'UE était trop usine à gaz à leur gout. Maintenant faudrait que je prenne le temps de tester sérieusement. 

Après ça me fait doucement rigoler les gars sur les forums officiels qui postent des screens de leur jeu avec 4-5 modèles 3d super mal faits avec des textures horribles, pas de lightmapping, pas d'éclairage ni rien et qui pleurent en disant qu'ils veulent passer sous l'Unreal Engine parce qu'avec Unity gratuit leur jeu est moche.

Bref à quand des semaines de 14 jours de 48h pour avoir le temps de tout tester  :;):

----------


## Tildidoum

> et quelle différence avec l'UDK (qui lui était gratuit quand je l'avais testé) ?


UDK c'est la version gratuite de l'Unreal Engine 3, et tu peux toujours obtenir gratuitement la dernière version *ici*.
C'est une version qui a aussi ses bons côtés mais qui n'a jamais été pensé pour être aussi souple et accessible qu'Unity et l'UE4 aujourd'hui.

Ca dépend de ce que tu veux faire mais en gros pour du FPS / TPS ok, pour autre chose je ne conseillerais pas UDK.

----------


## Adu

Et je présume que l'UE niveau 2D n'a pas toutes les facilités d'Unity ?
Etant donné que je suis carrément plus orienté 2D que 3D (plus facile de trouver des sprites gratuits vu que je suis une tanche en dessin, que de modèles 3D animés etc ...), passersur l'UE, je pense que je peux me brosser ?

----------


## Saito Gray

> Et je présume que l'UE niveau 2D n'a pas toutes les facilités d'Unity ?
> Etant donné que je suis carrément plus orienté 2D que 3D (plus facile de trouver des sprites gratuits vu que je suis une tanche en dessin, que de modèles 3D animés etc ...), passersur l'UE, je pense que je peux me brosser ?


Ça dépend. Sans plug-in la 2D est aussi facile à faire sous Unity que sous Unreal. Certain plug-in sous Unity aident beaucoup, mais je ne doute pas les voir arriver un jour sur L'Unreal.
UE dispose de 2 exemples de jeu en 2D, un clone de Flappy Bird ainsi qu'un runner, le moteur est donc tout à fait capable de faire de la 2D

Le gros problème d'Unreal concernant la 2D c'est le manque de documentation, mais l'équipe travaille vite et je ne doute ne pas voir arriver relativement rapidement un ensemble de tuto couvrant le sujet.

Si tu utilises des plug-ins sous Unity pour la 2D attend quelques mois que la doc se mette en place, tu profiteras de l'expérience des early adopter ainsi que de tuto bien plus complets.

----------


## Adu

Pour le moment je me sers (enfin j'apprends surtout) à me servir de Unity2D tel qu'il est fourni, je n'ai pas encore trop regardé les plug-ins.
Je vais me pencher un peu sur ce que propose UE pour la 2D.

EDIT : bon je viens de matter un peu, pour le moment la 2D, ça reste mieux sous Unity. Et l'Asset Store, waow, j'avais jamais pris le temps de regarder .... Je sens que ça va booster ma productivité sous Unity !

EDIT² : bon, pourquoi y a pas une version lite pour tester l'UE4 ?  ::(:  ou alors je lâche 20€juste pour un mois ...

----------


## Poussin Joyeux

Pour faire suite au message que j'avais laissé ici il y a une semaine, je vais plutôt me tourner vers Torque3D (http://www.garagegames.com/products/torque-3d) finalement:
- c'est open source sous Licence MIT (très permissive) => rien à payer même si on en fait un jeu commercial après.
- pas de bridage comme Unity Free au niveau des sources lumineuses et des ombres par exemple
- accès au source code et on peut le modifier comme on veut.
- la communauté anglophone a l'air assez active (moins importante que Unity forcément)
- programmation en script très proche du C++ ou C++ directement donc ça me plait bien.
- un inconvénient par rapport à Unity, c'est qu'il n'y a pas de portage Android/IOS mais ça ne me dérange pas pour l'instant.

Voilà, je vais jouer un peu avec et je ferai un topic dédié sur le forum à ce moteur si j'accroche bien.

----------


## quidal

Salut les amis petite question sur Unity 3D ou autre d'ailleurs
Si on veut faire un jeu gratuit avec des options payante pour IOS et android . (comme candy crush par exemple)
ca se passe dans unity?

----------


## Black Wolf

Tu n'as aucune limitation de ce que tu peux vendre ou autre avec Unity. Tu peux faire un jeu payant avec la version gratuite, tout comme faire de l'achat in app si t'en as envie. Cependant Unity n'intègre rien par défaut qui permette d'utiliser les API officiels des stores ios et google play, donc il te faudra coder toi même l'intégration des achats in-app ou avoir recours à des plugins dispo sur l'asset store (sûrement payants mais jamais bien chers).

----------


## quidal

> achats in-app ou avoir recours à des plugins dispo sur l'asset store (sûrement payants mais jamais bien chers).


Merci beaucoup

----------


## stigma

Bonjour,
Je viens de découvrir ton jeu Unity. Vraiment très bien. Pourrais-tu me dire quel Asset tu as utilisé pour l'herbe ?
Je travaille actuellement sur un Myst-Like avec la version Indie (je suis pas riche) et l'herbe par défaut fait un peu cartoon mais je trouve la tienne très réaliste.
Voici mon jeu en construction :
http://www.maximages.fr/?page_id=186
cordialement

----------


## botu

salut pour l'herbe, il y a un outil sympa sur l'asset store : http://forum.unity3d.com/threads/vol...ensity.256497/
Tomaszek est qq de serieux et qui repond vite en cas de problemes.
N'hésite pas si tu as d'autres questions.

edit: je viens de voir que c'est quand même 71 euros.. il te reste la solution de packs avec en peu de tout :

https://www.assetstore.unity3d.com/en/#!/content/1021
https://www.assetstore.unity3d.com/en/#!/content/3076
https://www.assetstore.unity3d.com/en/#!/content/9023
https://www.assetstore.unity3d.com/en/#!/content/12751

----------


## stigma

Certains packs me font rêver, mais le prix est excessif pour moi. Je vais prendreLe Grass Textures à 15€, ça me paraît convainquant.
Merci pour l'info.
Edit :
Effectivement ce plug me satisfait pleinement pour mon projet.

----------


## Black Wolf

Vraiment dommage, le package "Volume Grass" était en forte promo "football madness" sur l'asset store pendant toute la fin de la coupe du monde, jusqu'à avant-hier...

----------


## Metalink

Plus j'ai envie de me mettre à Unity, plus j'ai l'impression que ça se résume à acheter des plugins qui font 90% du jeu à notre place  ::|:

----------


## Saito Gray

Non.
Si tu as 6 mois à perdre tu peux sans problème construire les mécaniques de jeu dont tu as besoin.
Bien sûr, tu risques de finir démotivé et de tout laisser tomber au bout de quelques semaines, car tu ne vois pas les résultats de ton projet.

L'achat de plugins fait gagner du temps, de l'argent si tu es un indé, et, surtout, permettent de se concentrer sur le plus important : le jeu.

Après tu devras obligatoirement mettre les mains dans le code pour bidouiller un peu les mécaniques qui ne te conviennent pas, mais les plug in, que ce soit des morceaux de code ou du graphisme, font gagner un temps non négligeable dans le développement d'un jeu.

C'est bien joli de savoir coder, de vouloir faire son jeu de A à Z, mais, en pratique avoir une base pour commencer rapidement est un plus non négligeable pour le moral, la motivation et donc, un gros plus qui augmente énormément les chances que le projet soit finit un jour.


Mon prochain jeu, par exemple, va utiliser l'Unreal Engine 4 et pourtant je bosse depuis quelques jours sur le prototype dans RPG Maker. Parce qu'il est inutile que je perde mon temps à écrire du code temps que je ne suis pas sur que les mécaniques vont fonctionner correctement.

----------


## stigma

ça dépend des plugins. Si c'est pour acheter des bâtiments, des objets, des persos, alors oui, c'est le plugin qui fait le jeu à ta place. Personnellement j'ai tout modélisé dans Blender, terrain compris. Bien sûr j'ai acheté l'herbe qui couvre le terrain et le shder pour la mer car dans la version indie c'est pas top. Ah oui, j'ai acheté aussi Playmaker mon plug chéri, pourtant je développe en php au boulot mais Playmaker c'est tellement bon. Je l'ai eu pendant une période de baisse à 25€ sinon il est à 95€.
J'ai déjà dépensé pas mal sur l'Asset-Store mais il faut faire vivre Unity !

----------


## Djal

> Ah oui, j'ai acheté aussi Playmaker mon plug chéri, pourtant je développe en php au boulot mais Playmaker c'est tellement bon.


Moi j'ai du mal! Je galère 10 fois plus pour faire un truc qu'en le codant à la main. Ça m'enerve car ça a l'air vraiment pas mal.

----------


## stigma

ça m'est arrivé au début aussi. J'ai vu quelques tutos, fais des trucs simples et après on ne peut plus s'en passer. C'est fou les trucs qu'on peut faire avec. Dans mon jeu il n'y a que 1% de code à peine. Tout le reste est en Playmaker.
Je te donne un lien en français pour débutants. Il me semble que ce sont les seuls tutos en français dailleurs https://www.youtube.com/watch?v=rG7Y...XS3EXOIeN_5dOR

----------


## Djal

Merci!

----------


## Black Wolf

Oui enfin comme Djal j'ai un peu de la peine avec Playmaker suivant ce que tu veux faire, même si j'en adore le concept et que j'ai essayé de l'utiliser pendant un moment. 

Ca devient particulièrement pénible quand t'as des opérations mathématiques à faire et qu'il faut ajouter une action pour faire a - b, créer une variable pour stocker un résultat intermédiaire, rajouter une action pour faire resultat * c etc... on finit par faire PLEIN de clics, avec plein de variables dans tous les sens, et perdre beaucoup de temps à fouiller dans les actions, pour finir enfin par devoir créer des scripts d'action perso pour que cela soit un poil moins pénible.

Bref c'est un excellent outil, mais je pense qu'il faut bien choisir à ce pour quoi on en a besoin et ne pas hésiter à mixer code pur, actions playmaker perso, et actions prédéfinies de playmaker. Se forcer à tout faire en playmaker "pur" quand on sait coder, cela complique quand même pas mal les choses (même si cela aide bien à poser une structure claire pour le code... parfait pour faire du prototypage p.ex).

----------


## stigma

Je l'utilise principalement pour faire des animations. Gérer un ascenseur, un clavier de PC pour entrer des mots de passe, un boitier d'ouverture de porte par code secret etc.... Bref, une programmation visuelle plutôt simple à gérer et à modifier une fois qu'on y est habitué.

----------


## Black Wolf

Oui alors en effet pour ce genre de truc il est juste génial ! C'est surtout dès qu'il s'agit de faire des calculs que le nombre de clics et manipulation à faire par "bénéfice apporté" commence à diminuer.

----------


## Metalink

> ...


Complétement d'accord, c'est pour ça que depuis 6 mois je cherche le framework/soft qui me permettra de réaliser mes idées le plus vite possible tout en gardant la plus grosse marge de manœuvre (et éventuellement de plaisir à la réalisation).
Seulement avec Unity c'est devenu un putain de business, et c'est "ça" que je reproche un peu. Parce que ouais, claquer 100 boules dans un script qui fait de l'herbe (j'agresse personne, je reprend vite fait les exemples vu sur la page  :;):  ) franchement ça me fait pas kiffer ... Surtout quand jme dis "tiens, avec LibGDX, ya ptet un mec qu'a fait une lib pour faire de l'herbe" et elle sera gratos, opensource, je pourrais l'améliorer, discuter avec son créateur ...


Unity fait vraiment envie et à beaucoup de qualités, la preuve j'essaye de m'y mettre, mais là en passant sur le topic (et comme je l'ai déjà vu plusieurs fois sur le net) j'ai eu une sorte d'impression (encore une fois je n'agresse personne, c'est mon point de vue d'ignare qui débarque sur le topic) de voir des gens acheter des jeux en kits et les assembler ... Je me trompe surement mais du coup j'imagine que la majorité des ressources pour Unity sont payantes, vu qu'il y a une possibilité "simple" de se faire des sous avec (et je ne blame personne) et ça, ben je trouve ça dommage :/

Edit : genre là vous parlez d'un plugin qui à juste l'air ultime, mais 100€ quoi  ::|:  ...

----------


## Black Wolf

Alors oui c'est clair que des fois il y a cet aspect "jeu en kit", après tout dépends si tu veux faire un jeu, ou faire de la programmation. Certains de ces plugins sont d'ailleurs dédiés aux artistes, afin qu'ils puisse se débrouiller pour faire un proto sans avoir de programmeur avec eux en permanence, tout comme tu trouves des packs graphiques bien fournis pour que le programmeur puisse faire autre chose qu'une bataille de cubes. 

Etant programmeur, je ne compte plus les projets qui n'avançaient jamais car je voulais tout faire moi même... évidemment tu peux toujours le faire, certains plugins te prendraient une semaine ou deux à recoder toi même si tu te limites clairement à ce que tu as besoin et que tu cherches pas à faire un truc super générique (ce qui est surtout un ÉNORME boulot pour ceux qui créent ces packages sur l'asset store, sans compter le support qui devient un boulot à plein temps ensuite). 

Après quand tu l'utilises dans le monde professionnel, compares 2 semaines de travail d'un ingénieur et un plugin à 100$, le calcul est vite fait. Par contre si c'est ton projet perso, t'as aucune obligation, tu peux utiliser un plugin gratuit (sisi ça existe, y a même des trucs très bien), suivre un tuto sur le net (la aussi y en a plein), demander des infos sur le forum officiel ou tout coder toi même, c'est pas parce que c'est du unity que tout change du tout au tout, l'adaptation d'un shader trouvé sur le net est pas si compliqué et tout ce qui est code est en C# ou javascript, donc la aussi tu trouve tout ce qu'il te faut comme ressources et infos sur le net. Au niveau assets graphiques, tu peux importer sans problème du obj, fbx ou du blender sans aucun souci, importer du maya ou 3ds nécessite par contre d'avoir le soft installé sur sa machine.

Sans compter que l'asset store fait des promo journalières, et de plus grosses promo assez régulièrement. Au final c'est un peu comme steam, si tu as pas besoin d'un plugin ou d'assets immédiatement, ils finiront bien par passer en promo (genre il me semble que playmaker dont on parle plus haut est souvent passé à une 30aine de $). Tu peux aussi tout simplement ne pas utiliser de plugin, unity est déjà très complet tel quel. Pour reprendre ton exemple du script pour l'herbe, il y a déjà un système de base pour gérer la végétation, la c'est juste un gars qui s'est tapé un sacré travail d'études et d'implémentation de shaders pour arriver à un meilleur résultat, rien ne t'oblige à l'avoir.

Bref c'est la tendance pour tous les moteurs, l'Unreal Engine va suivre le même chemin qu'unity avec leur asset store qui est en cours de création aussi. Cela permet également aux petits studio de payer leur développement en vendant les outils qu'ils ont créés pour leur jeu.

----------


## stigma

Je plussoie Black Wolf, il y a pas mal de plugins gratuits que j'ai utilisé dans mon jeu ou bien pas trop cher, dans les 5 à 15€. Je n'ai jamais acheté au-delà de 25€ et c'est le prix de Playmaker dans les périodes où il baisse.

----------


## tompalmer

Niveau jeu 2D, type gestion ça vaut quoi ?

----------


## Black Wolf

Je ne vois pas trop de limitations. Unity gère assez bien tout ce qui est 2D depuis quelques versions SAUF la GUI pour laquelle un gros patch doit sortir cet été (la 4.6) avec un nouveau système de GUI tout beau tout neuf. Les jeux de gestions étant souvent bourrés de menus dans tout les sens, cette update sera nécessaire pour toi si tu ne veux pas passer à la caisse pour un plugin genre NGUI ou DaikonForge. Il y a une grosse conférence Unity tout soudain, ça m'étonnerait pas qu'ils en profitent pour sortir leur nouvelle version à ce moment là, mais en attendant rien n'empêche de s'y mettre pour apprendre les bases.

----------


## tompalmer

Ouais c'est ce que je fais, mais niveau tuto c'est galère pour la 2D. 
Surtout que la plupart de ces rares tutos concernent des jeux de plates formes ou des space invader like

----------


## Saito Gray

Oui, mais c'est assez normal. Tu ne trouveras pas un tuto tout fait sur le jeu que tu veux faire, les tuto sont là pour d'apprendre à utiliser les fonctions 2D de base du moteur, pour le reste c'est a toi de creuser.

Je te conseille vraiment de faire les tuto de base du logiciel, même en 3D sinon tu vas être vite perdu.
Unity n'est pas excessivement compliqué à utilisé, mais il demande quand même du temps. Fait la bases, des tuto, bricole dans ton coin, et une fois que tu te sens confortable avec l'outil libre a toi de créer ce que tu veux  :;):

----------


## Djal

> Ouais c'est ce que je fais, mais niveau tuto c'est galère pour la 2D. 
> Surtout que la plupart de ces rares tutos concernent des jeux de plates formes ou des space invader like


Je ne sais pas si ces tutos sont déjà passés:

http://pixelnest.io/tutorials/2d-game-unity/
http://www.raywenderlich.com/61532/u...etting-started

----------


## tompalmer

Y'a Playmaker qui -apparemment- serait l'extension phare, en solde a 65 $.
Je ne sais pas de quel genre d'assets j'aurais besoin, j'attends encore un peu ce serait stupide de me lancer tête baissée dans un truc ou je ne pige rien.

---------- Post added at 21h23 ---------- Previous post was at 21h22 ----------




> http://pixelnest.io/tutorials/2d-game-unity/


Celui ci existe ne Français pour info, je suis dessus depuis quelques heures  ::):

----------


## Louck

Conseil perso pour les débutants (je ne sais pas si tu en es vraiment un, mais bon): N'achetez pas d'assets pour vos débuts.

*Jamais.*


Sans rentrer dans les détails: Réalises déjà un petit jeu avec l'outil de base afin de prendre en main ce dernier, de connaitre ses fonctionnalités, sa puissance, etc... Mais surtout pour savoir comment fonctionne un jeu! 
Tu peux développer directement ton jeu de gestion avec Unity sans assets (qui n'est pas difficile en soit, surtout si tu ne te bases que sur quelques images et GUI) ou des prototypes de jeu classique.

Quand tu sauras utilisé l'outil, tu connaîtras mieux les limites (personnel et de l'outil) et tes besoins pour ton projet.
Là, tu sauras quel asset choisir pour ton jeu.

Mais passer par la case "assets store" sans avoir touché une seule fois au développement d'un jeu, c'est griller toutes les étapes. Et il y a bonne chance de se sentir perdu (+ les contraintes habituelles de la réalisation d'un jeu amateur).

----------


## Ravine

y'a http://www.unity3d-france.com/unity/ aussi sinon
Et je plussois la personne au dessus.

----------


## Dicsaw

Vous entendez quoi par "assets" ? Les modèles 3D ? 

Parce que Playmaker c'est bien sympa quand même, et ça permet d'économiser du temps sur des fonctions à la con comme "sauvegarder" ou "prendre un screenshot".  C'est moins #_oldschool_, mais bon.

----------


## tompalmer

Bah assets -> Un accessoire quoi, un truc qui se dl et qui t'aide.

---------- Post added at 00h03 ---------- Previous post was at 23h47 ----------




> y'a http://www.unity3d-france.com/unity/ aussi sinon


Oui non là ça m'aide pas pour la 2d

----------


## Louck

> Parce que Playmaker c'est bien sympa quand même, et ça permet d'économiser du temps sur des fonctions à la con comme "sauvegarder" ou "prendre un screenshot". C'est moins #oldschool, mais bon.


Autant oui, il y a certains outil/framework qui peuvent aider les développeurs. Dont playmaker, 2Dtoolkit, et plein d'autres. Et certains sont très bien.

Mais vouloir débuter son premier jeu à partir d'assets "qui sont bien" sans même avoir posé ses pattes sur Unity ?


C'est possible de travailler comme ca. Mais à mon avis, ce n'est pas ce qui est de plus efficient, pour un débutant.

----------


## Black Wolf

Hésite pas a poser toutes tes questions ici si il le faut. On est plusieurs à avoir une certaine expérience d'unity. 

Pour la 2D franchement c'est 80% pareil que la 3d sauf que tu te sers pas des coordonnées en Z ou très peu (juste histoire d'ordonner tes "couches" de sprite si nécessaire). Les seuls trucs à savoir en plus c'est comment gérer tes sprite, animations, spritesheets, mais une fois que t'as les bases du reste, ça s'apprend très rapidement. Comme je te disais, te prend pas trop la tête avec tout ce qui est GUI pour l'instant, le système fourni actuellement avec unity est un peu pourri, ça devrait changer très bientôt pour quelque chose de beaucoup plus pratique.

Et comme dit plus haut ne t'arrête pas à "c'est un tuto pour un jeu de plateforme, ça me sert à rien", alors oui tu vas pouvoir "filtrer" une partie des infos qui te seront moins utiles, mais c'est quand même nécessaire d'avoir des bases sur un peu tout les sujets pour pouvoir faire ce que tu veux ensuite. Pour un jeu de gestion, j'imagine qu'une bonne partie du code n'aura même rien à voir avec unity et sera du code C# (calcul etc..), donc en effet tu vas pas trouver de tuto tout fait sur ce point.

----------


## tompalmer

Le détail de mon projet est dans ce topic, je ne le dis pas pour toi puisque tu l'a déja lu mais reste a voir si c'est compatible avec unity.

Parce que par "gestion" j'ai peur que vous compreniez un truc a la sim city alors que le concept est bien plus simple

----------


## Black Wolf

Ouais justement, j'avais pas tout de suite lu ton post, du coup je pensais plus à un truc à la simcity pour lequel Unity serait bien adapté.

Maintenant que j'ai plus d'infos sur ton projet disons que c'est faisable... mais il te faut au minimum soit un plugin genre NGUI soit attendre la version 4.6 d'Unity pour gérer correctement toutes les interfaces graphiques que demande un tel projet. Évidemment tu n'est pas obligé d'attendre pour t'y mettre et comprendre les bases du moteur, mais pour t'attaquer à la GUI en elle même ça sera nécessaire.

----------


## Louck

Au mieux en attendant, tu sors ton crayon + bloc-note (+ calculette) et tu fais ta conception sur papier avant de débuter le développement.

Bon conseil: notes bien ce que tu veux faire pour ton jeu (ses "features") et ses limites (contenu, nombre de tableaux, etc...). Comme ca tu auras ton objectif et tu auras esquivé 50% des possibilités d'échecs d'un projet amateur.

----------


## Djal

Vous arrivez à vous en tenir à ce que vous avez conçu vous? Moi je fonctionne par incrementation et prototypage.

----------


## Saito Gray

Au début c'est difficile de s'y tenir, tu as toujours l'idée géniale au dernier moment à rajouter.
Mais tu finis vite par comprendre que si tu ne définit pas très rapidement tes objectifs tu te retrouver noyé sous la demi-tonne de feature et que ton code ne ressemble plus a rien.

La clef pour vraiment sortir un jeu c'est de se limiter, une fois que tu as le concept papier tu construis un prototype, si le proto n'est pas fun à jouer tu revois ta copie.

Il ne faut pas oublier que la motivation est d'une importance vitale pour tout projet non payé, Trop de rajout de dernière minute > plus de travail > démotivation rapide.

----------


## Ravine

recupere un truc gratuit; si tu n'es pas programmeur tu vas avoir les yeux plus gros que le ventre avec Unity, perdre ta motivation, acheter quelques plugins "parce que j'en ai besoin ca me permettrait de programmer sans programmer" ou faire la GUi, ou mettre des arbres ou whatever, et tu vas te focaliser sur les petits trililis autour en oubliant que ton projet repose sur une simulation.

Chope GameMaker ou Construct 2, c'est plus intuitif quand tu debutes, et tu pourras commencer a poser ta logique, tes elements de gameplay, tester ce qui fonctionne ou ce qui ne fonctionne pas. Si a partir de la tu arrives a un jeu, tu auras acquis assez d'experience pour savoir ce que tu souhaites faire vraiment, et tu aviseras. Ou fais un proto papier. (et j'ai lu ce que tu as dit dans le topic de description de ton projet; tant que tu n'as pas essaye ni l'un ni l'autre, je maintiendrai que tu n'as pas besoin de plus pour commencer)

----------


## Louck

> Vous arrivez à vous en tenir à ce que vous avez conçu vous? Moi je fonctionne par incrementation et prototypage.


Oui et j'ai déjà essayé les deux cas:
- J'ai finis tous mes petits projets lorsque j'ai fais un planning (sauf rares exceptions).
- Pas les autres.

Même en faisant un planning, tu peux toujours prévoir de rajouter un ou deux features (voir en retirer) à ton projet, mais il faut toujours rester raisonnable et garder le cap sur ton objectif.
Le luxe est de pouvoir estimer le temps pour réaliser tel ou tel partie du projet. Mais cela vient avec l'expérience.

----------


## tompalmer

J'ai déja un design document, et si je trouve clickteam et gamemaker trop limités c'est pas pour essayer construct  ::P:

----------


## Ravine

As tu testé tes mécaniques ? Écrire des trucs sur un papier c'est bien mais tant que ça ne tourne pas ça ne vaut pas tripette, et tu vas changer 80% du truc et dégager les 20% restant. Tu dis plus haut que la programmation c'est ce qui t'empêche principalement de sauter le pas, et tu veux commencer avec le plus touffu et le plus complexe du marché directement ? Go for it. Il paraît qu'il faut se planter soit même pour vraiment apprendre.

----------


## tompalmer

Non mais déja unity est moins compliqué que d'autres, et si je pouvais réaliser le jeu que je voulais avec un logiciel de ce type je le ferais. 
J'suis désolé mais là c'est comme si tu me disais d'aller apprendre à cuisiner au feu de bois en me faisant engager chez McDonald, faut au moins débuter sur un truc adapté. 

Même si j'arrivais a maitriser gamemaker ou clickteam, je serais toujours aussi paumé si je change de moteur vu que c'est des langages propriétaires. 

Là mes mécaniques c'est des calculs et du "causes à effets". ça tourne comme un tableau excel, mais excel c'est un peu limite comme moteur  ::P: 

Edit : oh putain c'est ça qui me faudrait, un truc mi excel mi photoshop

----------


## Ravine

Un algo c'est un algo. Tu peux l'implementer en C, Ruby, Fortran, assembleur, C#, javascript, "langage proprietaire de script dans un outil" ou "en interface clic clic dans un autre outil", ca reste un algo. Et c'est ca qui est important. L'autre partie importante c'est de faire le jeu.
Tu n'as aucune idee de ce qu'est faire un jeu video mais tu as deja décrété que Unity etait adapté (c'est un moteur et un outil générique, c'est "adapté" a 95% de ce que les gens veulent faire). Mon conseil c'est pas de t'envoyer te bloquer dans une voie, c'est de t'empecher de te retrouver submergé par l'outil. Unity c'est touffu. Et si comme je le pense c'est ton premier jeu, tu vas faire des erreurs, plein, parfois irréversibles, et ca va te frustrer et tu vas jeter l'eponge sur ton projet.

Apres je ne vais pas me fatiguer plus que ca, hein: c'est ton temps et ta motivation, pas les miens.

----------


## tompalmer

J'ai surtout une humble expérience de moddeur à la base, et de conception web light. Et j'ai reçu des cours de Gamedesign  ::P: 

J'ai quand même dit plus haut que j'allais commencer par des hello world sur unity avant de débuter, je sais bien qu'il faut y aller progressivement mais a force de faire des casses briques sur clickteam et des jeux de tirs moisis sur gamedev je pense qu'il faut franchir un pallier. 




> "en interface clic clic dans un autre outil"


Bah ça j'ai pas trouvé comment, mais si ça peut m'éviter de me casser la tête je suis ravi qu'on m'explique  ::P:

----------


## Ravine

Scirra Construct. Si tu suivais les liens que je poste plutot que de faire la tete de mule. Et si les behaviours qui sont proposés de base ne te conviennent plus, y'a meme un SDK en javascript. On a vu plus propriétaire comme techno. (version free, tout ca, ca te prend un aprem a essayer).

----------


## tompalmer

J'ai suivi mais comme d'hab j'ai vu que des jeux de plates formes et un STR tout moisi basé sur des health bars et des timers. Je veux bien que ce soit flexible mais faut que je le sache a l'avance, si c'est possible

----------


## Ravine

Tout est adapté. Ton concept c'est des boutons, des jauges, et des trucs derrieres qui se passent quand tu cliques sur les boutons. Prends une calculatrice programmable et fais ton jeu. Fais une page web et fais ton jeu. Prend Excel, colle des boutons et fais ton jeu. Prend un papier, un crayon, et fais ton jeu.
Le jeu video c'est ni plus ni moins que des formules excel avec une jolie interface. Plutot que de te demander si tu dois choisir entre plusieurs marteaux alors que tu ne sais pas planter un clou, prends en un au pif et commence a taper.

(et pour repondre a ta question originale qui est de determiner si Unity c'est "adapté": non, pour moi, c'est overkill en regard de ce que tu montres comme experience)

----------


## tompalmer

Pas facile avec autant d'avis contradictoires  ::P:  Mais c'est la réponses que je cherchais. 
Enfin après l'utilisation d'un code web limite les portages, etc ... Ce genre de choses il faut y penser, bref je vais me lancer dans des essais divers.

----------


## Ravine

De ce que j'ai compris, tu n'as pas vraiment fait de jeu jusqu'a present. Je parle de projet complet, perso, jouable. Un truc a garder en tete c'est que le premier jeu sera naze. Le second aussi. Et pas mal de suivants. Mais a chaque fois tu auras appris un truc et tu feras differement, mieux, plus rapidement. Si tu passes 10 ans a attendre l'outil qui te permet de faire ton jeu avec le Bouton Magique™ (celui qui fait ton jeu apres avoir sélectionné le type de jeu dans une liste, ce fameux bouton), tu ne feras jamais rien. C'est pour ca que j'insere "fais un proto papier" dans le tas, parce que c'est le plus simple a realiser, tu peux ecrire au crayon, avoir des marqueurs en verre pour representer des bidules, lancer des dés pour faire de l'aléatoire, etc etc. C'est la forme la plus simple du jeu, et ca reste la plus accessible pour tester des mecaniques.

Shadowrun Returns par exemple, a subis de nombreux playtests... avec des figurines. Pendant ce temps, les techos mettaient en place le toolset pour creer le monde et la logique derriere, pendant que les GD testaient le systeme de combat autour d'une table, avec des dés et des crayons.

Teste GameMaker ou Construct, fais des trucs avec. Sort du carcan "oh le tuto il montre comment faire une plateforme, je m'en fous". Tu t'en fous, certes, mais ce tuto explique les bases de l'interface. Quand tu as pigé comment l'outil fonctionne, tu peux commencer a retourner dans tous les sens ce que tu sais. "et si au lieu d'etre une plateforme c'est un bouton, qui me donne +10 credits quand je clique dessus ? Et si aleatoirement, ca me donne entre 1 et 50 credits ? Parfois ca m'en fais perdre 50 direct? Etc". Experimente, teste, prototype. Et arrete de juger les productions faites avec ces outils: eux au moins, ils ont produit quelque chose.

Le Bouton Magique™ n'existe pas.

----------


## tompalmer

Mais je sais  :Emo:  J'arrête pas de le dire, seulement j'essaye juste de trouver un truc qui me donne des bases exploitables pour un et des futurs projets. J'suis venu ici humblement, pas en posant mes ballz en disant que je vais faire le meilleur jeu du monde en 5 minutes. Le choix du moteur est une vraie question.

Les tutos, je les fait, *mais* *je regarde aussi qu'est ce que les devs qui maitrisent le logiciel arrivent a en faire.* 
S'il faut passer 400 heures pour se rendre compte que je ne pourrais jamais faire un jeu de gestion avec c'est pas tip top. 
Et ne pourrais me servir du savoir accumulé sur ce logiciel pour passer sur un autre, c'est donc pas mal de temps *perdu*. 

Pour ça que je dis que j'ai commencé sur clickteam -> j'ai fais des tutos, des jeux a la con 
-> dès que j'ai voulu me lancer dans une version prototypée du projet j'ai pu faire qu'un menu principal et une scène avec des scores vides.

j'ai pas envie de passer mon temps à réinventer la roue non plus, si tel moteur permet d'économiser un peu de temps parce que "c'est pensé pour", c'est mieux.

----------


## Metalink

C'est où pour kickstart Le Bouton Magique ?  :Cigare: 

Sinon ayant dev plusieurs jeux (plus ou moins gros, certes, vive les gamejams), je ne peux qu'être d'accord avec Ravine  :;): 
Et je tiens à rajouter que les logiciels dont vous parlez, autant GameMaker que Clickteam ou Construct sont loin de permettre de faire uniquement des jeux "basiques" (je citerais de loin Hotline Miami et Spelunky), et sont biiiiiien plus simples à appréhender qu'Unity (j'en sais quelque chose, je fais la transition là  ::ninja:: ).
Voilà, j''espère que c'est compréhensible je suis en retard pour le taf  ::lol::

----------


## Louck

> Les tutos, je les fait, mais je regarde aussi qu'est ce que les devs qui maitrisent le logiciel arrivent a en faire.


Le truc aussi, c'est que tu ne trouveras pas de tuto pour réaliser un jeu de gestion avec des images.
Par contre, tu as l'avantage que beaucoup d'outils (même RPG Maker) ont des fonctionnalités pour mettre en place un scénario, des événements, et surtout une interface... soit le nécessaire pour réaliser ton jeu, si je ne me trompe pas ?

----------


## LaVaBo

> C'est où pour kickstart Le Bouton Magique ? 
> 
> Sinon ayant dev plusieurs jeux (plus ou moins gros, certes, vive les gamejams), je ne peux qu'être d'accord avec Ravine 
> Et je tiens à rajouter que les logiciels dont vous parlez, autant GameMaker que Clickteam ou Construct sont loin de permettre de faire uniquement des jeux "basiques" (je citerais de loin Hotline Miami et Spelunky), et sont biiiiiien plus simples à appréhender qu'Unity (j'en sais quelque chose, je fais la transition là ).
> Voilà, j''espère que c'est compréhensible je suis en retard pour le taf


Construct semble quand même, comme gamemaker et pas mal d'autres, très orienté sur un personnage ou un groupe de personnage, suivis par une caméra.

De ce que j'en ai vu, faire par exemple une interface où tout est cliquable, mais où chaque élément cliqué amène une fenêtre ou un menu différent, avec masse d'attributs, ne semble pas super adapté. En tout cas, personne ne fait ce genre de chose, et encore moins de tutos dessus.
Alors tompalmer a raison d'avoir des doutes, il pourra peut-être poser des bases en quelques jours, pour se rendre compte derrière qu'il n'arrivera pas à aller au-delà des bases et devoir tout refaire dans un autre environnement.

----------


## tompalmer

> Et je tiens à rajouter que les logiciels dont vous parlez, autant GameMaker que Clickteam ou Construct sont loin de permettre de faire uniquement des jeux "basiques" (je citerais de loin Hotline Miami et Spelunky)


Au delà de leur qualité que je ne nie guère, je dirais que c'est des jeux simples mais conçus au poil de cul (surtout hotline). C'est efficace. Et j'ai bien peur que ce soit les limites que permettent ces logiciels.



> Le truc aussi, c'est que tu ne trouveras pas de tuto pour réaliser un jeu de gestion avec des images.


Je sais bien c'est pour ça que je me suis interessé à des tutos similaires, comme pour faire un rts. Mais en fait c'est assez différent. 




> Par contre, tu as l'avantage que beaucoup d'outils (même RPG Maker) ont des fonctionnalités pour mettre en place un scénario, des événements, et surtout une interface... soit le nécessaire pour réaliser ton jeu, si je ne me trompe pas ?


J'ai pas mal test rpgmaker XV ace mais on ne peut pas vraiment sortir du Jrpg, donc c'est pas du tout ce qui me conviendrait pour ce projet. Comparons : 
 



LaVabo > Merci de me comprendre, et encore je vais parfois chercher loin en tentant d'assembler des bouts de tutos en pensant que ça me servira mais non. 

Après c'est possible que j'ai zappé un truc sur clickteam, mais même pour faire un module de sauvegarde c'est galère là dedans. Et la communauté est assez restreinte.
Encore une fois je regarde surtout et d'abord les jeux "featured", si y'a aucun jeu s'approchant de près ou de loin de ce que je désire c'est mauvais signe.

----------


## Louck

On peut très bien faire une interface pour le menu principale, les options, la sélection du niveau, et d'autres. Pourquoi on ne peut pas utiliser cette même pratique pour son jeu de gestion ?

Je n'ai jamais utilisé Construct ni Game Maker, mais ca m'étonne beaucoup que cela est impossible à faire.


Edit: En faite, le mieux serait que tu fasses une charte graphique de ton projet afin que tu nous montres vraiment ce que tu veux faire *techniquement*. Je pense pas qu'on ai la même définition d'UI pour ton jeu.

----------


## tompalmer

Vais tenter dans la matinée, j'avais tenté de faire plusieurs jauges de scoring et c'est là que le drame fut. Pour influer le score dans ces jeux faut qu'un truc se passe à l'écran, genre sauter sur une caisse. 
Mais par contre définir des classes d'électorats, faire en sorte qu'ils aiment X idées et te faire gagner des adhérents en fonction c'est une autre histoire, j'ai complètement largué le logiciel là dessus.

---------- Post added at 11h16 ---------- Previous post was at 10h53 ----------



Voilà, en haut y'a des scores. qui fonctionnent aussi comme des ressources qu'on peux dépenser. 
Les boites grises sont des trucs cilquables, c'est abstrait mais ça peut être des conseillers, ou n'importe quelle icône bref. (et si on clique on peut avoir accès a des menus du type de l'image que j'ai posté plus haut)

En haut a droite y'a une date, qui se modifie d'un certain intervalle a chaque tour (le bouton aurait du être en bas à droite mais il est là bref)

L'agenda serait une sorte de raccourci vers des actions spéciales ou des informations générales (électorat, sondages, news, opinions dominantes ...) 

Bref ce qu'il faut retenir c'est qu'on clique, pour avoir des menus. Et a chaque tour des events aléatoires / semi aléatoires/scriptés viennent influencer le tout et donner du piment. 

Le but est d'accumuler un bon score dans les jauges, et une formule secrète viendra comparer ça a ceux des autres candidats "IA" le dernier tour venu -> ça se transforme en valeur relative, en % et voilà. 

La mécanique est assez huilée, elle s'inspire des jeux paradox entre autres

----------


## Metalink

De loin comme ça j'aurais presque envie de te dire "Mais fais le en HTML bon sang !"  ::P: 
Après effectivement tu vas avoir besoin d'un système de GUI solide et là je peux pas trop t'aider, c'est le genre de trucs que je bidouille à la fin de mon dev puisque je suis plus les main dans le moteur en général  ::lol:: 
Mais ça m'a effectivement pas l'air infaisable avec Clickteam (même si jte conseille d'oublier juste pour la gestion des variables, et tu vas en avoir besoin on dirait) ou Gamemaker (et Unity une fois de plus je peux pas donner mon avis)  ::P:

----------


## tompalmer

Hmm je ne sais pas encore coder *les jeux* en HTML, mais c'est capable de supporter des calculs comme ça ? 
(Sans compter que le HTML, je l'avais dit plus haut, ne permet pas le portage, et puis c'est pas très compatible avec la commercialisation surtout  :Emo:  ). 

Je sais qu'a la rigueur Javascript ferait l'affaire, mais pareil : je veux un exe !  ::ninja::

----------


## Louck

> ne permet pas le portage


What ?

Il est vrai que le HTML5 serait très bien adapté pour ce projet. Mais cela implique de toucher au moteur du jeu et de beaucoup coder (même s'il existe quelques frameworks).

----------


## tompalmer

Bah a partir d'unity par exemple, tu peux exporter ton jeu simplement si j'ai bien compris. Là en HTML c'est cuit si je veux en faire une version PC/ tablette / super nintendo . 
Et beaucoup coder aussi en effet, niveau rendement ça doit pas être jojo. Et pour débugger .. omg.

----------


## Metalink

HTML5 ça sous entendait effectivement Javascript, après quoi il existe des MILLIARDS (au moins) de trucs pour compiler sur tout autant de plateformes (sauf peut-être la SNES)  ::P: 
Jette un œil du côté de Phonegapp et autres trucs dans le genre. Après ça va demander de beaucoup coder, même en utilisant un framework, c'est clair ...

----------


## Ravine

(avant de penser a le vendre, fais ton jeu)

----------


## Louck

> ( et puis c'est pas très compatible avec la commercialisation surtout  ).


Autre sujet (désolé pour les fans d'Unity3D) mais fais super gaffe si tu cherches à vendre ton jeu (et à gagner quelque chose derrière) surtout quand tu n'as pas d'expériences. Il y a une très grosse différence entre "faire un jeu par hobby" et "faire un jeu pour gagner du fric".

Je ne te connais pas après tout, et c'est toi qui décide. Mais si tu veux découvrir *le monde merveilleux de la création d'un jeu-vidéoludique* je te conseil comme la personne d'en haut: fais ton jeu. Ne pense pas à le commercialiser.

----------


## tompalmer

Je disais juste que dans l''éventualité que le projet prenne forme et que je puisse le partager, bah le HTML sera pas adapté. 
Autant qu'il soit commercialisé ou pas je m'en fous, mais j'aimerais qu'il soit joué.  Et a chaque type de jeu son public et ses plates formes. 

Par exemple ça me viendrait pas a l'idée de sortir un wargame sur Smartphone ; ou quand j'écris sur un blog je ne le fais pas comme un bouquin.

----------


## Djal

J'ai pas suivi si tu savais coder ou pas (le html ne compte pas).

Si tu tâtes un peu de Java, libGDX est un outil tout à fait adapté à ce que tu veux faire avec son système Scene2D et Scene2D.ui et sa capacité à compiler pour toute sorte de plateforme.
Après il faut un peu de connaissances transverses (Gradle..) et c'est plus complexe que Unity, Gamemaker and co.

----------


## tompalmer

Non, je ne sais que le lire et le comprendre vaguement. Je m'y suis encore jamais intéressé suffisamment jusqu'à maintenant. 

J'ai vu que Prison architect était codé avec visual c++, et comme dit plus haut y'a moyen de faire des trucs en C# ou C avec les outils microsoft. j'aimerais en savoir plus là dessus (parce que j'ai visual studio)

----------


## Sahnvour

Bah apprends le C#, familiarise toi avec Unity et utilise leur système de GUI bien foutu qui sortira avec la 4.6.

----------


## tompalmer

Ah bah si unity est compatible C# je suis sur que ce language me servira a quelquechose  ::P: 

Sinon desolé d'avoir un peu squatté le topic, merci a tous  :;):

----------


## Saito Gray

> [...]
> Voilà, en haut y'a des scores. qui fonctionnent aussi comme des ressources qu'on peux dépenser. 
> Les boites grises sont des trucs cilquables, c'est abstrait mais ça peut être des conseillers, ou n'importe quelle icône bref. (et si on clique on peut avoir accès a des menus du type de l'image que j'ai posté plus haut)
> [...]


Je reviens rapidement répondre à un ancien message, mais une interface de ce genre c'est très possible (et facile) avec Game maker.

J'ai bricoler un petit truc en une heure (parce que je suis rouillé, quelqu'un d'expérimenté avec l'outil peut faire ça en 15 minutes) qui montre une peu comment on peu faire ce genre d'interface : https://mega.co.nz/#!w5ljET5C!EQXX8x...EDEdYq_Al0Xgbw (attention cliquer sur l'agenda quitte le jeu).
Ça ne casse pas des briques, mais ça montre bien qu'il est possible de créer relativement facilement ce genre d'interface avec GM.

Maintenant c'est très basique, il y a encore une tonne de travail à faire pour rendre ça amusant et plus joli, mais c'est juste une démo.

En fait je suis plutôt d'accord avec ce que dit Ravine, le choix du moteur importe peu, ton expérience est facilement transmissible d'un moteur a l'autre, même si le moteur utilise du langage propriétaire, l'important c'est de comprendre le concept.
S'adapter à un nouveau langage n'est pas vraiment compliqué.

Après je ne sais pas si c'est très pertinent de te lancer la tête première dans Unity et le C#, si tu as des difficultés avec le PHP tu risques de très vite te casser les dents avec tout ce qui est POO, mais ça, c'est toi qui vois !
Bon courage en tout cas.

----------


## tompalmer

Merci Saito, l'interface n'a jamais été un problème vu que c'est du drag & drop. C'est le scoring  :Emo: 
Je vais faire des essais il se trouve que j'ai la 8.0

----------


## Saito Gray

Pour le scoring c'est simple. Tu créer un objet Score dans lequel tu initialises les variables dont tu as besoin :


Ensuite, tu les mets à jour en fonction des actions que le joueur fait :


Tous tes jeux vont tourner autour du concept d'objet et de variable le plus difficile dans ton projet c'est l'équilibrage et la création de contenu, la base en lui-même est faisable relativement rapidement si tu es familier avec les gros concepts que l'on trouve dans n'importe quel langage de programmation.

Si tu n'arrives pas a faire ce que tu veux, démonte ton problème en petit bloc simple et recherche sur les forums de la communauté ou sur google, généralement quelqu'un a eu le même souci avant toi et a la réponse a sa question.

Unity c'est très bien, le C# aussi, mais c'est vraiment massif et s'y prendre "à sec" sans avoir un peu d'expérience dans la création de jeu c'est possible, mais c'est un peu comme si tu voulais commencer l'escalade par monter l'Everest..

La meilleure chose que l'on puisse te conseiller c'est de faire des tuto, même si les jeux sont chiants, minimes et ne t'intéressent pas. Ton expérience est transférable avec un peu de logique, tu ne perdras donc pas ton temps et tu apprendras les concepts de base de la plupart des moteurs modernes.

----------


## Louck

En ce moment, je m'amuse avec le module réseau d'Unity
Globalement, je suis entrain de réaliser une architecture clients<=>server pour des jeux en 2D, en coop (4/8 joueurs), serveur autoritaire, pouvant contenir beaucoup d'entités et de la physique (pour un jeu dans l'espace).

J'hésite à faire un topic devlog pour parler de mon avancé.

----------


## yourykiki

Je bidouilles avec unity depuis mi-Aout, et je trouverai intéressant un topic dédié à un sujet technique !

----------


## Louck

Je ferais un topic sur mon sujet  ::): .

----------


## Poussin Joyeux

Coucou!

Un peu déçu par Metrocide (http://store.steampowered.com/app/313130/), j'ai envie de tenter de me faire un jeu qui se passerait dans une ville en vue de dessus (comme Metrocide, les vieux GTA, etc...). Ca n'ira peut-être pas très loin mais ça me démange d'essayer depuis quelques temps.  ::): 

J'ai donc pensé à Unity pour pas réinventer la poudre. 

Je n'y connais pas encore grand chose à Unity, d'où ma question suivante...

Je me dis que je pourrais commencer un projet en 2D sur Unity avec vue de la ville du dessus mais si jamais plus tard, je souhaite passer à une vue 3D de ma ville, est-ce que cela sera compliqué? 
Ou bien vaut-il mieux que je commence direct par un projet 3D où je positionnerai la caméra pour qu'elle soit seulement au-dessus?

----------


## tompalmer

T'as pensé a gamemaker ou tu te braque sur unity ?

----------


## Louck

> Je me dis que je pourrais commencer un projet en 2D sur Unity avec vue de la ville du dessus mais si jamais plus tard, je souhaite passer à une vue 3D de ma ville, est-ce que cela sera compliqué?


Changer le jeu de dimension implique énormément de choses: esthétique, camera, mécaniques du jeu, etc etc .... Ce n'est pas quelque chose à prendre à la légère.
Au mieux, tu peux penser ton jeu en 2D et appliquer un esthétique en 3D pour plus tard. Mais ce n'est pas simple.

Reste sur de la 2D, fais les choses simples au début. Quand tu auras un peu d'expérience, tu pourras tenter de faire un nouveau jeu en 3D.

----------


## Poussin Joyeux

Merci pour vos réponses rapides (comme toujours ici!)




> T'as pensé a gamemaker ou tu te braque sur unity ?


Je me braque sur Unity car j'ai parfois des envie de création de jeu en vue subjective et ça je ne pourrai pas le faire avec GameMaker.  Donc je me dis que si j'en apprends un, autant apprendre celui qui permet de faire de la 2D et de la 3D (même si j'aime beaucoup certains jeux 2D faits avec GameMaker!).




> Changer le jeu de dimension implique énormément de choses: esthétique, camera, mécaniques du jeu, etc etc .... Ce n'est pas quelque chose à prendre à la légère.
> Au mieux, tu peux penser ton jeu en 2D et appliquer un esthétique en 3D pour plus tard. Mais ce n'est pas simple.
> 
> Reste sur de la 2D, fais les choses simples au début. Quand tu auras un peu d'expérience, tu pourras tenter de faire un nouveau jeu en 3D.


En fait, c'est surtout qu'une vue de dessus pour une ville en 2D uniquement me parait avoir un peu morne. Un GTA2 par exemple donne une plus grande impression d'immensité:




qu'un Retro City Rampage:




Et je ne parle pas de Teleglitch... Mais là, je passerai beaucoup trop de temps à maîtriser la technique et plus de temps pour le reste!

Mais oui, faut sans doute que je sois raisonnable dans un premier temps (surtout vu le nombre de projets de projets de jeux commencés et jamais finis que j'ai à mon passif).

----------


## Black Wolf

Disons que si ton jeu se passe surement "dans le plan" et que tu pars avec des modèles 3d dès le départ, techniquement cela sera très simple de passer de la 2D à la 3D, il te suffit sous Unity de changer 2 ou 3 propriétés de la camera. Mais passer un jeu après coup en vue 3D pose quand même pas mal de soucis, parties de modèles 3d qui cachent ton personnage, contrôles pas forcement adaptés d'après l'angle de la caméra, ce genre de choses.

----------


## Sergebourg

Je ai lu dans cet  article les avantages de Unity face Cocos2D, et je ai aussi décidé de développer un petit jeu. Vos créations sont incroyables!!!!

----------


## Poussin Joyeux

Coucou!
Avec Unity 5, j'essaie d'utiliser le "AI Third Person Controller" mais je n'arrive pas à le faire bouger.
En Target pour les AI 3rd person, j'ai essayé plusieurs Transform (celui de mon personnage et celui des autres personnages) mais mes AI ne bougent pas alors que la variable Target semble bien mise à jour.
En regardant la scene d'exemple (où on clique avec la souris pour lui indiquer la cible), je ne vois pas ce qui manque chez moi.
Je trouve quasi rien sur ça sur Internet alors c'est peut-être une nouveauté de Unity5?

Est-ce que quelqu'un a une idée?

Edit: Bon mon problème est le suivant en fait: 


> "SetDestination" can only be called on an active agent that has been placed on a NavMesh.


Faut juste que je comprenne un peu mieux comment ça marche le NavMesh maintenant  :;):

----------


## Molina

Salut les canards,
Pour un gros noob, vous avez déjà lu ce livre http://www.amazon.fr/Unity-Developme.../dp/1849690545 ? 

On peut commencer par là ?

----------


## Louck

Aucune idée.

Qu'est ce que tu cherches à apprendre ? A utiliser Unity3D ? A programmer ? A faire de l'art/graph/musique ?

Sinon, est-ce que tu as déjà des connaissances techniques ou artistiques ?

----------


## Molina

> Aucune idée.
> 
> Qu'est ce que tu cherches à apprendre ? A utiliser Unity3D ? A programmer ? A faire de l'art/graph/musique ?
> 
> Sinon, est-ce que tu as déjà des connaissances techniques ou artistiques ?


Je sais coder sous SAS  ::ninja::  (un logiciel de traitement statistique). 

Mon but est double, j'ai idée qu'unity3D serait parfait pour mon futur jeu idéal, et ensuite, j'aimerais savoir programmer en vrai en C#.

Au moins pendant cette année (ou pendant 2 ans). Après, pour tout ce qui est artistique, ce n'est pas réellement ma priorité, même si je conçois que c'est important. J'ai pas vraiment de talent artistique particulier...

----------


## Djal

Moi je l'ai lu. 

Très bien pour débuter quand comme moi tu as besoin de mettre les mains dedans concrètement pour comprendre un truc. Par contre c'est vraiment pour y mettre un pied, après faut prendre un peu plus copieux.

Je me demande où je l'ai foutu, je peux peut être te le lâcher si t'es sur panam.

----------


## schouffy

http://it-ebooks.info/

Tu as qques bouquins gratos ici, cherche "unity".
ça te permet de cibler un bouquin, ensuite évidemment si tu le trouves bien achète le.

Personnellement je recommande celui là :
http://www.amazon.fr/Pro-Unity-Game-...ords=pro+unity

----------


## Louck

Ouai donc, on peut considérer que tu commences à 0  ::P: .

Je n'ai aucune idée si le bouquin est très intéressant cependant. Mais l'idéal est d'apprendre à utiliser l'outil (et de comprendre son workflow) et d'avoir un minimum de connaissance en programmation objet (si tu veux coder), qui est différent du SAS je pense  ::P: .
A partir de là, je pense que tu peux commencer à expérimenter avec l'outil, à réaliser des minis-jeux ou des prototypes pour t’entraîner (en quelques semaines), avant de faire ton projet

----------


## Molina

Merci à vous ! Je suis pas pressé, c'est d'ailleurs plus pour avoir un but qui me permet de passer mon temps et de m'occuper les soirs d'hiver que de créer mon RPG daggerfall-like que j'ai en tête  ::ninja::

----------


## Mysterius

> En ce moment, je m'amuse avec le module réseau d'Unity
> Globalement, je suis entrain de réaliser une architecture clients<=>server pour des jeux en 2D, en coop (4/8 joueurs), serveur autoritaire, pouvant contenir beaucoup d'entités et de la physique (pour un jeu dans l'espace).
> 
> J'hésite à faire un topic devlog pour parler de mon avancé.


C'est toujours au programme ?

----------


## Louck

> C'est toujours au programme ?


Oui, même si j'ai pris beaucoup de temps à le faire  ::P: 

Pour le jeu de l'espace, ca sera un très gros projet perso que j'essayerai de commercialiser (note: ce n'est pas un SS13 like  ::P: ). J'ai une préférence à tenter certaines expériences/concepts avant de m'attaquer à ce jeu.

D'ailleurs, je travaille actuellement sur un prototype d'un jeu multijoueurs. Je ferai un nouveau topic en septembre ou octobre (selon son avancé).

----------


## Mysterius

Ah d'accord, je pensais que tu parlais d'un remake de SS13 vu que tu l'avais vite fait évoqué  ::): .

----------


## Louck

> Ah d'accord, je pensais que tu parlais d'un remake de SS13 vu que tu l'avais vite fait évoqué


Il y a bien ce projet  :;): . Mais en ce moment, je travaille sur deux projets de jeux en même temps, un troisième serait très compliqué  ::P: .
Néanmoins ce projet de remake SS13 est en phase de conception: j'écris des idées sur papier, et je développe des scripts à côté, qui me serviront plus tard (un système de compétences et d'états, comptabilité avec un éditeur de map, système de multijoueurs, etc...).

Dès que j'aurais plus de temps (= moins de projets en cours et moins de priorité), je m'attaquerai à son prototype  :;): .

----------


## Molina

> http://it-ebooks.info/
> 
> Tu as qques bouquins gratos ici, cherche "unity".
> ça te permet de cibler un bouquin, ensuite évidemment si tu le trouves bien achète le.
> 
> Personnellement je recommande celui là :
> http://www.amazon.fr/Pro-Unity-Game-...ords=pro+unity


Hmm, il dit en intro que c'est pour les "Pro" qui ont déjà de bonne base en C#. 

J'ai une question un peu concon. Comment qu'on sait si on va faire ramer notre jeu ? J'ai rajouté un sprite 2D dans un environnement 3D, issu des sprites déjà sur unity (le petit robot) et en enlevant les collider 2D et en lui rajoutant un collider 3D, Unity a commencé à ramer comme jamais.

----------


## Louck

Avec la version 5 d'Unity, tu as accès au Profiler, qui te donne pas mal d'infos sur l'utilisation des ressources proc/mémoires/gpu par ton jeu. Et donc d'avoir une idée de qui peut te faire rammer.

http://docs.unity3d.com/Manual/Profiler.html

Sinon, l'optimisation du jeu doit toujours se faire à la fin du projet  (sauf s'il subit une très grosse latence).

----------


## Grhyll

> J'ai une question un peu concon. Comment qu'on sait si on va faire ramer notre jeu ? J'ai rajouté un sprite 2D dans un environnement 3D, issu des sprites déjà sur unity (le petit robot) et en enlevant les collider 2D et en lui rajoutant un collider 3D, Unity a commencé à ramer comme jamais.


Alors ça manque un petit peu de précisions. Quand tu dis un Sprite 2D, c'est un SpriteRenderer ou une Image (système de UI) ? En fait ça me surprend pas mal, de ce dont je me souviens, Unity met simplement un message d'erreur quand on essaie de mélanger des scripts 2D/3D qui ne vont pas ensemble. Quant à ce que ça se mette à ramer pour ça, c'est étonnant :/ Tu as juste ça dans ta scène, rien d'autre ?

----------


## Djal

> Sinon, l'optimisation du jeu doit toujours se faire à la fin du projet  (sauf s'il subit une très grosse latence).


Ou alors tu applique le principe 4/1 qui est pas mal aussi. Pendant 4 jours tu développes les nouvelles features, sans te préoccuper de l'implémentation. Il faut que ça marche et c'est tout.
Le 5eme jour tu ne développes plus rien, tu optimises les features que tu viens d'implémenter. J'aime bien cette façon de faire elle permet de prendre du recul.

----------


## Louck

> Ou alors tu applique le principe 4/1 qui est pas mal aussi. Pendant 4 jours tu développes les nouvelles features, sans te préoccuper de l'implémentation. Il faut que ça marche et c'est tout.
> Le 5eme jour tu ne développes plus rien, tu optimises les features que tu viens d'implémenter. J'aime bien cette façon de faire elle permet de prendre du recul.


J'ai pratiqué cette méthode mais plutôt par mois (3 semaines de dev, 1 semaine de debug/peaufinement) sur deux de mes projets, dont un actuellement.
Le problème avec cette technique est que je reviens (trop) souvent sur ce que j'ai réalisé, à peaufiner et à appliquer des idées/retours jusqu'à plus en finir. Au bout d'un moment, j'avais l'impression que le projet stagner, à force de retravailler sur le moindre détail du jeu.
Au final, je perd un temps fou avec cette méthode de travail. Peux être que tu t'organises mieux de ton côté ?


Pour mon dernier jeu de plateforme (Punxel Agent), j'avais décidé d'avancer le projet selon un plan, et je prenais note des bugs et améliorations à faire pour plus tard. Quand le jeu était "terminé" (selon le plan), je ressortais mes notes et je m'organisais de nouveau pour améliorer les derniers éléments (la phase de "peaufinement", en gros).

Exception faite avec des idées ou features importantes (par exemple, l'idée de la musique passive/active selon la situation, proposée par le compositeur Bigju  :;):  ) ou des bugs très gênants. Je n'attend pas la fin pour les traiter  ::): .

En travaillant ainsi, je suis sûr de finir le projet dans les temps que j'ai fixé.
Mais ca reste ma propre méthode de travail.

----------


## Blasteguaine

> J'ai une question un peu concon. Comment qu'on sait si on va faire ramer notre jeu ? J'ai rajouté un sprite 2D dans un environnement 3D, issu des sprites déjà sur unity (le petit robot) et en enlevant les collider 2D et en lui rajoutant un collider 3D, Unity a commencé à ramer comme jamais.


Yep on peut avoir un screen de l'inspector de l'objet ? C'est quoi comme collider 3D (de mémoire il en existe quatre différents) ?
Mais ouais sinon profiler -> qu'est-ce qui bouffe autant de temps ?

----------


## Djal

> Peux être que tu t'organises mieux de ton côté ?


Je ne sais pas si c'est mieux mais en tout cas la règle c'est de s'imposer de ne faire que de l'optimisation ce jour là. Pas d'évolution de la feature, pas de paufinage. Le soir, d'un point de vue user, rien ne doit avoir changé par rapport à l'état de la feature le matin. Si tu vois une évolution possible, tu la notes et tu t'y colle la semaine d'après.

----------


## UndeadThings

J'ai une toute petite question, Unity, c'est en quel langage?  ::):

----------


## Djal

Au choix: Javascript, C# ou Boo

----------


## UndeadThings

Ah, du javascript, du coup Unity a un équivalent au WebGL?

Je vais peut-être me pencher sur ça.

----------


## Molina

> Avec la version 5 d'Unity, tu as accès au Profiler, qui te donne pas mal d'infos sur l'utilisation des ressources proc/mémoires/gpu par ton jeu. Et donc d'avoir une idée de qui peut te faire rammer.
> 
> http://docs.unity3d.com/Manual/Profiler.html
> 
> Sinon, l'optimisation du jeu doit toujours se faire à la fin du projet  (sauf s'il subit une très grosse latence).


Merci énormément ! 
Ca me fait un peu peur de voir passer mon FPS de 140 à 70 quand je rajoute trois ennemies avec IA sur une surface plane mais bon, on verra !



> Yep on peut avoir un screen de l'inspector de l'objet ? C'est quoi comme collider 3D (de mémoire il en existe quatre différents) ?
> Mais ouais sinon profiler -> qu'est-ce qui bouffe autant de temps ?


J'ai complétement zappé de regarder ça hier... (Et au boulot, là, c'est difficile de regarder  ::P: ) Après, en soi, ce n'est pas très important, j'ai fait ça à l'arrache, et pour l'instant je ne m'occupe pas trop de l'aspect cosmétique. 


Globalement, j'aime beaucoup unity. J'ai réellement l'impression de faire quelque chose de consistant par rapport à RPGMaker et de faire exactement ce que j'ai en tête  ::love:: . Seul bémol, c'est que je fais mes script en Javascript, en pratique c'est bien plus facile qu'en C#.
-J'ai fait un script d'animation d'épée (ça donne un coup de taille) + clic de souris qui enlève des dégats (je gère la distance d'attaque, le nombre de dégât et le DPS)
-Une boite de vie. 
-Une IA ennemie qui me remarque à 20 mètres, m'attaque à 15 mètres en fonçant sur moi et me fait des dégâts (du coup j'ai des cubes rouges qui me foncent dessus  ::ninja:: ) en m'enlevant de la vie.
-Quand l'ennemie meurt, son corps disparait (\o/)
-Un pistolet qui envoie des billes (bon, avec un changement de scène, mon script ne marche plus...). 

Pour la suite, j'hésite à me concentrer sur la partie plate forme (mais j'ai un peu regardé, c'est quand même galère de faire en sorte que le FPScontroller puisse marcher sur les murs à la PoP) ou la partir RPG (boite de dialogue, compétence). 

L'objectif final : Avoir un gameplay assez simple, et me concentrer sur les quêtes + apprendre à utiliser l'aléatoire et le procédural.  ::unsure::

----------


## JulLeBarge

C'est peut-être déjà passé, mais il y a un très bon cours sur Unity avec la mise en place de plateformer simple et les bons conseils ici:
http://openclassrooms.com/courses/re...deo-avec-unity

Je l'ai suivi et j'ai appris beaucoup de choses, ça m'a donné envie de faire un petit prototype de jeu à la DeadCore !

----------


## Poussin Joyeux

Sympa! Merci!

----------


## botu

Ca fait longtemps que je n'avais pas posté ici !

Voici une petite zone que je viens de commencer. Son nom est "The red lair".
Elle est realisee dans unity 5. Le modeling dans maya. Le sculpt dans mudbox. Ensuite je passe dans
Substance painter pour les textures. Les arbres sont du speedtree. 
L'arbre autour de l'auberge est fait dans speedtree modeler. 

Pour le shader terrain j'utilise toujours l'excellent RTP.
Voici une petite video de l'auberge encore WIP:

----------


## Djal

Magnifique.

----------


## Grhyll

Classe ! Tu fais ça pour un projet en particulier ?

----------


## UndeadThings

ça me fait penser à ça:

----------


## botu

Merci  ::): 

Je fais ça pour le plaisir.
J'en ai déjà réalisé plusieurs : https://www.youtube.com/playlist?lis...EC7Bb3E94bEW6G

----------


## Molina

> C'est peut-être déjà passé, mais il y a un très bon cours sur Unity avec la mise en place de plateformer simple et les bons conseils ici:
> http://openclassrooms.com/courses/re...deo-avec-unity
> 
> Je l'ai suivi et j'ai appris beaucoup de choses, ça m'a donné envie de faire un petit prototype de jeu à la DeadCore !


www.youtube.com/watch?v=xARemJhSW0k

Il y a lui aussi, je le trouve très clair et explique assez bien ses script. Mais il code en Javascript...

----------


## JulLeBarge

> Ca fait longtemps que je n'avais pas posté ici !
> 
> Voici une petite zone que je viens de commencer. Son nom est "The red lair".
> Elle est realisee dans unity 5. Le modeling dans maya. Le sculpt dans mudbox. Ensuite je passe dans
> Substance painter pour les textures. Les arbres sont du speedtree. 
> L'arbre autour de l'auberge est fait dans speedtree modeler. 
> 
> Pour le shader terrain j'utilise toujours l'excellent RTP.
> Voici une petite video de l'auberge encore WIP:


Super beau comme d'habitude !  ::love::  Unity 5 en a dans le ventre niveau graphismes, ça s'est bien amélioré !

De mon côté, j'ai créé un petit prototype de jeu de plateforme à la première personne inspiré (vaguement, j'y ai pas joué !) de Deadcore:


C'est très sommaire pour le moment, j'essaie de ne pas griller d'étape et de bien régler pour le moment le level design (c'est comme ça qu'on dit ?) de mon niveau. Le niveau n'est pas complet, c'est juste le début, et les scripts de mouvement sont à revoir, le air control est trop fort par exemple. J'ai fait ça en repartant des scripts donnés dans le cours dont je parlais ci-dessus. Je compte ajouter d'autres types de plateformes (notamment des mouvantes), des pièges, etc... J'aimerais bien intégrer aussi le double jump (pour remplacer les accélérateurs que j'ai posé pour le moment), mais va falloir que je sois plus à l'aise avec les scripts avant... Si je laisse pas tomber le truc trop vite, je ferai sans doute un topic devlog.

C'est dispo ici pour ceux qui veulent tester:
https://mega.nz/#!6AR1CarD!HimjTtMvF...o60sBvpnPPSIgs

Soyez indulgents, j'ai fait ça en 3 jours et je débute encore sous Unity !  ::rolleyes::

----------


## Djal

> C'est dispo ici pour ceux qui veulent tester:
> https://mega.nz/#!2V5BEA5a!Wq_d_4a5b...9AWsFz85HUhtaw


Tu n'as pas mis le fichier Data :lapintriste:

----------


## JulLeBarge

> Tu n'as pas mis le fichier Data :lapintriste:


Ah oui zut, c'est corrigé, voici le nouveau lien:
https://mega.nz/#!6AR1CarD!HimjTtMvF...o60sBvpnPPSIgs

----------


## Poussin Joyeux

Question: je veux créer un paysage avec des arbres qui ne tombent pas, comment fais-je? 
J'ai créé un arbre sous Blender (cylindre+cône) puis l'ai importé sous Unity. J'ai rajouté un rigidbody et un capsule collider. Le tout est posé sur un gros cube.
Le souci, c'est que quand mon perso fonce dans l'arbre, il tombe au bout d'un moment: très rapidement si je mets une petite valeur de masse dans le rigidbody de l'arbre mais même si je mets 10000 comme valeur de masse, il va tomber au bout d'un moment (et mon perso n'est pas censé être Musclor).
Il y a une astuce ou bien ma seule solution c'est de me passer du rigidbody? Ca m'embête car j'aimerais que cet arbre puisse tomber sous d'autres conditions...

Merci de votre aide!  :;):

----------


## schouffy

Tu peux avoir un rigidbody désactivé dessus, et l'activer lorsque ta condition est atteinte. C'est quoi ta condition ?

----------


## Poussin Joyeux

> Tu peux avoir un rigidbody désactivé dessus, et l'activer lorsque ta condition est atteinte. C'est quoi ta condition ?


Ma condition ce seront des débris projetés d'un volcan qui renverseront tout sur leur passage  ::P:  (je n'en suis pas encore là comme tu t'en doutes!). 
Donc je pourrai activer le rigidbody sur cette collision du coup.
Merci pour ton conseil, je ne savais pas qu'on pouvait activer/désactiver le rigidbody en dynamique!

----------


## schouffy

Tu peux activer/désactiver n'importe quel component dynamiquement.
Par contre, à tester, peut-être que l'activer au moment de la collision est trop tard car la collision à déjà eu lieu ?
Peut-être que tu devrais l'activer quand le volcan entre en éruption, ou avoir deuxième collider (as trigger) plus grand autour de l'arbre qui va activer le rigidbody de l'arbre quand un débris entre en contact.

----------


## Poussin Joyeux

Bien vu! Ca risque en effet d'être trop tard si je fais comme j'ai dit.
Je pense que je partirai sur ta 2eme solution (2eme collider as trigger) car je ne voudrai pas que le joueur renverse tous les arbres en fuyant le volcan en éruption!  ::): 
J'essaie d'implémenter ça ce week-end et je vous montrerai le résultat. Merci *schouffy* pour tes précieux conseils!

Edit: j'ai été optimiste en pensant implémenter tout ça durant le week-end. Ce sera pour un peu plus tard  ::P:

----------


## schouffy

De rien  :;):

----------


## Blasteguaine

Sinon tu mets deux objets : un sans rigidbody qui collisionne avec le personnage et un avec qui collisionne avec les débris. (et qui détruit/désactive le premier quand il reçoit une collision)
Mais je pense que simplement activer le rigidbody au moment où le débris percute peut fonctionner, c'est à tester. Sinon tu peux aussi activer le rigidbody ET appliquer une force dans ton script.

Autre solution : tu mets un "fixed joint" (ou un autre type de joint si tu veux que l'arbre puisse plier sans casser) entre ton arbre et le sol, et soit tu règles les paramètres qui le font casser soit tu le casses par script quand un débris le percute.

----------


## Molina

Salut ! 

C'est encore moi.. 

Dites moi, niveau performance, mieux vaut créer un objet (un immeuble par exemple) avec des gameobjects 3D d'unity (un empilement de cube par exemple), ou alors créer un bloc avec la forme que je veux avec blender et l'importer sur unity ? 

Désolé si la question vous parait bête....



PS: Putain,  le forum d'unity3D france... Toutes les questions sont répondues par "la fonction recherche existe". Et quand, effectivement on cherche, la première itération de la question a comme seule réponse "la fonction recherche existe".  Et quand le mec se fait chier à poster son script pour avoir de l'aide, il n'a aucune réponse.  ::XD::

----------


## Grhyll

A moins que tu ne comptes faire des scènes immenses ou que tu n'arrives pas à rester en-dessous des je-ne-sais-combien de polygones sur Blender, je ne crois pas que tu pourras vraiment constater un impact sur les performances. Après ça dépend aussi si tu veux que ce soit juste un placeholder pour développer, auquel cas un cube de Unity peut faire l'affaire ; ou si tu es plutôt du genre artiste 3D exigeant, auquel cas tu risques d'avoir du mal à t'en sortir avec juste les formes de base de Unity. Disons qu'on commence à se soucier des perfs quand des modèles sont vraiment très compliqués, a priori.

Sinon pour le forum de unity France j'ai jamais essayé, mais Unity Answer est quand même vraiment top je trouve, il y a énormément de questions répondues dessus, c'est génial.

----------


## schouffy

Niveau perfs, ça ne change pas grand chose, mais niveau emmerdement, utilises Blender. Sauf pour les placeholder comme dit Ghryll.
Si tu fais un immeuble avec des cubes Unity, tu pourras pas faire d'UV map, tu vas galérer à le texturer, lui affecter des matériaux etc..

----------


## JulLeBarge

> De mon côté, j'ai créé un petit prototype de jeu de plateforme à la première personne inspiré (vaguement, j'y ai pas joué !) de Deadcore:
> http://tof.canardpc.com/preview/65c1...241bd9eaf3.jpg
> 
> C'est très sommaire pour le moment, j'essaie de ne pas griller d'étape et de bien régler pour le moment le level design (c'est comme ça qu'on dit ?) de mon niveau. Le niveau n'est pas complet, c'est juste le début, et les scripts de mouvement sont à revoir, le air control est trop fort par exemple. J'ai fait ça en repartant des scripts donnés dans le cours dont je parlais ci-dessus. Je compte ajouter d'autres types de plateformes (notamment des mouvantes), des pièges, etc... J'aimerais bien intégrer aussi le double jump (pour remplacer les accélérateurs que j'ai posé pour le moment), mais va falloir que je sois plus à l'aise avec les scripts avant... Si je laisse pas tomber le truc trop vite, je ferai sans doute un topic devlog.
> 
> C'est dispo ici pour ceux qui veulent tester:
> https://mega.nz/#!6AR1CarD!HimjTtMvF...o60sBvpnPPSIgs
> 
> Soyez indulgents, j'ai fait ça en 3 jours et je débute encore sous Unity !


Hop, pour ceux qui veulent tester, voici une version webplayer de mon proto:
https://dl.dropboxusercontent.com/u/...form_test.html

----------


## Grhyll

Sympa, ça marche déjà bien  ::):  Par contre, trop d'inertie, je trouve, et trop de air control aussi ! Je suis arrivé au canon, sauf que je m'y attendais pas, j'ai instinctivement reculé un dixième de seconde après avoir été lancé, et hop retour au sol !

----------


## JulLeBarge

Oui je suis d'accord les contrôles ne sont pas au point, je suis reparti des scripts du cours que j'avais suivi mais je pense que je vais reprendre le FirstPersonController de base plutôt, ça sera plus propre.
Le canon est la première vraie difficulté, j'ai eu d'autres retours comme quoi l'ensemble était trop facile et ne proposait aucun challenge. En même temps c'est censé être le tout début du jeu, s'il faut s'y reprendre à 10 fois pour passer les 30 premières secondes, je risque de lasser le joueur.
Tu as trouvé ça compliqué ou trop simple ?

----------


## Molina

> Niveau perfs, ça ne change pas grand chose, mais niveau emmerdement, utilises Blender. Sauf pour les placeholder comme dit Ghryll.
> Si tu fais un immeuble avec des cubes Unity, tu pourras pas faire d'UV map, tu vas galérer à le texturer, lui affecter des matériaux etc..





> A moins que tu ne comptes faire des scènes immenses ou que tu n'arrives pas à rester en-dessous des je-ne-sais-combien de polygones sur Blender, je ne crois pas que tu pourras vraiment constater un impact sur les performances. Après ça dépend aussi si tu veux que ce soit juste un placeholder pour développer, auquel cas un cube de Unity peut faire l'affaire ; ou si tu es plutôt du genre artiste 3D exigeant, auquel cas tu risques d'avoir du mal à t'en sortir avec juste les formes de base de Unity. Disons qu'on commence à se soucier des perfs quand des modèles sont vraiment très compliqués, a priori.
> 
> Sinon pour le forum de unity France j'ai jamais essayé, mais Unity Answer est quand même vraiment top je trouve, il y a énormément de questions répondues dessus, c'est génial.


Merci à vous deux !

----------


## Poussin Joyeux

> Sinon tu mets deux objets : un sans rigidbody qui collisionne avec le personnage et un avec qui collisionne avec les débris. (et qui détruit/désactive le premier quand il reçoit une collision)
> Mais je pense que simplement activer le rigidbody au moment où le débris percute peut fonctionner, c'est à tester. Sinon tu peux aussi activer le rigidbody ET appliquer une force dans ton script.
> 
> Autre solution : tu mets un "fixed joint" (ou un autre type de joint si tu veux que l'arbre puisse plier sans casser) entre ton arbre et le sol, et soit tu règles les paramètres qui le font casser soit tu le casses par script quand un débris le percute.


Merci pour ton retour.  :;): 
J'en suis encore à placer mes arbres sur le terrain (je suis un peu distrait par tous ces jeux qui sortent en ce moment  ::rolleyes:: )
Je ne connaissais pas l'existence des "joint", ça peut être sympa en effet de permettre parfois à l'arbre de se plier sans se casser!

----------


## schouffy

Enfin une démo Unity qui a "vraiment" de la gueule :
http://www.rockpapershotgun.com/2015...d-reflections/

----------


## Poussin Joyeux

Ouais! Enfin une une vidéo où on se dit pas "tiens c'est du Unity ça"!
Ils disent que ce sera pour la prochaine version "majeure". A suivre!

----------


## Metalink

Comment ils se la jouent UE4 avec ses scènes photoréalistes qui font la hype tous les 2 jours sur le net  ::P: 
Sinon pour savoir quoi sort quand : http://unity3d.com/unity/roadmap

Ce qui me permet de remarquer que l'utilisation des tiles en 2D a été repoussé à juin  :tired:

----------


## Black Wolf

Ils sont drôles ils sortent une demo pour faire la promo de leur feature de SSRR en disant bien que c'est prévu pour la 5.3, et en même temps ils updatent la roadmap pour dire que ça sera retardé pas dans cette release...

----------


## schouffy

ils ont dit next major non ? Donc Unity 6 ? Oo

----------


## Adu

Vivement d'autres améliorations (dont le 2D Tileset) parce qu'ils ont fait des efforts, mais je fais un jeu via GameMaker en 2D quand même carrément plsu vite que sous Unity  ::(:

----------


## Grhyll

Je sais pas si on peut vraiment comparer les deux :D

----------


## Black Wolf

Non non le SSRR était prévu pour la 5.3 qui sort en décembre, mais la ils viennent de le passer dans la roadmap en "retardé" mais ils parlent de le sortir en tant que module indépendant en version beta en attendant. Pour les tiles c'est en effet prévu pour la 5.5 en juin seulement  ::(:  Bon en attendant il y a toujours le plugin 2D Toolkit qui avait un truc pas trop trop mal pour gérer les tiles.

----------


## Adu

J'ai profité des promos pour acheter Playmaker, et omg .... que ce plugin fait gagner du temps pour tester des trucs sans se prendre la tête avec du code  :WTF: 
Je le recommande à tous (quand il est en promo)

----------


## Grhyll

Ouip c'est un bon plugin en effet ! A noter que même pour certaines features finales il peut être utilisé ; triggerer quelque chose quand le joueur franchit un collider, faire bouger des éléments du décors sous certaines conditions simples... Bon, la promesse de faire un jeu entier sans une ligne de code est un peu exagérée, mais ça reste un très bon outil, pour le prototypage comme pour le jeu propre lui-même  ::):

----------


## Adu

Après faut voir le jeu, mais pour un shoot'em up ou un jeu de plateformes, je tape pas de lignes de code (faudra juste que je vois si je craque pour le plug in BulletML qui m'a l'air parfait pour le shoot de furax que j'ai envie de me faire  ::P:  )

----------


## Djal

> J'ai profité des promos pour acheter Playmaker, et omg .... que ce plugin fait gagner du temps pour tester des trucs sans se prendre la tête avec du code 
> Je le recommande à tous (quand il est en promo)


J'étais vachement partisan aussi, on en avait débattu avec un canard ici. Mais ça devient vite un sac de noeud. Mais c'est bien. Mais gaffe. L'autre canard avait raison  ::ninja::

----------


## Adu

D'ailleurs petite question. J'ai des assets d'images, de sprites etc que j'ai acheté sur le Store (oui je suis une tanche en GFX donc je préfère acheter des assets qui me plaisent pour ce que je fais).
Est-ce que j'ai moyen de les extraire pour m'en servir dans d'autres logiciels ?

----------


## Louck

Tu peux accéder à tes assets directement dans le répertoire de ton projet, via l'explorateur.
Si ce n'est pas le cas, est-ce que tu peux nous dire quelle extension ces fichiers utilisent ?

Par contre, je ne m'avancerai pas d'un point de vue légal (pour un projet non commercial, ca devrait aller).

----------


## Roscopolo

Sur le plan légal pas de pb du côté de Unity, en revanche la licence de l'éditeur des assets peut contenir des restrictions.

Par ailleurs les coordonnées de texture sont souvent chelous avec les modèles du store, et inutilisables avec certains logiciels. Et évidemment le code, les shaders et les scènes sont spécifiques à Unity.

----------


## Adu

Ce sont juste des assets avec des PNG dedans ... Des tilesets en PNG, rien d'autres.
En fait voilà, j'ai cet asset là que j'adore : https://www.assetstore.unity3d.com/en/#!/content/36123 et je souhaite me faire pour mon délire un petit metroid-like. Par contre, j'ai 1000x plus l'habitude sous GameMaker Studio, et donc pour tester des trucs/prototyper des idées ça va bcp bcp plus vite pour moi (et pour ma beta-testeuse qu'est ma femme). C'est pour cela que j'aimerai tester en utilisant les PNG contenus dans l'asset (asset qui ne contient d'ailleurs que ça).
Et je n'ai pas trouvé de restrictions m'empêchant de m'en servir dans un autre logiciel.

EDIT : bon je viens de passer la nuit (au boulot  ::ninja:: ) à me taper des tutoriels Youtube plutôt bien foutus, je vais passer totalement sous Unity + PlayMaker, au moins j'aurai pas de soucis pour me servir des assets. Je laisse néanmoins ma question ouverte, pour l'import/utilisation de tilesets en PNG dans d'autres moteurs de jeu.

----------


## Grhyll

> Sur le plan légal pas de pb du côté de Unity, en revanche la licence de l'éditeur des assets peut contenir des restrictions.


Je pense que tu peux considérer ta question comme étant fermée  ::):

----------


## botu

Mes catacombes en cours de construction :

----------


## Louck

Magnifique  ::): .

----------


## botu

merki :D

----------


## Louck

D'ailleurs, tu n'avais pas besoin de quelqu'un pour coder le déplacement d'un protagoniste dans tes créations ?

----------


## botu

Pour les deplacements j'utilise l'asset de base de unity ( first person controler). (ou dans ce cas-ci, un simple mouvement de cam)
Pour le moment, j'utilise unity que pour creer des environnements mais j'ai envie, un jour, d'aller en peu plus loin et avec la
cooperation d'un codeur, integrer des elements de gameplay (j'ai une idee de jeu qui pourrait etre amusante, et en plus qui fonctionnerait bien avec un casque vr).

----------


## Louck

A voir tes besoins après oui  ::): . Perso je suis bien occupé, mais ca ne me dérangerait pas d'aider un petit peu (sauf si c'est trop gros pour moi  ::P: ).

----------


## Grhyll

Waou classe en effet :D

----------


## botu

Rien de "gros" , en tout cas pour une maquette de jeu. Apres, vu que programme tres tres peu, c'est peut-etre plus de boulot que je pense  ::):

----------


## Myron

Ça a vraiment de la gueule. Beau boulot.  ::):

----------


## Poussin Joyeux

Très joli décor (comme toujours)! Bravo!

----------


## botu

merci !
Tiens, avez-vous un probleme de framerate avec la video, comme si il y avait du lag (sur la brume par exemple)
A propos de la brume/fog. Vous en pensez quoi ? A supprimer absolument / a revoir en partie ou bien a garder?

----------


## Poussin Joyeux

Oui pour la brume, je la voyais avancer par à coups (comme si chaque mouvement du brume était cadencé à la seconde par exemple). Ca ne le faisait pas avec le reste du décor.
Je me suis dit que c'était des soucis de temps de processing. Ca ne te le fait pas sous Unity, c'est que dans la vidéo?

----------


## Grhyll

Aucun problème de framerate chez moi, elle est toute jolie cette brume  ::):  Par contre elle va un peu vite je trouve, je l'aurais vu plus lente. (Et aussi ça fait un peu bizarre qu'il n'y en ait pas juste devant la caméra, mais seulement un peu plus loin.)


Hop je vous partage un petit article de ma composition sur les allocation de garbage en C# sur Unity, pour ceux que ça pourrait intéresser ! Je vais essayer de le faire tourner un peu sur le net ce soir, mais Canard PC l'a en exclusivité au cas où vous auriez des remarques judicieuses sur comment l'améliorer  ::P: 
http://3-50.net/reducing-memory-allo...ge-collection/

----------


## Hyperpenguin

Je m'y connais assez peu encore en unity mais je programme sur des systèmes embarqués, tout ça me parle. Très intéressant.

----------


## botu

> Oui pour la brume, je la voyais avancer par à coups (comme si chaque mouvement du brume était cadencé à la seconde par exemple). Ca ne le faisait pas avec le reste du décor.
> Je me suis dit que c'était des soucis de temps de processing. Ca ne te le fait pas sous Unity, c'est que dans la vidéo?



oui, c'est a cause de la compression youtube. Chez certains le fog semble saccadé et chez d'autres c'est nickel. Etrange...

----------


## Grhyll

> Je m'y connais assez peu encore en unity mais je programme sur des systèmes embarqués, tout ça me parle. Très intéressant.


Merci  ::): 
Mon article a été featuré sur Gamasutra, le rêve de toute une vie (pour moi)  ::lol::

----------


## Poussin Joyeux

Ouah la classe ! La gloire !

----------


## Grhyll

Mais tellement  :^_^:  Je me roule dans des billets de monopoly depuis ce matin !

----------


## Hyperpenguin

Et bah PAF en favori pour quand je voudrais optimiser un jeu pour de l'android.

----------


## Gafda

Dites, quelqu'un a déjà testé une base SQL+Unity3D ?

----------


## Kupris

Vous auriez un site/e-book à conseiller pour débuter sur Unity3D ?

----------


## Gafda

> Vous auriez un site/e-book à conseiller pour débuter sur Unity3D ?


http://unity3d.com/learn

----------


## Roscopolo

Pas mieux : leur docu est sans doute la meilleure qui soit (loin d'être parfaite mais par rapport aux coutumes du milieu c'est déjà du luxe).

----------


## Adu

Bon, petit retour après un petit moment d'utilisation de PlayMaker ...
Ben en fait je vais rester sans  ::P: 
Au final, pour moi qui ne fait que de la 2D, je me rends compte qu'en le scriptant, je vais des fois plus vite que penser au cas et à la mise en place via PM, les States etc ...
Et à corriger des bugs, c'est limite plus visuel pour moi en C# que débugguer une FSM ....
Bon plugin malgré tout, mais bon, je vais plutôt tout faire moi-même dorénavant  ::):

----------


## Ravine

> Merci 
> Mon article a été featuré sur Gamasutra, le rêve de toute une vie (pour moi)


J'en ai profite pour le lire et j'ai tilte quelques trucs.

_.Equals()_ allocate parce que _Vector3_ est une struct, donc value type. Comme Equals() n'est pas overriden, et que c'est une methode d'_object_, le code derriere est compile pour appeler une methode sur une reference; il a donc besoin de creer une reference temporaire, et tu te retrouves a faire du boxing sur ton vector3.
En revanche, l'operateur == est overriden, donc tu peux l'utiliser sans probleme de performance (pas moyen de verifier tout de suite, mais je suppose que l'override est une comparaison membre a membre). http://docs.unity3d.com/ScriptRefere...erator_eq.html

J'ai check sur les rules de Gendarme, et je n'ai rien vu sur la detection de ce genre de trucs. C'est con, ca serait pratique. 

C'est un chouette post mais avoir quelques code snippets pour illustrer les differents points aurait ete un plus plutot cool. Voila, my 2 cents.




> Dites, quelqu'un a déjà testé une base SQL+Unity3D ?


Check du cote de SQLite, c'est une db serverless qui dispose d'un binding C#, donc qui fonctionne tres bien dans ce contexte. Une recherche rapide sur Google renvoit pas mal de resultats. Ta question est tres vague et generale donc je ne vois pas trop comment repondre plus en detail. En esperant que ca aide tout de meme.

----------


## Gafda

> Check du cote de SQLite, c'est une db serverless qui dispose d'un binding C#, donc qui fonctionne tres bien dans ce contexte. Une recherche rapide sur Google renvoit pas mal de resultats. Ta question est tres vague et generale donc je ne vois pas trop comment repondre plus en detail. En esperant que ca aide tout de meme.


Merci  ::lol:: 
J'avais vu SQLite sur le ternet, mais vu qu'il y a des DB à la pelle je n'étais pas sûr. 
J'ai en fait une grille qui compose l'air de jeu, et chaque case de la grille comporte des variables genre entiers, flottants, items, renderer, etc.. et le truc c'est que le jeu n'utilise pas toutes les cases en même temps, donc j'avais pensé à faire du dump ou utiliser un DB pour enlever les objets inutiles/inutilisés de la RAM. 
Parce qu'en fait une grille de 200x200 ça consomme pas mal et je ne sais pas comment optimiser le bousin
Bon après c'est vrai que je n'ai aucunes connaissances en optimisation avec le C# et Unity... C'est plus facile en C++  ::(:

----------


## Ravine

Hors consideration des langages ou des plateformes, ne pas faire le boulot ou ne pas charger les data est la meilleure facon de gagner du temps ou de la place. La DB est une possibilite. Utiliser des fichiers textes est aussi faisable (genre chaque coordonnee pointe sur un fichier, et tu ne le charges que quand tu es a une certaine distance). Y'a plein de facon d'approcher le truc a haut niveau sans se bloquer psychologiquement sur la plateforme.

(L'important c'est d'aborder le probleme d'une facon qui t'es confortable et qui te donne satisfaction)

----------


## Gafda

> Hors consideration des langages ou des plateformes, ne pas faire le boulot ou ne pas charger les data est la meilleure facon de gagner du temps ou de la place. La DB est une possibilite. Utiliser des fichiers textes est aussi faisable (genre chaque coordonnee pointe sur un fichier, et tu ne le charges que quand tu es a une certaine distance). Y'a plein de facon d'approcher le truc a haut niveau sans se bloquer psychologiquement sur la plateforme.
> 
> (L'important c'est d'aborder le probleme d'une facon qui t'es confortable et qui te donne satisfaction)


Pas idiot le coup des fichiers txt. Je n'y avais pas pensé  :tired: 

C'est vrai qu'il y a toujours un paquet de solutions et on ne pense pas souvent à toutes les explorer.

----------


## Zevka

> Pas idiot le coup des fichiers txt. Je n'y avais pas pensé 
> 
> C'est vrai qu'il y a toujours un paquet de solutions et on ne pense pas souvent à toutes les explorer.


Surtout qu'à vue de nez, tu dois pouvoir décomposer ta grille de 200 * 200 en sous-grille, de genre 10 * 10, et ensuite créer des fonctions de serialisation pour ces dernières, si tu passes par des simples fichiers après c'est super rapide vu que l'indexation se fait dans le nommage desdits fichiers. L'avantage c'est que tu dois pouvoir faire ça de manière vachement souple si tu veux changer la taille pour optimiser au mieux (ou à la volée ?), et tu as pas besoin de gérer un DLL externe pour ta base SQL.

J'imagine que tu est tributaire du système de fichier si tu commences à avoir une liste longue comme le bras de fichiers, et là l'utilisation d'une base de données sera surement plus efficace.

Tu as déjà créer ou instanciés des Gameobjects de manière procédurale ?

----------


## Grhyll

> J'en ai profite pour le lire et j'ai tilte quelques trucs.
> 
> _.Equals()_ allocate parce que _Vector3_ est une struct, donc value type. Comme Equals() n'est pas overriden, et que c'est une methode d'_object_, le code derriere est compile pour appeler une methode sur une reference; il a donc besoin de creer une reference temporaire, et tu te retrouves a faire du boxing sur ton vector3.
> En revanche, l'operateur == est overriden, donc tu peux l'utiliser sans probleme de performance (pas moyen de verifier tout de suite, mais je suppose que l'override est une comparaison membre a membre). http://docs.unity3d.com/ScriptRefere...erator_eq.html
> 
> J'ai check sur les rules de Gendarme, et je n'ai rien vu sur la detection de ce genre de trucs. C'est con, ca serait pratique. 
> 
> C'est un chouette post mais avoir quelques code snippets pour illustrer les differents points aurait ete un plus plutot cool. Voila, my 2 cents.


Han, merci, intéressant  ::):  Et bon à savoir, quelqu'un m'avait posé la question du pourquoi, je n'ai pas su répondre ! (Bon, en même temps je ne suis pas du tout spécialiste quand on descend trop bas dans les langages...)

Pour les extraits de code, j'ai un peu hésité, je dois dire :/

----------


## Ravine

> Han, merci, intéressant  Et bon à savoir, quelqu'un m'avait posé la question du pourquoi, je n'ai pas su répondre ! (Bon, en même temps je ne suis pas du tout spécialiste quand on descend trop bas dans les langages...)


J'ai ete repondre la bas aussi  ::):  (je suis tombe sur le post completement par hasard  :^_^:  , mais comme c'est plus technique la bas, j'ai ete un peu plus dans le detail)

----------


## Grhyll

Tu as bien fait ^^

----------


## Gafda

> Tu as déjà créer ou instanciés des Gameobjects de manière procédurale ?


C'est déjà instancié, cependant c'est ça le problème. Sérialiser des objets simples ça va, mais sérialiser un objet qui contient des composants Unity là pour le coup ça semble assez compliqué à mettre en place. Après, rien ne m'empêche de recréer les composants à partir des données sauvegardées, mais il faut alors se poser la question "Est-ce performant de toujours détruire et recréer des GameObjects?"

----------


## Ravine

http://www.archmagerises.com/news/20...ion-in-unity-c
http://forum.unity3d.com/threads/ser...gapost.155352/
et 



Bonne lecture, et bon visionnage.  :^_^:

----------


## Grhyll

Beh si j'ai bien compris, les prefabs sont là pour ça  ::): 
Tu as ton objet "type" en prefab, tu as une pool d'instances inactives, et dès que tu as besoin d'un, hop tu l'actives, tu l'initialises avec tes data, il se met à jour, et c'est parti \o/

Edit: Ravine, trop rapide pour moi ^^' Je suis fan du Megapost des best practices sur la serialization, j'y ai déjà étalé ma bêtise et mon ignorance deux ou trois fois :P

----------


## Gafda

Owai merci  ::lol::

----------


## Hyperpenguin

Hein salut, petite question, dans unity, y'a un façon simple de creer un espace sur une partie de l'ecran, et d'y charger le contenue d'une scène ou du moins une vu de la scène? En fait carrément un écran splitté finalement, mais ou l'on pourrait charger dynamiquement des trucs. Je sais pas si c'est très clair. C'est pour faire apparaître des mini-jeux différent sur une partie de l'écran.

----------


## Gafda

Tu peux mettre 2 caméras et changer le Viewport Rectangle pour avoir plusieurs "trucs"

----------


## Adu

D'ailleurs c'est pas comme ça qu'on fait pour un GUI et avoir une minimap en surimpression ?

----------


## Hyperpenguin

Actuellement on procédé comme suit: on a nos mini-jeu dans une scène séparé, et on fait un loadsceneadditive en rentrant et en scalant les objets comme on veut. J'ai des décalages un peu bizarre et je voulais savoir s'il y avait plus simple/ propre.

----------


## schouffy

Met tout sur la même scène en éloignant bien les différents éléments, et met 2 caméras ouais. C'est la bonne méthode je pense.

----------


## Grhyll

Pas forcément besoin d'éloigner les éléments, avec les culling mask ça peut même être complètement superposé  ::):  (C'est généralement le cas de la UI.)

----------


## Metalink

Ptite question Unity : j'ai fais une appli toute conne avec une image qui balance un son quand on clique dessus (avec le système d'UI), mais dès que je compile un .apk il fait 20 mo, une idée de comment optimiser un peu ça ?

----------


## Grhyll

Tu passeras pas en-dessous d'un poids minimum avec une build Unity hélas :/ Je suis pas certain qu'il y ait moyen de vraiment passer sous la barre des 20mo, à moins de faire des trucs bizarres de sorcellerie :/

----------


## Metalink

J'imagine bien que ya les libs de base d'Unity mais quand même, je trouve ça énorme 20mo en fait ...

----------


## schouffy

Ben le truc c'est que pour faire une appli qui lance un son quand tu clic sur une image, Unity c'est un très mauvais choix  :^_^: 
Tu as très exactement pris un rouleau compresseur pour étaler une pâte a pizza.

----------


## Metalink

Ah oui non clairement l'aurait mieux vallu le faire en natif.
Mais c'est juste que j'ai fait une jam sous Unity le WE dernier et je voulais "tester" vite fait l'export Android avec une application débile  ::P: 

Edit : tiens je vais essayer avec GameMaker pour voir si c'est aussi simple (j'y crois pas trop) et moins lourd (je pense)

----------


## schouffy

Je crois que sous Android tu peux atteindre une dizaine de Mo (j'avais fait un jeu avec quelques textures dedans qui en faisait 15). Check les architectures compilées, parfois  il y en a plusieurs et c'est inutile (enfin y'a très peu de Android pas ARM).
https://www.reddit.com/r/Unity3D/com...e_for_android/
Mais pas moins.

- - - Mise à jour - - -

Tiens j'en profite pour poser une question.
Est-ce que vous connaissez une façon "efficace" de raycaster un objet mais vers "n'importe où dans le collider", pas juste vers le centre. Un schéma comme c'est pas clair :



A gauche, c'est le comportement de base, je raycast depuis moi vers l'ennemi. Comme y'a un mur entre, je ne vois pas l'ennemi.
A droite, c'est un comportement plus précis car si je ne vois pas le centre de l'ennemi mais une autre partie du collider, je le vois quand même. Mais faudrait matraquer de raycast pour faire ça. Est-ce qu'il existe une méthode plus "efficace" ?

----------


## Louck

J'ai le même problème sur mon projet, sachant que je pratique *très* souvent le raycasting (pour l'IA). Ce qui est très coûteux.

Je n'ai pas eu le temps d'y réfléchir pour une solution à ce problème.
Par contre j'avais essayé d'utiliser un triangle au lieu de plusieurs raycasts pour tester, mais c'était pire  ::P: .


Une chose que tu peux faire, c'est déjà limiter le nombre de raycasts par 4 par entité, en ne visant que les recoins de la zone de collision (top-left, top-right, bottom-left, bottom-right). Ensuite, tout dépend de la précision que tu veux apporter à ton test (par exemple en rajoutant un raycast au centre, au cas où si l'entité peut se retrouver derrière un trou)  ::): .

----------


## Sahnvour

Tu peux calculer la projection de ton objet sur un plan 2D vu depuis ta camera (ou autre) et sampler plusieurs directions qui tombent dedans ?
Unity a peut-être un moyen de faire ça en prenant en compte l'occlusion culling, ou avec des tricks obscurs à base de stencil buffer et compagnie.

----------


## Gafda

Si c'est en 2D tu peux repérer les coins de ton sprite/objet (.Sprite.bounds) et faire un raycast uniquement sur ces points. L'idéal serai de récupérer ça sous forme de rectangle (4points + le milieu à la rigueur)
De plus, si tu es dans une grille alors là tu peux utiliser le rectangle précédent et regarder si la droite tracée passe par la case que tu désire "voir", donc plus besoin de raycast, juste des vecteurs suffisent.

Autre solution, tu traces un cône, et tu regardes si ta case est dans ce dernier. Relativement efficace dans une grille carrée

----------


## schouffy

Je vois, y'a pas de méthode miracle quoi.
Je vais partir sur 3 raycast (un au milieu, un à droite, un à gauche). Ce n'est pas parfait car si par exemple il y a des piliers ou barreaux entre moi et le méchant, il peut ne pas me voir.
Si je trouve une meilleure façon je raconterai ici.

----------


## Gafda

> Je vois, y'a pas de méthode miracle quoi.
> Je vais partir sur 3 raycast (un au milieu, un à droite, un à gauche). Ce n'est pas parfait car si par exemple il y a des piliers ou barreaux entre moi et le méchant, il peut ne pas me voir.
> Si je trouve une meilleure façon je raconterai ici.


Je suis intéressée si t'as une meilleure méthode  :;):

----------


## Ravine

En terme d'optim, la regle numero 1 c'est: la facon de faire quelque chose le plus rapidement possible est de ne pas le faire.

Donc toujours essayer de penser son probleme d'une maniere globale, d'eliminer les cas les plus courants le plus rapidement possible et rafiner petit a petit.

@Louck
pour l'IA:
- le faire toutes les X millisecondes plutot qu'a chaque frame. Je partirai sur un truc du style "AI Frequency", qui est une propriete qui peut varier (ca te permet de regler ca en testant avec tes data et ton contexte). Genre 30hz d'update c'est un tick d'AI toutes les 33ms. C'est peut etre un peu too much
- faire un tick en fonction de la distance. Plus tu es loin du point of interest (le joueur?), moins tu as besoin d'update. Ca regle aussi le probleme de detection. Si tu es en dehors du detection range, hop, pas d'update de visibilite.
- faire des groupes pour update tes AI en asynchrone. Genre 5 groupes qui s'update chacune leur tour. Au lieu d'update toutes tes AI a chaque frame, tu en update 1/5eme.

pour la visibilite, grosso modo les memes trucs.
- On degrossit sur la distance: un SquareMagnitude des 2 positions devrait te dire si ce que tu essaies de voir est dans ton visible range/degrossit sur le frustum view (aucune idee lequel est le plus simple/rapide. Intuitivement je dirais la distance)
- uen premiere passe avec un volume de detection (si tu n'as pas acces au frustum). Tu peux avoir un trigger collider attache au game object, et avoir un trigger collider sur ton "detecteur". Si l'un declenche l'autre, il s'ajoute a une liste des "objets a verifier plus finement si je peux les voir".
- Avec les quelques objets a verifier qu'il te reste, l'approche des raycast decrite plus haut fonctionne bien. Regarde quels sont tes cas de detection les plus courants, et traite les dans cet ordre. Un early return vaut mieux que de checker tous les raycasts et decider a la fin. Par exemple, on note Player Transform Position vs Target Transform Position. Si ca hit, return true. Si non, check Target Position + Up offset (le top edge de la collision box/capsule/whatever), si oui, return true, si non, etc.

Ne pas oublier que les RayCast peuvent gerer les layers. Vous pouvez definir votre grille comme "SeeThrough" et ignorer les objets qui appartiennent a cette categorie dans votre detection.

Apres je vous balance ca comme ca, je n'ai aucune idee de votre contexte, si vous etes en 2d/Top Down, en FPS, en 3rd person, etc.

----------


## schouffy

> Ne pas oublier que les RayCast peuvent gerer les layers. Vous pouvez definir votre grille comme "SeeThrough" et ignorer les objets qui appartiennent a cette categorie dans votre detection.


A propos de ça, je suis amoureux du type LayerMask et son rendu dans l'inspecteur <3
Pour le reste, je suis content de voir que je n'ai rien "raté" dans le sens où j'ai envisagé tout ce que tu mentionnes.
Les opérations "toutes les X millisecondes" plutôt que chaque frame, j'en use et abuse grâce aux WaitForSeconds des coroutines. Je ne sais pas quel impact à a sur les perfs par contre, ni sur l'allocation mémoire (cf blog post de Ghryll où il semblait dire que les coroutines GC à fond).

----------


## Ravine

Faut "optimiser" quand c'est necessaire. L'important c'est de generer les bonnes data, et que le code soit maintenable. Y'a une chouette video sur l'optim, et le mec a des reflections super importantes, dans le sens ou on donne la responsabilite de la performance au code, alors que c'est partage entre le code, le hardware, et *les data*

----------


## Grhyll

Après ça dépend aussi pas mal de là où tu es bottleneck ! Moi j'en suis arrivé à faire la chasse aux allocs pour mon jeu mobile parce que ça faisait des sautes de fps, mais le jeu PC/PS4 sur lequel je travaille avec ma boîte, on serait plutôt inclinés vers les performances. Comme dit plus ou moins Ravine (c'est comme ça que j'interprète en tout cas ^^), y a un juste milieu à trouver, et passer des heures à chercher la petite bête risque de ne pas toujours être très rentable (à tous les niveaux) !
Du coup, si tu n'as pas de soucis de garbage actuellement, continue sans hésiter avec tes coroutines si tu es à l'aise avec et qu'elles ne posent pas de problème ; et si un jour tu t'aperçois qu'elles posent soucis (peu probable si tu ne vises pas le mobile), tu pourras éventuellement y faire quelque chose  ::):

----------


## Louck

> @Louck
> pour l'IA:
> - le faire toutes les X millisecondes plutot qu'a chaque frame. Je partirai sur un truc du style "AI Frequency", qui est une propriete qui peut varier (ca te permet de regler ca en testant avec tes data et ton contexte). Genre 30hz d'update c'est un tick d'AI toutes les 33ms. C'est peut etre un peu too much
> - faire un tick en fonction de la distance. Plus tu es loin du point of interest (le joueur?), moins tu as besoin d'update. Ca regle aussi le probleme de detection. Si tu es en dehors du detection range, hop, pas d'update de visibilite.
> - faire des groupes pour update tes AI en asynchrone. Genre 5 groupes qui s'update chacune leur tour. Au lieu d'update toutes tes AI a chaque frame, tu en update 1/5eme.


A l'exception d'exécuter le code en asynchrone, j'ai déjà mis en place un timer et une limitation sur la distance du raycast  :;): .

Mon vrai problème par contre, c'est que j'invoque trop le raycast pour tester un peu tout et n'importe quoi. Je pense qu'il y a moyen de limiter l'utilisation en réfléchissant un peu plus à ce que je fais.

Sinon, je pensais simplement à faire du caching pour enregistrer le résultat d'un traitement que je répète un peu trop souvent (et qui sera renouvelé par un timer beaucoup plus important).

----------


## schouffy

Quand tu vois des trucs comme Left 4 Dead 2 qui mitraillent de raycast pour chaque zombie, parfois tu te dis que t'es large quand même  :^_^:

----------


## Louck

Je pense surtout qu'ils ont un système de pathfinding beaucoup plus simple que le mien  ::P: .

----------


## Molina

Bon salut les canards. 

J'avais déjà commencé un prototype, avant mon cambriolage, et je compte m'y remettre depuis le début vu que ça y' est je suis stabilisé professionnellement ( et que j'ai acheté un ordi). 

Je voudrais savoir si mon projet est faisable pour une seule personne ou si je vise trop haut.  En gros, je voudrais faire un jeu à la delver (http://www.delvergame.com/)   plus porté sur le RP que l'action, avec feuille de stat, ouverture d'une box avec choix  multiple pour certaines actions ( par exemple : ouverture de porte verrouillées  -> la défoncer, crocheter, mettre le feu;  ce genre de chose) et boîte de dialogue. 
Le tout dans une seule et même ville. 

J'ai plutot l'impression que le facteur limitant sera les sprites 2D plutôt que le codage mais je peux me tromper.

----------


## Grhyll

Ca dépend de la taille de ta ville, et ça dépend du temps que tu es prêt à y investir  ::):  Techniquement c'est faisable, si tu as la motivation et que tu parviens à la garder d'un bout à l'autre, mais ça a l'air d'être pas mal de boulot quand même !

----------


## Louck

A première vue, c'est surtout un jeu qui a beaucoup de contenu (objets, monstres, décors, sprites, etc...).

Après si tu veux te faire une idée si c'est un très gros boulot ou non, tu peux déjà lister les fonctionnalités que tu veux intégrer dans ton jeu: système de combat, équipement, magasin, et j'en passe.


A partir de là, tu auras déjà une petite idée de ce qu'il faut coder pour ton jeu... pour produire un prototype  ::P: . Avec un peu plus de travail, tu finiras par produire ta première version alpha de ton jeu.

Mais ce n'est que la version alpha  :;): .
Tout dépendra ensuite de ton objectif (si c'est produire un tout petit jeu, même un peu bugué, ou quelque chose de plus gros) et à quel point tu veux peaufiner ton bébé.

----------


## Grhyll

J'ai publié un nouveau blog post qui illustre quelques techniques pour créer ses outils editor pour Unity, avis bienvenus !
http://3-50.net/make-your-tools-in-unity-editor/

----------


## schouffy

Grhyll je suis tombé sur ton article ajd, félicitations !!

http://gamasutra.com/blogs/GrhyllJDD...ity_editor.php

----------


## Grhyll

Yay il a été partagé sur les réseaux sociaux (comme celui d'avant d'ailleurs) \o/ Je suis kontan  :^_^:

----------


## Poussin Joyeux

Hier j'ai joué à *Braid* et quelques temps avant à *Life is Strange*. Et ces deux jeux permettent de remonter le temps en conservant les actions du reste de l'environnement. 
Savez-vous comment c'est géré ce genre de trucs? 

Parce que s'il faut sauvegarder tous les déplacements de tous les objets en permanence, ça peut faire une tonne de variables en mémoire... 

Dans le cas de *Life is Strange*, on n'a pas tout le temps la possibilité de revenir en arrière donc ça limite la charge. Par contre sur *Braid* (et aussi *les mésaventures du Professeur Winterbottom* si je me rappelle bien), il n'y a pas de limite et on peut revenir dans le passé aussi loin qu'on le souhaite...

----------


## Molina

> A première vue, c'est surtout un jeu qui a beaucoup de contenu (objets, monstres, décors, sprites, etc...).
> 
> Après si tu veux te faire une idée si c'est un très gros boulot ou non, tu peux déjà lister les fonctionnalités que tu veux intégrer dans ton jeu: système de combat, équipement, magasin, et j'en passe.
> 
> 
> A partir de là, tu auras déjà une petite idée de ce qu'il faut coder pour ton jeu... pour produire un prototype . Avec un peu plus de travail, tu finiras par produire ta première version alpha de ton jeu.
> 
> Mais ce n'est que la version alpha .
> Tout dépendra ensuite de ton objectif (si c'est produire un tout petit jeu, même un peu bugué, ou quelque chose de plus gros) et à quel point tu veux peaufiner ton bébé.


C'est bien ce dont j'avais peur. 

J'ai trouvé une graphiste qui serait partante par l'univers. Elle fera surtout le concept art (pourquoi pas, c'est gratuit..) et quelques sprites. En fait, pour avoir fait l'inventaire faudrait que je termine vite fait le coté programmation pour me concentrer uniquement sur le remplissage... 

Merci en tout cas pour ton avis !

----------


## schouffy

> Hier j'ai joué à *Braid* et quelques temps avant à *Life is Strange*. Et ces deux jeux permettent de remonter le temps en conservant les actions du reste de l'environnement. 
> Savez-vous comment c'est géré ce genre de trucs? 
> 
> Parce que s'il faut sauvegarder tous les déplacements de tous les objets en permanence, ça peut faire une tonne de variables en mémoire... 
> 
> Dans le cas de *Life is Strange*, on n'a pas tout le temps la possibilité de revenir en arrière donc ça limite la charge. Par contre sur *Braid* (et aussi *les mésaventures du Professeur Winterbottom* si je me rappelle bien), il n'y a pas de limite et on peut revenir dans le passé aussi loin qu'on le souhaite...


Pour le joueur, oui tout est sauvegardé je pense.
Pour les autres éléments, tu peux je pense juste sauvegarder les changements de direction.
De toute façon même si tout était sauvegardé pour tout le monde, ça ne serait pas non plus énorme. On parle pas d'heures de data, quelques minutes au max (et quelques secondes la plupart du temps), tout ça représentera au pire quelques Mo de data.

----------


## Louck

> Hier j'ai joué à *Braid* et quelques temps avant à *Life is Strange*. Et ces deux jeux permettent de remonter le temps en conservant les actions du reste de l'environnement. 
> Savez-vous comment c'est géré ce genre de trucs? 
> 
> Parce que s'il faut sauvegarder tous les déplacements de tous les objets en permanence, ça peut faire une tonne de variables en mémoire... 
> 
> Dans le cas de *Life is Strange*, on n'a pas tout le temps la possibilité de revenir en arrière donc ça limite la charge. Par contre sur *Braid* (et aussi *les mésaventures du Professeur Winterbottom* si je me rappelle bien), il n'y a pas de limite et on peut revenir dans le passé aussi loin qu'on le souhaite...


A mon avis, c'est un peu le même délire qu'un snapshot dans une architecture multijoueurs: Tous les X ticks, tu produis une copie de l'état du jeu ou le snapshot: soit une copie brute (ce qui est le plus coûteux mais le plus simple), soit un différentiel par rapport au précédent snapshot (un peu plus compliqué, mais bien moins coûteux).

En soit, ce n'est pas difficile de copier l'état d'un objet. Le plus difficile néanmoins est de le retranscrire, "d'animer" le retour en arrière.

----------


## Poussin Joyeux

Merci pour vos retours!

----------


## schouffy

> Hop je vous partage un petit article de ma composition sur les allocation de garbage en C# sur Unity, pour ceux que ça pourrait intéresser ! Je vais essayer de le faire tourner un peu sur le net ce soir, mais Canard PC l'a en exclusivité au cas où vous auriez des remarques judicieuses sur comment l'améliorer 
> http://3-50.net/reducing-memory-allo...ge-collection/


J'aurais une petite question que je pose là, mais à l'avenir tu préfères qu'on commente sur ton blog peut-être ?
Je me demandais si les instanciations d'objets que tu fais initialement plutôt qu'au fil du temps (comme les effets de particules que tu vas réutiliser un peu partout), ne ralentissent pas le lancement du jeu ? Genre freeze une fois le niveau chargé pendant que t'instancies ton tableau de 500 impacts de balles.
Et vaut-il mieux mettre tout ça dans Start ou Awake ?

----------


## Roscopolo

L'instanciation des 500 objets est négligeable. En revanche leur existence permanente peut ralentir le jeu de plusieurs façons :

* Si jamais tu réalises d'autres allocations durant le jeu, à un moment le ramasse-miettes va devoir opérer. Et là il aura plus d'objets à visiter que ceux actuellement utilisés. En général pré-allouer n'est donc pas recommandé avec les GC. Mais c'est le bon choix si c'est pour complètement éviter le ramasse-miettes ou si tu réduis significativement le nombre de visites tout en alourdissant peu chacun d'entre elles. Considère que le GC passe après 1Mo alloué et prend deux ou trois frames pour une passe superficielle. Chaque objet pèse 12 octets de base plus les champs.

* Si ce sont cinq cents objets d'Unity (je ne me rappelle plus le type de leur objet de base), il est possible que le moteur les passe en revue à chaque frame. Par exemple pour vérifier s'il faut lever un événement Update ou s'il faut afficher un modèle. Dans ce cas le passage en revue de ces 500 objets causera l'éviction de la moitié du cache L1 (64ko, donc 1000 lignes). Une fois par frame ça doit rester à peu près négligeable. Mais si tu en rajoutes, gare à l'éviction du cache L2 : rien de tel pour tuer les perfs.

Cela dit l'avantage d'une allocation préalable c'est que tes objets sont gentiment alignés dans la mémoire, bien compactés. Donc leur passage en revue implique une lecture en mode burst.

----------


## schouffy

500 ou 10000 hein. T'es sûr que c'est négligeable ?
Pour le reste de tes remarques oui je comprends bien qu'il faut faire gaffe que tes objets "dormants" ne font rien.

----------


## Roscopolo

Instancier un million d'objets ne monopolisera que la première frame, guère plus. Avec les GC l'instanciation est extrêmement rapide (pas de tas ou autre à gérer ; ce n'est qu'une simple incrémentation). Le premier appel à GC.Collect(), à la fin du chargement, est plus significatif en comparaison.

----------


## schouffy

Ah je vois, j'avais à tort compris qu'on "initialisait" (Start ou Awake) les Monobehavior lors de leur instanciation. Alors qu'en fait on ne fait qu'instancier sans rien faire.
Et du coup pour que la méthode Update soit appelée à chaque frame, il faut que l'objet fasse partie de la scène ou simplement qu'il soit instancié et "traîne" qque part dans un Array ?

----------


## Gafda

> Et vaut-il mieux mettre tout ça dans Start ou Awake ?


En fait l'utilisation de Start ou Awake va dépendre de ce que tu veux faire dans ton/tes script(s). Le meiux c'est d'aller jeter un coup d'oeil aux deux liens de la doc. C'est très bien expliqué, et je pense que cela va t'aider à choisir l'un ou l'autre  :;): 

Personnellement, j'ai une préférence pour l'utilisation de Awake();

EDIT:



> Ah je vois, j'avais à tort compris qu'on "initialisait" (Start ou Awake) les Monobehavior lors de leur instanciation. Alors qu'en fait on ne fait qu'instancier sans rien faire.
> Et du coup pour que la méthode Update soit appelée à chaque frame, il faut que l'objet fasse partie de la scène ou simplement qu'il soit instancié et "traîne" qque part dans un Array ?


Pour que la méthode Update() soit appelée, il faut que l'objet soit actif dans ta scène.
Après, rien ne t'empêche de parcourir ton tableau de scripts pour appeler une fonction lors d'un update d'un autre script.


Je pense que cette vidéo peut t'être utile:

----------


## schouffy

Merci à vous deux  :;):

----------


## Roscopolo

On initialise bien dès l'instanciation à ma connaissance mais le budget CPU pour une frame à 60ips c'est plusieurs dizaines de millions d'instructions et des centaines de mégaoctets de bande passante mémoire en mode burst (beaucoup moins en aléatoire). Ça laisse de quoi voir venir ! Heureusement vu que les jeux parviennent à ridiculiser ces capacités ; je ne cesse de trouver miraculeux le fait que ça fonctionne.

En C++ les allocations sont lentes car elles nécessitent souvent de manipuler de lourdes structures de données (notamment des tas) contenant parfois des centaines de millions d'entrées. Avec un GC on reporte la charge sur le nettoyage.

----------


## Grhyll

J'arrive avec un peu de retard, mais tout a déjà obtenu une réponse ^^
Aussi, comme je le disais dans mon article, il n'y a pas d'unique stratégie gagnante, ça dépend des contraintes du support et de ce qui est critique. En tout cas, l'instanciation de mes quelques centaines d'objets en début de jeu ne se voit pas, et ça permet, une fois que le jeu roule, de ne plus rien avoir à créer (bien sûr il y a quand même une sécurité, si on arrive au nombre max, ça en créée d'autres). En plus d'avoir drastiquement réduit les allocations partout où je le pouvais, je fais un Collect manuel dès que possible (lancement du jeu, ouverture du menu pause, écran de game over...), pour éviter que tout se cumule d'une partie sur l'autre.

----------


## Gafda

Dites, est-ce que vous avez des articles sur le design d'interfaces avec le nouveau système de Unity ?
J'ai lu la doc Unity, mais je trouve que ce nouveau système est carrément plus compliqué que l'ancien (avec les OnGUI() )  ::sad::

----------


## schouffy

http://www.raywenderlich.com/114700/...nity-ui-part-1
les OnGUI c'était le bordel (enfin du peu que j'en ai vu, j'ai peu pratiqué à cette époque), le nouveau système pour docker et s'adapter aux différents écrans c'est pas mal.

----------


## Myron

J'ai pas vraiment eu l'occasion de tester l'ancien système pour comparer mais le nouveau est plutôt bien expliqué dans les tuto de la 4.6 qui l'introduisait je n'ai eu aucun mal a m'y mettre.
Par contre ce qui manque c'est du DataBinding.

----------


## schouffy

Un peu HS, mais vous utilisez quoi pour le version control de vos projets JV ?
Car on atteint vite quelques Go entre les sons, modèles, textures et assets du store.
Y'a des solution qui peuvent hoster ça gratuitement ou faut forcément payer ? J'ai vu quelques trucs (Bitbucket, Assembla, RiouxSvn,..) mais c'est souvent limité à 500M ou 1G..

----------


## Gafda

J'ai testé GitHub, j'ai vite abandonné avec la limitation de taille des fichers. BitBucket est pas trop mal, mais par contre il faut bien faire son .gitignore, parce que le dossier Library est trop volumineux (l'occlusion ambiante est horrible en espace disque...)
Le mieux je pense c'est de faire comme expliqué dans cette vidéo. C'est à dire un SVN pour les ressources graphiques et un git tout simple pour le code.

----------


## schouffy

Pourquoi pas tout mettre sur svn dans ce cas ?

----------


## Gafda

> Pourquoi pas tout mettre sur svn dans ce cas ?


Choix perso, je préfère git, je le trouve plus simple pour gérer le code que svn.

----------


## Grhyll

Ouaip git va mieux gérer les merges que svn a priori.
Pour ma part j'utilisais Assembla, sauf qu'ils ont revu à la baisse leur programme gratuit, depuis je suis passé sur github pour 12$ par mois, mais j'ai pas vraiment fait d'étude complète du marché, j'ai juste fureté vite fait. 
(Au boulot on utilise Assembla, mais je veux pas savoir combien ma boîte paie pour ça !)

----------


## Molina

Salut les canards ! 


J'ai un peut problème, rien de gênant, c'est juste par confort. Quand je clique sur un onglet d'unity, ou plus généralement quand j’interagis avec unity, j'ai des artefacts d'affichage qui apparaissent.  
Vous connaissez le problème ? 

Exemple, ces petits pixel blancs à gauche de l'image :

----------


## Gafda

Jamais eu ce genre de soucis... C'est ptet un problème de pilotes graphiques ?


Bon, je viens désespérément quémander de l'aide pour un problème avec le système d'UI (je suis dessus depuis plusieurs jours, je vais devenir fou!!) 
En gros, j'ai une grille avec des cases, et le soucis c'est qu'en jeu les images sont complètement déformés.
En images c'est plus parlant: 

Ici on à l'impression que les bords noirs ne sont pas de la même épaisseur alors qu'en réalité si !  :Vibre: 
Voici l'image utilisée: 


J'ai tenté d'explorer plusieurs pistes:
Changer la valeur "pixel per units" => Change rienChanger la taille des cellules de la grille => Résultat aléatoire, parfois c'est bon, d'autres fois nonVisiblement, plus la texture de la case est grande, moins le problème est présent =>Dois-je activer le "mip map" pour la texture ?Activer le "preserve aspect" => Change rienApparemment, le "canevas scaler" à une influence sur le phénomène

Dois-je changer le "canevas scaler" ?

J'ai d'autres pistes à explorer:
Tenter en faisant des textures uniquement en puissances de 2 (genre 32x32)Changer les paramètres du canevas, si ça se trouve ça vient de là..


De plus j'ai remarqué que le niveau de zoom à un impact sur ce bug étrange, c'est à dire que plus on est proche, moins l'effet de déformation est visible.

----------


## Hyperpenguin

C'est pas une histoire de perspective de camera? Bon c'est l'ui donc c'est peut probable mais bon. Sinon essai en puissance de 2 oui.

----------


## Gafda

L'effet est toujours le même.
Est-ce que, par le plus grand des hasard, il faudrait prendre en compte le ratio de l'écran ? Parce qu'en mettant le canevas scaler en "Constant Pixel Size", le problème est corrigé, mais du coup je perds la mise à l'échelle en fonction de la résolution de l'écran.

----------


## Molina

Oua... Putain, c'est la grande galère pour faire un système de dialogue....

----------


## Grhyll

Pour les artefacts dans l'editor je sais pas trop, peut-être lié à un bug Windows 10, moi je suis encore à 8 mais il me semble avoir entendu d'autres gens se plaindre de problèmes sous le 10 (peut-être pas de ce style ceci dit).

Par rapport au souci de pixel, tu as essayé de cocher "Pixel perfect" sur ton canvas ?
En tout cas tu trouveras peut-être des infos utiles ici : http://blogs.unity3d.com/2015/06/19/pixel-perfect-2d/

----------


## Metalink

Hop là petite question, puisque je vais attaquer mon gros projet de M1 qu'on va programmer sous Unity.
En gros c'est un jeu de tennis de table en 3D, et je me demandais si vous auriez des pistes/articles sur les bonnes manières d'utiliser (ou non) la physique d'Unity ?
Merci  ::lol:: 

Edit : je me retrouve tout seul en programmation sur le projet ... Si jamais vous avez des idées avant que je me jette, je prends

----------


## Poussin Joyeux

J'ai trouvé de très bon tutos Unity ici (scripts C#): http://catlikecoding.com/unity/tutorials/

Bien détaillés avec copie d'écran quand il faut.  :;):

----------


## Gafda

> J'ai trouvé de très bon tutos Unity ici (scripts C#): http://catlikecoding.com/unity/tutorials/
> 
> Bien détaillés avec copie d'écran quand il faut.


Merci !

Génial, il y a même des chapitres avec les cartes hexagonales et le bruit  ::wub::  
Pile ce qu'il me fallait !!

----------


## Poussin Joyeux

Oui j'ai trouvé ça en cherchant justement comment faire une carte hexagonale  ::):

----------


## Poussin Joyeux

Il vient d'ailleurs de rajouter une nouvelle partie de son tuto sur les hexagones avec des hauteurs différentes suivant les cases  ::):

----------


## Molina

En fait, c'est dommage, il n'y a pas de topic général : 

Toons premium va sortir son soft en libre accès, avec notamment toutes les features qu'a créé le studio Ghibli. J'ai un peu regardé ce que faisait toonz, et je me demande si ça permet pas de simplifier amplement la vie aux graphistes (2D) pour les animations. 

http://www.toonzpremium.com/

Sorti le 26 mars.

----------


## Poussin Joyeux

Un logiciel avec des features de Ghibli? C'est étrange car ce studio fait tout à l'ancienne, à l'encre avec cellophane etc (et qui d'ailleurs n'arrive plus à en vivre...) donc pas de logiciel, sauf si je ne suis plus à jour !

Edit: ok, j'ai rien dit  ::): 




> Commenting on this exciting announcement, Mr. Atsushi Okui, Executive Imaging Director at Studio Ghibli said “During the production of ‘Princess Mononoke’ in 1995, we needed a software enabling us to create a certain section of the animation digitally. We checked for what was available at that time and chose ‘Toonz’. Our requirement was that in order to continue producing theatre-quality animation without additional stress, the software must have the ability to combine the hand-drawn animation with the digitally painted ones seamlessly. From then onwards we continued to use the software while going through major updates to make it easier for us to use. We are happy to hear that this open source version contains the Ghibli Edition. We hope that many people inside and outside of the animation industry will utilize this software for their work. We would like to extend our gratitude to the staff of Digital Video.”

----------


## Longwelwind

Dites, est-ce que quelqu'un a réussi à trouver un workaround pour faire des prefabs imbriqués ?
Impossible de me faire un workflow optimisé à cause du manque de ce genre de fonctionnalités. Je suis obligé de copier-coller des changements sur plusieurs prefabs alors que je devrais pas avoir à le faire  ::(:

----------


## Grhyll

C'est l'une des features les plus réclamées de Unity. Il n'y a pas de solution parfaite, mais parmi les moyens de contourner ça, on trouve :
- Des plugins type PrefabEvolution (pas sans inconvénient non plus, la question est forcément un peu compliquée, sinon Unity l'aurait fait depuis longtemps)
- Adapter ton workflow à cette contrainte. Instancier les sous-prefabs en runtime uniquement (et ils ne sont donc présents dans le "super" prefab qu'en tant que référence, pas instanciés), ne pas créer X modèles de prefab différents pour des entités similaires mais les initialiser à l'instanciation pour en faire le prefab spécialisé voulu...
J'ai utilisé les deux méthodes, chacune a ses inconvénients et ses limites. Après il faut aussi garder à l'esprit que le prefab, c'est quand même une feature sympa de Unity, qui évite de recréer un objet de 0 via du code ; là où on rencontre les limites des prefabs, il est parfois nécessaire de revenir en partie aux méthodes utilisées dans un moteur où le concept même de prefab n'existe pas.

----------


## Longwelwind

C'est ce que je m'étais dis aussi; peut-être que je sur-utilisais les Prefab. Mais au final, j'ai l'impression que le Prefab, c'est la manière graphique de faire une fonction qui crée un GameObject, y ajoute les Component appropriés et les initialise tout-comme-il-faut.
Mais si je fais vraiment des fonctions "prefab", j'aurais pas les avantages que m'offrent Unity en utilisant les Prefab (genre la prévisualisation des SpriteRenderer).

Je pense que je vais me cantonner à mon script qui Instantiate le Prefab enfant pour l'instant, même si j'y perds la prévisualisation des sous-Prefab.

----------


## Grhyll

C'est ce que je fais personnellement, en tout cas, et il est probable qu'on ne conserve pas PrefabEvolution pour le prochain projet de ma boîte, ça rajoute des temps d'importation un peu excessifs sur un gros projet. Ceci dit qui sait, peut-être que Unity s'y penchera un jour, ils ont bien ajouté les multi-scènes récemment, ils sont sur la bonne voie !

----------


## Adu

Preview des améliorations prévues pour la 2D : http://blogs.unity3d.com/2016/06/13/...ental-preview/
Et on peut déjà tester !

----------


## Acceomega

Bonjour à tous  ::): 

   Je viens de dl Unity avec la ferme intention d'en faire quelque-chose, j'ai décidé de me lancer dans la création de JV. Cependant, je n'ai aucune idée de comment créer un JV, de comment apprendre, de comment faire quoi que ce soit en ce sens. Ce qui fait de moi le newbie originel..
   En ce sens, j'aimerai beaucoup avoir des pistes pour mieux appréhender le milieu et rejoindre votre communauté et pour apprendre les ficelles de la création. Avez-vous des liens ou même un canal vocal pour en parler et m'introduire à tout ceci ?  :;):

----------


## Gafda

> Bonjour à tous 
> 
>    Je viens de dl Unity avec la ferme intention d'en faire quelque-chose, j'ai décidé de me lancer dans la création de JV. Cependant, je n'ai aucune idée de comment créer un JV, de comment apprendre, de comment faire quoi que ce soit en ce sens. Ce qui fait de moi le newbie originel..
>    En ce sens, j'aimerai beaucoup avoir des pistes pour mieux appréhender le milieu et rejoindre votre communauté et pour apprendre les ficelles de la création. Avez-vous des liens ou même un canal vocal pour en parler et m'introduire à tout ceci ?


Déjà, je te conseille de commencer par les tutos disponibles sur le site de Unity. Ils sont de très bonne qualité et vont t'apprendre les bases:
https://unity3d.com/fr/learn/tutorials

----------


## Ashley TOUCRU

> Bonjour à tous 
> 
>    Je viens de dl Unity avec la ferme intention d'en faire quelque-chose, j'ai décidé de me lancer dans la création de JV. Cependant, je n'ai aucune idée de comment créer un JV, de comment apprendre, de comment faire quoi que ce soit en ce sens. Ce qui fait de moi le newbie originel..
>    En ce sens, j'aimerai beaucoup avoir des pistes pour mieux appréhender le milieu et rejoindre votre communauté et pour apprendre les ficelles de la création. Avez-vous des liens ou même un canal vocal pour en parler et m'introduire à tout ceci ?


Si tu t'orientes vers de la 2D, je t'invite à jeter un oeil aux vidéos de CasanisPlay. Elles sont super bien fichues. Sinon, pour quelques conseils "de base", la discussion que j'avais ouverte... J'y avais obtenu des réponses très intéressantes pour débuter.  :;):

----------


## Silver

Tu peux aussi regarder cette longue liste de tutoriels en réponse à la question How can I start learning Unity fast? La liste date de 2010, mais il y a une update de 2016, alors la plupart des liens peuvent être encore d'actualité.

J'avais aussi regardé les tutos des TornadoTwins il y a 2 ans, c'était déjà un peu dépassé pour ce qui est des fonctionnalités dans Unity (ils ont commencé la série de tutos en 2009), mais je trouve que les raisonnements restent valables : Make a Videogame from Scratch

----------


## Ashley TOUCRU

Merci à toi, je me suis gardé tout ça en favoris.  :;):

----------


## Voodoom

Salut !

Je me lance enfin dans Unity, j'ai trouvé un tuto récent et bien expliqué en 40 épisodes pour se faire un Zelda (2D) assez complet (manque la gestion de l'inventaire et des sauvegardes en gros).
Étant moi-même développeur (étudiant) et bossant principalement en ASP.net qui contient du C#, ça peut être intéressant.  ::): 
Je viendrai quémander votre aide si j'ai de gros problèmes.
A terme j'aimerai réaliser un Zelda-like mobile avec des zones à la WoW (mobs dans diverses zones par niveaux) et pas mal de quêtes.
Le seul truc qui va me limiter est je pense (hormis les problèmes techniques) le manque de ressources graphiques, même si les packs de Kenney sont très fournis et facilement modifiables.

----------


## Adu

Plop ! Bon courage  ::):  Et pourrais-tu partager ce tuto stp ?

----------


## Voodoom

Ça commence ici : https://youtu.be/Pk3GCgaNVTY

----------


## Adu

Merci ! (en plus j'étais déjà abonné à la chaine  :tired: )

----------


## Kalimmba

Coicoin tt le monde

Je suis en train de dev un chti soft de chat avec unity et j'ai un pb lors de la deco.
C'est avec l'aide d'un tuto que j'en suis arrivé là.
Mais là je bloque.

quelqu'un pourrait m'aider ?

coté client


```
using UnityEngine;
using UnityEngine.Networking;
using UnityEngine.UI;
using System.Collections;
using System.Collections.Generic;
using System.Net.Sockets;
using System.IO;
using System;

public class Client : MonoBehaviour
{
    private bool socketReady;
    private TcpClient socket;
    private NetworkStream stream;
    private StreamWriter writer;
    private StreamReader reader;
    private NetworkConnection network;

    public string clientName;
    public NetworkPlayer networkClient;

    public GameObject chatContainer;
    public GameObject messagePrefab;
    


    public void ConnectToServer()
    {
        // Si deja connecté, ignorez cette methode
        if (socketReady)
            return;

        // IP et port par défaut
        string host = "127.0.0.1";
        int port = 9865;
        //string login = "";

        // Remplace les valeurs par défaut par celle saisies dans les champs
        string h;   // HostInput
        int p;      // PortInput
        string l;   // Login
        h = GameObject.Find("HostInput").GetComponent<InputField>().text;
        if (h != "")
        host = h;

        l = GameObject.Find("Login").GetComponent<InputField>().text;
        if (l != "")
        clientName = l;
        //networkClient = l;
        // Debug.Log("Login = " + login + "ou L = "+l);

        int.TryParse(GameObject.Find("PortInput").GetComponent<InputField>().text, out p);
        
        if (port != 0)
           //port = p;
           
        // On créé la connexion
        try
        {
            socket = new TcpClient(host, port);
            stream = socket.GetStream();
            writer = new StreamWriter(stream);
            reader = new StreamReader(stream);
            socketReady = true;

        }
        catch(Exception e)
        {
                
                Debug.Log("CLIENT.CS - Fonction ConnectToServer Socket Error : " + e.Message + " IP = " + host + " et Port = " + port );
        }
    }

    /*
    public void DisconnectFromServer()
    {
        try
        {
            // GameObject.Find("Deconnexion").GetComponent<Button>().OnClick.RemoveAllListeners();
            // GameObject.Find("Deconnexion").GetComponent<Button>().OnClick.AddListener(MonoBehaviour.singleton.StopHost);
            // network = new NetworkConnection();
            // network.Disconnect();
            Network.CloseConnection(Network.connections[1], true);
        }
        catch(Exception e)
        {
            Debug.Log("error message : " + e.Message);
        }
    }
    */

    private void Update ()
    {
        if (socketReady)
        {
            if(stream.DataAvailable)
            {
                string data = reader.ReadLine();
                if(data != null)
                {
                    OnIncomingData(data);
                }
            }
        }
    }

    private void OnIncomingData(string data)
    {
        if(data == "%NAME")
        {
            Send("&NAME|" + clientName);
            return;
        }

        GameObject go = Instantiate(messagePrefab, chatContainer.transform) as GameObject;
        go.GetComponentInChildren<Text>().text = data;

//Debug.Log("CLIENT.CS - Server : " + data);
    }

    private void Send(string data)
    {
        if (!socketReady)
            return;

        writer.WriteLine(data);
        writer.Flush();
    }

    public void OnSendButton()
    {
        string message = GameObject.Find("EnvoiTexte").GetComponent<InputField>().text;
        Send(message);
    }

    public void CloseSocket()
    {
        if (!socketReady)
            return;

        // Network.CloseConnection(networkClient, true);
        stream.Close();
        writer.Close();
        reader.Close();
        socket.Close();
        
        socketReady = false;
    }

    private void OnApplicationQuit()
    {
        CloseSocket();
    }
    
    private void OnDisable()
    {
        CloseSocket();
    }
}
```


Cote serveur



Spoiler Alert! 




```
using UnityEngine;
using System.Collections;
using System.Net.Sockets;
using System.Collections.Generic;
using System;
using System.Net;
using System.IO;

public class Server : MonoBehaviour
{
    private List<ServerClient> clients;
    private List<ServerClient> disconnectedList;

    public string ip = "127.0.0.1";
    public int portnb = 9865;
    private TcpListener server;
    private bool serverStarted;


    private void Start()
    {
        clients = new List<ServerClient>();
        disconnectedList = new List<ServerClient>();

        try
        {
            server = new TcpListener(IPAddress.Any, portnb);
            server.Start();

            StartListening();
            serverStarted = true;
            Debug.Log("Le serveur a démarré sur le port " + portnb.ToString());
            // Debug.Log("Le serveur a démarré sur le port " + port);
            // Debug.Log("IP est  " + ip);
        }
        catch (Exception e)
        {
            Debug.Log("SERVER.CS - Fonction Start Socket Error : " + e.Message);
        }
    }

    private void Update()
    {
        if (!serverStarted)
            return;

        foreach(ServerClient c in clients)
        {
            // Client tjrs connecté ?
            if(!IsConnected(c.tcp)) 
            {
                c.tcp.Close();
                disconnectedList.Add(c);
                return;

            }

            // Verif si message envoyé par client
            else
            {
                
                NetworkStream s = c.tcp.GetStream();
               
                if (s.DataAvailable)
                {
                    StreamReader reader = new StreamReader(s, true);
                    string data = reader.ReadLine();

                    if(data != null)
                        OnIncomingData(c, data);
                    
                }
            }

            // Affiche tableau des users connectés
            // Debug.Log("SERVEUR tableau users : " + clients.Count +"\t - Name = " + c.clientName + "\t - DECO = " + disconnectedList.Count);

            // Message 'User' s'est déconnecté
            for (int i = 0; i < disconnectedList.Count - 1; i++)
            {
                Broadcast(disconnectedList[i].clientName + " s'est déconnecté !", clients);

                clients.Remove(disconnectedList[i]);
                disconnectedList.RemoveAt(i);
            }
            // Affiche tableau des users connectés
            Debug.Log("SERVEUR tableau users : " + clients.Count + "\t - Name = " + c.clientName + "\t - DECO = " + disconnectedList.Count);
        }




    }

    private void StartListening()
    {
        server.BeginAcceptTcpClient(AcceptTcpClient, server);
    }

    private bool IsConnected(TcpClient c)
    {
        try
        {
            if(c != null && c.Client != null && c.Client.Connected)
            {
                if (c.Client.Poll(0, SelectMode.SelectRead))
                {
                    return !(c.Client.Receive(new byte[1], SocketFlags.Peek) == 0);
                }
                return true;
            }
        }
        catch
        {
            return false;
        }
        return true; // empeche erreur : not all code paths return a value
    }

    private void AcceptTcpClient(IAsyncResult ar)
    {
        TcpListener listener = (TcpListener)ar.AsyncState;
        clients.Add(new ServerClient(listener.EndAcceptTcpClient(ar)));
        StartListening();

        // Envoi message à tt le monde : nouvelle connexion
        //Broadcast(clients[clients.Count - 1].clientName + " s'est connecté", clients);
        Broadcast("%NAME",new List<ServerClient>() { clients[clients.Count - 1]});
    }

     private void OnIncomingData(ServerClient c, string data)
    {
        //Debug.Log(c.clientName + " a écrit : " + data);
        if(data.Contains("&NAME"))
        {
            c.clientName = data.Split('|')[1];
            Broadcast(c.clientName + " s'est connecté ++++ ", clients);
            return;
        }
        Broadcast(c.clientName + " : " + data, clients);
    }

    private void Broadcast(string data, List<ServerClient> cl)
    {
        foreach(ServerClient c in cl)
        {
            try
            {
                StreamWriter writer = new StreamWriter(c.tcp.GetStream());
                writer.WriteLine(data);
                writer.Flush();
            
            }
            catch(Exception e)
            {
                Debug.Log("BROADCAST - Message d'erreur : " + e.Message + " pour client : " + c.clientName); 
            }
        }
    }
}

public class ServerClient
{
    public TcpClient tcp;
    public string clientName;

    public ServerClient(TcpClient clientSocket)
    {
        clientName = "Invité";
        tcp = clientSocket;

    }
    
}
```

----------


## Grhyll

Alors j'ai jamais touché au côté réseau de la force, donc je peux pas t'aider, mais de toute façon ça pourrait éventuellement être bien que tu dises ce sur quoi tu bloques au juste, là tu as juste mis plein de code, je vois pas comment on peut deviner en quoi on peut t'aider !

----------


## Kalimmba

Milles excuses, je pensais avoir expliquer plus en détails
voici l'erreur quand je clique sur 'deconnexion"

ObjectDisposedException: The object was used after being disposed.
System.Net.Sockets.TcpClient.CheckDisposed ()
System.Net.Sockets.TcpClient.GetStream ()
Server.Update () (at Assets/Script/Server/Server.cs:62)

ALors evidemment, j'ai cherché de mon cote mais je ne trouve pas de solutions.
J'ai bien compris que c'est à la ligne 62 que j'ai un pb et que c'est lié à la récupération d'un flux d'info. Mais il me semble pourtant que je ferme bien le flux quand je me deco, alors bon je sais pas trop quoi faire.

Somebody help ?

----------


## Grhyll

Alors effectivement il a l'air d'y avoir plusieurs soucis dans ton Update du client :
- Pourquoi ce "return;" quand tu fermes un client ? Tu ne veux plus regarder les autres dès lors que tu en fermes un seul ?
- Ta gestion de disconnectedList a l'air louche, déjà ça ne passe pas dans ce code quand tu y ajoutes un élément (à cause de ce "return;" mentionné ci-dessus), ce qui fait qu'à l'Update suivante ton client déconnecté est encore dans la liste de clients (alors que tu l'as Closed, c'est probablement ça qui génère l'exception que tu mentionnes : tu le closes puis à l'update suivante tu essaies encore d'appeler des fonctions dessus comme GetStream). De plus dans cette partie du code où tu vides disconnectedList, tu fais des Remove sur ta liste de clients alors que tu es à l'intérieur d'un foreach qui parcourt clients, et ça a priori c'est interdit. 

En gros, il te faudrait quelque chose plutôt dans ce style :



```
 private void Update()
    {
        if (!serverStarted)
            return;

        for(int i = 0; i < clients.Count; i++)
        {
            ServerClient c = clients[i];

            // Client tjrs connecté ?
            if(!IsConnected(c.tcp)) 
            {
                c.tcp.Close();
                disconnectedList.Add(c);
                clients.RemoveAt(i);
                i--;
            }

            // Verif si message envoyé par client
            else
            {
                
                NetworkStream s = c.tcp.GetStream();
               
                if (s.DataAvailable)
                {
                    StreamReader reader = new StreamReader(s, true);
                    string data = reader.ReadLine();

                    if(data != null)
                        OnIncomingData(c, data);
                    
                }
            }
        }


        // Affiche tableau des users connectés
        // Debug.Log("SERVEUR tableau users : " + clients.Count +"\t - Name = " + c.clientName + "\t - DECO = " + disconnectedList.Count);

        // Message 'User' s'est déconnecté
        for (int i = 0; i < disconnectedList.Count - 1; i++)
        {
            Broadcast(disconnectedList[i].clientName + " s'est déconnecté !", clients);
        }
        disconnectedList.Clear();

        // Affiche tableau des users connectés
        Debug.Log("SERVEUR tableau users : " + clients.Count + "\t - Name = " + c.clientName + "\t - DECO = " + disconnectedList.Count);

    }
```

(Non testé, donc je garantis rien !)

----------


## Kalimmba

> Alors effectivement il a l'air d'y avoir plusieurs soucis dans ton Update du client :
> - Pourquoi ce "return;" quand tu fermes un client ? Tu ne veux plus regarder les autres dès lors que tu en fermes un seul ?


Tout simplement parce que c'etait comme ça dans le tuto 




> - Ta gestion de disconnectedList a l'air louche, déjà ça ne passe pas dans ce code quand tu y ajoutes un élément (à cause de ce "return;" mentionné ci-dessus), ce qui fait qu'à l'Update suivante ton client déconnecté est encore dans la liste de clients (alors que tu l'as Closed, c'est probablement ça qui génère l'exception que tu mentionnes : tu le closes puis à l'update suivante tu essaies encore d'appeler des fonctions dessus comme GetStream). De plus dans cette partie du code où tu vides disconnectedList, tu fais des Remove sur ta liste de clients alors que tu es à l'intérieur d'un foreach qui parcourt clients, et ça a priori c'est interdit.


Merci pour la correction. La reconnexion fonctionne maintenant.

----------


## Kalimmba

Coincoin tt le monde,

J'ai un probleme, qui est plus de la methodo de dev, qu'un vrai pb unity mais bon

voila le probleme
J'ai 2 listes


```
    public List<ServerClient> clients;
    private List<ServerClient> disconnectedList;
```

avec


```
public class ServerClient
{
    public TcpClient tcp;
    public string clientName;

    public ServerClient(TcpClient clientSocket)
    {
        clientName = "Invité";
        tcp = clientSocket;
    }
    
}
```

Ce que je veux c'est 


```
                    
                    // Si liste clients contient cl.clientName alors on instancie usernamePrefab correspondant
                    if (clients.Contains(cl.clientName))
                    {
                        GameObject go = (GameObject)Instantiate(usernamePrefab, connectedUserContainer.transform);
                    }
                    
                    // Si liste disconnectedList contient cl.clientName alors on destroy usernamePrefab correspondant}
```

Or quand je fais ça, j'ai le message


```
 Argument `#1' cannot convert `string' expression to type `ServerClient'
```

Et là, je sais pas quoi faire.
J'essaie bien avec la methode Convert.ToString, mais ça passe pas. Je me dis aussi c'est peut etre dans la class ServerClient mais je sais pas quoi ajouter

Quelqu'un aurait une idée ?

----------


## Louck

Cette ligne est étrange:

*if (clients.Contains(cl.clientName))*

Tu fais un test sur ta liste de ServerClient, si elle contient... un nom de client ? (qui est un type string je suppose).

Je pense que tu souhaites faire ca plutôt:

*if (clients.Contains(cl))*

----------


## Kalimmba

Merci pour ta réponse Louck, c'est bon j'instancie bien mes users
Mais j'ai pas trouvé pour destroy le user qui s'est deco.
Une idée ?

----------


## Kalimmba

Bon pour ceux qui suivent sans interet cette discussion, j'ai trouvé un moyen de destroy mes users.
il suffisait de donner un nom a l'objet que j'instancie, puis de le chercher et de le destroy 
ouais c'etait tout bete en fait
Merci à ceux qui ont essayé de m'aider

----------


## Tylers

If(disconnectedlist.Contains(cl))
{
        disconnectedList.Remove(cl);
        Destroy(cl);
}

----------


## Hyperpenguin

Juste pour infos, sur Udemy on peut chopper 52h de tutos Unity 3D pour 15€ au lieu de 195€:

https://www.udemy.com/unitycourse/learn/v4/overview

avec le code *MAP204*

ça peut en décider certains à se lancer.

----------


## Molina

https://www.udemy.com/courses/

Les cours sont à 10 balles pour je ne sais combien de temps.

----------


## madgic

> https://www.udemy.com/courses/
> 
> Les cours sont à 10 balles pour je ne sais combien de temps.


Ca fait un peu plus d'un mois que je suis sur Udemy, les cours sont à 10€ pendant quelques jours puis autres promos pendant quelques jours (cours à 20€...) puis aucunes promos pendant 1 ou 2 jours, etc...

Si vous voulez prendre un vours sur Udemy pour Unity, je vous conseille celui là : https://www.udemy.com/unitycourse/learn/v4/overview  :;):

----------


## Molina

> Ca fait un peu plus d'un mois que je suis sur Udemy, les cours sont à 10€ pendant quelques jours puis autres promos pendant quelques jours (cours à 20€...) puis aucunes promos pendant 1 ou 2 jours, etc...
> 
> Si vous voulez prendre un vours sur Udemy pour Unity, je vous conseille celui là : https://www.udemy.com/unitycourse/learn/v4/overview


Oui, je me disais bien que personne de normalement constitué allait mettre 300 balles dans un cours sur internet (alors que les tuto sont gratuits...). Du coup, ça m'étonne pas que 10-20euros soit en fait le prix normal  :^_^: .

Perso, j'ai pris ce cours, celui sur le RPG, et celui sur Blender de la même équipe. On verra bien.

----------


## Molina

Han je suis content, je suis content ! 

Petit RPG/FPS en construction. J'ai des ennemies qui s'approchent de moi, m'attaquent de près ou de loin, m'enlèvent de la vie par raycast avec barre de vie au dessus de leur tête.  De même, je peux leur enlever de la vie. J'ai un changement de curseur selon le layer (c'est con, mais c'est ce dont je suis le plus fier) je suis jamais assez aussi loin, sans asset ni rien, juste du code  :Cigare:  

Me reste à implanter une attaque spéciales, et la fiche de stat.

----------


## Patate

Cool  ::):  un petit screen ?

----------


## schouffy

Je pose la question ici car j'utilise Unity mais c'est plutôt un problème Blender.

Je me demandais comment faire pour modifier un objet dans plusieurs scènes, je m'explique :
J'ai fait des bras pour une vue FPS, que j'ai riggé avec de l'IK et tout c'est sympa. Ensuite je vais faire des animations en mode proto pour quelques armes, donc je vais dupliquer ces bras d'une façon ou d'une autre, pour faire les anims de chaque arme indépendamment (dans Blender).
Tout ça est modélisé très sommairement, mais à un moment je vais vouloir refaire le modèle des bras et des armes. Pour les armes pas de problème, elles apparaissent dans une seule scène, celle de leurs animations. Mais les bras eux, ont été dupliqués dans chaque scène.

Donc ma question est, savez-vous si/comment je peux modifier le modèle des bras simultanément dans toutes mes animations ?

Merci à tous ceux qui pourront m'aider  ::):

----------


## Louck

Si le but est de modifier le modèle ou le texture d'un objet dynamiquement, il faut passer par un script et sa méthode LateUpdate. Je ne pourrais pas aider plus, vu que je ne connais pas trop la 3D sous Unity3D.


Si le but est d'animer plusieurs objets en même temps, d'un point de vue animation, il y a deux façons de faire:

Le plus simple, c'est de faire l'animation à partir du GameObject père: dans la fenêtre animation, il est possible d'animer les GameObjects fils en même temps que le GameObject cible.

Beaucoup plus compliqué, mais qui peut servir dans certains cas spécifiques, c'est de passer par plusieurs animators (un pour le bras, un autre pour le torse, etc...).
Ensuite, l'objectif est de bien synchroniser les animations:
 - Dans le code, bien s'assurer qu'on invoque les animations des animators en même temps (les triggers aident pas mal).
 - Dans la fenêtre des animators, vérifier que la transition entre les animations est semblable pour tous les animators (pour éviter qu'une animation commence avec un retard par rapport aux autres).
 - Enfin, si besoin, utiliser la valeur "Cycle Offset" des animations pour synchroniser leurs temps d'exécutions.

La dernière solution est clairement beaucoup plus compliqué. Mais c'est ce que j'ai utilisé dans mon projet DTC, étant donné que je ne pouvais pas utiliser la première solution.

----------


## Grhyll

J'ai pas vraiment compris la situation de base en fait, pourquoi tu as dû dupliquer le bras dans différentes scènes ? C'est pas un prefab, ton bras ?

----------


## schouffy

Non je parle de Blender en fait, pas Unity. J'ai précisé mais c'est vrai que je suis très HS.
J'ai trouvé ça, je vais essayer : https://www.blender.org/forum/viewtopic.php?t=1420

----------


## Molina

> Oui, je me disais bien que personne de normalement constitué allait mettre 300 balles dans un cours sur internet (alors que les tuto sont gratuits...). Du coup, ça m'étonne pas que 10-20euros soit en fait le prix normal .
> 
> Perso, j'ai pris ce cours, celui sur le RPG, et celui sur Blender de la même équipe. On verra bien.


Tiens, je n'ai jamais parlé de ce truc après deux mois d'utilisation. 

Je fais un peu tout : un peu d'apprentissage C#, un peu de leur module RPG et un peu de blender. 
Pour le module C#, c'est du bonheur en barre. Vraiment. Les mecs expliquent très bien, pas à pas, et leur mini challenge est juste ce qu'il faut pour se creuser la tête et être très fier de ce qu'on fait. Au final, c'est mieux que faire un pong dans son coin. On apprend plein de truc pratico-pratique. Je suis loin d'être autonomne mais je suis beaucoup plus à l'aise avec les scripts. (arrivé à la moitié en gros)

Blender : Idem, très pédagogique, très bien expliqué. Parfois ça tourne un peu rond à redire la même chose, mais c'est tant mieux au vu de l'outil. Par contre, c'est leeeeeeeeeeeeent. Mais vraiment, quand je vois que je verrais les textures qu'à la toute fin du cours, soit après 120h de vidéos, ça pique un petit peu. Je pense que pour ce cours, il faut faire des aller retours avec des trucs plus consistant de Youtube. (Arrivé au quart je pense) 

RPG : Alors c'est le cours le moins bien pensé. Déjà, parce que ça se focalise sur le combat, les déplacements et les effets visuels. Du coup, on retrouve ça dans d'autres vidéos gratuites. Ensuite, parce que j'ai plus l'impression de regarder des mecs faire leur jeu, plutôt que des mecs qui m'expliquent comment je peux faire mon propre jeu. Il ya beaucoup trop de vidéo de game design qui ... bon... ne sert pas à grand chose la plupart du temps et la programmation se résume surtout à recopier ce que fait le prof. Maintenant il y a quelques tips, j'ai appris quelques choses sur les layers, les triggers et surtout le raycast qui restaient un mystère pour moi. Je bitch un peu le cours, mais en soi, je suis arrivé à un stade de mon jeu auquel je n'aurais pas pu penser il y a encore 3 mois sans eux. Donc bon. 

Bref, je suis plutôt content des 30 euros investis. Depuis début juillet j'ai un peu perdu la cadence des vidéos, mais il me reste pas mal à apprendre d'eux, donc je peux dire que pour un débutant, ce sont des cours plutôt bien foutu pour peu qu'on comprenne l'anglais.

----------


## Yves Signal

Hello, je voudrais me lancer dans l'apprentissage du c# et la création de jeu, du coup je vais sans doute acheter les cours udemy cités ci-dessus.
Pour un débutant complet c'est adapté ?
J'aimerais en parallèle une approche plus théorique en lisant quelques bouquins sur le game design, c'est jouable à votre avis ?

----------


## Metalink

J'ai fais un jeu en 3D pour la Ludum pour une fois, vous pouvez l'essayer là https://meta-link.itch.io/tiny-sub-mission si vous vous ennuyez au boulot  ::P:

----------


## Grhyll

Congrats :D
Par contre du coup la version WebGL est à télécharger, elle n'est pas jouable directement sur internet ?

(Edit: Désolé Couyu, je ne sais pas, pas essayé !)

----------


## Metalink

Merci  ::lol:: 
Pour la version WebGL en fait je préfère pas la mettre directement sur le site car le rendu est complétement pété par rapport au standalone, et j'ai tellement galéré pour faire un truc digne d'une PS2 que j'ai pas trop envie que les gens jouent par défaut à une "inferior version". Mais c'est un peu bête je te l'accorde ...

----------


## Grhyll

Ben disons que si elle est pas en ligne, je vois pas trop son intérêt XD Je testerai la version Windows ce soir  ::):

----------


## Metalink

L'intérêt c'est pour les gens sous MacOS et Linux  :;): 
Tu me dira ce que tu en as pensé !

----------


## Grhyll

Bon, je suis désolé, j'ai rage quitté au niveau 2 XD
Niveau 1 tout va bien, niveau 2 à la première tentative, pas assez de puissance pour atteindre le troisième checkpoint. Je charge à fond pour la tentative suivante, je l'atteins, rebelotte sur le final. Réessaie, je charge à fond, quand même pas assez pour le truc rouge. Rereretentative, je me dis que je vais avancer un peu dans le checkpoint histoire d'être plus proche, j'en sors involontairement est meurs direct après. J'ai abandonné ^^'
Mais sinon c'est assez joli je dois dire !

----------


## Adu

Humble Bundle Ebook spécial Unity/Unreal Engine

----------


## Metalink

> Bon, je suis désolé, j'ai rage quitté au niveau 2 XD


Je crois que je vais devoir refaire une build, tu es la 3 ou 4e personne à avoir un problème avec ce niveau, même si de loin je vois pas de problèmes apparents ...
Merci d'avoir testé en tous cas, je viendrais peut-être mettre un message quand j'aurais upload une nouvelle build  :;):

----------


## schouffy

> Humble Bundle Ebook spécial Unity/Unreal Engine


Merci pour l'info !
Un lien : https://www.humblebundle.com/books/u...y5-book-bundle

Couyu: y'a un ebook "learning c# by developing games". ça vaut le coup de jeter un oeil.

----------


## Djal

Ouep merci pour le tuyau !

----------


## raaaahman

J'ai testé ton jeu Metalink, je n'ai pas eu de problèmes pour le second niveau, c'est celui où il faut repasser par dessus le point départ qui m'a paru vraiment serré sur les distances. Au final c'est le fait de recommencer les niveaux du début à chaque fois qui m'a fait lâché avant la fin (j'ai du en faire cinq ou six), mais sinon c'est bien sympa. Bravo à toi.  :;): 

PS: J'ai ouvert un thread pour les jeux du ludum, toutes technos confondues -> Ludum Dare 39

----------


## Metalink

Merci pour les retours  ::lol::

----------


## Ashley TOUCRU

> Merci pour l'info !
> Un lien : https://www.humblebundle.com/books/u...y5-book-bundle
> 
> Couyu: y'a un ebook "learning c# by developing games". ça vaut le coup de jeter un oeil.


Ça inclut une version Fr ou seulement en anglais ?  ::huh::

----------


## Adu

Les livres PACKT sont généralement qu'en Anglais

----------


## Ashley TOUCRU

Dommage.  :Emo:  Merci.  ::):

----------


## Adu

J'en profite d'ailleurs !
Sur ce site : https://www.packtpub.com//packt/offers/free-learning
Tous les jours un nouveau bouquin complet offert (en anglais certes). Et des fois y a des livres sur Unity justement qui passent (je commence à en avoir quelques uns).
Hésitez pas à vous inscrire et à y passer tous les jours  :;):

----------


## Ashley TOUCRU

J'aimerais reprendre les graphismes vectoriels que j'avais commencés pour un petit jeu de plate-forme à destination des enfants, et je m'aperçois que j'ai dessiné les _sprites_ image par image dans Illustrator, mais qu'il serait peut-être plus facile de l'animer directement sur Unity, sous forme de squelette. Au-delà de cet aspect de facilité d'animation, y a-t-il des choses à prendre en compte pour choisir entre les deux ? L'animation par squelette est-elle plus gourmande, ou moins que celle via des sprites ?  ::huh::

----------


## Grhyll

Quelques différences entre les deux :
- Grosse différence de style entre de l'anim traditionnelle image par image et de l'animation de squelette. Ceci dit, si par "graphismes vectoriels" tu veux dire que c'est déjà de l'anim de squelette que tu fais dans Illustrator, ça changera pas grand chose (si ce n'est que tu galèreras peut-être plus à obtenir le même résultat sur Unity, ils progressent sur l'animation mais c'est quand même pas un logiciel dédié à ça !).
- Différence de poids des assets : entre 10 sprites qui se battent en duel et des fichiers d'animation assez léger ; et plusieurs dizaines voire centaines de sprites pour une animation image par image, il y a un gouffre. Ceci dit, c'est peut-être pas un facteur limitant pour toi ! Si tu es sur mobile, ça peut avoir de l'importance, mais sur desktop, tant que tu n'as pas des tonnes et des tonnes de sprites, ça devrait pas faire de différence (pense à utiliser quand même les spritesheets, il y a un sprite packer inclus dans Unity qui fait bien le boulot). 
- Performances : je pense pas que ça vaille le coup de s'en préoccuper. A moins que tu aies, encore une fois, des tonnes de sprites sur plein de spritesheets de 2048*2048, aucune des deux méthodes ne devrait être plus gourmande que ça.
- Praticité : La méthode de squette permet a priori beaucoup plus facilement les changements (un changement de tenue, d'accessoire...), tant que tu ne touches pas à la hiérarchie de l'objet (si tu y touches tout est pété). Le sprite par sprite, si tu veux une autre tenue, il faut exporter une autre animation.

En gros, et à plus forte raison si c'est un "petit" projet, fais ce avec quoi tu te sens le mieux  ::):

----------


## schouffy

Y'a aussi le fait que l'anim par squelette te demandera moins de temps et de talent (même moi je peux en faire :x), pour un résultat bien inférieur.

----------


## Ashley TOUCRU

Merci pour vos réponses. Ca confirme mon impression que le réaliser dans Unity sous forme de squelette me simplifierait la vie.  :;): 
Les spritesheets dont tu fais mention, Grhyll, ce sont bien ces planches sur lesquelles on place tous les éléments du sprite ?  ::huh::  Du coup, comment ça fonctionne ? Imaginons que mon perso soit nu au départ et que je veuille ensuite lui ajouter des accessoires, je peux compléter la spritesheet ou il me faut en créer un nouvelle ?  ::huh:: 

Pour vous rendre compte, voici l'ébauche de mon animation... réalisée il y a bien trop longtemps déjà :



Et le décor :



Comme chuis une grosse feignasse, je n'ai pas travaillé dessus depuis des mois.  :tired: 
Pas que le projet soit indispensable à l'humanité, mais disons que n'ayant jamais rien codé et ne connaissant le jeu vidéo qu'en tant qu'utilisateur, la tâche me paraît presque insurmontable.  ::O:  'Faut vraiment que je me colle un gros coup de pied au derrière et que j'essaie au moins de produire un tableau.  ::sad:: 

J'avais fait un essai à l'arrache pour voir comment rendait la parallaxe du décor, ça me satisfaisait plutôt. Mais la question que je m'étais posée à l'époque, c'était comment réaliser l'ensemble du décor sans que ça pèse un âne mort et que ça râme.  ::sad::  L'ensemble est composé de tiles de 128x128, dans mon souvenir, que l'on peut assembler à volonté. Ca vous paraît à peu près cohérent ou est-ce qu'il vous apparaît déjà des erreurs grossières de débutant dans ces graphismes basiques ?  ::unsure::

----------


## schouffy

Une spritesheet c'est juste les images successives de ton animation, les unes à la suite des autres. Dans une animation par squelette, il n'y en a pas.
Sinon il n'y a pas d'erreur dans ce que tu fais (autant que je sache). Unity essaie de render uniquement ce qui est à l'écran en ignorant le reste. Oublie les performances pour l'instant, tu pourras toujours y réfléchir plus tard, fais toi plaisir pour le moment  :;):

----------


## Ashley TOUCRU

> Merci pour l'info !
> Un lien : https://www.humblebundle.com/books/u...y5-book-bundle
> 
> Couyu: y'a un ebook "learning c# by developing games". ça vaut le coup de jeter un oeil.


Finalement j'ai craqué pour 15 euros. En plus d'apprendre le C# et Unity, ça me fera bosser mon anglais.  ::P:  Et puis, le fait de faire oeuvre de charité m'a convaincu. Merci pour l'info, les amis.  :;): 

- - - Mise à jour - - -




> Une spritesheet c'est juste les images successives de ton animation, les unes à la suite des autres. Dans une animation par squelette, il n'y en a pas.
> Sinon il n'y a pas d'erreur dans ce que tu fais (autant que je sache). Unity essaie de render uniquement ce qui est à l'écran en ignorant le reste. Oublie les performances pour l'instant, tu pourras toujours y réfléchir plus tard, fais toi plaisir pour le moment


OK, merci. Alors je fonce tête baissée !  ::lol::  Et maintenant que j'ai tous les manuels, je n'ai plus droit à l'échec !  ::P:  Et si je n'y parviens pas, je chercherai quelqu'un qui a envie de coder.  :;):

----------


## Grhyll

> Y'a aussi le fait que l'anim par squelette te demandera moins de temps et de talent (même moi je peux en faire :x), pour un résultat bien inférieur.


Effectivement j'ai oublié de citer ce point, et c'est pas le moindre ^^'

Les spritesheets je me suis un peu emballé, tant que tu ne rencontres pas des problèmes de perf c'est pas vraiment utile de fouiller là-dedans ! Ceci dit ça peut être utilisé quel que soit le système que tu choisis, ça permet de réduire le nombre de drawcalls (donc de l'optimisation qui n'a pas lieu d'être tant que ça n'est pas un problème !). 

Concernant le nombre de tiles pour le décor, là encore ça dépend du système auquel tu destines ton jeu. Si c'est PC, fais juste au plus simple, il y a de bonnes chances pour que ça ne pose jamais de souci. Si c'est pour mobile et que tu veux supporter les appareils qui ne sont pas au top, il faudra faire attention à la taille totale des textures en mémoire, ça peut aller assez vite ! Sur des machines vieillissantes, au bout de 5 ou 6 textures de 2048*2048 ça commence déjà à s'essouffler un peu. 

Mais au final, comme dit Schouffy et comme tu as l'air d'avoir l'intention de le faire, ne te soucie pas trop de tout ça pour l'instant  ::):  Fais comme tu peux, tu apprendras en chemin ^^

----------


## Ashley TOUCRU

Merci. Je vais tâcher d'avancer un peu. On verra par la suite.  :;):

----------


## Zevka

Vous savez si il existe une bonne librairie/asset de pathfinding pour Unity ? De mémoire ils avaient introduit des outils directement dans le moteur, mais pas eu le temps de tester.

Ce dont j'ai besoin est assez simple, c'est pour un jeu en vue de dessus, 2.5D, pas de relief, IA très basique, genre à peine moins con qu'un minion de moba (mais idéalement je voudrais en mettre beaucoup). Mais sur le terrain j'ai prévu d'avoir beaucoup d'obstacles dont une grosse partie peut être détruits, donc ça peut évoluer. J'ai déjà fait des trucs du genre, mais ayant perdu pas mal de mes projets et ayant envie de me concentrer sur d'autre parties du jeu, je "sous-traiterais" bien ça, quitte à payer un asset si ça vaut le coup.

Idéalement, j'aimerais quelque chose que tu peux ajouter à un gameobject, qui te génère automatiquement des chemins (en indiquant départ, arrivée, et paramètres de collision) dans un format simple (genre un tableau de Vector3) qui peut être utilisé un peu comme on veut après.

EDIT: désolé si c'est facile à trouver, j'ai pas encore commencé à chercher, mais comme je préfère avoir des retours utilisateurs dans tout les cas...

----------


## Metalink

Bah dans Unity les navmesh font exactement ça, après j'en ai jamais utilisé mais c'est fait pour  :;): 
https://docs.unity3d.com/Manual/nav-...ngNavMesh.html

----------


## schouffy

Le navmesh est intégré, si ça répond pas bien à ton besoin t'as A* pathfinding.

----------


## Adu

https://www.packtpub.com/packt/offers/free-learning
Dépéchez vous de le récupérer greatos (juste s'inscrire et c'est tout)

----------


## Ashley TOUCRU

Chuis pas sur d'avoir bien compris : c'est payant ensuite, non ?  ::o:

----------


## Adu

Non, tu t inscris gratuitement, et tous les jours t as un ebook qui est proposé gratuitement. Et parfois, c'est sur Unity  :;):

----------


## Ashley TOUCRU

Ah OK. Alors je vais m'inscrire. Merci.  :;): 
*Edit :* OK, je viens de comprendre. Seul le livre en exergue est gratuit pendant un temps limité, les autres sont ceux passés pour lesquels il faut un abonnement. J'avais cliqué celui intitulé _Mastering Unity 2D..._.  ::):

----------


## Kupris

Merci pour le bon plan, ça fait un moment que j'entends parler de Docker au boulot  :;):

----------


## Molina

Vous en pensez quoi ? Un aprem pour l'architecture, 1 aprem pour colorier. C'est mon premier bâtiment, et avant je faisais que des pyramides maya  ::ninja::

----------


## Adu

De rien pour le plan, oui c'est juste un bouquin imposé par jour gratuit, mais ça revient régulièrement  ::):

----------


## Ashley TOUCRU

> Vous en pensez quoi ? Un aprem pour l'architecture, 1 aprem pour colorier. C'est mon premier bâtiment, et avant je faisais que des pyramides maya 
> https://scontent-cdt1-1.xx.fbcdn.net...85&oe=599831DF
> https://scontent-cdt1-1.xx.fbcdn.net...6f&oe=599933C4


Ben dans les années 90 ça aurait cartonné !  ::o: 
Plus sérieusement, je suis totalement incapable d'évaluer s'il s'agit d'une prouesse technique de réaliser un tel graphisme en une journée -je n'y connais strictement rien en graphisme 3D- mais le résultat est quand même vachement... comment dire... géométrique.  ::unsure::  Bon, c'est sûr que c'est plus élaboré qu'une pyramide.  ::ninja:: 
Je pense surtout que les textures sont dégueulasses et grossières. Par exemple, les pierres sur le côté de l'immeuble face à nous sont énormes. Et surtout, qui construit des immeubles en pierre de taille ?!  ::O:  J'imgine qu'avec des textures plus adaptées, ça rendrait déjà mieux. 
Bon, et puis si tu pouvais nous redresser cette perspective tordue avec de vraies verticales, ce serait mieux. Et qu'on voie aussi davantage la façade... Oui, j'ai horreur des perspectives de m...de (Cf. discussion photo).  ::P:

----------


## Molina

Ben à paris il y a plein d'immeuble en pierre de taille ^^ 

En tout merci pour ton retour. J'vais retravailler les textures je pense, peut être faire quelque chose de plus unis. Faut que je joue encore avec blender.

----------


## schouffy

Vu que tu vas bouffer pas de mal de ce que je trouve être de loin le pire aspect du modeling (à savoir l'uv unwrapping), voilà une super vidéo qui m'a bien aidé à l'époque :

----------


## botu

J'ai enfin termine mon petit court metrage dans unity, ce n'est pas un jeu, mais je ne savais pas trop ou le poster.
C'est pas parfait mais je me suis bien amuse a le faire  ::):  (l'anim du perso est basique, la prochaine fois je demanderai a un vrai animateur
de me donner un coup de main) 
C'est la premiere fois que je tente de creer la musique aussi.

----------


## Molina

Chapeau l'artiste !

----------


## Grhyll

Woah  ::wub:: 

C'est super impressionnant ! Tu es à l'origine de tout là-dedans ? (Et la musique est très très réussie !)

----------


## botu

Oui de tout, modelisation/sculpt, textures/shading, animation/setup, creation d'arbres dans speedtree,fx, musique.. Bon pour le montage ce n'etait pas difficile, je n'avais qu'a assembler
les shots (et j'ai en plus reussi a me planter  ::):  )

----------


## Molina

Si j'avais 1 dixième de ton talent... !  ::P:

----------


## Kupris

Ça impose le respect  :WTF: 

Combien d'heures de travail à la volée ?

----------


## botu

> Ça impose le respect 
> 
> Combien d'heures de travail à la volée ?


Au pif +- 100 heures. J'ai travaillé sur ce projet durant mon temps de midi au boulot a raison de +- 30 minutes par jour. Et de temps en temps le weekend chez moi. 
Mais c'est pas facile à évaluer, parfois je me prenais une pause (surtout quand un bon jeu sortait  ::):  )

----------


## LeRan

En tous cas ça en jette un max ! Il ne manque plus qu'une jolie héroïne aux longues jambes et des effets pyrotechniques sans rapport avec l'intrigue, et c'est Final Fantasy  :;): 

Si je puis me permettre, avec quel outil as-tu fait la végétation ?

----------


## Grhyll

Speedtree a été cité un peu plus haut !

----------


## botu

> Speedtree a été cité un peu plus haut !


Tout a fait, speedtree modeler pour unity.

----------


## LeRan

> Tout a fait, speedtree modeler pour unity.


C'est ce dont je me sers aussi... Tu as fait toute la végétation à la main ?

Je voudrais bien qu'il soit possible d'échanger des modèles Speedtree pour Unity, ou d'en commander simplement à des artistes, mais comme Speedtree-Unity n'est pas compatible avec les autres moutures de Speedtree, tout ça est très difficile  ::(:  En plus, l'équipe de Speedtree est très possessive avec ses modèles, la licence ne permet même pas aux créateurs de proposer leurs arbres sur l'asset-store de Unity, seuls les arbres faits par l'équipe Speedtree elle-même ont droit de cité on dirait...

----------


## botu

> C'est ce dont je me sers aussi... Tu as fait toute la végétation à la main ?
> 
> Je voudrais bien qu'il soit possible d'échanger des modèles Speedtree pour Unity, ou d'en commander simplement à des artistes, mais comme Speedtree-Unity n'est pas compatible avec les autres moutures de Speedtree, tout ça est très difficile  En plus, l'équipe de Speedtree est très possessive avec ses modèles, la licence ne permet même pas aux créateurs de proposer leurs arbres sur l'asset-store de Unity, seuls les arbres faits par l'équipe Speedtree elle-même ont droit de cité on dirait...


Tu pourrais commander des arbres a des personnes. Je pense que c'est ok, par contre en effet il n'est pas autorise de vendre les arbres dans un shop online. Perso j'ai profite de promos et des packs gratuits que speedtree donne au debut de chaque mois. Ca m'a fourni une bonne base pour les textures de feuilles et de troncs pour les arbres realises a 100% sinon je modifiais des existants. pour la vegetation, c'est modelise dans maya et le shader utilise est Advance folliage shader qui permet d'avoir une belle translucence.

----------


## Molina

Dites, J'ai une question de n00b sur le _Modular environments_ (ME).

Je trouve le concept génial, qui peut changer ma vie pour longtemps. Ca simplifie le dépliage des UV, la texturation, la construction des niveaux ...Bref je vois que des avantages et je m'en méfie. 

Du coup, je ne suis pas certain de comprendre le concept. Est ce que ça veut dire que je peux créer un bout de sol de 2x2, un bout de mur de 2x1, un autre de 2x2 et créer tout un environnement avec ça (ça serait très cubique mais passons) ?

Je vais aller plus : Disons que je veux un mur en brique. Soit je prends une texture de brique que j'applique à un mur lisse ou alors.. 

Ou alors je crée une brique, je duplique cette brique pour avoir un bout de mur, et avec ce bout de mur je peux avoir mon mur de 10 mètre de long. C'est génial (et je préfère) mais est ce que ça pompe pas trop de ressource ? 

J'ai quand même beaucoup de mal à voir en quoi ce n'est pas un problème. Un sol unifié et carré de 40 m², c'est 4 vertex. En ME, c'est 40 vertex. 

Du coup, est ce que ce n'est pas une technique à utiliser avec parcimonie ?

----------


## Janer

> Dites, J'ai une question de n00b sur le _Modular environments_ (ME).
> 
> Je trouve le concept génial, qui peut changer ma vie pour longtemps. Ca simplifie le dépliage des UV, la texturation, la construction des niveaux ...Bref je vois que des avantages et je m'en méfie. 
> 
> Du coup, je ne suis pas certain de comprendre le concept. Est ce que ça veut dire que je peux créer un bout de sol de 2x2, un bout de mur de 2x1, un autre de 2x2 et créer tout un environnement avec ça (ça serait très cubique mais passons) ?
> 
> Je vais aller plus : Disons que je veux un mur en brique. Soit je prends une texture de brique que j'applique à un mur lisse ou alors.. 
> 
> Ou alors je crée une brique, je duplique cette brique pour avoir un bout de mur, et avec ce bout de mur je peux avoir mon mur de 10 mètre de long. C'est génial (et je préfère) mais est ce que ça pompe pas trop de ressource ? 
> ...


De mon point de vue, et concernant les platformes PC, le bottleneck pour la carte graphique c'est plus trop la puissance de calcul mais plutôt la bande passante (grosse simplification ça dépend des cas, mais souvent vrai). Donc à partir du moment où les élements sont bien batchés (si c'est du décor statique par exemple ça devrait pas être trop dur), et que le nombre de draw call reste raisonnable ça devrait aller. 

Après 2x1 c'est petit quand même. Essaye de créer des 4x4, 8x8. Et y'a aussi un truc sympa qui s'appelle GPU instancing. (https://catlikecoding.com/unity/tuto...ering/part-19/)

Ton exemple avec une brique est un peu extrême quand même. Si c'est généralisé pour tout dans un monde géant ça peut finir par piquer. Mais à l'échelle de bouts élémentaires 1x1m ça peut aller! Pour pas que ça soit cubique faut faire varier tes modules élémentaires.

----------


## Molina

Cool, merci Janer !

----------


## Mechaick

Bien le bonjour a tous ! 

J'aimerais programmer un petit jeu en 2d vue de dessus (disons dans un style the escapist ou rimworld).
J'avais commencé l'année dernière à apprendre le C++ pour cela. Cependant mon programme traînait et avec l'arrivée d'une deuxième année de Prépa, je n'avais plus la tête a ça.
Maintenant que tout ça est fini, j'ai décidé de m'y remettre et sur Unity cette fois. Pensez vous que c'est une bonne idée ? et quels tuto me recommanderiez vous pour mon projet ?

Je vous remercie.

----------


## yourykiki

Il y a un tuto officiel pour un mini rogue like en 2D presque vu du dessus

https://unity3d.com/learn/tutorials/...elike-tutorial

----------


## Metalink

Ce tuto est vraiment pas mal pour apprendre les bases, je confirme  ::):

----------


## Mechaick

Ha ben ça tombe bien c'est le tuto que je  bosse la ^^

----------


## schouffy

Juste un petit message pour dire que ce bundle est intéressant financièrement pour les assets qu'il contient : https://www.humblebundle.com/games/unity-bundle

----------


## Grhyll

Ah oui je l'ai pris, pas pensé à partager le lien ici ^^
(Gaia a l'air assez intéressant surtout, et le pack de mille milliards de monstres peut être cool pour prototyper !)

----------


## schouffy

J'avais déjà UFPS d'ailleurs, je peux le refiler à quelqu'un ici si intéressé.

----------


## Metalink

C'est dommage, personnellement y'a rien qui m'intéresse dedans  ::(:  A part éventuellement Gaia qui est super puissant, mais dont j'aurais jamais l'utilité  ::P:

----------


## LeRan

> C'est dommage, personnellement y'a rien qui m'intéresse dedans  A part éventuellement Gaia qui est super puissant, mais dont j'aurais jamais l'utilité


Ah ben tiens, j'étais justement en train de réfléchir pas plus tard qu'hier à acheter Gaia, dont justement j'aurais l'utilité  ::): 

Le truc c'est que j'ai jamais utilisé Humble Bundle et que j'ai un peu de mal à comprendre comment ça fonctionne... Genre là si je paye 12,92 € je reçois Gaia plus divers autres trucs ? Sans abonnement, sans vendre mon âme ni plus généralement signer aucun contrat avec mon sang ?

----------


## schouffy

Tout a fait. Et tu peux essayer de refourguer ou donner ce que tu n'utilisez pas. Il y a des topics pour ça.

----------


## LeRan

C'est trop beau pour être vrai ! Gaïa ça coûte dans les 50 € et j'en ai besoin... C'est quoi le coup fourré ? Ils vont me refourguer un abonnement en douce ?

----------


## Poussin Joyeux

> C'est trop beau pour être vrai ! Gaïa ça coûte dans les 50 € et j'en ai besoin... C'est quoi le coup fourré ? Ils vont me refourguer un abonnement en douce ?


Même pas. L'intérêt des Bundles c'est que ça fait plein de softs ou jeux pas chers mais vendus pendant une période limitée. Donc forte attraction et visibilité.

Mais comme tu ne connaissais pas avant, méfie toi car on y prend vite goût à ces bonnes affaires et ensuite on accumule, accumule, accumule... sans trop utiliser !  ::P:

----------


## schouffy

LeRan, je pense que tu confonds avec Humble Monthly, qui lui est bien un abonnement mensuel.
Les Humble Bundle, ce sont juste des achats de clés standard, le seul pré-requis étant de créer un compte sur le site, comme sur tous les sites quand tu passes une commande.
Bref, tu peux acheter Gaia  ::):  Et fais nous un petit retour ici, je suis très curieux de savoir ce que vaut cet asset !

----------


## Yves Signal

Boi, il fallait que je me mette à apprendre l'UE4 pour qu'un bundle comme ça soit me fasse hésiter  ::sad:: 
Personne ne développe sur l'Unreal Engine par ici ?  ::unsure::

----------


## schouffy

Dans UE4 y'a de super outils et le rendu est top de base.
Mais bon je suis beaucoup moins productif en C++ et j'aime bien le workflow d'Unity.

----------


## LeRan

> Bref, tu peux acheter Gaia  Et fais nous un petit retour ici, je suis très curieux de savoir ce que vaut cet asset !


Bon en tous cas c'était pas une arnaque : pour seulement 15 €, et en fournissant au site le code de ma carte bleu, celui de l'alarme et la cachette de la clef de secours, j'ai Gaïa et plein d'autres trucs chouettes !

J'ai pas encore commencé à maniper avec Gaïa, pour l'instant je regarde des tutoriels en ligne, l'outil a l'air puissant, il permet de faire très facilement des choses jolies, mais comme j'ai un résultat très précis en tête il faut que j'apprenne à tout paramétrer finement. Mais j'ai bon espoir  ::): 




> Boi, il fallait que je me mette à apprendre l'UE4 pour qu'un bundle comme ça soit me fasse hésiter 
> Personne ne développe sur l'Unreal Engine par ici ?


Nan. Unreal Engine a une réputation d'outil pour l'élite, et j'ai une vraie conscience prolétarienne, moi, monsieur.

Ceci dit j'ai hésité entre me remettre au C++ et me mettre au C#, et le fait que la communauté autour de Unity avait l'air plus active m'a fait franchir le pas. Mais il semble que le rendu visuel d'UE soit un peu plus joli, si j'en crois les on-dit.

----------


## Yves Signal

Je vais terminer le tuto d'Open Class Room sur l'UE, mais quoi qu'il en soit j'ai pris le humble bundle, ne serait-ce que pour Shadow Tactics.

Je crois que la réputation de l'UE est surtout due à l'absence de documentation fournie et d'une communauté forcément moins dense que celle d'Unity, points qui me semblent désormais révolus.
Au niveau des bons points et en dehors du rendu il y a quand même leur système intégré de visual scripting et le système des blueprints qui me semblent être un argument majeur du moteur.

J'ai craqué pour le bundle justement parce qu'il y avait un outil de visual scripting et une chiée d'asets.

Donc une fois que j'ai terminé le tuto UE4, je passe sur le tuto Unity pour le rogue like et je verrai ce que je fais.

Avec mon absence de notions viables en programmation et game design je prédis une certaine violence  ::XD::

----------


## Molina

> Bon en tous cas c'était pas une arnaque : pour seulement 15 €, et en fournissant au site le code de ma carte bleu, celui de l'alarme et la cachette de la clef de secours, j'ai Gaïa et plein d'autres trucs chouettes !
> 
> J'ai pas encore commencé à maniper avec Gaïa, pour l'instant je regarde des tutoriels en ligne, l'outil a l'air puissant, il permet de faire très facilement des choses jolies, mais comme j'ai un résultat très précis en tête il faut que j'apprenne à tout paramétrer finement. Mais j'ai bon espoir 
> 
> 
> Nan. Unreal Engine a une réputation d'outil pour l'élite, et j'ai une vraie conscience prolétarienne, moi, monsieur.
> 
> Ceci dit j'ai hésité entre me remettre au C++ et me mettre au C#, et le fait que la communauté autour de Unity avait l'air plus active m'a fait franchir le pas. Mais il semble que le rendu visuel d'UE soit un peu plus joli, si j'en crois les on-dit.


Bof, c'est surtout qu'avec Unity tu as beaucoup d'amateur, donc forcément, le rendu est moins bon que sur UE. 
Mais sinon si tu as le talent et le temps, tu peux faire des trucs chiadés avec Unity.

----------


## schouffy

> Je crois que la réputation de l'UE est surtout due à l'absence de documentation fournie et d'une communauté forcément moins dense que celle d'Unity, points qui me semblent désormais révolus.
> Au niveau des bons points et en dehors du rendu il y a quand même leur système intégré de visual scripting et le système des blueprints qui me semblent être un argument majeur du moteur.


Le visual scripting, en tant que dév je trouve que c'est une hérésie, c'est plus long à écrire, moins performant, moins efficace et moins lisible que du code.
Je sais pas si y'a vraiment des gens qui font des gens entier comme ça mais ça doit pas être très beau à voir.

----------


## Yves Signal

Oui, mais si tu n'es pas dev... et que tu n'as aucune notion de C# ou C++ (pile mon cas) ?  ::P:

----------


## schouffy

Perso je trouve ça un peu illusoire de se dire qu'on peut faire un "vrai" jeu sans taper de code.
Et les techniques qu'ils ont trouvées pour le faire sont contre productives à mon sens. Quitte à apprendre un système de programmation, autant apprendre le code. De toute façon l'esprit est le même, mais au lieu de taper de l'anglais saupoudré de maths tu relies des noeuds dans un arbre. La façon de penser est exactement la même, quand tu relies des noeuds tu codes, c'est juste que tu te spécialises dans une façon de coder que tu ne pourras pas réutiliser ailleurs (et qui est beaucoup moins productive).

Enfin c'est mon point de vue sur ces trucs.

----------


## Yves Signal

Je ne le vois pas comme un substitut non plus, plutôt comme un premier pied à l'étrier pas trop repoussant.
Je te rejoins là-dessus, ça sera indispensable.

En tout cas ça a le mérite de ne pas sabrer la logique ni le langage, j'ai vite retrouvé la logique que j'avais apprise dans ma formation universitaire (déjà loin) de Java.

Mais mets un parfait débutant devant un cours de 50h de C# ou C++ et il partira en courant... Et moi aussi d'ailleurs.
C'est bienvenu et motivant de pouvoir bricoler quelques trucs de façon presque instantané.

----------


## LeRan

> Perso je trouve ça un peu illusoire de se dire qu'on peut faire un "vrai" jeu sans taper de code.
> Et les techniques qu'ils ont trouvées pour le faire sont contre productives à mon sens. Quitte à apprendre un système de programmation, autant apprendre le code. De toute façon l'esprit est le même, mais au lieu de taper de l'anglais saupoudré de maths tu relies des noeuds dans un arbre. La façon de penser est exactement la même, quand tu relies des noeuds tu codes, c'est juste que tu te spécialises dans une façon de coder que tu ne pourras pas réutiliser ailleurs (et qui est beaucoup moins productive).
> 
> Enfin c'est mon point de vue sur ces trucs.


Quand je regarde les dizaines de milliers de lignes de code qu'il faut pour un projet pourtant modeste, et la quantité de rustines hackéiformes qu'il faut écrire honteusement ici et là pour que ça tourne proprement même en étant un codeur ultra-consciencieux et ordonné, je ne vois même pas comment c'est possible de faire ça avec des noeuds et des lignes.

Le cauchemar  ::O: 

Ceci dit respect pour ceux qui y arrivent.




> Mais mets un parfait débutant devant un cours de 50h de C# ou C++ et il partira en courant... Et moi aussi d'ailleurs.
> C'est bienvenu et motivant de pouvoir bricoler quelques trucs de façon presque instantané.


D'mon temps on codait du Turbo Pascal sur un éditeur de texte et on n'était pas plus malheureux.  ::|: 

Ceci dit la seule présence d'un ordinateur dans la pièce était déjà quelque chose d'excitant alors la motivation n'avait rien à voir  ::):

----------


## schouffy

> Je ne le vois pas comme un substitut non plus, plutôt comme un premier pied à l'étrier pas trop repoussant.
> Je te rejoins là-dessus, ça sera indispensable.


Si c'est juste pour te mettre dedans et apprendre, alors le bundle que tu viens d'acheter contient 1 (voire 2 je crois) système de programmation visuelle (dont un très proche des blueprint et qui est bien noté).
Tu es également possesseur d'un ensemble de cours pour faire une dizaine de jeux sur Unity, qui semblent être de qualité professionnelle et qui t'enseigneront en passant les bases du C# et la façon de l'utiliser efficacement dans Unity. Tu n'as pas besoin d'être un expert C# pour faire des trucs super dans Unity, quelques connaissances de base sont suffisantes et le système de Behavior de Unity t'encadre pas mal ce qui te permet de focus sur ton game design.

Je ne cherche pas à te forcer à utiliser une solution plutôt qu'une autre hein, UE4 et Unity sont tous les deux géniaux et je te conseille de faire ce qui te parait le mieux pour toi sachant que dans tous les cas tu ne perdras pas ton temps, mais sache que tu as déjà tout ça  ::):

----------


## Ashley TOUCRU

> Ceci dit la seule présence d'un ordinateur dans la pièce était déjà quelque chose d'excitant alors la motivation n'avait rien à voir


En même temps, quand j'ai commencé à utiliser Photoshop dans les années 90, on savait tout faire avec le lasso. C'est pas pour autant que je ne me réjouis pas que des dizaines d'outils se soient fait jour.  ::ninja::  Je pense surtout que ceux qui ont pris le train en marche seront toujours un peu désavantagés par rapport à ceux qui ont les bases depuis longtemps et connaissent toutes les combines pour pallier les carences du logiciel/code.  :;):  Je crois que c'est ce que nous appelons, nous les vieux, "l'expérience".  ::rolleyes::

----------


## Yves Signal

> Si c'est juste pour te mettre dedans et apprendre, alors le bundle que tu viens d'acheter contient 1 (voire 2 je crois) système de programmation visuelle (dont un très proche des blueprint et qui est bien noté).
> Tu es également possesseur d'un ensemble de cours pour faire une dizaine de jeux sur Unity, qui semblent être de qualité professionnelle et qui t'enseigneront en passant les bases du C# et la façon de l'utiliser efficacement dans Unity. Tu n'as pas besoin d'être un expert C# pour faire des trucs super dans Unity, quelques connaissances de base sont suffisantes et le système de Behavior de Unity t'encadre pas mal ce qui te permet de focus sur ton game design.
> 
> Je ne cherche pas à te forcer à utiliser une solution plutôt qu'une autre hein, UE4 et Unity sont tous les deux géniaux et je te conseille de faire ce qui te parait le mieux pour toi sachant que dans tous les cas tu ne perdras pas ton temps, mais sache que tu as déjà tout ça


Oui c'est précisément pour les cours et l'outil de visual scripting que j'ai pris le bundle, ce pourra être les petites roulettes pour démarrer  :;): 
Contrairement à beaucoup de monde ici, je n'ai pas un projet précis en tête, je cherche juste à assimiler des notions de game design en mettant la main à la pâte (ce qu'on m'avait conseillé ici il y a quelques temps).
Une fois que j'aurais tripatouillé suffisamment un moteur, là je me lancerais dans la confection de prototypes rigolos pour coder des petites idées et concepts farfelus.

Du coup le choix du moteur ne s'opère pas par commodité puisque je suis plutôt dans une approche générale. Maintenant je constate que la base de canards sur Unity est bien plus importante, donc je ne vais pas balancer mon petit projet d'apprentissage Unreal Engine (considérant que de toute façon j'apprends en même temps des bases de conception JV), mais je tripatouillerai Unity avec ces nouvelles ressources une fois cette première étape terminée.

Mais la route promet d'être très longue, surtout que mes journées pro ne sont déjà pas particulièrement propice à un tel déploiement d'énergie une fois de retour à la maison  ::): 

@LeRan : ça devait être une sacrée époque  ::P:

----------


## Janer

> Le visual scripting, en tant que dév je trouve que c'est une hérésie, c'est plus long à écrire, moins performant, moins efficace et moins lisible que du code.
> Je sais pas si y'a vraiment des gens qui font des gens entier comme ça mais ça doit pas être très beau à voir.


J'arrive après la bataille, mais pour moi une bonne utilisation du visual scripting, c'est pour les designers qui utilisent ça en interface avec les systèmes crées par les programmeurs. C'est un peu comme la relation script écrits par des designers qui agissent avec le code du programmeur. Par exemple utiliser le visual scripting pour toute la logique du système de déplacement, ou de l'IA des ennemis c'est une using à gaz sur un gros jeu, mais l'utiliser pour par exemple "demander le spawn de 10 ennemis et leru assigner le comportement agressif" suite à l'interaction avec un levier, c'est une utilisation raisonable je pense. Le "vrai" code, lui s'occupe de gérer l'évènement de spawn, le choix des endroits de spawn, les checks de collision pour pas le faire spawner dans un mur, puis le loop IA sur ce que ça veut dire agressif, par exemple à quel state machine ça correspond etc... Bref, pour de la logique haut niveau. Pas pour les systèmes élémenaires.

----------


## schouffy

Oui je n'avais pas pensé à ça c'est vrai que c'est pas bête. Dans Unity ça n'est pas forcément utile vu que les inspecteurs sont super extensibles, mais dans UE4 ça peut avoir du sens de travailler comme ça.

----------


## Enyss

On pourrai par exemple imaginer, dans un RPG, écrire les quêtes en visual scripting. Ça me parait être une bonne utilisation de ce genre d'outils.

----------


## squintik

Ce qu'on appelle visual scripting aujourd'hui (en tout cas les Blueprint de UE4) n'a pas grand chose à voir avec le visual scripting de UE3 ou d'autres moteurs quand même.
Je trouve ça un peu dommage de se dire qu'il faut se limiter à de simples "je spawn 10 mecs" ou je fais une petite quête avec.
C'est devenu un outil très riche, qui permet de faire des tas de choses, et qui permet de s'organiser pour ne pas juste faire un script gigantesque illisible (c'est la même organisation que du code orienté objet, avec des classes avec héritage, fonctions, macros, enum, etc...), donc pour moi y a aucun problème à faire un jeu complet à base de blueprint, tant qu'on bosse pas sur un énorme projet ultra complexe.
Forcément, si on veut faire un MMO multi gigantesque qui a des milliers de système, c'est pas la meilleure idée de faire tout en blueprint  ::):  Mais pour des tas de jeux indé, je vois pas le problème de gérer ça en blueprint.
Je pense qu'y a autant de gens qui font du code illisible, horrible à débugger et qui pouprri les performances parce qu'ils codent ça avec leurs petits moyens ... que des gens qui font des blueprints illisibles, horribles à débugger et pourris en perf  ::): 
C'est surtout une question d'organisation et de maitrise de la technologie.

Du coup, vu que Couyu posait la question sur la page d'avant, j'en profite pour répondre que si, y a des gens qui développent sur Unreal ici. (perso, je fais des prototypes de jeu quand j'ai un peu de temps en tout cas, donc même si y a des trucs auxquels j'ai pas encore trop touché, hésite pas si t'as des questions !)
D'ailleurs je suis surpris qu'y ait pas de topic Unreal sur le forum, mais tant pis.

----------


## schouffy

C'est tout à fait vrai, mais les blueprints sont quand même beaucoup "volumineux" que le code quand tu les regardes. Donc du code pourri vs un blueprint pourri, le code aura l'avantage d'être (beaucoup) plus succinct.
Ou alors j'ai une méconnaissance quasi totale de l'outil, c'est possible aussi.

----------


## Janer

> Ce qu'on appelle visual scripting aujourd'hui (en tout cas les Blueprint de UE4) n'a pas grand chose à voir avec le visual scripting de UE3 ou d'autres moteurs quand même.
> Je trouve ça un peu dommage de se dire qu'il faut se limiter à de simples "je spawn 10 mecs" ou je fais une petite quête avec.
> C'est devenu un outil très riche, qui permet de faire des tas de choses, et qui permet de s'organiser pour ne pas juste faire un script gigantesque illisible (c'est la même organisation que du code orienté objet, avec des classes avec héritage, fonctions, macros, enum, etc...), donc pour moi y a aucun problème à faire un jeu complet à base de blueprint, tant qu'on bosse pas sur un énorme projet ultra complexe.
> Forcément, si on veut faire un MMO multi gigantesque qui a des milliers de système, c'est pas la meilleure idée de faire tout en blueprint  Mais pour des tas de jeux indé, je vois pas le problème de gérer ça en blueprint.
> Je pense qu'y a autant de gens qui font du code illisible, horrible à débugger et qui pouprri les performances parce qu'ils codent ça avec leurs petits moyens ... que des gens qui font des blueprints illisibles, horribles à débugger et pourris en perf 
> C'est surtout une question d'organisation et de maitrise de la technologie.
> 
> Du coup, vu que Couyu posait la question sur la page d'avant, j'en profite pour répondre que si, y a des gens qui développent sur Unreal ici. (perso, je fais des prototypes de jeu quand j'ai un peu de temps en tout cas, donc même si y a des trucs auxquels j'ai pas encore trop touché, hésite pas si t'as des questions !)
> D'ailleurs je suis surpris qu'y ait pas de topic Unreal sur le forum, mais tant pis.


Disons que pour moi ça se limite à des mécaniques relativement sumples et justement à du script! Je me verrai pas faire une IA compliqué où un système de génération procédurale un peu sophistiqué avec ? Après peut être que j'ai pas assez utilisé l'outil en effet. J'imagine aussi que si on a un jeu très "physique", on peut tout faire en visual scripting. L'essentiel de la complexité étant dans le moteur physique.

----------


## squintik

> Disons que pour moi ça se limite à des mécaniques relativement sumples et justement à du script! Je me verrai pas faire une IA compliqué où un système de génération procédurale un peu sophistiqué avec ? Après peut être que j'ai pas assez utilisé l'outil en effet. J'imagine aussi que si on a un jeu très "physique", on peut tout faire en visual scripting. L'essentiel de la complexité étant dans le moteur physique.


Pour une IA compliquée, il y a des systèmes dédiés à ça dans Unreal (comme dans beaucoup de moteurs de jeux), donc oui ce serait plutôt avec leurs Behavior Tree qu'avec les scripts Blueprint de base.
Mais aucun problème à faire une IA complexe avec ce système sans avoir à taper de code, c'est fait pour. (tout comme la plupart des gros jeux utilisent aussi des behavior tree et des tas de data du genre pour gérer leur IA, et non pas tout géré uniquement en code)
Pour le procédural, je pense pas qu'il y ait de gros problèmes non plus. Les construction script (équivalent des fonctions constructeurs) sont utiles pour ça par exemple, et vu que c'est pas exécuté en permanence, mais plutôt une fois au début du niveau en général, je vois pas de problème non plus.

C'est sûr que ça rajoute une surcouche en plus avec la Virtual Machine qui gère les Blueprints à l'exécution, mais à moins d'avoir des cas très complexes ou de vouloir le faire tourner sur du hardware très simple, je pense pas que ce soit critique ... mais je serai curieux de voir des benchmarks faits sur les différents cas. (code / blueprint / blueprint "nativisé")

----------


## Yves Signal

Bon ben j'ai terminé les leçons sur le 2DGame Kit.
C'est une bonne prise en main pour les débutants complets et c'est très ludique.

Pas une ligne de code, mais un bon moyen de s'approprier l'interface et de comprendre comment utiliser l'outil pour faire du level design, tout en ayant un aperçu du reste.
C'est un poil décourageant pour un novice de se rendre compte de l'ampleur de la tâche, mais je vais tenir bon.

Prochaine étape : me mettre à jour avec la dernière leçon de "Développez Couché" pour écrire un peu de C# (hors Unity) avant de m'essayer aux différents tutoriels de la partie Learn de Unity.

----------


## Ashley TOUCRU

Si jamais tu cherches à voir des cours pour débutants, t'as cette chaîne Youtube que j'avais trouvée sympa :

CasanisPlays

----------


## Yves Signal

C'est toujours bon à prendre !
Merci  :;):

----------


## Ashley TOUCRU

> C'est toujours bon à prendre !
> Merci


Ouais. Quand je m'étais un peu intéressé à Unity 3D (pour finalement abandonner lâchement…  ::unsure:: ), j'avais trouvé pas mal de tutos sur Youtube mais qui étaient souvent foireux ou incomplets, où les mecs naviguaient à vue, oubliaient des étapes… Bref, le meilleur moyen d'apprendre des conneries.  :tired:  Mais lui enseigne dans une école, et je trouve qu'il rend les choses à la fois claires et ludiques.  :;):

----------


## Louck

Brackeys est pas mal aussi.
https://www.youtube.com/user/Brackeys

----------


## Hyperpenguin

Pour le prix d'un jeu indé Switch j'avais choppé un cours en promo sur udemy, très bien fait et clair:
J'adore ce cours sur Udemy. Je pense qu'il pourrait t'intéresser aussi.
https://www.udemy.com/unitycourse/learn/v4/

Pas uniquement orienté 2D, mais très orienté "j'apprends le C# dans la foulée"

Édit: 
Alors là par exemple il est a 194€ mais ils font régulièrement des périodes de promo ou ça passe à 15/20€

----------


## Ashley TOUCRU

> Pour le prix d'un jeu indé Switch j'avais choppé un cours en promo sur udemy, très bien fait et clair:
> J'adore ce cours sur Udemy. Je pense qu'il pourrait t'intéresser aussi.
> https://www.udemy.com/unitycourse/learn/v4/
> 
> Pas uniquement orienté 2D, mais très orienté "j'apprends le C# dans la foulée"
> 
> Édit: 
> Alors là par exemple il est a 194€ mais ils font régulièrement des périodes de promo ou ça passe à 15/20€


10,99€, en l'occurrence.  ::rolleyes:: 

Moi, ce qui me tue, c'est qu'il soit aussi difficile d'en trouver en français, histoire de ne pas rajouter à la compréhension du cours celle de la langue. J'ai beau comprendre plutôt facilement l'anglais, c'est quand même moins fatiguant et plus naturel dans ma langue natale.  :tired: 
Sur Humble, j'avais acheté tout une série de bouquins numériques pour 15 euros qui étaient plutôt bien fichus aussi… en anglais toujours.  ::):

----------


## Yves Signal

Bon, ça y est : je me suis lancé.
Sur vos bons conseils j'ai attaqué également la programmation C#.

Et effectivement je vais me joindre à l'avis général : le cours (2D) de Ben Tristem et Rick Davidson est vraiment très bien fichu.
C'est accessible, même pour un gros naze dans mon genre, toujours très bien illustré et les profs maîtrise très bien l'outil vidéo.
C'est parsemé de petits challenges plutôt motivants et de petits traits d'humour, ça donne un tout très équilibré, plaisant et gratifiant.
À la fin de chaque gros chapitre, un QCM vient faire le point sur nos acquis et nous réorienter vers un chapitrage particulier en cas d'erreur.

Pour le moment, j'en suis à la fin de Text 101, autant dire qu'ils reste encore beaucoup de travail...
Surtout qu'il va falloir que je fasse une relecture rapide de tout ce qu'on assimile dans ce chapitre (c'est plutôt riche en enseignements), histoire d'être certain de tout avoir compris avant de passer à la suite.

Seul "inconvénient" en terme d'accessibilité : c'est en anglais. Personnellement ce n'est pas un problème, mais un niveau scolaire pourrait ne pas suffire, même avec des sous-titres.

Sur les conseils de Maximelene, j'ai également opté pour leurs cours 3D et RPG, qui apparemment sont du même tonneau.

À 11  ou 15€ l'unité, c'est vraiment un très très bon plan pour qui veut se lancer.

----------


## Paradox

> Moi, ce qui me tue, c'est qu'il soit aussi difficile d'en trouver en français, histoire de ne pas rajouter à la compréhension du cours celle de la langue. J'ai beau comprendre plutôt facilement l'anglais, c'est quand même moins fatiguant et plus naturel dans ma langue natale. 
> Sur Humble, j'avais acheté tout une série de bouquins numériques pour 15 euros qui étaient plutôt bien fichus aussi… en anglais toujours.


En meme temps, c'est logique : la majorite de la documentation/litterature scientifique et technique est en anglais...

----------


## Hideo

Y'a vraiment une grosse diff entre la version 2017 et 2018 d'unity (3D) ? 

Je m'y mettrai bien et je me ferai bien un petit cours video. Ceux de Ben Tristem et Rick Davidson me paraissent très bien mais sont sur la version 2017.
La partie code ne me fait pas vraiment peur, je suis dev mais pas du tout jv, du coup ce qui m’intéresse plus c'est justement tout ce qui est propre à Unity.

En passant, j'ai regardé quelques pages en arrière mais si vous avez des ressources intéressantes, toujours preneur  :;):

----------


## Enyss

Non, y'a pas de grosses différences, c'est une évolution continue du moteur

----------


## Yves Signal

@Hideo : le Unity 2D est mis à jour avec la version 2018 (du moins jusqu'à la fin du second jeu).
C'est peut-être le cas également pour les autres cours.

A priori les différences sont mineures, mais dans tous les cas tu as les anciens cours qui restent accessibles si tu veux comparer.

----------


## Metalink

Y'a des gros, gros ajouts dans 2018 qui changent beaucoup de choses (package manager, SRP, shadergraph, profiler d'UI, plein de trucs pour la 2D et j'en oublie une tonne), sans même parler de la 2018.3 qui arrive bientôt avec encore plein de nouveautés !

Mais je pense pas qu'apprendre avec un tuto dédié à 2017 soit vraiment un problème, le tout c'est d'apprendre à se servir du logiciel de manière globale et de comprendre sa philosophie, puis après de faire des recherches correspondant à ses besoin  ::):

----------


## Molina

> Bon, ça y est : je me suis lancé.
> Sur vos bons conseils j'ai attaqué également la programmation C#.
> 
> Et effectivement je vais me joindre à l'avis général : le cours (2D) de Ben Tristem et Rick Davidson est vraiment très bien fichu.
> C'est accessible, même pour un gros naze dans mon genre, toujours très bien illustré et les profs maîtrise très bien l'outil vidéo.
> C'est parsemé de petits challenges plutôt motivants et de petits traits d'humour, ça donne un tout très équilibré, plaisant et gratifiant.
> À la fin de chaque gros chapitre, un QCM vient faire le point sur nos acquis et nous réorienter vers un chapitrage particulier en cas d'erreur.
> 
> Pour le moment, j'en suis à la fin de Text 101, autant dire qu'ils reste encore beaucoup de travail...
> ...


Félicitation ! 
Par contre, fais gaffe, je trouve leur cours super, mais finalement trop long. C'est comme assimile, il faut être régulier !  :;): 
Le cours RPG, personnellement, je l'ai trouvé brouillon (ils ont beau se défendre  dans la réalité le developpement d'un jeu est bordélique... pédagogiquement c'est moyen).

- - - Mise à jour - - -




> En meme temps, c'est logique : la majorite de la documentation/litterature scientifique et technique est en anglais...


Ca donne plus d'effort, mais on retient mieux. Par exemple, je m'amuse à traduire toutes mes méthodes en français. Ca m'évite de copier bêtement, et ça permet de voir si j'ai compris.

----------


## Ashley TOUCRU

> En meme temps, c'est logique : la majorite de la documentation/litterature scientifique et technique est en anglais...


Logique, certes… Mais est-ce normal ?  ::rolleyes::  Les Français seraient-ils trop fainéants pour écrire dans leur propre langue ?  ::siffle::  Les traducteurs seraient-ils tous morts ?  ::o:  Dans ce cas, pourquoi traduire l'interface ?  :tired:

----------


## Enyss

Est-ce que tu aimerai que les italiens écrivent en italien, les allemands en allemand, les russes en russe, les coréens en coréen, etc. ?

----------


## Ashley TOUCRU

> Est-ce que tu aimerai*s* que les *I*taliens écrivent en italien, les *A*llemands en allemand, les *R*usses en russe, les *C*oréens en coréen, etc. ?


Oui, tout à fait. Ça pose un problème ?  ::huh::  Ça me paraît même plutôt logique et c'est le fait que tu poses la question qui me paraît insensé, personnellement.  ::O:  Y a un truc qu'on a inventé, c'est la traduction. Ça consiste à prendre un texte et le transformer dans une autre langue pour que ce soit plus facile à comprendre. Ça a un autre avantage : ça évite que ceux qui ne maîtrisent aucune des deux langues utilisent des mots à la place des autres, comme _versatile_ à la place de _polyvalent_, ou _digital_ à la place de _numérique_ par exemple. Y a des tas d'autres exemples…  ::):

----------


## Enyss

Ça me pose un problème de ne pas pouvoir avoir accès à ce qu'écrit plus de la moitié de l'humanité. 

Et la traduction, c'est bien gentil, mais si j'écris un truc, je vais pas le traduire dans les 23 langues principales, vu que je n'en ai pas la capacité, et je ne vais pas non payer un traducteur professionnel pour ça.

----------


## schouffy

Rien à voir avec Unity (quoique c'est fait avec) mais je suis tombé sur ça par hasard, c'est gratuit et ça a l'air de démonter.

----------


## Ashley TOUCRU

> Ça me pose un problème de ne pas pouvoir avoir accès à ce qu'écrit plus de la moitié de l'humanité. 
> Et la traduction, c'est bien gentil, mais si j'écris un truc, je vais pas le traduire dans les 23 langues principales, vu que je n'en ai pas la capacité, et je ne vais pas non payer un traducteur professionnel pour ça.


Ben ça c'est toi qui vois si tu veux être compris de tout le monde ou pas. Après, si chacun écrit dans sa propre langue, le problème ne se pose pas. On trouvera facilement des tutos dans toutes les langues.  :;): 
Si j'en crois ce tableau qui est bien renseigné, l'anglais ne représente "que" 26% des langues parlées (au grand maximum car il en manque un paquet, seules les plus parlées sont répertoriées ici). Certes le français ne représente que 5%, mais ça compte quand même.  ::rolleyes::  Je peux comprendre que l'anglais te satisfasse, mais ce n'est pas toujours mon cas bien que je le lise assez facilement.  :;): 

Du coup, j'en ai profité pour consulter *cette page.* Si le sujet t'intéresse, c'est très instructif.  :;):

----------


## Ashley TOUCRU

> Rien à voir avec Unity (quoique c'est fait avec) mais je suis tombé sur ça par hasard, c'est gratuit et ça a l'air de démonter.
> https://www.youtube.com/watch?v=vtnJToPxBNo


Purée, chuis bluffé !  ::O:  Depuis des années que je me demande si je serais capable de créer des textures pour du modding, ce programme pourrait être une façon d'expérimenter un peu.  ::o: 
Celle-ci est sympa aussi. Elle permet de bien comprendre les différentes options de texture pour un béotien comme moi.  ::):

----------


## schouffy

Pareil, aucun rapport, mais des trucs offerts pour Unreal Engine 4. Certains assets (sons notamment) doivent pouvoir être utilisés dans Unity, au moins pour prototyper.

https://www.unrealengine.com/en-US/b...ne-marketplace

----------


## Paradox

> Logique, certes… Mais est-ce normal ?  Les Français seraient-ils trop fainéants pour écrire dans leur propre langue ?  Les traducteurs seraient-ils tous morts ?  Dans ce cas, pourquoi traduire l'interface ?


Normal, oui, l'anglais est la lingua franca des sciences et techniques, et je ne vois aucunement l'interet de refaire quelque chose qui est deja fait. Sans compter qu'en plus de couter du temps et/pi de l'argent, la traduction peut vite devenir fausse voire incomprehensible : meme pour des notices d'utilisation d'appareils en tout genre, je ne compte plus dans mon entourage ou les temoignages de personnes allant se referer a un manuel papier, chercher la partie en anglais pour effectivement comprendre ce qui y est reellement dit...

Pour l'interface, c'est simple :
- soit ce sont des personnes comme toi qui tiennent au maintien de la langue francaise
- soit c'est pour des questions d'accessibilite (mais encore une fois, des que l'on s'eloigne du mainstream, on est pas sur que la traduction soit au rendez-vous - pas du tout ou pas de bonne facture)
- parfois c'est egalement une facon pour des personnes non-techniques de participer a un projet benevolement
- etc.

Il existe beaucoup de raisons, mais il serait plus simple de savoir de quoi l'on parle pour mieux cibler.

----------


## Paradox

> Oui, tout à fait. Ça pose un problème ?  Ça me paraît même plutôt logique et c'est le fait que tu poses la question qui me paraît insensé, personnellement.


Moi, ca me pose probleme en effet.

- l'anglais permet d'avoir une base commune (et c'est deja un GROS plus)
- ca permet une transmission sans barriere de langue, contrairement a ce que tu evoques
- ca permet une ouverture aux autres, parce que soyons honnetes, meme avec beaucoup de temps a y consacrer, peu d'entre nous ont le temps de maitriser 4 langues, qui plus est, "*utiles*"

Note que cela ne m'empeche pas de parler couramment 3 langues, et d'en comprendre 2 autres. Neanmoins quand a un peu de sens critique, on se rend bien compte qu'une situation abordee dans une langue, peut se voir vider de son sens une fois traduite, car elle aurait ete aborde differemment dans une autre. Parce qu'un langage, encore une fois contrairement a ce que tu dis, ce n'est pas une simple traduction, il y a un bagage derriere (culturel, etc.), d'ou l'interet voire la necessite d'une langue commune.




> Y a un truc qu'on a inventé, c'est la traduction. Ça consiste à prendre un texte et le transformer dans une autre langue pour que ce soit plus facile à comprendre. Ça a un autre avantage : ça évite que ceux qui ne maîtrisent aucune des deux langues utilisent des mots à la place des autres, comme _versatile_ à la place de _polyvalent_, ou _digital_ à la place de _numérique_ par exemple. Y a des tas d'autres exemples…


Pas la peine d'etre condescendante. Et tu remarqueras que tu confonds "traduction", qui est de tres mauvaise qualite de nos jours dans la vie de tous les jours, avec "anglicismes" qui est quelque chose qui me repugne egalement. Sauf que pour ce dernier aspect, ca a un interet : on "brouille" le sens des mots et pour ceux qui le font, ca a un interet specifique en fonction du mot et de son utilisation. Quelqu'un sait reellement ce que veut dire "digital marketing" ? Personne, et pire ca change d'un individu a l'autre ; on a donc perdu le seul interet de la traduction. Mais ca fait bien et on peut le mettre sur son CV et des fiches de postes alors on garde.

Enfin, tu feras gaffe, "versatile" existe en francais.

- - - Mise à jour - - -




> Ben ça c'est toi qui vois si tu veux être compris de tout le monde ou pas. Après, si chacun écrit dans sa propre langue, le problème ne se pose pas. On trouvera facilement des tutos dans toutes les langues.


Le probleme de la perte d'information/non-communication se pose.




> Si j'en crois ce tableau qui est bien renseigné, l'anglais ne représente "que" 26% des langues parlées (au grand maximum car il en manque un paquet, seules les plus parlées sont répertoriées ici). Certes le français ne représente que 5%, mais ça compte quand même.  Je peux comprendre que l'anglais te satisfasse, mais ce n'est pas toujours mon cas bien que je le lise assez facilement. 
> 
> Du coup, j'en ai profité pour consulter *cette page.* Si le sujet t'intéresse, c'est très instructif.


Je n'ai pas retrouve ton 26% si ce n'est dans l'origine de la langue anglaise donc j'imagine qu'il ne s'agit pas de ca ; corrige-moi si je me trompe. Et meme si c'etait le cas c'est deja enorme : il existerait entre 3000 et 7000 langues vivantes !

Apres, si l'on parle de l'ecrit, les proportions risquent d'exploser ; ayant travailler en France et a l'etranger, j'ai majoritairement travaille en anglais (a l'ecrit encore plus qu'a l'oral, et de loin), meme quand je parlais la langue du pays d'accueil... on en revient au cas d'ecole de... la documentation.  ::rolleyes::

----------


## Ashley TOUCRU

> Je n'ai pas retrouve ton 26%


J'ai pris ma calculatrice...  ::):

----------


## Paradox

> J'ai pris ma calculatrice...


... mais pas le temps d'expliquer ta methodologie.  ::rolleyes::

----------


## Yves Signal

Bon, casse brique 2D réalisé (après un jeu d'aventures textuelles et un petit jeu de maths).  ::): 

C'était long (probablement 12 heures de cours + beaucoup de temps à bricoler dans mon coin), mais j'ai appris énormément de choses :
Le système de scenesL'utilité des préfabsLa création de boutons et d'interfacesL'utilisation de modules complémentairesL'import d'assets depuis un packageL'utilisation des rigid bodies et un petit dépatouillage avec la physiqueLa gestion des collisions et des triggersL'ajout de sound effects et vfx

Et parmi une quantités de choses supplémentaires, j'ai énormément progressé en C# (oui bon, je partais de zéro).
Pour un mec qui n'a fait que 2 mois de java il y a 8 ans je suis pas peu fier de moi.

Bon, la route est encore très longue, mais je suis super motivé.  ::):

----------


## Metalink

Bien joué et bon courage, c'est super satisfaisant de créer ses premiers trucs au début !
Hésite pas si jamais t'as des questions  :;):

----------


## Yves Signal

Parce qu'après ça... devient absolument pas satisfaisant ?  :Emo: 

Merci pour les encouragements et la proposition en tout cas, on verra de quoi demain sera fait  :^_^:

----------


## Metalink

Si bien sur, mais perso plus de 10 ans après je me souviens plus de mes premières compilations que de ce que je fais toute la journée  ::P:

----------


## Molina

> Parce qu'après ça... devient absolument pas satisfaisant ? 
> 
> Merci pour les encouragements et la proposition en tout cas, on verra de quoi demain sera fait


Moi je, personnellement..
Ce que je remarque, c'est qu'il y a un gap entre suivre un tuto (et inventer par dessus) et inventer un jeu à partir de rien. C'est une manière de penser absolument différente qui demande de s'adapter. En fait d'un point de vue personnel, inventer son propre jeu, j'ai l'impression de travailler sur ma thèse. J'ai un but (faire ceci ou faire cela) y'a des tutos qui m'expliquent grosso merdo comment faire, mais forcément tout ne sera pas adaptable à mon propre jeu. Du coup, faut se démerder tout seul et personne pourra t'aider. T'es tout seul avec ton skills que tu dois améliorer sur le pouce. Et chaque itération devient une montagne de nouveau truc à apprendre, des nouveaux liens à tisser (souvent je sais les choses mais je les ai jamais appliqué dans ce nouvel environnement).

Et dans ce sens, c'est très proche avec la thèse. Tu lis un article tu te dis "ouai c'est bon, les mecs ont fait ça et ça et roule ma poule". Sauf qu'une fois que tu as ton propre projet... ben même les trucs triviaux deviennent compliqués.  :^_^:

----------


## Yves Signal

Ah mais c'est clair que j'ai hâte de passer sur des protos persos.
Mais là, maintenant tout de suite, j'ai zéro compétence en quoi que ce soit, donc il faut bien commencer quelque part.

D'où les cours, réellement indispensables.
Et ils sont suffisamment bien foutus pour te laisser te démerder, j'ai passé pas mal de temps à éplucher la documentation et à réaliser les exercices d'anticipation où le prof te donne un objectif à atteindre.
Ce n'est pas insurmontable, mais ça m'aide vraiment à m'approprier le projet plutôt que de bêtement recopier le code.

----------


## Ashley TOUCRU

> …Ce n'est pas insurmontable, mais ça m'aide vraiment à m'approprier le projet plutôt que de bêtement recopier le code.


Cette phrase m'a ramené dans les années 80 où on tapait des pages entières de basic copiées depuis la revue Tilt… pour finalement obtenir à chaque fois un résultat buggué sans être capable de comprendre pourquoi.  ::P:  Mais bon, à côté du Logo, c'était une promenade de santé.  :^_^:

----------


## Hideo

Pouet. 

Je savais pas trop ou poser ma question, ici ça me parait pas mal. 

J'aimerai trouver une solution pour détecter ce genre de mouvement pour pouvoir réduire ou faire sauter la physique pour le stopper.  J'ai quelques idées mais tout me parait très lourd en terme de traitement.
Le truc c'est que je veux "stabiliser" l'object uniquement quand les forces "s'équilibrent". Normalement le gameobject est tracté vers le(s) point(s) d'accroche.
La comme ça si ça vous inspire vous feriez comment ? 
En sachant que les deux cordes sont des linerenderer et j'applique une vélocité a mon GameObject vers chaque point d'accroche.

J'essaye de faire un equipement tridimensionnel à la Attack On Titans pour donner un peu de contexte  ::):

----------


## LaVaBo

Dans le jeu Attack on Titans, j'ai pas l'impression que la traction des cordes soit gérée avec un modèle physique.
J'ai l'impression que c'est plutôt une formule simple du style "quand les grappins sont accrochés aux points A et B, le perso accélère dans la direction où une droite qui part du PJ coupe (AB) perpendiculairement", avec les points A et B toujours devant le PJ. Et plus on est loin des points d'accroche, plus on accélère.

Il faut peut-être ajuster la direction de l'accélération, pour aller vers le milieu de [AB], ou vers un point de [AB] symétrique à la perpendiculaire de mon exemple par rapport au milieu du segment, pour simuler que le plus long brin tire plus que le plus court.

Utiliser le moteur physique pour gérer les forces de traction, ça me paraît lourd pour un truc qu'on peut sûrement extrapoler, avec potentiellement de meilleures sensations en se passant de réalisme physique (dans le jeu AoT, on ne respecte pas grand-chose des lois de la physique).

----------


## botu

Coucou, voici un nouveau terrain toujours crée dans unity. Juste une camera fixe et le vent qui souffle  ::):

----------


## Ashley TOUCRU

> Coucou, voici un nouveau terrain toujours crée dans unity. Juste une camera fixe et le vent qui souffle 
> https://www.youtube.com/watch?v=aXBziZnZpgc


C'est toi qui l'as créé ?  ::huh::  C'est jouli !  ::wub::

----------


## botu

> C'est toi qui l'as créé ?  C'est jouli !


Merci  ::):  oui c'est perso.

----------


## Ashley TOUCRU

> Merci  oui c'est perso.


 :Clap:

----------


## Hideo

> Dans le jeu Attack on Titans, j'ai pas l'impression que la traction des cordes soit gérée avec un modèle physique.
> J'ai l'impression que c'est plutôt une formule simple du style "quand les grappins sont accrochés aux points A et B, le perso accélère dans la direction où une droite qui part du PJ coupe (AB) perpendiculairement", avec les points A et B toujours devant le PJ. Et plus on est loin des points d'accroche, plus on accélère.
> 
> Il faut peut-être ajuster la direction de l'accélération, pour aller vers le milieu de [AB], ou vers un point de [AB] symétrique à la perpendiculaire de mon exemple par rapport au milieu du segment, pour simuler que le plus long brin tire plus que le plus court.
> 
> Utiliser le moteur physique pour gérer les forces de traction, ça me paraît lourd pour un truc qu'on peut sûrement extrapoler, avec potentiellement de meilleures sensations en se passant de réalisme physique (dans le jeu AoT, on ne respecte pas grand-chose des lois de la physique).


Au final effectivement je suis parti sur un truc un peu plus a la mano ça fonctionne très bien  :;):

----------


## Hyperpenguin

> Au final effectivement je suis parti sur un truc un peu plus a la mano ça fonctionne très bien


Et tu as très bien fait! Un moteur physique c'est parfait pour faire tomber des barils et des caisses mais pour gérer un personnage jouable ou équivalent c'est rapidement la galère!

----------


## Holdgling

Hello, j'ai une petite question, vous avez déjà fait mumuse avec ML-Agent (Machine Learning) pour le développement de vos IA sur Unity ?
J'essaie d'apprendre de mon côté, mais la documentation est très succincte, hormis les tutoriels fournis avec le package, j'ai un peu de mal à développement mon propre agent et je bloque sur deux~trois points ...

----------


## LaVaBo

Pour faire quoi ? C'est extrêmement dur d'exploiter une IA dans un jeu, et ça consomme beaucoup de ressources.

----------


## Grhyll

Pas encore essayé pour ma part, mais j'avoue que ça m'intrigue beaucoup :D

----------


## Silver

Je ne sais pas trop où le poster autre part dans cette section, mais il y a un Humble Bundle avec de nombreuses ressources graphiques 2D/2D iso/UI de RPG (principalement heroic fantasy) et des banques de sons pour pas cher en ce moment : https://www.humblebundle.com/softwar...ame-dev-bundle

----------


## Holdgling

Je dis pas qu'il y a forcément un intérêt pour le jeu en lui-même de faire du machine learning, je trouve juste ça super intéressant à pratiquer (et à apprendre par la même occasion), et il y a un potentiel monstre derrière cette technologie !
Cependant au niveau des documentation c'est pas folichon je trouve pour le moment

Sinon oui ça à l'air pas mal le humble bundle, c'est surtout de la 2D donc je suis pas trop intéressé mais c'est sympatoche !  ::):

----------


## Ashley TOUCRU

> Je dis pas qu'il y a forcément un intérêt pour le jeu en lui-même de faire du machine learning, je trouve juste ça super intéressant à pratiquer (et à apprendre par la même occasion), et il y a un potentiel monstre derrière cette technologie !


Oui, et comme pour toutes les nouveautés technologiques/numériques, plus tu apprends tôt et moins tu seras à la ramasse quand ça démarrera vraiment et deviendra utile.  ::o:

----------


## Janer

> Hello, j'ai une petite question, vous avez déjà fait mumuse avec ML-Agent (Machine Learning) pour le développement de vos IA sur Unity ?
> J'essaie d'apprendre de mon côté, mais la documentation est très succincte, hormis les tutoriels fournis avec le package, j'ai un peu de mal à développement mon propre agent et je bloque sur deux~trois points ...


Tu peux me poser tes questions, je suis spécialisé en ML et j'ai déjà fait des projets ML sur Unity.




> Pour faire quoi ? C'est extrêmement dur d'exploiter une IA dans un jeu, et ça consomme beaucoup de ressources.


Faux, c'est très dur à utiliser mais pas pour ça. L'apprentissage est coûteux, mais une fois appris le modèle prend ses décisions très rapidement, c'est pas ça le problème. Dans 99% des cas d'usage on préfera une méthode plus classique avec des arbres de décisions un modèle goal-oriented. Les problèmes sont, par ordre de difficulté croissant, la génération de données pertinentes (comment générer des données qui couvrent bien et sans biais les situations possibles?), la formalisation de l'espace de décision (comment faire rentrer notre problème dans le cadre formel du RL, comment définir un espace d'observation et un espace d'action raisonnable etc...) et enfin le contrôle de ce qui est appris (on se retrouve souvent avec un agent très performant masi au comportement peu organique, très gamey on va dire).

Si ça vous intéresse je peux vous parler rapidement des cas où c'est utile et développer un peu les difficultés rencontrées.

----------


## Ashley TOUCRU

> Faux, c'est très dur à utiliser mais pas pour ça. L'apprentissage est coûteux, mais une fois appris le modèle prend ses décisions très rapidement, c'est pas ça le problème. Dans 99% des cas d'usage on préfera une méthode plus classique avec des arbres de décisions un modèle goal-oriented. Les problèmes sont, par ordre de difficulté croissant, la génération de données pertinentes (comment générer des données qui couvrent bien et sans biais les situations possibles?), la formalisation de l'espace de décision (comment faire rentrer notre problème dans le cadre formel du RL, comment définir un espace d'observation et un espace d'action raisonnable etc...) et enfin le contrôle de ce qui est appris (on se retrouve souvent avec un agent très performant masi au comportement peu organique, très gamey on va dire).
> 
> Si ça vous intéresse je peux vous parler rapidement des cas où c'est utile et développer un peu les difficultés rencontrées.


J'ai rien compris !  ::P:  ...mais ça a l'air passionnant !  ::o:

----------


## Holdgling

Ha ca fait plaisir de voir quelqu'un qui maitrise le sujet  :;): 

(désolé pour les accents et les fautes ... etc, je ne suis pas illétré, j'ai juste un qwerty depuis quelque jours ...)

Alors voila mon probleme (simplifié le plus possible, ca risque de te paraitre tres primaire, mais c'est bien la ou j'en suis en terme d'apprentissage, c-a-d le niveau 0):
Si tu peux m'aider a me debloquer pour ce probleme tres simple, je suis preneur !

Ma scene est composée de deux gameObjects:
- Un chasseur, qui est l'agent qui se déplace, controlé par le brain
- Un chassé, qui ne se déplace pas, qui est la cible du chasseur

C'est une version extrémement simple (je me repete la) de ce que je souhaite réaliser réellement, mais il faut bien commencer quelque part ...


Donc, l'agent se déplace grace a un nav mesh agent, les coordonnées de destination sont celles du "chassé", elles sont écrites en dur dans le code, et ne changent jamais.
La seule chose qui est influencée par le brain c'est la vitesse de déplacement du "chasseur"

Il faut que le chasseur atteigne le plus rapidement possible le chassé, mais lorsqu'il est proche du chassé, il DOIT ralentir sinon il perd. Si il touche le chassé il gagne.
En gros le resultat attendu, c'est que le chasseur se deplace rapidement jusqu'au chassé, puis ralentisse quand il en est proche pour enfin le toucher.

Au niveau du code, ca donne ceci.

Fonction *AgentAction*



```
[...]
vitesse_chasseur = vectorAction[0] * 4f; //On change la vitesse du chasseur a chaque step, entre 0 et 4


AddReward(-0.001f); //Il faut que le chasseur soit rapide, donc on puni a chaque step


if(DistanceFromTarget() < 20.0f && vitesse_chasseur  > 2.0f) //Si le chasseur est proche, mais trop rapide il fait "peur" au chassé, et donc c'est perdu, on recommence
{
    AddReward(-1f *  DistanceFromTarget() / 20.0f);
    Done();
}

if(GotTarget() == true) //Victoire
{
    AddReward(1f);
    Done();
}
[...]
```

Et au niveau des observations, je remonte ceci dans la fonction *CollectObservations*:



```
[...]
AddVectorObs(DistanceFromTarget());
if(nav_mesh_agent != null)
{
    AddVectorObs(nav_mesh_agent.speed);
}
else
{
    AddVectorObs(0.0f);
}
[...]
```

Voila, ca me semble super simple pourtant le brain doit juste jouer sur la vitesse du chasseur ...
Ce qu'il semble se passer lors du training, c'est que le l'agent comprend bien qu'il faut aller le plus vite possible, cependant il ne comprend pas qu'il faut ralentir lorsqu'il arrive trop proche de la cible.

Est-ce que j'ai rate quelque chose concernant le machine learning ?
J'ai beau tenter des millions de choses differentes ca ne fonctionne pas, surtout pour une tache aussi simple ca ne devrait pas prendre beaucoup de step a etre maitrisé ... (la j'ai poussé jusqu'á 1 millions au cás ou, mais rien n'y fait.

Merci pour ton aide  ::): 
(Je suis conscient que c'est inutile et dispoportioné de faire du ML pour ca, je sais, c'est juste pour apprendre en pratiquant  ::): )

Je vais faire tourner un training cette nuit, ca en est la pour l'instant:
https://imgur.com/a/tsNr8k2
Ca confirme ce que je dis plus haut, l'agent va de plus en plus vite, mais perd systématiquement lorsqu'il est trop proche de la cible, et donc tend vers environ -0.0020 de reward (j'ai changé un peu les valeurs de reward par rapport a ce qu'il y a plus haut)

Edit: je commence a avoir des valeurs positives la au bout de 800 000 runs .... on verra demain au bout de 5 000 000

----------


## Enyss

Je ne comprends pas trop quelles informations tu fournis au "brain" et à quels moments.

----------


## Holdgling

Mince j'ai oublié de vous commenter ce bout de code

Les informations que j'envoie via la fonction *CollectObservations* correspondent a:

- La vitesse de l'agent
- La distance par rapport a la cible

Et c'est tout, c'est volontairement succint, mais selon moi il n'y a pas besoin de plus d'informations pour que le brain sache quoi faire

----------


## Janer

De ce que je vois, pas d'erreur fondamentale dans le code! Essaye de jouer avec les hyperparamètres de l'apprentissage pour voir, normalement c'est une tâche facile ça devrait pas poser problème à apprendre! Une possibilité, c'est qu'il est entré dans un minimum local sous-optimal (foncer pour minimiser les pertes) et il n'a même pas l'occasion d'expérimenter ce qui se passe si il avance doucement.

En effet, au début il a un comportement erratique. Il va avancer de façon complètement chaotique, aléatoire au départ. Quand il arrivera dans la zone "danger", la probabilité qu'à chaque frame sa vitesse soit inférieure à 2 jusqu'au bout risque d'être très faible et il risque de ne jamais y arriver. Pour vérifier ce fait, et d'autres informations utiles, je te propose de collecter plus d'infos que celles générées par défaut par unity (reward), telle que le nombre de fois qu'il arrive au bout, la distance moyenne atteinte, le temps moyen etc... Bref, du coup à mon avis, il va donc se rendre compte que ce qu'il a de mieux à faire c'est de foncer et après yolo, il aura déjà "brûlé" dans ses paramètres un fort biais pour que son action soit égale à 1. Tu peux remédier à cela en jouant sur les hyperparamètres qui favorisens l'exploration et réduisent le biais. 

Ce que tu peux faire aussi, c'est le guider un peu plus en lui donnant une petite récompense à chaque fois qu'il s'approche de la cible, comme ça il comprend plus vite qu'il doit avancer, et au moment où il devra apprendre à ralentir, les paramètres ne seront pas encore trop "brulés".

----------


## Holdgling

Merci pour ton retour  ::): 




> Ce que tu peux faire aussi, c'est le guider un peu plus en lui donnant une petite récompense à chaque fois qu'il s'approche de la cible, comme ça il comprend plus vite qu'il doit avancer, et au moment où il devra apprendre à ralentir, les paramètres ne seront pas encore trop "brulés".


Je viens de tenter de faire ca en modifiant le code suivant:


```
if(DistanceFromTarget() < 20.0f [...]
{
    AddReward(-1f *  DistanceFromTarget() / 20.0f);
    Done();
}
```

Par celui-ci:


```
if(DistanceFromTarget() < 20.0f [...]
{
    AddReward(1f *  DistanceFromTarget());
    Done();
}
```

Afin de donner une récompense plutot qu'une punition



```
[...]je te propose de collecter plus d'infos que celles générées par défaut par unity (reward), telle que le nombre de fois qu'il arrive au bout, la distance moyenne atteinte, le temps moyen etc...
```

Tu veux dire en remontant ces informations via des *AddVectorObs* ?



```
[...]Tu peux remédier à cela en jouant sur les hyperparamètres qui favorisens l'exploration et réduisent le biais[...]
```

Pour un néophyte comme moi, faut pas se leurrer, c'est ca qui est le plus intimidant
Par contre en observant le board tensorflow, je vois que l'entropy reste a une valeur raisonnable, ce qui, si je ne m'abuse, est sensé faire en sorte que les décisions restent aléatoires, du coup je n'ai pas forcément besoin de modifier mon parametre "Beta" tout de suite

https://imgur.com/a/5NFYjTi

Bon, je vais déja tenter en modifiant la reward recue quand on s'approche de la cible

----------


## Holdgling

Ca fonctionne enfin !
Je fais quelque tests et je posterai ce qui a fonctionné tout a l'heure  ::):

----------


## Janer

Si tu fais le changement que tu indiques il va juste s'arrêter à 20 il me semble, car c'est là qu'il peut collecter le plus de reward. Il faut que tu fasses un truc du genre vérifier que la distance from target a diminué et lui récompenser la diminution (normalisée pour qu'au total sur tout son parcours ça fasse 1). Il peut pas aller en arrière non? Mais tu gardes la pénalisation si il va trop vite, sinon il l'apprendra jamais.




> Merci pour ton retour 
> Tu veux dire en remontant ces informations via des *AddVectorObs* ?


Nein, pas du tout, en les enregistrant dans des structures de données C#classique et en printant (ou en écrivant dans un fichier) les statistiques qui t'intéressent! En gros c'est juste monitorer plus finement ce qui se passe.




> ```
> [...]Tu peux remédier à cela en jouant sur les hyperparamètres qui favorisens l'exploration et réduisent le biais[...]
> ```
> 
> Pour un néophyte comme moi, faut pas se leurrer, c'est ca qui est le plus intimidant
> Par contre en observant le board tensorflow, je vois que l'entropy reste a une valeur raisonnable, ce qui, si je ne m'abuse, est sensé faire en sorte que les décisions restent aléatoires, du coup je n'ai pas forcément besoin de modifier mon parametre "Beta" tout de suite
> 
> https://imgur.com/a/5NFYjTi
> 
> Bon, je vais déja tenter en modifiant la reward recue quand on s'approche de la cible


Ouai les hyperparamètres c'est ce qui demande ce qu'on appelle les "Dark Skills" dans le milieu. L'entropie ça donne un peu une idée mais c'est difficile à évaluer, vaut mieux utiliser tes propres observations.

----------


## Janer

> Ca fonctionne enfin !
> Je fais quelque tests et je posterai ce qui a fonctionné tout a l'heure


Ah super!

----------


## Adu

Hello !

Petite question moteurs de jeu ...
Voilà j'ai envie de me faire un petit plateformer en 2D (à base de sprites 2D, pas en 2,5D) Unity a-t-il maintenant un mode 2D bcp mieux gaulé ? Gère-t-il enfin bien les tilesets ?
Ou dois-je me tourner vers un moteur dédié genre Game Maker Studio 2, Godot ou autre ?

----------


## Janer

> Hello !
> 
> Petite question moteurs de jeu ...
> Voilà j'ai envie de me faire un petit plateformer en 2D (à base de sprites 2D, pas en 2,5D) Unity a-t-il maintenant un mode 2D bcp mieux gaulé ? Gère-t-il enfin bien les tilesets ?
> Ou dois-je me tourner vers un moteur dédié genre Game Maker Studio 2, Godot ou autre ?


Réponse courte : oui.

https://www.youtube.com/watch?v=bOOqMYFQL9I

----------


## Adu

> Réponse courte : oui.
> 
> https://www.youtube.com/watch?v=bOOqMYFQL9I


Merci !

----------


## Yves Signal

Question bête et un peu HS : Qu'utilisez-vous pour créer des Sprites et des animations ?

Pour le moment je veux faire des trucs tout simples et basiques, plus pour m'amuser qu'autre chose.
Tout ce que j'ai pour le moment c'est Illustrator CC que j'utilises pour dessiner quelques sprites 2D et After Effect (que je ne sais pas utiliser).

----------


## madgic

> Question bête et un peu HS : Qu'utilisez-vous pour créer des Sprites et des animations ?
> 
> Pour le moment je veux faire des trucs tout simples et basiques, plus pour m'amuser qu'autre chose.
> Tout ce que j'ai pour le moment c'est Illustrator CC que j'utilises pour dessiner quelques sprites 2D et After Effect (que je ne sais pas utiliser).


Il y a Spriter pro qui peut être utile pour les animations. Moi je l'ai eu dans un humble bundle, pour Steam. D'ailleurs dans le humble bundle cité page précédente, certains packs utilisent et fournissent les fichiers pour éditer les animations avec Spriter.

J'ai d'ailleurs une clé en rab provenant d'un autre Humble Bundle si tu veux. Contacte moi en mp si t'es intéressé  :;): 

ps : il y a eu une version 2 en development, qui sera gratuite pour ceux qui ont déjà la version 1, en tout cas sur Steam

----------


## Yves Signal

Oh <3

Ça a l'air super pratique et vraiment bien fichu, je te MP !

----------


## Metalink

Perso j'utilise Aseprite pour le pixel art, sinon Photoshop pour le reste  :;):

----------


## madgic

Sinon il y a DragonBones  en gratuit et open source mais jamais testé.

----------


## Paradox

> Sinon il y a DragonBones  en gratuit et open source mais jamais testé.


J'en avais entendu beaucoup de bien il y a quelques annees.

----------


## Yves Signal

Pour info, il y a des cours passés momentanément gratuits sur Udemy.

J'ai trouvé ça sur Dealabs, je vous mets le lien ici : https://www.dealabs.com/bons-plans/s...nglais-1398585

----------


## schouffy

Coin,

Sur l'optimisation graphique, j'ai une question assez simple.

Si je veux créer une map avec plein d'objets texturés (je pense à quelque chose d'assez simple, pensez au rendu des jeux Build Engine par exemple), vaut-il mieux avoir un seul material avec une grande texture atlas, ou une petite texture par objet ?
Si j'ai bien compris l'objectif est de diminuer les draw calls (donc un seul material), mais ça va pas prendre plus de VRAM si chaque objet utilise une grande texture ? Et plus de GPU car il y a plus de pixels dans la texture à afficher ?

De manière générale, avez-vous des liens intéressants pour l'optim graphique (je pense aux draw calls mais aussi à l'occlusion culling, aux LOD, à l'éclairage, aux différents post process et leur impact sur les performances,...).
Merci !  :;):

----------


## Grhyll

Pour ta question, ça sera a priori plus optimisé d'avoir un seul material ; tu auras un seul draw call, et la texture unique de toute façon ne sera pas beaucoup plus grande que toutes les petites textures additionnées. Après, fais gaffe à l'optimisation prématurée, est-ce que ta scène va vraiment avoir tant d'objet que ça va commencer à ramer ?

----------


## schouffy

Disons que je me cherche un workflow qui me plait et qui soit efficace pour la modélisation, et je voudrais juste pas tomber dans des pièges grossiers.
Mais j'en suis pas encore à compter les draw calls  ::):

----------


## raaaahman

Un cookbook gratuit sur Unity, ça peut en intéresser certains je crois: https://www.packtpub.com/packt/offers/free-learning

----------


## Sifr

Côté audio, pour sonoriser vos scenes, vous utilisez quoi comme sources qui passent bien dans le système audio de Unity ?

Y’a des références de liens qui existent quelque part ?

----------


## schouffy

Coucou les canards,
J'avais quelques idées de proto et j'essaie de me remettre dans le game et du coup j'ai installé une version récente d'Unity.
C'est moi ou tout est pété ? Avec le nouveau Scriptable Render Pipeline, on a perdu la compatibilité avec plein d'assets. Même des trucs venant d'Unity comme la Post Processing Stack affichent des erreurs même en utilisant l'ancien système de rendu. Quasiment chaque mise à jour pète des assets  ::o: 
Sauf que la nouvelle stack est pas prête du tout, plein de choses sont incompatibles ou semi-compatibles (ex les Terrain et la plupart des shaders). Les outils dédiés au SRP comme le shader graph ou le nouveau post process sont tout buggés et super difficiles à configurer et les performances sont horribles.
C'est moi qui rate quelque chose et qui doit revoir le SRP depuis 0, ou ils sont vraiment dans une période de transition où ni l'ancien ni le nouveau système sont viables et c'est pas le moment de faire du Unity ?
J'ai réinstallé l'UE4 et c'est la première fois que je pense sérieusement à basculer  ::(: 
Vous pensez quoi vous ?

----------


## Louck

Ça dépend de quelle version tu utilises. Si tu prends la toute dernière, elle sera truffé de bugs jusqu'à la moelle tant qu'elle n'aura pas ses hotfixs.

Perso c'est rare que je change de version, sauf s'il y a une feature qui est intéressante pour mes projets. Sinon je reste sur le LTS ou les versions compatible à mes projets.

Mais ouai, passer à une nouvelle version peut impliquer pas mal de modifs.

----------


## schouffy

Ben j'avais "un peu" l'habitude de ça, mais avec le nouveau pipeline de rendu j'ai vraiment l'impression qu'ils font ça beaucoup plus à l'arrache que de coutume.
Ils livrent des bribes de trucs tout en sachant que c'est inutilisable avec plein d'outils intégrés à Unity... Je trouve que ça fait très amateur comme démarche.

----------


## Louck

Aucune idée dans ce cas, désolé.

J'avais une histoire similaire quand ils ont sortis l'UNet. L'essentiel était là, mais il y avait pas mal de problèmes.
Du coup, je me fis pas trop aux dernières évolutions d'Unity. En général, il faut attendre une ou deux versions pour qu'ils puissent patcher la fonctionnalité et rajouter les méthodes manquantes pour que ca soit utilisable.

----------


## Grosnours

> Ben j'avais "un peu" l'habitude de ça, mais avec le nouveau pipeline de rendu j'ai vraiment l'impression qu'ils font ça beaucoup plus à l'arrache que de coutume.
> Ils livrent des bribes de trucs tout en sachant que c'est inutilisable avec plein d'outils intégrés à Unity... Je trouve que ça fait très amateur comme démarche.


Tout ce qui est pipeline de rendu nouveau modèle est indiqué comme Preview, donc ce n'est pas vraiment étonnant que c'est encore en chantier. Ajoute à cela que la plupart des producteurs d'assets attendent justement des versions plus matures pour produire des nouvelles versions compatibles et tu as effectivement un gros risque à vouloir être un early adopter si tu veux faire de la prod.
Maintenant c'est un peu habituel avec Unity ces temps-ci, avec par exemple l'Entity Component System qui est utilisable mais tout n'est pas compatible. Ça bouillonne sec et de tous les cotés chez Unity, avec beaucoup de changements plus ou moins radicaux dans les tuyaux donc si tu veux être à la pointe cela demande un certain investissement.

Bref je fais comme Louck et hors patchs essentiels de sécurité je préfère des versions (et assets/technologies) plus anciennes et éprouvées.

----------


## schouffy

Oui mais ce que je reproche, c'est que la PostProcessingStack du store par exemple, développée par Unity, et ciblant le legacy rendering pipeline, ne fonctionne plus non plus sur ce rendering pipeline (ok c'est juste quelques lignes de code à modifier, mais ça prouve qu'ils ont un peu arrêté de la maintenir).
En gros ils font des changements qui cassent l'existant, et les outils censés les remplacer ne sont pas prêts.

----------


## Molina

> Oui mais ce que je reproche, c'est que la PostProcessingStack du store par exemple, développée par Unity, et ciblant le legacy rendering pipeline, ne fonctionne plus non plus sur ce rendering pipeline (ok c'est juste quelques lignes de code à modifier, mais ça prouve qu'ils ont un peu arrêté de la maintenir).
> En gros ils font des changements qui cassent l'existant, et les outils censés les remplacer ne sont pas prêts.


Plus simplement, tu ne peux pas utiliser Unity 2018 ? C'est ce que j'ai fait, et je n'ai strictement aucun, mais alors aucun problème. En plus, ça m'évite de réapprendre l’ergonomie du logiciel.

----------


## Grosnours

Ah clairement, ils considèrent le legacy pipeline comme deprecated alors que le remplaçant est toujours en version bêta (je suis généreux).
Ceci dit je travaille en ce moment sur la 2018.3.8f1 et le post processing fonctionne correctement.

----------


## Molina

> Ah clairement, ils considèrent le legacy pipeline comme deprecated alors que le remplaçant est toujours en version bêta (je suis généreux).
> Ceci dit je travaille en ce moment sur la 2018.3.8f1 et le post processing fonctionne correctement.


Tu fais quoi ? Aller montre. Je trouve les canards bien timide avec leur création  :tired:

----------


## schouffy

> Plus simplement, tu ne peux pas utiliser Unity 2018 ? C'est ce que j'ai fait, et je n'ai strictement aucun, mais alors aucun problème. En plus, ça m'évite de réapprendre l’ergonomie du logiciel.


Si, si, bien obligé, je trouve juste que c'est pas professionnel comme attitude de leur part et j'aime me plaindre dans les forums.

----------


## Grosnours

> Tu fais quoi ? Aller montre. Je trouve les canards bien timide avec leur création


Des serious games dans le cadre de projet européens. Ce qui veut dire que tu n'aura pas forcément des trucs super sexy non plus, c'est pas le but initial et on a pas le temps ni le budget pour non plus.  ::P: 
Là on bosse sur un truc en 3D avec des paysages made in Gaia, d'où l'utilisation de post processing. On verra d'ici 5-6 mois si on arrive à faire un truc décent.  ::):

----------


## Sifr

> Tu fais quoi ? Aller montre. Je trouve les canards bien timide avec leur création


En même temps entre le premier Wow des petits screenshots postés à la va vite pour illustrer et le temps qui passe pour avoir un Ouaais c’est partageable et jouable, y’a de quoi rester en réserve et c’est toute l’histoire de l’early access infinie  ::XD:: 

Et puis tout le monde veut protéger sa meilleure idée du siécle  ::ninja::

----------


## Molina

> En même temps entre le premier Wow des petits screenshots postés à la va vite pour illustrer et le temps qui passe pour avoir un Ouaais c’est partageable et jouable, y’a de quoi rester en réserve et c’est toute l’histoire de l’early access infinie 
> 
> Et puis tout le monde veut protéger sa meilleure idée du siécle


En parlant de wow : 
J'ai un problème avec mon terrain de jeu. En gros, je suis en train de faire un jeu au fil de l'eau. Je lui rajoute du contenu quand j'ai envie, je construis mes asset pour qu'ils soient le plus modulaires possible et j'en suis très fier. Je commence à réfléchir à implémenter un système de sauvegarde, jusqu'à là, rien de fifiou (j'vais surement m'acheter Easy Save 2 histoire de ne pas trop me prendre la tête). Et de fil en aiguille, j'ai commencé à baliser à propos de l'optimisation et comment j'vais rajouter du contenue au fur et à mesure de mes envies. 

Alors dans ma tête, j'étais en mode : C'est facile, suffit de désactiver (SetActive) les objets distants à plus de 200m en  'Start" puis de continuer en Update, et c'est marre. Ca me permettra de rajouter des tiles de terrains au fur et à mesure sans me soucier que l'IA à 1km fasse ramer mon bébé. Le tout avec une occlusion agressive. Je crois que pour l'instant j'ai mis une fog à 60m et une occlusion à 100m  ::ninja:: . 

Et en lisant les forum, bon déjà il y a le Floating Point Errors, mais ça on s'en fout, si je comprends bien ça arrive à 10km du point d'origine donc ça fait quand même pas mal de marge pour un amateur. Qui a besoin de 400 km² de terrain ? Mais surtout... Ben tout le monde dit que c'est hyper compliqué et qu'il faut acheter l'asset World Streamer. Et en regardant le bousin, ça me plait pas des masses comme façon de faire (il faut limite avoir déjà son terrain pour l'utiliser). 

Du coup, où est ce que je rate quelque chose ?

----------


## Sifr

Si l’IA n’a aucune raison d’avoir une activité à 1 km de distance, c’est « facile », une bonne localisation de la zone autour du joueur et une sgmentation du terrain par zones d’activation avant d’y arriver ça passe crême.

Si c’est de la stratégie et que tout le terrain compte en permance, alors c’est plus tordu car pour gagner en perfs faut prévoir une représentation allégée purement technique où le terrain et ses objets ne font que traduire le résultat visuel.

De là à streamer, ça sature déjà à ce point en perfs pour faire de l’optim ?

----------


## Molina

> Si l’IA n’a aucune raison d’avoir une activité à 1 km de distance, c’est « facile », une bonne localisation de la zone autour du joueur et une sgmentation du terrain par zones d’activation avant d’y arriver ça passe crême.
> 
> Si c’est de la stratégie et que tout le terrain compte en permance, alors c’est plus tordu car pour gagner en perfs faut prévoir une représentation allégée purement technique où le terrain et ses objets ne font que traduire le résultat visuel.
> 
> De là à streamer, ça sature déjà à ce point en perfs pour faire de l’optim ?


Pas du tout, c'est juste que je préfère faire les trucs chiants assez tôt car c'est le truc qui me plait le moins. Et savoir si c'est tenable de tout mettre dans une seule scène (plus pratique) ou alors tout éclater dans plusieurs, ça a une incidence sur comment je fais les assets.  En tout cas merci, effectivement, les IA sont très très basiques et ne doivent rien faire sans la présence du joueur. Ta réponse me rassure, je peux y aller en mode yolo et tout construire comme je l'ai déjà fait avec juste un petit script en plus.

----------


## Janer

> Pas du tout, c'est juste que je préfère faire les trucs chiants assez tôt car c'est le truc qui me plait le moins. Et savoir si c'est tenable de tout mettre dans une seule scène (plus pratique) ou alors tout éclater dans plusieurs, ça a une incidence sur comment je fais les assets.  En tout cas merci, effectivement, les IA sont très très basiques et ne doivent rien faire sans la présence du joueur. Ta réponse me rassure, je peux y aller en mode yolo et tout construire comme je l'ai déjà fait avec juste un petit script en plus.


C'est pas aussi qu'il risque d'y avoir un problème de RAM avec trop d'assets chargés en même temps ?

----------


## Molina

> C'est pas aussi qu'il risque d'y avoir un problème de RAM avec trop d'assets chargés en même temps ?


Ah merci, oui, ça doit être pour ça que les gens conseillent World Streamer, je suis bête... J'y ai pas du tout pensé. 
Si c'est "juste" ça, je ne pense pas avoir de problème avant longtemps dans ce cas.

----------


## Janer

Oui c'est tout de suite plus coton, quand on doit gérer le chargement depuis le disque dur des différents assets. Après je suis pas certain, parce que j'ai pas trop touché à ces aspects là, mais je crois que tu peux laisser unity gérer ça, en séparant ton monde en plusieurs scènes, et en fait je sais pas si tu es au courant mais tu peux charger plusieurs scènes en même temps. Donc tu peux avoir 9 scènes chargées pour 9 chunk autour de ta position. Et dans ton cas simple, juste pour être sûr des problèmes de précisions float, tu as qu'à mettre tous les objets de chaque chunk comme enfants d'un objet vide appelé "chunk_21" par exemple, et dès que le joueur est trop loin, tu le remet à l'origine, et tu décales les 9 chunks de la bonne distance. Juste garder en mémoire cet offset, comme ça quand tu charges de nouveaux chunks tu les place bien par rapport au joueur.

----------


## schouffy

Est-ce que vous auriez de bonnes resources pour découvrir les shader (en graph nodes hein, pas le langage) ?
J'essaie de faire un truc spécifique, mais j'ai aucune idée de comment démarrer, ce truc est une énorme boite noire pour moi.
Les tutos que je trouve expliquent comment faire certaines choses, mais je comprend pas la logique derrière. En gros les mecs disent "tu veux faire un truc brillant quand on regarde de biais ? Bah c'est du Fresnel avec du specular voyons !"  :WTF:

----------


## Grosnours

Peut-être ceci ?
https://catlikecoding.com/unity/tutorials

----------


## schouffy

Oui c'est pas mal, c'est pour le shader language mais les effets sont assez bien introduits et expliqués, je peux sans doute appliquer ça au shader graph après. Merci.

----------


## Janer

> Oui c'est pas mal, c'est pour le shader language mais les effets sont assez bien introduits et expliqués, je peux sans doute appliquer ça au shader graph après. Merci.


En fait c'est pas facile ce que tu demandes, parce que en gros tu dois avoir les bases en computer graphics, et tous les tutos passent par le code pour expliquer. Du coup la partie "rendering" de catlike coding c'est super je pense, et même si tu comprends pas tout le script, tu vas pouvoir comprendre ce qu'il y a derrière.

Ce sont vraiment d'excellents tutos en plus. Je sais pas si il y a d'autres sources de cette qualité sur internet mais si quelqu'un connaît ce serait super de partager!

----------


## Janer

Je sais pas si ça a été partagé mais ce site propose plein de tutos sur des sujets précis vraiment pas mal. Après c'est du format vidéo donc densité d'information faible et très lent à digérer, mais les soutiens patreons peuvent récupérer le code source et le digérer par eux-même.

https://sharpaccent.com/

----------


## schouffy

ça n'a rien à voir avec Unity, mais je passe juste recommander ce Youtubeur qui fait de super tutos pour artistes (ou développeur qui se prennent pour des artistes  ::ninja:: ) :

Polygon Academy

Exemples:

Sur les trim sheets



Sur la composition de scènes et le grayboxing :

----------


## raaaahman

Yop, faites le plein d'e-books en étant charitables sur Humble Store.

C'est con, ça aurait fait de bons "cahiers de vacances".

----------


## Janer

Merci pour l'info

----------


## Silver

Je viens de le prendre aussi. J'étais intéressé par le livre sur les shaders, mais celui sur C# sera un bon début pour moi, vu que j'avais seulement pratiqué le Unity JavaScript. Et puis les vidéos de pratique ainsi que le livre sur l'IA seront des bonus.

----------


## Grosnours

Dernier jour en ce 31 pour prendre un an d'abonnement plus ou pro avant la montée des prix de demain.

----------


## Adu

Joli packs de ressrouces pour Unity3D et/ou Unreal Engine sur le humble bundle en mode low polygon pour prototyper rapidement !

----------


## Sifr

Petite question au passage parce que je trouve pas trop de réponse pour le moment.

Y’en a qui rencontre le problème suivant sur Unity 2019 LTS ?

Je fais attaquer 1000 unités contre 1000 unités dans le soft histoire de faire de l’optim’ et dès qu’elles se mettent à tirer je me trouve avec un truc à trois 3 fps totalement impossible à supporter.

Je fais un build, je lance le jeu et là ça passe à 100 fps sans soucis’ mais pas un ralentissement alors que je dois trainer au moins 10000 projectiles en simultané.

Ca peut venir d’où un tel écart dans le soft ? C’est pas du tout représentatif du coup et c’est un peu chiant pour voir les perfs réelles...

----------


## schouffy

T'as beaucoup de choses qui se passent dans l'éditeur pour gérer des infos de debug et de trace, d'affichage de gizmos, d'events qui sont lancés par ton jeu etc...
C'est pas du tout étonnant que les performances soient différentes, mais je ne sais pas ce qui pourrait justifier un écart aussi extrême. Le profiler dit quoi ?

----------


## Grhyll

Quelques possibilités qui peuvent ralentir un peu (même si à ce point c'est impressionnant) :
- Tu as le profiler qui est allumé (pire encore s'il est en deep profile)
- Tu as la scene view affichée
- Tu as une hiérarchie très densément peuplée et plein de trucs sont dépliés
- Tu affiches l'inspector d'un objet avec énormément de components
- Tu as des scripts editor qui tournent à fond.
En tout cas, si aucune de ces pistes n'a l'air valide, comme dit schouffy faut essayer de profiler  ::):

----------


## Sifr

Merci pour les indications.
Je vais tester, par contre je vois pas comment profiler si c’est le profiler qui pose problème et qu’il faut que je le coupe  ::XD::

----------


## Grhyll

Tu n'es pas censé le laisser allumé tout le temps, le profiler  ::):  Si tu constates que c'est lui qui étais allumé et qu'en l'éteignant tout redevient smooth, parfait ! S'il n'est pas allumé, tu peux le mettre en route quelques frames (et ça va vraisemblablement ramer encore plus), puis l'arrêter pour aller fouiller dans ce qu'il a enregistré.

----------


## Sifr

Quand je regarde le profiler j'ai un truc à 300 ms dans le pic qui est lié au tag *EditorOnly* *GetComponentNullErrorWrapper* - ils disent dans la doc que c'est lié au profiler mais même quand il n'est pas actif ça crée cette baisse de fps.

Ca explique qu'en build ça ne soit pas visible du coup.

Par contre je ne trouve pas grand chose sur ce GetComponentNullErrorWrapper  ::(:

----------


## schouffy

Vérifie que t'as pas sur tes gameobjects, des références vers des composants/scripts qui ont été supprimés. C'est ce que je comprend du nom du wrapper.
Regarde aussi si le profiler ne te donne pas plus d'infos sur cette erreur spécifique, peut-être qu'il t'indique déjà tout dans sa UX parfois pas évidente à utiliser.

----------


## Grhyll

Si c'était pas déjà le cas, tu peux essayer de te mettre en deep profile, tu pourras peut-être voir d'où provient ce GetComponentNullErrorWrapper. Aussi, hésite pas à poster un screenshot de ta frame de profiler ici, au cas où ça donnerait plus d'infos  ::):

----------


## Metalink

Si t'as du Debug.Log à chaque frame aussi, avec tes dizaines de milliers d'objets ça fait exploser les performances  :;):

----------


## Grhyll

On sent le vécu  ::P:

----------


## Metalink

3 ans que je bosse professionnellement sur un gros jeu avec Unity, malheureusement ça fait partie des trucs connus  :tired:

----------


## Sifr

De mon côté j’ai aucun debug.log actif, j’ai un boolean pour les sortir ou non.
Et j’ai fait sauter aussi tous les samples du profiler dans mon code.
Ca reste pareil.

Je me demande si cela vient pas des TryGetComponent en fait.

J’en ai remplacé pas mal avec cette variante au lieu du GetComponent classique.

Je vais faire un test... ça laisse rêveur ce genre de truc quand même.

----------


## Metalink

Le GetComponent c'est effectivement à éviter de faire à toutes les frames, ça peut couter très très cher. Il me semble qu'aujourd'hui Unity fait un peu de cache en interne, mais le faire soi même c'est un gain de performance garanti.

----------


## Sifr

La plupart de mes components sont mis en cache dès le start.

Mais dans certains cas je ne vois pas comment les cacher.
Par exemple, pour déterminer si un gameobject est un batiment ou une unité.
Je fais un test sur le Trygetcomponent et après j’applique ce qu’il faut.
Donc parfois oui j’ai pas mal d’appels si le nombre d’unités augmentent.

Mais pourquoi générer autant en editor et pas en build.

----------


## Grosnours

Question conne (puisque je connais pas ton code), tu peux pas plutôt différencier les objets différemment genre par des tags, leur nom, leur layer, ou une autre méthode moins gourmande ? Comme les autres l'on dit il vaut mieux garder les Update() et FixedUpdate() aussi légers que possible.
Le code compilé passe sur tout un tas de choses qui peuvent provoquer un arrêt immédiat en mode éditeur (y compris les certaines NullException), il ne faut pas trop prendre le comportement/les perfs dans l'éditeur comme parole d'évangile quant au résultat final.

----------


## Sifr

> Question conne (puisque je connais pas ton code), tu peux pas plutôt différencier les objets différemment genre par des tags, leur nom, leur layer, ou une autre méthode moins gourmande ? Comme les autres l'on dit il vaut mieux garder les Update() et FixedUpdate() aussi légers que possible.
> Le code compilé passe sur tout un tas de choses qui peuvent provoquer un arrêt immédiat en mode éditeur (y compris les certaines NullException), il ne faut pas trop prendre le comportement/les perfs dans l'éditeur comme parole d'évangile quant au résultat final.


Je pourrais effectivement passer par les tags pour éviter l’appel au getcomponent dans le if ça limiterait déjà.

Il me restera alors le getcomponent pour accéder aux fonctions et variables du composant en lui-même.

Mais ce que je retiens surtout de toutes les remarques et tips c’est que je suis pas mal côté optim de code et qu’il faut pas trop que je me soucie de ce truc en mode editor, je prendrai moins d’unités pour faire de l’optim, ça évitera de saturer l’éditeur, tout en sachant qu’en build je serai beaucoup mieux et que j’ai de la marge.

----------


## Grosnours

Autre méthode plutôt que de chercher activement des objets : les faire s'enregistrer à leur création auprès d'un objet référence, dont on peut se servir pour accéder à tous les objets enregistrés et à leurs composants.
Je ne sais pas si je suis clair.  ::unsure::

----------


## Molina

> Autre méthode plutôt que de chercher activement des objets : les faire s'enregistrer à leur création auprès d'un objet référence, dont on peut se servir pour accéder à tous les objets enregistrés et à leurs composants.
> Je ne sais pas si je suis clair.


Tu veux dire les mettre en fils dans une hiérarchie ou les mettre dans une liste que tu fous quelques part ou y accéder rapidement ?

----------


## Sifr

> Autre méthode plutôt que de chercher activement des objets : les faire s'enregistrer à leur création auprès d'un objet référence, dont on peut se servir pour accéder à tous les objets enregistrés et à leurs composants.
> Je ne sais pas si je suis clair.


C’est ce que je fais dans d’autres circonstances dans mon code, mais là il semble d’après ce que j’ai lu/vu que le GetComponent reste supérieur en terme de perfos par rapport au parcours d’un array qui peut du coup s’allonger pas mal en fonction des objets actifs.

Par objet j’ai maxi sept composants pour les unités les plus complexes ça limite l’impact de la recherche sur l’objet.

----------


## Grosnours

> Tu veux dire les mettre en fils dans une hiérarchie ou les mettre dans une liste que tu fous quelques part ou y accéder rapidement ?


Plutôt b) mais a) fonctionne tout aussi bien (il faut parfois se méfier de certains effets de bord des arborescences dans Unity mais là cela devrait aller).
Tout dépend du code, des objets à spawn et du projet en général.
Dans un de mes projets j'avais plutôt utilisé des tags pour retrouver rapidement toutes les sources de SFX ambiants en runtime mais j'aurai pu procéder autrement aussi.




> C’est ce que je fais dans d’autres circonstances dans mon code, mais là il semble d’après ce que j’ai lu/vu que le GetComponent reste supérieur en terme de perfos par rapport au parcours d’un array qui peut du coup s’allonger pas mal en fonction des objets actifs.
> 
> Par objet j’ai maxi sept composants pour les unités les plus complexes ça limite l’impact de la recherche sur l’objet.


Effectivement à toi de voir ce qui te convient le mieux.  :;): 



Au fait, si des gens par ici on réussi sans trop de problèmes à bake les paramètres d'illumination dans un prefab cela m'intéresse monstrueusement. J'en ai besoin pour une version de nuit de tous les éléments d'une ville low poly sans utiliser de sources lumineuses qui seraient très couteuses vu le nombre d'instances. Et les matériaux émissifs ont leur limites, on ne peut pas les utiliser pour tous les cas.
Il y a des threads de ce genre : https://forum.unity.com/threads/prob....324514/page-9 mais après avoir testé à peu près tous les scripts donnés là dedans tout ce que je peux conclure c'est que cela fonctionne sans fonctionner et que bien entendu cela dépend totalement de la version d'Unity.
Il y a bien cela : https://unity.com/how-to/advanced/op...g-mobile-games mais d'une part je ne peux pas tout utiliser là dedans et d'autre part j'en pige bien la moitié pas plus, je dois être un peu simplet.

----------


## schouffy

Tiens, une question me taraude.

Je pensais que le poids de la build finale était majoritairement fonction des assets (textures, sons et meshs/anims principalement). Mais je constate, en rajoutant des scenes à ma build, qui ne font que réutiliser les mêmes assets que les autres scenes déjà présentes, le poids de la build augmente systématiquement de façon non négligeable.
En gros, avec une map j'avais un zip de 150Mo, avec deux maps 250Mo, et avec trois maps 350Mo.
Et je vois bien en effet dans le répertoire Data que levelX et levelX.resS pèsent chacun un bon poids, et j'imagine que mes assets sont dans les fichiers sharedassets.

C'est quoi du coup, tous ces Mo dans les level ? Les lightmaps ? Parce que mes niveaux sont assez simples et je suis pas sûr de ce qui pourrait nécessiter autant d'information pour être représenté (cross topic prototypes  ::P: )

----------


## Grosnours

Cela dépend de comment tu as éclairé la scène bien sur. Question : est-ce que tu as regardé ce que te donne l'Editor Log après un build ? Une autre question est quel poids font tes assets seuls ?

----------


## raaaahman

Un e-book sur l'optimisation de jeux Unity, gratuit pour la journée: https://www.packtpub.com/free-learning

P.S.: Ca ressemble à de la pub de m**** mais je n'ai aucun intérêt chez Packt Publishing.

----------


## Sifr

Tiens un petit problème rigolo que je cherche à optimiser côté ergonomie.

J’ai un sous marin sous une surface d’eau, visualisation de la caméra en mode STR.
Un collider rectangulaire permet de détecter le clic souris sur le sous marin.
Un collider rectangulaire de faible épaisseur permet de détecter un clic sur la surface de l’eau.

L’idée c‘est que si le joueur clique sur l’eau, il faut déselectionner une action, une entité ou donner un ordre de mouvement etc...

Maintenant, pour pouvoir sélectionner le sous marin je suis obligé d’augmenter le collider pour qu’il dépasse la surface de l’eau afin qu’on puisse le sélectionner sans que le raycast touche l’eau avant.

Mais en tant que joueur, on a plus tendance a cliquer sur le sous marin que juste au dessus, voir sur le kiosque pour le selectionner.
Du coup c’est chiant on clique plus bas et le raycast avec l’inclinaison caméra touche le collider de l’eau et pas la base de celui du sous marin.
Ca sélectionne pas et on est forcé de bouger un peu le curseur pour tomber au bon endroit.

Ma question : y’a t il une autre technique connue/usuelle qui permette de faire une sélection au travers d’un collider pour voir s’il y en a un autre derrière pour optimiser ce type de test de sélection sans bidouiller du layer ?

----------


## Louck

Plusieurs idées à chaud:
- Souvent dans les RTS, les unités ont un "drapeau" (ou une icone) pour être visible et être identifiable de loin, et souvent ils se trouvent en hauteur. Le joueur peut cliquer sur l'icone pour sélectionner le sous-marin.
- Pour un jeu de sous-marin, je pense que l'eau fait partie de 90% du décor du jeu ? Si l'eau a un collider, est-ce que tu prévois une action spécifique à l'eau si le joueur clique dessus ? Sinon, autant virer le collider et considérer l'intégralité du jeu comme un terrain jouable (clique gauche dans le vide = déselection, clique droit dans le vide = action).
- Tu peux jouer avec les layers et prioritiser: Tu test d'abord si le joueur clique sur le sous-marin (en testant le layer utilisé par l'unité). Ensuite tu vérifies s'il clique sur l'eau (en faisant un autre raycast, mais cette-fois avec le layer utilisé par l'eau).

----------


## Sifr

La proposition 3 me va bien. Facile à mettre en oeuvre et robuste. Merci.

Je peux pas supprimer le collider de l’eau car je n’ai pas que des sous marins, mais aussi les navires, les hélicos et les avions même si ces derniers ne sont pas cliquables vu qu’ils sont lancés depuis une base aérienne, le ciblage se fait avec le collider surface d’eau.

----------


## Grhyll

Après tu as aussi Physics.RaycastNonAlloc qui va te renvoyer plus d'un hit, et du coup tu peux juste parcourir ta liste de hit pour voir celui qui a la plus grosse priorité.

----------


## Sifr

> Après tu as aussi Physics.RaycastNonAlloc qui va te renvoyer plus d'un hit, et du coup tu peux juste parcourir ta liste de hit pour voir celui qui a la plus grosse priorité.


Ah oui et je cherche s’il y a un composant Unit dans la liste, ça va passer sans soucis.

En parlant de soucis, je suis fou, j’ai converti tout mon Projet avec le HDRP et je pleure.

Passé trois heures à comprendre leur système d’éclairage... et trifouiller pour avoir enfin un peu de lumière correcte.

Tous les shaders HS, j’ai dû refaire mon eau dans Shader Graph. Comme découverte de l’outil ça a été violent  ::lol:: 
Et les particles systems sont majoritairement HS aussi vu la gestion de la transparence.

Question pour ceux qui pratiquent le HDRP : c’est normal qu’on ait du mal d’avoir les effets bien visibles issus du particle system ?
Il faut passer par le VFX graph pour refaire l’équivalence sous ce render pipeline ?

----------


## Sifr

En fait j’ai trouvé, je sais pas si c’est idéal mais en changeant les shaders des particules avec leur version particule/additive ou autre ça remet les choses en ordre.
Bizarre d’ailleurs que les effets génériques fournis par Unity n’héritent pas direct de ceux-ci.

En tout cas le HDRP est génial, je pestais contre le rendu pourri de mes modèles issus de Magica Voxel quand c’est super beau dans le rendu de Magica et là je retrouve enfin la même chose  ::):

----------


## schouffy

Si tu ne vises pas le photo réalisme, en général il vaut mieux s'orienter vers l'Universal RP.
Sinon oui l'éditeur est encore bien buggé avec le SRP, tu verras souvent la couleur mauve  :^_^: 
Pour ton problème de colliders, j'arrive après la bataille, mais pourquoi ne pas mettre tes colliders sous marins & navires, et l'eau sur 2 layers différents ? Comme ça dans ton clic, tu raycast uniquement le layer contenant les bateaux/sous marins et si tu hit rien, c'est que tu hit de l'eau ?

----------


## Sifr

Ils sont déjà sur deux layers différents.

Mais oui l’idée de tester par ce biais est pas mal aussi.

Je vais tester ce qui est le plus efficace. Faut juste que je vois les conséquences entre le clic unité / batiment / la déselection / le clic glissé pour la multi sélection / le clic des super armes et de ciblage des avions, ça fait un gros mix qui parfois part en sucette avec pourtant la bonne idée du moment  ::lol:: 

J’aime bien le HdRP, faire un shader avec fresnel et se rendre compte qu’il est invisible.. se gratter les neurones pendant une heure et comprendre qu’il faut forcer l’intensité des sources pour dépasser le seuil d’illumination global... c’est rigolo.

----------


## Grosnours

Tout le monde s'en tape, mais le baking de prefab, c'est dans la poche.  :Cigare: 
Grâce à Bakery, un de mes meilleurs investissements en tant qu'asset. On peut donc illuminer ses prefabs autant qu'on veut dans une certaine scène, calculer l'illumination, enregistrer les données dans le préfab et sortir l'asset dans une autre scène déjà pré-illuminé. Le tout même avec des lumières qui font partie du préfab et qu'on peut éteindre par la suite tout en disposant de leur lumière.
Résultat dans un monde instancié : vous pouvez disposer d'une illumination nocturne pour un cout faramineux de ....zéro. Il suffit de disposer de ses préfabs en version jour/nuit et de les créer/détruire dynamiquement à l'aube et au crépuscule pour avoir toute une ville illuminée sans la moindre lumière qui coute un bras. Pas mal de travail à faire en amont, mais le résultat en vaut laaaargement la peine.

----------


## Sifr

> Tout le monde s'en tape, mais le baking de prefab, c'est dans la poche. 
> Grâce à Bakery, un de mes meilleurs investissements en tant qu'asset. On peut donc illuminer ses prefabs autant qu'on veut dans une certaine scène, calculer l'illumination, enregistrer les données dans le préfab et sortir l'asset dans une autre scène déjà pré-illuminé. Le tout même avec des lumières qui font partie du préfab et qu'on peut éteindre par la suite tout en disposant de leur lumière.
> Résultat dans un monde instancié : vous pouvez disposer d'une illumination nocturne pour un cout faramineux de ....zéro. Il suffit de disposer de ses préfabs en version jour/nuit et de les créer/détruire dynamiquement à l'aube et au crépuscule pour avoir toute une ville illuminée sans la moindre lumière qui coute un bras. Pas mal de travail à faire en amont, mais le résultat en vaut laaaargement la peine.


Comment ça fonctionne exactement ?
On a toute l’illumination dans le prefab et ensuite on exclut celui ci de toute l’illumination de la scène ?
Ou faut quand même laisser un peu d’illumination globale ?

Dans mon environnement je crée les icones de mes unités par un chargement d’une mini scène qui snapshot tous les 3d des batiments et des unités donc les icones sont automatiquement remis à jour si je fais une modif.
Par contre j’ai toujours des problèmes d’éclairage et ça pourrait être une solution pour gérer la visu plus finement.

----------


## Grosnours

Tu prends ton préfab et le met dans une scène qui aura une illumination plus ou moins comparable à celle dans lequel il sera inséré (moi par exemple ce sera avec une skybox nocturne). Si ton préfab possède des sources internes d'illumination, tu leur rajoutes pour chacune d'elle un script Bakery d'illumination. Tu t'assures bien que le préfab est static. Ensuite tu rajoutes à la racine de ton objet préfab dans la scène un script Bakery particulier, tu l'appliques au préfab mère et tu lances le calcul de la lumière via Bakery.
Ensuite tu sauvegardes le préfab obtenu comme une nouvelle version dans ton projet. Puis tu va dans ce préfab et désactive la version Unity des lumières internes au préfab (juste le composant Unity de lumière, pas tout l'objet).
Tu testes le préfab résultat dans une nouvelle scène, et poum il a effectivement conservé tous les paramètres d'illumination internes et externes.

J'ai donc désormais des versions nocturnes de tous mes assets, avec une tonne d'illumination statique faite (plein de lumière de façades d'immeubles par exemple) mais qui me coûte pas un rond. Ce qui n'est bien entendu pas du tout le cas si tu rajoutes de véritables sources d'illumination. A chaque cycle jour/nuit, je crée/détruit dynamiquement tous les assets et les remplace par leur version jour/nuit. Tu peux faire cela de façon graduelle histoire de ne pas avoir de coût trop grand quand il y a beaucoup d'assets.

En théorie, le baking de l'illumination dans un baking est possible dans Unity de base, en pratique le thread à ce sujet dans les forums d'Unity dure depuis au moins 7 ans et tout le monde à des expériences radicalement différentes et qui dépendent totalement de ta version de l'éditeur. Avec Bakery, cela fonctionne out-of-the-box.

Les limitations de la chose est que ton préfab doit être statique et que l'illumination enregistrée ne projettera bien entendu aucune ombre à l’extérieur du préfab ou sur tout objet tierce.


Un exemple ici où on a le segment de route et la maison illuminés alors que la scène ne l'est pas et leurs illuminateurs internes sont désactivés.

----------


## Sifr

Merci c’est très intéressant. Je vais y trouver une utilité pour des scènes de nuit  ::): 

J’ai encore une question simple mais qui me semble importante : y’a t il des paramètres capitaux à définir quand on fait un build ?

Jusqu’ici je cliquais et hop et puis je testais mais maintenant je voudrais en faire un vrai package possiblement testable.
Et je me demande ce que Unity capte dans son package de build.

J’ai déjà vu des users raler par exemple sur Jagged Alliance Rage que le build activait par défaut des trucs de tracking/module de pubs...
Je sais pas si c’est une légende mais par le passé j’aimais bien savoir ce que je lachais dans la nature.
Alors s’il y a un guide connu je veux bien la référence car cette partie me semble pas assez décrite.

----------


## schouffy

J'avoue que j'ai pas bien compris l'intérêt de tout ça. Le PBR, c'est pas justement pour avoir un seul asset qui pourra être utilisé dans toutes les conditions de luminosité ?
J'ai bien compris ton argument des performances, mais dans quel cas un asset peut-il désirer exactement le même éclairage dans deux contextes différents ?

----------


## Grosnours

> J’ai encore une question simple mais qui me semble importante : y’a t il des paramètres capitaux à définir quand on fait un build ?
> 
> Jusqu’ici je cliquais et hop et puis je testais mais maintenant je voudrais en faire un vrai package possiblement testable.
> Et je me demande ce que Unity capte dans son package de build.


Qu'est ce que tu veux dire par package de build ? Les packages que tu inclues dans tes builds via le gestionnaire ?
Si c'est le cas jepeux te faire un retour sur le package d'analytics et bien qu'on avait à l'époque vraiment fait une grosse personnalisation de ce qui était envoyé et comment (avec un téléphonage maison d'une tonne de données sur les machines utilisateurs dans le cadre d'un jeu 3D gourmand) tout cela était extrêmement peu utilisable, l'interface analytics du dashboard étant taillée uniquement pour l'aspect analyse consommateurs/ventes et supporte assez mal les data points personnalisés sur des tableaux à double/triple/plus entrées. Bref on a pas vraiment atteint notre but, qui était d'établir des guidelines générales sur quelles machines (RAM/CPU/CG) étaient nécessaires pour quelles usages.
Bon c'était il y a plus d'un an et l'interface à changé depuis mais je pense que le principe de base reste le même, un outil pointu à usage limité.





> J'avoue que j'ai pas bien compris l'intérêt de tout ça. Le PBR, c'est pas justement pour avoir un seul asset qui pourra être utilisé dans toutes les conditions de luminosité ?
> J'ai bien compris ton argument des performances, mais dans quel cas un asset peut-il désirer exactement le même éclairage dans deux contextes différents ?


Reprenons mon problème de base.
On est dans un cas où tu as un univers totalement instancié, avec une illumination totalement dynamique (cycle jour/nuit en particulier). Il y a cependant une énorme majorité d'objets statiques, très nombreux. La question est donc : comment les illuminer de nuit ?

Réponse 1 : leur filer des objets internes d'illumination, trop coûteux car le coût faible de base est démultiplié par le nombre d'objets.

Réponse 2 : créer dynamiquement des illuminateurs externes aux obets, mais vu le nombre élevé d'objets on arrive à un coût prohibitif bien que moins élevé que la réponse 1. Et c'est moins joli en rendu que la réponse 1. Je suppose que le PBR rentrerait en action dans ce cadre. Mais pour que le pBR fonctionne il faut des sources lumineuses, et ça c'est couteux.

Réponse 3 : créer une version nocturne de tous les préfabs avec l'illumination pré-calculée dans une autre scène et autant d'illuminateurs internes qu'on veut. Bakery permet aux préfabs de faire référence à la lightmap de cette scène dans laquelle ils ont été bake et de l'utiliser dans une autre scène. On a donc un résultat illuminé mais avec un coût nul (et aucun shader à ajouter, important ça). En fait après tests sur une carte avec des milliers de tronçons de route, on gratte une poignée de FPS de nuit (je ne sais pas trop pourquoi par contre). 

Il y en a peut être d'autres réponses, mais je doute qu'elle aient un coût inférieur à la réponse 3.

Ce qu'on fait désormais c'est au lieu d'avoir un préfab avec la logique et les assets, on a un préfab père avec la logique de l'objet et un préfab fils qui possède l'objet physique. Ce dernier est crée et détruit à chaque transition du cycle jour/nuit, alternant entre le préfab version jour et le préfab version nuit. La création/destruction a un coût, mais il est subi uniquement deux fois par jour in game et peut-être intelligemment perlé pour en réduire l'impact.
Le véritable coût ici est en amont vu qu'il me faut maintenant générer des versions de nuit de centaines d'assets ce qui va me prendre un temps certain. Mais une fois que ce sera fait, on en parlera plus.

----------


## schouffy

Mais tes objets, en situation d'aube ou de crépuscule, ils n'ont pas un éclairage bizarre ? Soit tu affiches l'asset "jour" et tu obtiens un truc trop clair, soit tu affiches l'asset "nuit" et il est au contraire trop foncé.
Et ça veut dire quoi, que tous tes objets pop "LOD style" 2 fois par jour pour le joueur, aux heures que tu as choisi pour les transitions ?

Et ça veut aussi dire que tous tes objets ne pourront plus être impactés par un éclairage dynamique si tu voulais en rajouter ? Des explosions par exemple.

----------


## Grosnours

C'est un city builder low poly, la caméra utilisateur passe son temps loin des objets eux-même. Donc la transition brutale jour/nuit est peu gênante et peu ou prou fidèle au fait que l'éclairage public/entreprises/particuliers en général est un on/off par définition.
D'ailleurs si c’était vraiment pas un problème, je pourrais parfaitement créer un troisième préfab avec un éclairage intermédiaire (mais là je ne vois pas trop l'intérêt).
La meilleure solution est à mon avis de passer en prefab de base (non éclairé) à l'aube/crépuscule pour laisser l'éclairage solaire dynamique temps réel avec ombres faire son effet. La seule chose que je perds réellement est un poil de fidélité dans l'éclairage nocturne (lune/étoiles) mais il est par définition très faible est totalement inférieur à de l'éclairage nocturne de ville.

Pour ce qui est de l'éclairage, avoir l'éclairage statique pré-baked ne veut pas dire que les assets ne seront plus impactés par un éclairage dynamique. Pas d'une manière qui m'handicape en tout cas.

Pour illustrer voilà un exemple bateau (uniquement pour les routes) avec deux gros spot rouges et verts au dessus de la même ville en version jour et nuit (la nuit sera mieux faite niveau skybox, là c'est juste le jour sans le soleil pour vérifier que tout va bien).

Dans mon cas les performances sont infiniment plus importantes que la qualité du rendu et je ne vois pas trop comment obtenir des performances de ce type sans prefab baking ou sans devoir te taper des écritures de shaders à la pogne.

----------


## schouffy

Ok j'ai compris maintenant, ça semble en effet pas mal adapté à ton jeu  :;): 
Dont le rendu est cool d'ailleurs !

----------


## Grosnours

Merci beaucoup.  ::): 
Pour l'anecdote si vous voulez utiliser Bakery, n'oubliez pas d'activer "Generate Lighmap's UV" sur les modèles sinon cela ne fonctionnera pas toujours. Trois jours que je cherchais pourquoi certains prefab ne gardaient pas l'éclairage et on a enfin trouvé via expérimentations...  ::P:

----------


## Molina

Je suis en version 2017.3. Je peux migrer jusqu'au 2018 stable (je ne sais plus quel numéro), sauf que n'importe quel upgrad me demandera de refaire mes niveaux (mais tous mon code et UI restent nickel avec quelques modifications) parce que ça a la bonne idée de bouger mes rotations et transform et l'échelle. 
Ce qui est de l'ordre d'une bonne journée de boulot au moins si je me rappelle bien de mes niveaux. 

Les versions supérieures valent le coup ? Sachant que mon but, c'était peut être d'aller jusqu'au 2020 car il y a une feature de polybrush qui me plairait bien mais je peux vivre sans largement.

----------


## Sifr

Perso n’ayant aucune volonté d’en faire un truc vendable et donc à s’arracher les cheveux dès qu’un truc buggait en passage de version, j’ai suivi  toutes les montées de version proposées.

Ce que j’ai pu voir c’est que le passage à 2018 a pété plein d’assets que certains n’ont jamais remis au goût du jour.
Au final maintenant ça m’a obligé à tout faire moi même et je le regrette pas du tout.

La 2019 m’a apporté beaucoup d’anomalies de perfs dont j’ai déjà parlé ici. Et pas mal de trucs dépréciés qu’il a fallut remettre en ordre.
Par contre l’outil terrain et shader graph était enfin au niveau.

La 2020 m’a apporté un bond en perfs, et de la maturité supplémentaire dans les fonctions proposées sans trop de problème de transition.
Par contre j’ai perdu beaucoup de temps à switcher vers HDRP... pour finalement tout remettre en place ou presque.
Shader graph m’a permis de me débarasser des shaders piqués à droite à gauche pour refaire les miens par ce biais.

Y’a que mon fog of war que j’ai perdu sans solution  ::(: 
J’utilisais un projector qui n’est plus au même niveau avec le decal projector.

Donc à mon humble niveau de connaissance, ça se bonifie sur ce que je manipule mais tout ce qui est job system and co et nouvelle méthode de programmation remplaçant le monobehavior je ne sais pas.

Edit : ah si depuis la 2020, le temps de chargement de Unity est super long, il fait des refresh à tout va et c’est un peu relou.

----------


## schouffy

Vers 2018/début 2019, y'a vraiment eu un pas en arrière je trouve. Tout était pété de partout, le SRP commençait à être poussé mais n'était pas encore prêt du tout. Maintenant je trouve que tout fonctionne relativement bien (depuis les versions 2019 LTS un peu avancées), je pense que tu as tout intérêt à migrer mais effectivement ça peut demander pas mal de boulot.
Si toutes tes modifs de transform sont "similaires" tu peux sans doute faire un script qui fait la mise à jour pour toi.

----------


## Grosnours

Si ce n'est que les informations de transform que tu perds, il n'y a pas trop mort d'homme à migrer, comme le dit schouffy.
On est sur la 2019.4.1f1 LTS si ma mémoire est bonne et on a pas trop envie de migrer plus haut, d'une part parce qu'il n'y a pas de 2020 LTS, d'autre part parce qu'on a pas envie de réécrire tous nos shaders, aussi facile cela puisse être(même si on devra y passer un jour). On y est mieux que sur la précédente LTS 2018 en tout cas et de plus en plus d'assets demandent 2019 minimum.
EDIT : Et bien sur crée une nouvelle branche dans ton code pour le passage à la nouvelle version, afin de pouvoir toujours avoir la version de base comme comparaison. Avec Hub qui gère une tonne d'installs de l'éditeur dans des versions différentes, tu peux vraiment faire de la comparaison facilement.

----------


## Molina

Merchi.
C'est quand même beaucoup d'emmerde... J'ai fait en sorte que mes asset soit modulaires, donc j'ai BEAUCOUP d'objets dans une scène....  Faudra que je teste, je me demande si le fait que les prefab soient en fils dans la hiérarchie ne fout pas la merde. 

Vous avez intérêt à ce que l'UI et les feature en plus vaillent la peine  :tired: . Surtout que pour une fois, mon jeu est stable sans un message d'erreur,  :^_^: .

----------


## Sifr

> Surtout que pour une fois, mon jeu est stable sans un message d'erreur, .


Ca c'était avant  ::ninja::

----------


## Sifr

Besoin d’un petit conseil histoire de pas perdre du temps pour rien : je suis passé sous HdRP, tout tourne bien et entre temps j’ai joué avec VFX Graph et ça en met plein les mirettes.

Du coup je me demande si je vais pas repasser tous mes particles systems sous VFX graph.

Mais j’ai un doute, car y’a des trucs qui me semblent être plus lourds à mettre en oeuvre.

Est ce qu’on peut vraiment faire par VFX graph tout ce qui est fait avec le particle system ? A performance équivalente ?
Balancer une roquette avec un sillage de fumée ? Un railgun bien classe ?

Ou ça sert pas à grand chose et faut savoir se contenter de ce qu’on a et VfX graph c’est pour de l’effet ponctuel qui doit claquer dans la mise en scène ?

----------


## Grosnours

D'après ce que j'ai compris (on utilise pas VFX graph) cela remplace peu ou prou les particules avec de meilleures performances (en particulier sur une tonne de particules sur desktop ou n’importe quoi avec un GPU correct) mais avec quelques limitations (GPU, collisions). Bref, ça dépend de ce que tu veux faire.
Là on fait du low poly, les particules en faible nombre suffisent large.

----------


## Sifr

Bon y a pas à dire, avec les particules VFX c'est vachement plus brillant et beau  ::): 

Par contre ça fait une bonne centaine d'effets en tous genres à recréer - ça va me prendre du temps.
Et puis la fumée... woua c'est chaud, heureusement qu'il y a des tutos mais c'est tellement agréable de finesse  :Bave:

----------


## Sifr

Je viens de passer à la 2020.2 en ayant suivi jusqu'à la 2020.1.17...

Eh ben ça m'a pas tout cassé pour un coup, juste perdu le depth test dans mes shaders en shader graph parce qu'ils ont changé des checks de zone/fonction et mon fog of war ne fonctionne de nouveau plus.
Décidément ils veulent pas stabiliser leur Decal Projector...

Quand j'aurai réussi à fiabiliser mon fog je pourrai enfin partager un truc potable.

----------


## Louck

C'est très rarement conseiller de changer la version du moteur ou d'un package en cours d'un projet, pour éviter les soucis que tu rencontres  ::): .

Sauf, bien sûr, si c'est critique. J'ai du le faire sur un projet de jeu en VR pour le rendre compatible avec les derniers casques, mais ca m'a pris énormément de temps pour tout re-tester et corriger ce qui a changé/cassé.

----------


## Sariyah

Hello les Canards,

J'ai cette année repris des études en LP. (dev multi-supports) Une UE comporte un projet collectif (groupe de 4)

Le thème étant la découverte du patrimoine de la ville, on a choisi de faire un mini RPG (type Secret of mana, toute proportion gardée évidemment...) à destination des plus jeunes.

Globalement l'idée c'est d'avoir une quête qui donne une ligne directrice et qui incite le joueur à se déplacer IRL sur certains sites (monuments etc.) de la ville pour achever certaines quêtes et /ou débloquer une nouvelle zone. (donc géolocalisation sur mobile à implémenter)
Pour le reste ce sera un RPG "classique" avec des quêtes ludiques qui renseignent sur le patrimoine et des combats "simples" au tour par tour.
On a choisi d'utiliser Unity. Les semaines passent et on va devoir rapidement avancer.

Est-ce que des canards sont connus pour bien connaître Unity ? Mon idée c'est simplement de pouvoir échanger et de prendre quelques conseils car j'ai le sentiment qu'on a sous estimé la complexité du projet et ça m'inquiète un peu. (et qu'il s'agit au passage d'un coeff 10 qui potentiellement peut planter mon diplôme )

J'aimerais bien également savoir ce que vous pensez du choix du moteur.  ::unsure::

----------


## schouffy

Vous avez combien de temps? Vous êtes 4 développeurs?
Avec le peu d'infos que tu as donné, c'est un peu difficile de voir le type de renseignements que tu attends.
Unity semble être un choix correct; renseigne toi bien avant de commencer sur l'interaction entre le moteur et les capacités du tél type géoloc ou réalité augmentée.
Peut-être que si ton jeu n'est pas très graphique ou interactif, une app native ou React Native ou Flutter peut être un meilleur choix car l'accès aux ressources du tél sera simplifié. Faites aussi en fonction de vos connaissances actuelles évidemment.

----------


## Grosnours

J'ai pas tout compris. Tu veux utiliser du GPS dans Unity ? Utiliser Unity dans ton browser qui lui utilisera le GPS ?
Tout cela est possible mais pas forcément facile (mais alors du tout) ni souhaitable en termes de perfs. On est plusieurs ici à avoir un peu de bouteille avec Unity, donc pose toutes les questions que tu veux.  :;): 

EDIT : pour avoir via ma femme contact avec des tonnes d'étudiants qui font des projets via Unity, il faut vraiment que vous définissiez le plus exactement possible votre jeu : histoire, gameplay, mécaniques, etc.. De là (ce n'est pas le process le plus standard mais vous avez le luxe de procéder ainsi) tu pourras en déduire ce dont vous avez besoin techniquement de manière beaucoup plus claire et précise. C'est le genre de décisions à faire le plus en amont possible car changer en cours de route est plutôt catastrophique.

----------


## Sariyah

On voudrait que la position de l'utilisateur, quand il joue sur mobile, puisse être géolocalisée et déclenche un évènement directement dans le jeu. Ce serait une grosse plus-value à notre projet mais effectivement on ne mesure pas la complexité. 

En terme de temps c'est assez court. La soutenance finale est prévue le 29 juin mais entre temps, on va devoir présenter plusieurs prototypes.
1er mars : Prototype 1 : Maquette fonctionnelle Interactive, MVP pour tester son idée
15 avril : Prototype 2 : Fonctionnalité coeur, MVP pour briefer son équipe technique
31 mai : Prototype 3 : Prototype complet, MVP à diffuser au public

Précisément on a définit nos prototypes ainsi :

*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.
*Prototype 2* :
• Contenu : Prototype 1 / Gestion des interactions (Quêtes, combats, informations patrimoine).
• Objectif : Rendre le jeu interactif
*Prototype 3* :
• Contenu : Prototype 2 + Création de tous les bâtiments, les quêtes, la carte complète et tout le contenu de l’histoire.
• Objectif : Avoir un jeu jouable sur mobile et avoir le fil conducteur du jeu

Au niveau graphique ce serait vraiment à l'image des RPG qu'on retrouve sur Snes par exemple mais avec des combats simplifiés au tour par tour. 

Oui on est 4 développeurs et on découvre tous Unity. 

Pour le moment on est en train de faire le mini tuto Creator Kit: RPG disponible dans le Learn du Hub.

Ce qui m'inquiète c'est de ne pas mesurer la charge de travaille.

Par exemple est-ce que vous considérez comme faisable rapidement par des débutants de :
Créer un menu simple pour entrer dans le jeu 
Créer une MAP avec quelques éléments de décor, quelques bâtiments, un PNJ qui donne une quête (rendre visite à PNJ B par exemple et valider) 

L'idée de géolocaliser l'utilisateur avec son mobile ça vous semble utopique ?

----------


## schouffy

Pas du tout utopique, mais je comprend pas comment ton jeu fonctionne.
Tu te déplace in game, ou tu te déplaces dans la réalité et ça update ta position in game ? Si c'est l'option 1, à quoi sert la géoloc? Si c'est l'option 2, à quoi servent les commandes de déplacement dans le jeu?

----------


## Sariyah

Admettons que tu sois en train de jouer sur ton mobile chez toi. Pour accéder à la zone B, un PNJ te demande de reconstruire le pont X. Là tu dois te rendre IRL à ce pont X : lancer le jeu avec la position d'activée, là tu reconstruis le pont et tu peux donc continuer à progresser dans le jeu.

En fait notre objectif c'est d'inciter les plus jeunes à se rendre vraiment sur les lieux pour découvrir le patrimoine et pour ça on a pensé qu'il faudrait forcément géolocaliser l'utilisateur pour valider qu'il est bien au bon endroit IRL et donc que l’évènement "le pont se reconstruit" se déclenche à ce moment. Pour le déclencher il faudrait et que le joueur soit au bon endroit in game et à l'endroit voulu IRL.

----------


## schouffy

Je vois. Dans ce cas, je pense que la géoloc n'est pas du tout la partie complexe de ton projet.
Regarde le lien dans mon post précédent, c'est très simple sur le papier d'obtenir la position GPS dans Unity.

Je te recommanderais de procéder ainsi pour vérifier la faisabilité:
- Utilise un outil de cartographie (genre https://www.keene.edu/campus/maps/tool/) pour déterminer les coordonnées GPS d'une zone que tu veux utiliser comme trigger
- Fais toi une mini app unity qui te géoloc et affiche un truc si tu entres dans les coordonnées en question
- va la bas et vérifier que ça fonctionne et que la précision te convient.

Si ça fonctionne, tu sais comment trigger des événements en fonction de la position GPS et tu sais que ça fonctionne bien.
Ensuite, oublie complètement cette partie, et crée ton jeu sans te soucier de la géoloc. Au lieu de vérifier la position pour activer tes quêtes ou autre, tu peux juste appuyer sur un bouton qui permet de simuler que "ok ta géoloc est conforme, valide la quête".
A la fin, il te suffira de remplacer le code "appui sur le bouton" par le code "vérification qu'on est dans la bonne zone gps".

Vu ce que tu comptes faire comme jeu, utiliser RPG maker te simplifierait sans doute beaucoup la tâche (je ne connais pas l'outil, mais je sais qu'il est fait pour ça). Si tu as une API de geoloc dans RPG maker, c'est tout bon (mais j'y crois pas trop, encore que). Peu importe l'outil que tu choisis, vérifie d'abord la faisabilité de ta feature de géoloc dans cet outil.

----------


## Grosnours

Excellents conseils de schouffy.
Validez techniquement la partie GPS d'abord (car critique dans votre idée), puis passez ensuite au reste. Reste qui d'ailleurs n'est pas insurmontable. Oui il est relativement facile de faire un Main Menu (une scène) pour accéder ensuite à une autre scène avec le jeu ou des éléments du jeu dedans. Une scène simple avec PNJ et décor cela peut être très vite fait aussi.

Maintenant j'aimerais juste que vous creusiez un peu plus le gameplay lui-même. Le joueur qui joue à ton jeu va devoir se déplacer sur place. Très bien. Mais comment rendre cela organique et intéressant ? Parce que dit comme cela c'est un peu chiant de voir le jeu qui se met en pause le temps que je fasses quelques kilomètres. Comment relier au plus près le monde que vous voulez créer avec le monde réel pour justifier les contraintes de placement que vous voulez imposer à l'utilisateur ?
Certaines applications procèdent de la façon inverse en réagissant au déplacement du joueur via nouvelles interactions/infos/popups quand il approche un certain lieu. Cela pourrait aussi être une piste.

Il y a tout un corpus d'applications/jeux mobiles qui utilisent le GPS au cœur de leur gameplay (avec sans doute Pokemon Go comme figure de proue), c'est toujours intéressant de voir comment eux procèdent et s'ils ont eu de bonnes idées que vous pouvez réutiliser.

----------


## Sariyah

Merci pour vos conseils.
On va tenter de valider que techniquement ça fonctionne la position GPS. C'est une bonne idée de créer une mini app pour simplement tester cette partie.  ::): 

Pour la partie gameplay, on est vraiment en train d'en discuter pour affiner nos idées mais tu as raison sur les points que tu soulèves Grosnours.

Concernant RPG Maker je ne connais pas l'outil mais je suis pas certain que ce soit bien perçu et en plus on a des contraintes comme par exemple versionner le projet et travailler à 4 sur des branches distinctes.

----------


## Grosnours

Par curiosité, pourquoi cette dernière contrainte ?
Cela ne vous force pas à bosser à 4 chacun dans votre coin, ce qui est un peu le contraire de ce qu'on veut nourrir dans un travail de groupe ?

----------


## schouffy

Et je connais pas RPG maker encore une fois, mais ça reste un outil pour faire des jeux, un processus très itératif, donc je serais vraiment surpris que ce ne soit pas compatible avec les systèmes de versioning.

----------


## Sariyah

> Par curiosité, pourquoi cette dernière contrainte ?
> Cela ne vous force pas à bosser à 4 chacun dans votre coin, ce qui est un peu le contraire de ce qu'on veut nourrir dans un travail de groupe ?


Actuellement on est en full distanciel (on est aussi tous en alternance, d'où la contrainte de temps qui me fait peur) et je pense que c'est pour nous forcer à bien se partager les tâches et à utiliser git.
Tous les 4, je pense qu'on va pas se revoir avant longtemps. C'est pas forcément idéal pour le travail de groupe mais on n'a pas le choix.

----------


## schouffy

Bosser chacun sur une branche différente, c'est une sale idée, crois moi. ça va être un cauchemar à tout fusionner à la fin.
Bossez tous sur une branche identique de développement, et tirez une branche quand vous partez sur une feature importante qui risque d'impacter les autres. Puis quand c'est fini tu refusionnes dans la branche principale.

Jette un oeil à Git flow. Quitte à utiliser quelque chose, autant prendre direct les bons réflexes.

----------


## Grosnours

C'est une contrainte des enseignants ou que vous vous êtes fixés vous-mêmes ?
Parce que je me vois mal procéder comme vous au quotidien avec mes deux collègues, le travail de l'un nourrissant le travail des autres. Typiquement avec Unity tu peux travailler sur du script, sur une scène, sur des assets ou sur un mix de tout cela. Ce qui veut dire que en amont découper tout cela (et les taches qui vont avec) en 4 morceaux plus ou moins étanches c'est extrêmement difficile.

- - - Mise à jour - - -




> Bossez tous sur une branche identique de développement, et tirez une branche quand vous partez sur une feature importante qui risque d'impacter les autres. Puis quand c'est fini tu refusionnes dans la branche principale.


Voilà.
Le branching c'est quand tu va faire un truc vraiment distinct/nouveau.

----------


## Sariyah

En fait sur le projet précédent (un app Android) on avait :
une branche dev_prénom 
une branche feature_dev
une master

Chacun d'entre nous faisait son dev sur sa branche puis on faisait une MR qui était intégré à feature_dev et un seul s'occupait de gérer les conflits. La même personne s'occupait de merger dans master.
Par contre c'est vrai qu'on avait au préalable tout découpé pour ne pas se marcher dessus et donc au final on a eu très peu de conflits.

Je fais remonter que ça peut être très compliqué de faire comme ça avec Unity, merci.  :;):  (le repo a été crée que ce matin)

----------


## schouffy

C'est pas lié à Unity, c'est juste une pratique pas terrible que plus vous allez utiliser, plus vous aurez du mal à désapprendre quand vous bosserez dans un environnement professionnel.
Par contre dans Unity y'a une option à cocher pour que les scènes soient enregistrées en textuel et pas en binaire, n'oubliez pas de l'activer pour rendre les merges possibles.

----------


## Sariyah

C'est vrai que c'est complètement différent là ou je bosse depuis un an où on tire une branche depuis master pour chaque ticket. (qui est un dev distinct à chaque fois)
C'est noté pour l'enregistrement des scènes merci.

----------


## Sariyah

Pour les assets, vous auriez des packs à recommander pour tout ce qui est bâtiment / pnj / items ? (gratuit ou payant)
Je remarque qu'il y en a beaucoup qui sont "découpés" et c'est pas vraiment top.

On a reparlé de git et oui on va avoir des problèmes du coup on va changer. Un des formateurs dit qu'il devrait y avoir une seule personne à bosser sur les scenes sinon ça va être un enfer.

Il y a aussi un outil de versionning sur Unity Hub, vous l'avez déjà utilisé ?

----------


## Grosnours

Collab, je l'utilise tous les jours. Le gros avantage c'est qu'il est intégré à Unity. Le gros inconvénient c'est qu'il est limité en fonctionnalités. Et quand le projet grossit et la liste des commits aussi, bonjour les 5 minutes d'attente au lancement pour la sync...  ::P: 

Pour les assets, j'en ai une bonne centaine dans ma besace, mais c'est parce que je bosse avec Unity. Jamais je ne demanderais à des étudiants d'acheter des assets. C'est parfois cher et si c'est pour un seul projet quel est l'intérêt ?
La question que vous devez vous poser est plutôt quel assets pour quoi faire ?
Partant de là vous écumez les gratuits. Bien sur que ce n'est pas idéal, avec un résultat qui risque de ressembler à la créature de Frankenstein question style. Mais on s'en tape, c'est un projet étudiant et les formateurs doivent avoir cela à l'esprit.

----------


## schouffy

J'ai jamais bossé en équipe sur Unity, à part très ponctuellement pendant des game jams, mais les problématiques sont les mêmes (voire amplifiés vue la contrainte de temps).
A mon avis :
- Bossez chacun sur des scènes séparées pendant toutes les phases de prototypage.
- Utilisez au max les prefabs, dont le contenu est stocké indépendamment des scènes, pour éviter les conflits.
- Quand vous passerez en étape de production, une seule personne (ou mieux, 2 personnes devant un seul ordi) peut bosser sur la scène finale.

Je pense que l'outil de versioning choisi ne changera pas grand chose, il va juste vous falloir méthode et rigueur.

Pour les assets, je sais que les packs de synty sont cools et pas trop chers (on sait pas si tu pars vers de la 2D ou de la 3D cela dit), et tu peux essayer de leur faire pitié en disant que c'est pour un projet étudiant, peut-être qu'ils t'offriront une licence.

----------


## Grosnours

Je serais un poil moins intransigeant en ce qui concerne le partage du travail : vous pouvez bosser à deux sur la même scène, mais pas en même temps et en communiquant beaucoup.
En d'autres termes, il arrive souvent que tu bosses sur un aspect d'une scène et qu'un collègue bosse sur un aspect complémentaire. Si toi tu bosses en particulier sur du script que tu rajouteras à des objets de la scène, l'autre peux directement toucher à la scène puis commit et ce sera à ton tour de toucher à la scène. Mais il faudra beaucoup communiquer pour être sur de ne jamais modifier la scène en même temps et hériter de conflits.
Au pire la scène sauvée en mode texte peut s'ouvrir via outils tiers mais il vaut mieux éviter d'en arriver là.

Et oui les préfabs dans Unity c'est la vie.  :;):

----------


## Sariyah

On a fait le choix de partir sur de la 2D. C'est noté pour les assets. Honnêtement l'idée d'en acheter c'est pour se faciliter la tâche et d'avancer plus vite. (si ça le permet évidemment)
Pour le moment on a fait le choix de bosser sur des scènes séparées. Au moins pour le prototype 1. J'hésite à prendre l'intérieur d'un bâtiment. 

J'ai pas bien compris ce que permet les préfabs, je regarde ça ce matin.

----------


## Grosnours

Un préfab te permet d'emballer un ou plusieurs objets de ta scène de la manière dont tu le souhaites pour pouvoir les réutiliser à l'infini dans n'importe quelle scène.
Prends un objet qui est un arbre. Il est composé de plein de sous objets, qui ont tous des composants et/ou du code. Tu les packages ensemble dans un préfab (glisser/déposer dans la fenêtre projet) et tu as un préfab. Glisse/dépose le préfab dans la scène et tu la peuples d'arbres. Change une couleur dans le préfab et tous les arbres instances de la scène changeront. Groupent des arbres ensembles et crée un préfab bosquet.
Tu peux imbriquer des préfabs, faire des préfabs de GUI, etc, les préfabs sont vraiment au centre de la manière de coder dans Unity, difficile de faire sans.

----------


## Sifr

N’empêche si le concept des prefabs est déjà obscur à la base, il faut peut être déjà prendre le temps de comprendre un peu les concepts de base de Unity avant de se lancer dedans...

----------


## Grosnours

A propos d'assets, il y a un bundle "à la humble" sur l'asset store en ce moment.

----------


## Sifr

Tiens l’envie d’intégrer un nouveau truc dans mon STR me démange et je voudrais me frotter à nouveau à un concept que je n’arrive pas à mettre en oeuvre.

C’est le principe des carriers type Starcraft ou vaisseaux aliens de C&C 3.

J’arrive pas à comprendre ce qui est utilisé comme principe pour rendre plus réalistes les mini chasseurs dans leurs mouvements.
Déterminer un point d’attaque et un point de départ pour faire un vecteur : pas de soucis.
J’utilise déjà ça pour les attaques aériennes venant hors de la map.

Mais le côté rotation, évasion pour retour sous un angle d’attaque cela me semble plus obscur.

Une idée ou un principe connu ?

----------


## schouffy

J'ai jamais fait ça et je suis toujours un peu intimidé par ces trucs, et je m'y connais assez peu donc y'a peut-être des techniques bien plus simples ou déjà intégrées, mais je vois deux approches, une simple et une plus complexe (comprendre, y'a des maths)

Approche simple (et performante)
Tu fais quelques animations à la mano où ton vaisseau décrit une boucle ou un 8, et ensuite tu charges l'une de ces animations aléatoirement. Vu que c'est des avions, t'as pas de risque de collision avec l'environnement, et si ils sont assez rapides même les collisions entre eux ne seront pas trop visibles et en tout cas n'impactent pas le gameplay (tu peux même prétexter qu'ils sont à des altitudes différentes). Même s'ils sortent de la map pendant un temps très court c'est pas bien grave non plus je pense. Pour reprendre ton exemple, les Carrier de SC s'en battent le steak de tout ça.
Pour positionner ton anim, tu peux faire en sorte que le vaisseau commence par attaquer la cible (hors anim), puis une fois au-dessus, il lance l'anim (la première frame de l'anim est donc à considérer comme celle ou le vaisseau survole sa cible).
Pendant qu'il joue l'anim, lorsque le forward du vaisseau est dirigé "a peu près" vers la cible et que la distance est inférieure à sa portée d'attaque, le vaisseau tire

Approche complexe
1. Tu calcules quelques positions qui forment une boucle autour de la cible. le pattern peut être toujours le même, ou déterminé en fonction des contraintes de ta cible et de l'environnement, ça dépend à quel point tu veux te challenger  :^_^: ^ Il faut que au moins un segment entre deux point passe approximativement au dessus de ta cible
2. Tu ajoutes des points intermédiaires qui permettent de smooth la trajectoire (prends exemple sur les bezier curve par exemple, matte ça)
3. Tu fais en sorte que ton vaisseau cherche toujours à rallier le point suivant, et le regarde.
4. Lorsque le forward du vaisseau est dirigé "a peu près" vers la cible et que la distance est inférieure à sa portée d'attaque, le vaisseau tire
5. Tu ajoutes des petites rotations sur l'axe Z du vaisseau pour que la courbe paraisse plus réaliste.

----------


## Roscopolo

A chaque rendu le chasseur a un vecteur vitesse donné et il veut aller vers sa cible. On commence par réduire sa vitesse pour modéliser le frottement (mettons 2% par 50ms).

Ensuite on ajoute un gain de vitesse vers l'avant qui représente une poussée dirigée vers l'arrière du vaisseau, plus ou moins un certain angle car le réacteur est orientable (par exemple +-70° et 2m/s par 50ms). La direction du gain est choisie en fonction de l'angle de la cible. Si cet angle est inférieur à 180 on choisit un min(angle, 70), sinon on prend max(angle, 290).

Si on veut permettre des tours plus rapides on peut ajouter un réacteur secondaire latéral (poussée vers le côté) ou un aérofrein (poussée vers l'avant). Ils seront allumés si le produit scalaire de leur poussée avec la direction de la cible est positif.

Enfin pour les manoeuvres d'évasion c'est le même principe : on veut aller dans la direction opposée à celle du missile. On peut raffiner mais ça donnera déjà un joli résultat.

----------


## Sifr

Merci pour les idées, je m’en suis inspiré, et du coup je suis en train de faire un mix en recyclant mon module d’arme guidée et au lieu d’impacter la cible je me contente de faire voler l’objet avec un Y fixe pour le côté aérien et quand il passe au dessus de la cible je lui redonne deux points formant par un triangle isocèle avec la position de la cible.

Avec un update de mouvement selon X frames, ça finit par faire des quasi cercles paramétrables avec la vitesse et les deux côtés du triangle.

Je déclenche ensuite un tir direct ou par missile quand la cible est à portée.

Ça devrait rendre pas mal quand j’en lancerais plusieurs depuis le porteur.

----------


## Sifr

Bon j’en suis au stade des chasseurs type starcraft et ça rend vraiment bien.

C’est excellent comme un truc sur lequel on se casse les dents et finit par marcher apporte autant de satisfaction  ::): 
Du coup je me lasse pas de faire voler des micro chasseurs sur des petites cibles fragiles  ::ninja:: 

Merci pour votre aide.
Me reste plus qu’a me faire un beau porte avions sous Magica Voxel !

----------


## Sariyah

Salut les Canards,

Pour l'intérieur d'un bâtiment j'ai pris des assets avec une démo et je me pose quelques questions. 

Sur le screen, ci-dessous, est-ce que vous pouvez m'expliquez pourquoi la table (sur laquelle j'ai le curseur) passe sous le sol ? Celle juste devant le personnage idem. Pas mal d'éléments coupés (les tonneaux à l'entrée etc)



Ensuite je me demande comment je peux linker cet intérieur avec la porte d'un bâtiment à l'extérieur ? Pour que quand le perso passe la porte, ça switch à l'intérieur comme beaucoup de jeux qu'on connait tous.

Pour le reste on a réussi à bien avancer sur la géolocalisation donc c'est un bon point.

----------


## Grosnours

1)Vérifier tes valeurs de Z (ou X ou Y) pour la table et le sol. S'ils ont la même, il y a un léger souci, ton sol doit être au dessus de la table. Vu que la plupart de tes assets sont à moitié visibles, ils ont sans doute tous ce problème.
2) Tu mets ton extérieur dans une autre scène dans laquelle cliquer sur la porte provoquera le chargement de la scène d'intérieur.
3) Ce n'est pas parce que tu développes une scène en 2D qu'il te faut laisser l'affichage en mode 2D, décoche cela et tu verras bien mieux ce qui déconne dans ta scène en changeant ton point de vue. La 2D dans Unity cela n'existe pas vraiment, le monde est en 3D.

----------


## Sariyah

Merci Grosnours.  ::):  

L'extérieur existe déjà sur une autre scène y compris les bâtiments. Ça veut dire que le lien pour le switch de la porte se fait facilement à partir de la scène extérieur ?

Tu parles bien des valeurs (X, Y, Z) de la position à modifier ? La Z est la même effectivement mais l'a modifier ne change rien. Ce serait quoi la logique de cette valeur ? 

Edit => Project Settings => Editor => Default Behaviour Mode, rien ne bouge quand je passe de la 2D à la 3D. Il y a autre chose à faire ?

----------


## Grosnours

Dans ton screenshot d'avant tu as un bouton 2D enfoncé. Entre shaded et l'ampoule, sur la ligne juste au dessus de la fenêtre de la scène. Décoche le.

Pour le reste, c'est tout simplement de la géométrie dans l'espace. Tu as trois axes X, Y et Z, longueur, largeur, hauteur. Traditionnellement Z reflète ce qu'on appelle la hauteur mais cela dépend totalement de ta scène et comment elle est orientée: la hauteur peut correspondre à X, Y ou Z en fait. L'idée est que si deux objets occupent le même espace ils vont se confondre et provoquer des artefacts d'affichages. Il faut que ta table soit au dessus de ton sol. Passe en 3D, change ton point de vue et place les éléments de la scène comme tu le souhaites.
En terme d'UI tu peux placer des canvas à divers ordre de tris, pour les caméras tu as des profondeurs distinctes, tu as aussi un systèmes de couches(layers) mais on va éviter tout cela pour le moment et essaye juste de placer tes objets correctement dans la scène 3D.

Dans la scène d'extérieur, tu places un bouton ou tout autre trigger sur la porte qui fera en sorte que tu LoadScene (charge la scène) ta scène d'intérieur. Une fois le porte externe cliquée, le joueur attendra un poil que ta scène d'intérieur se charge et se retrouvera dedans.

Bon par contre tout ce que je t'explique là c'est la base de la base d'Unity, un truc que vos profs auraient absolument du vous expliquer ou vous orienter vers des vidéos/training qui vous le fasse comprendre. Unity est un moteur complexe, on ne peut pas débarquer la fleur au fusil et faire un truc au quart de tour, il y a un certain nombre de concepts à comprendre pour utiliser l'outil. Je ne dis pas cela contre toi, mais contre tes profs qui vous demandent un projet qui n'est pas simple sans vous fournir la formation pour faire ainsi.

----------


## Sariyah

J'ai un gros soucis il y a eu un problème sur git du coup ma branche a été delete et je repars sur une nouvelle pour ma scène. Pas grave je peux recommencer. 
Je viens de git fetch &&  git chekout ma_nouvelle_branche

Comment je peux récupérer le pack que j'ai acheté svp ? Avec la scène de démo, les assets etc..

Rapport à ton message du dessus, on n'a pas eu de cours sur Unity donc vraiment pas le choix. On a choisis notre projet du coup maintenant faut assumer mais oui je me rends compte qu'on s'est tiré une balle dans le pieds...

----------


## Grosnours

Pas une balle, un putain de chargeur entier.
Tes assets sont présents ad vitam aeternam. Pour importer celui que tu as acheté dans la scène actuelle, tu va dans windows>Asset Store (ou CTRL+9) et tu cliques ensuite sur l’icône d'un carré qui contient une flèche vers le bas, qui sont tes assets. Tu auras une liste et tu cliques sur le bouton importer sur celui que tu veux.

----------


## Sariyah

C'est en train de faire un "fetching packages" depuis package manager. Je suis allé sur le store j'ai récupéré mon achat en choisissant d'ouvrir avec Unity, on va voir si ça marche

Dans quelle merde je suis...  ::cry:: 

edit : J'ai récupéré la scène de demo, je voudrais mettre les fichiers avec nos autres scenes.
Est-ce que vous me conseillez de couper/coller tous les fichiers à savoir : 
-Demo.unity
-Demo.unity.meta
-DemoSettings.lightning
-DemoSettings.lightning.meta
?

Je remarque que sur les scènes faites par les autres, il n'y a pas de :
-Settings.lightning
Settings.lightning.meta

Par contre on a une scene ou il y a les 4 qui s'appelle SampleScene..

edit : Bon ben j'ai déplacé les 4 fichiers ça a l'air de re marcher, toujours les soucis de départ mais bon je vais regarder

----------


## Sariyah

Le mode 3d je comprends absolument rien.



J'ai un peu peur de tout casser

----------


## Grosnours

Clique sur la main en haut à gauche pour bouger dans la scène. Laisse appuyer la toucher ALT pour bouger dans tous les sens. Double clic sur un élément de la scène dans l'inspecteur pour zoomer sur celui-ci.

EDIT :
Va là et fais les tutos, autant que tu peux : https://learn.unity.com/
En commençant par _Using the Unity Interface_.

----------


## Sariyah

Merci Grosnours (mp inclu  ::P: ),

Je vais regarder tout ça. Pour le moment j'ai refais la scène comme j'ai pu mais pour le loadScene avec un trigger ça me semble assez compliqué à faire pour le moment.

----------


## war-p

> J'ai un gros soucis il y a eu un problème sur git du coup ma branche a été delete et je repars sur une nouvelle pour ma scène. Pas grave je peux recommencer. 
> Je viens de git fetch &&  git chekout ma_nouvelle_branche
> 
> Comment je peux récupérer le pack que j'ai acheté svp ? Avec la scène de démo, les assets etc..
> 
> Rapport à ton message du dessus, on n'a pas eu de cours sur Unity donc vraiment pas le choix. On a choisis notre projet du coup maintenant faut assumer mais oui je me rends compte qu'on s'est tiré une balle dans le pieds...


Pour ton problème de git, sache que jamais rien n'est perdu. Tu peux toujours revenir sur les commits, même s'ils ne sont plus liés à une branche  :;):

----------


## Sariyah

> Pour ton problème de git, sache que jamais rien n'est perdu. Tu peux toujours revenir sur les commits, même s'ils ne sont plus liés à une branche


Là à priori ça n'a pas été le cas, j'avais ma branche et j'avais déjà récupéré mes assets et ma démo scène. J'ai commencé à travailler dessus sans pull dev (notre genre de pré prod), je pensais que je pourrais le faire après puisque je travaille sur une scène à part mais non et ça a fait de gros conflits.

Quelle idée stupide j'ai eu d'utiliser Unity pour ce projet.. C'était histoire de faire quelque chose d'original, de sortir du web etc. Si j'avais su on serait parti sur un truc simple histoire de prendre quelques points et basta. Là vu comment c'est parti je pense pas que ça paye en terme de notation et on va pleurer du sang.

----------


## Grosnours

C'est simple. Tu as une scène A qui est à l'extérieur et une scène B qui est ton intérieur.
Dans ta scène A tu as un bouton qui possède un bout de code du genre :


```
using UnityEngine.SceneManagement;


public void ClickExit()
{
		SceneManager.LoadScene("B");
}
```

Tu attache ce bout de code au bouton et tu relies le clic du bouton à ClicExit (dans l'inspecteur, tu rajoutes sur le plus dans la boite OnClick, tu glisses déposes le bouton lui-même sur la partie gauche du champ qui est apparue et tu utilises la liste déroulante pour pointer vers la fonction ClickExit) et le tour est joué.

Si tu veux passer de la scène B à la scène A, tu procède de même avec un bout de code quasi identique qui cette fois ci chargera "A" lors d'un clic.
On peut optimiser à mort tout cela mais le principe de base est là.


Juste pour vérifier je suis allé voir un très vieux projet que j'avais fait en full 2D et toute ma profondeur de champ était géré par l'ordre dans lequel les éléments étaient dans leur canevas (plus un élément est haut dans ta hiérarchie, plus il est rendu en-dessous des éléments placés plus bas), avec un Z nul pour tout le monde. Avec plusieurs canevas si besoin.

Bref tu peux parfaitement rester en full2D si tu veux, fais juste bien gaffe à bien ordonner les choses dans ton canvas. Pour ce faire tu peux t'aider à établir des hiérarchies propres avec des GameObjects vides dans le rôle de parents. Avec par exemple un parent appelé background, un appelé middle, un appelé foreground dans lequel tu place judicieusement tous les objets que tu veux, et chaque parent lui même resubdivisé en plusieurs familles (tapis, tables, chaises, etc...) en fonction de la profondeur que tu veux donner à tous tes objets individuels.

J'aurais pas du t'envoyer sur le chemin de l'affichage en 3D puisque tu peux parfaitement faire sans, mais bon vu que je n'ai plus touché à la 2D depuis des années j'ai quelques excuses.

- - - Mise à jour - - -




> Quelle idée stupide j'ai eu d'utiliser Unity pour ce projet.. C'était histoire de faire quelque chose d'original, de sortir du web etc. Si j'avais su on serait parti sur un truc simple histoire de prendre quelques points et basta. Là vu comment c'est parti je pense pas que ça paye en terme de notation et on va pleurer du sang.


Ah ce n'est clairement pas l'idée du siècle de se lancer dans un système complexe qu'on a jamais vu en pensant que c'est easy-peasy.
Ce n'est pas limité à Unity, t'en aurais chié pareil dans l'Unreal Engine aussi d'ailleurs. C'est un peu comme vouloir utiliser Blender sans jamais l'avoir vu alors que le Paint de base aurait suffit. Tu payes la puissance par de la complexité.

Cela ne veut pas dire qu'on peut faire des trucs simples dans Unity. Bien sur qu'on peut mais il faut d'abord étudier toute une série de concepts de base (interface, hiérarchie, scripts, etc...) qui ne sont peut être pas instinctifs ou évident si on a jamais vu cela avant.

----------


## war-p

Je dirais même que tu en aurais chié avec n'importe quel moteur en y allant en mode yolo. Mais c'est bien, c'est comme ça qu'on progresse  :;):  Et pour ton histoire de conflit, je pense que là aussi, tu dois avoir une petite incompréhension du fonctionnement de git, mais t'inquiètes pas, c'est normal au début. Git, ça paraît ultra simple, mais c'est très puissant et en fait très complexe  :;):  Et le mieux est d'utiliser un outil pour gérer tes conflits. Tant que c'est pas sur des fichiers binaires, t'es sauvé, sinon faut choisir.

----------


## Sariyah

Merci encore Grosnours ça devrait aller avec tes explications pour le bouton, je vois ça demain matin avec les autres.
Pour la profondeur de champ, je suis surtout très étonné qu'un pack payant comprenant une scène de Démo l'a gère pas correctement. Ou alors c'est le fait de l'importer dans notre projet qui a tout cassé ? Je ne sais même pas si c'est possible ce que je raconte.
Je vais essayer de mieux faire pour la prochaine scène..

Pour le git ce n'est pas moi qui m'en occupe en fait, je me sens pas du tout de le faire. Le versionning hormis au boulot ou c'est très carré et bien fait ça m'inquiète plus qu'autre chose. 

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.  ::sad::

----------


## Sifr

Ce que je comprends pas c’est pourquoi quasiment personne ne prend le temps de faire un ou deux exemples tutos des moteurs de jeu et se lancent direct dans le truc sans vraiment prendre le temps d’au moins assimiler les bases.

On dirait que maintenant c’est en mode para-je-saute-en-territoire-ennemi sans formation  ::): 

Prendre une semaine pour faire joujou avec un truc présenté et chiadé ça permet de fixer les choses.

Et ça permet de gagner bien plus que le temps consacré à la formation/découverte initiale.

D’ailleurs, les trucs payants ça peut gagner du temps mais souvent c’est fait comme des sagouins...
A part ceux sui ont une certaine notoriété forcément.
Et souvent il vaut vient se battre avec des carrés de couleurs et autres placeholders même si ça fait pas joli pour avancer et maitriser ce qu’on fait plutôt que de mettre une jolie couche graphique qui motive mais pète au moindre truc qui est hors contexte par rapport à ce qu’on veut faire.

Après un jeu ça peut être simple, avec deux commandes on arrive à faire du Flappy Bird  ::lol::

----------


## Grosnours

> D’ailleurs, les trucs payants ça peut gagner du temps mais souvent c’est fait comme des sagouins...


Je confirme...  ::P: 
Même ceux qui sont excellents et de bonne qualité peuvent parfois avoir des défauts pour notre usage particulier et vont nécessiter un peu (ou beaucoup) d'huile de coude pour les faire fonctionner parfaitement pour nous.

- - - Mise à jour - - -




> Et souvent il vaut vient se battre avec des carrés de couleurs et autres placeholders même si ça fait pas joli pour avancer et maitriser ce qu’on fait plutôt que de mettre une jolie couche graphique qui motive mais pète au moindre truc qui est hors contexte par rapport à ce qu’on veut faire.


Tout à fait.

----------


## 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.  ::ninja:: 

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.  ::o: 

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  ::P: 

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 !  ::P: 

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....  ::P: 
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 - - -
> 
> ...


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 ?  ::trollface:: ). 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  ::P: )

----------


## 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.  ::ninja:: 

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  ::P: 

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  ::ninja::

----------


## 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  ::ninja:: 

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  ::XD:: 
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  ::siffle::

----------


## 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.

----------


## Grosnours

Je te conseille de refaire le shader de la vidéo (il est très simple) car je ne sais plus si on peut le récupérer direct et voir si le résultat te plaît. Si ce n'est pas le cas, pas grave, tu auras passé un peu de temps à voir des trucs utiles. Mais je pense qu'avec ce shader tu n'auras pas les artefacts que tu obtiens avec ta méthode.

Le principe est que tu définis autant de plateaux de hauteurs que tu veux, et tu assignes une texture par plateau. Les textures sont interpolées en fonction de la distance des bornes. je trouve le résultat assez lisse. Après tu peux raffiner les choses en rajoutant  plusieurs textures pour un seul niveau que tu interpoleras elles aussi entre elle en fonction de ce que tu veux.

On a fini par procéder différemment mais on était parti là dessus au début quand on a passé le moteur de notre jeu à l'URP et cela donnait de bonnes choses.

----------


## Sifr

Solution invalidée  ::ninja:: 

Blague à part, le shader graph c’est pas beau en l’état, sans la gestion de la pente, c’est trop artificiel.
Pour le moment je garde mon script.

C’est étonnant qu’il y ait pas une fonction avancée depuis tout ce temps.
Même la 2021 ne présente que du texturing par filtrage de hauteur, on peut mixer un peu mais ça pourrait depuis le temps être sous forme de script automatisé.

----------


## Grosnours

Deux problèmes distincts là-dedans je pense :
- les pipelines qui sont assez troués car il leurs manque encore un certain nombre de fonctionnalités.
- le Shader Graph est assez largement naze si tu veux faire un machin un tout petit plus sophistiqué qu'appliquer un effet tout bête.

Il faudrait que je vois un jour pour trifouiller directement du hlsl. Ou utiliser Amplify Shader Editor qui est bien supérieur au Shader Graph.
Sinon t'as le gars de Microsplat qui a sorti un truc intéressant : https://assetstore.unity.com/package...rp-hdrp-187838

----------


## Sifr

J'ai finalement converti le défaut d'avoir un script en force : je suis passé par un workflow scripté pour réaliser mes maps.
J'ai récupéré des bouts de code/théorie à droite à gauche et finalement j'ai un premier menu qui charge une texture et la transforme en heightmap
Un second menu qui charge les layers dans le terrain pour auto texturer.
En deux clics j'ai un terrain potable.

Me reste à trouver un peu de théorique pour faire un script qui génère un simplex et l'empiler avec une texture avec des chemins génériques pour créer une texture correspondant à des maps sympas.

----------


## 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.


C’est resté coincé dans ma tête cette remarque et finalement j’en suis pas encore à supprimer la déformation mais par ricochet ça m’a permis d’affiner mon fog of war maintenant couplé en un decal projector et un plan juste à la surface de l’eau.
Ça s’affine  ::):

----------


## Djal

Hello les coins,

Ça roule? Ca fait longtemp que je ne suis pas passé, j'en vois qui sont toujours aussi talentueux (et je suis jaloux).

Je cherche un dev Unity plutôt expérimenté pour rejoindre une équipe dédié au *casu mobile*.

Le poste est en remote 100%, CDI, l'équipe est plutôt cool.

Si jamais il y en a ici qui cherchent, MP  ::): 

Autre question, on cherche un discord pour échanger avec d'autres Dev Unity, vous savez si il y a une communauté sympa pour échanger des tips?

----------


## Grhyll

Hey  ::):  Pour ce qui est des Discord, tu peux déjà essayer de voir auprès de ton cluster local, y a des chances qu'il en ait un ! (Enfin à moins que tu sois dans un désert total, mais même si c'est le cas y a souvent moyen de s'incruster au plus proche !)

----------


## schouffy

Perso je suis sur les Discords suivants :
Unity
Brackeys
GMTK
Ludum Dare
UModeler
PIGD - Paris Indie Game Dev Meetup

Tu peux poser des questions et obtenir des réponses sur quasi tous, mais je trouve que seul le dernier est suffisamment petit pour permettre d'avoir vraiment des échanges.
Fouille sur meetup, même si depuis 2020 c'est un peu moins actif, forcément.

----------


## LDiCesare

Salut.
Est-ce que quelqu'un connait des assets ou programmes pouvant s'interfacer avec Unity qui simplifieraient la création de quêtes/aventures texte?
Pour le moment j'ai regardé chatmapper (bof), Articy draft (bien), QuestMaker (bof), Dialogue System (a l'air bien mais faut que je creuse et ça peut importer chatmapper et Articy).
En gros, j'ai une carte, je veux pouvoir quand le joueur arrive à un endroit déclencher une évaluation d'événements à déclencher, et si c'est le cas, ouvrir un panneau de texte avec des choix, choix qui vont dépendre du contexte (nom de la ville, d'un perso..., localisation d'une autre ville...) et que je vais conserver dans des variables quelque part tout en pouvant tester les caractéristiques du joueur et son equipement (pour simplifier).
Et si quelqu'un a une experience avec Articy draft ou Dialogue System, je suis preneur de retours aussi.

----------


## Grosnours

On va utiliser Dialogue System incessamment sous peu pour avoir une couche de dialogues/tuto dans un jeu 3D mais comme d'une part on a pas commencé et d'autre part ce n'est pas moi qui vais coder cette partie, voilà un beau retour super utile de ma part. Ceci dit on va avoir un truc qui ressemble au tien (tonne de dialogues variables + localisation en plusieurs langues) et je pense que Dialogue System supporte cela très bien. Enfin j'espère...  ::P:

----------


## Molina

> On va utiliser Dialogue System incessamment sous peu pour avoir une couche de dialogues/tuto dans un jeu 3D mais comme d'une part on a pas commencé et d'autre part ce n'est pas moi qui vais coder cette partie, voilà un beau retour super utile de ma part. Ceci dit on va avoir un truc qui ressemble au tien (tonne de dialogues variables + localisation en plusieurs langues) et je pense que Dialogue System supporte cela très bien. Enfin j'espère...


J'utilise dialogue system (DS). 

Donc, en gros avec Dialogue system tu peux effectivement faire ce que tu veux, c'est assez facile à prendre en main (j'ai eu un peu de mal à comprendre comment faire communiquer les scripts et DS) mais... Mais je le retrouve un peu relou. Dans le sens, où il y a pas mal de micromanagement quand tu rentres dans les histoires de dialogues conditionnels et/ou quand tu veux faire fonctionner un script à toi dès qu'une réponse a été choisie. Il me semble que c'était Aurora à l'époque où tu pouvais très facilement utiliser des variables et tes scripts (enfin je trouve). Les méthodes par exemple. Tu dois faire gaffe qu'elles utilisent bien des variables lisibles par LUA (si je ne dis pas de bêtise, tu ne peux utiliser que des bool et des doubles et des string), tu dois l'inscrire dans une liste blanche de méthode utilisable par DS, puis l'utiliser dans ton dialogue. Et c'est quasi la même chose pour les variables perso. 

Après tu as le problème universel : l'organisation :


Spoiler Alert! 







Mais voilà, c'est facile, c'est lisible. Pour te donner une idée, l'équipe de Disco Elysium a utilisé Dialogue System avec quelques tweak dessus. Le mec qui s'occupe de DS est ultra gentil. J'ai jamais connu quelqu'un comme ça. Si tu relèves un bug, genre 2 jours après tu as un patch. Si tu ne comprends pas un truc, et que tu lui envoies un script il te le corrige en moins de quelques jours (voire le jour même).  Il est très actif sur le forum et il n'a pas peur de répéter dix fois la même chose. 

Il existe également une documentation assez touffue. Il faut un peu de temps pour digérer le tout, mais toute l'info est là (même si parfois je ne le trouve pas très très clair). Bref, personnellement, je comprends tout à fait pourquoi c'est l'asset le plus utilisé sur l'asset store. Ça te fait le job basique. Et tu peux faire des  trucs relativement complexe dessus. 

L'asset a son propre système de serialisation par contre. Du coup, personnellement, c'est pour moi une boite noire. Pour l'instant ça marche, du coup je ne me suis jamais planché dessus. Et DS est compatible avec la plupart des gros assets de l'asset store.

Bref, dans l'ensemble j'en suis content. Même si ça me demande un gros effort de concentration pour avoir exactement ce que je veux. C'est pas l'outil qui va combattre ta procrastination, au contraire.

----------


## LDiCesare

Articy draft permet d'avoir une organisation plus lisible (des boites dans des boites, donc tu peux voir tes conversations au niveau de detail que tu veux sans avoir tout l'arbre à regarder). Surtout, tu peux définir des templates et reutiliser en changeant 3 variables la meme "quete".
Avec Dialogue system, j'ai l'impression qu'il faudrait changer les acteurs de la conversation quand on la démarre et que tout est des variables globales, donc si je veux deux instances d'une meme conversation, je sais pas trop si le systeme est adapté? Autant dans la majorité des cas, réutiliser une conversation en changeant les variables d'entrée va suffire, autant il y a des fois où je veux par exemple "amener à X le Mc Guffin1" et avoir une autre quete "amener à Y le McGuffin2" et j'ai l'impression que je serais obligé de stocker les infos X, McGuffin1, Y, McGuffin2 etc. complètement en-dehors de Dialogue system?

----------


## Molina

> Articy draft permet d'avoir une organisation plus lisible (des boites dans des boites, donc tu peux voir tes conversations au niveau de detail que tu veux sans avoir tout l'arbre à regarder). Surtout, tu peux définir des templates et reutiliser en changeant 3 variables la meme "quete".
> Avec Dialogue system, j'ai l'impression qu'il faudrait changer les acteurs de la conversation quand on la démarre et que tout est des variables globales, donc si je veux deux instances d'une meme conversation, je sais pas trop si le systeme est adapté? Autant dans la majorité des cas, réutiliser une conversation en changeant les variables d'entrée va suffire, autant il y a des fois où je veux par exemple "amener à X le Mc Guffin1" et avoir une autre quete "amener à Y le McGuffin2" et j'ai l'impression que je serais obligé de stocker les infos X, McGuffin1, Y, McGuffin2 etc. complètement en-dehors de Dialogue system?


Tu peux avoir plusieurs conversations. Perso, j'ai fait une conversation par instance de PNJ.  Par exemple, ce que tu vois dans mon screen, il y a trois acteurs (un russe, un français et le joueur). La première ligne en partant du rectangle orange correspond à la première fois que le joueur rencontre ces deux personnages. La deuxième ligne, mélange aussi bien le retour du joueur s'ils ne trouvent rien ou n'a pas continué la quête, que la résolution de la quête. 

Je dois à être à une vingtaine de 'conversation'. 

Alors non, tu peux avoir une variable "McGuffin" qui peut avoir plusieurs valeurs. Je ne sais pas si tu peux avoir une liste par contre, faudra voir dans la docu. Mais, tu peux changer facilement les acteurs. Tu as le choix en fait. Soit pour une conversation, tu graves dans le marbre l'acteur. Soit tu peux dire à DS que le nom de l'acteur correspond à l'instance de l'objet qui porte la conversation. 


Et tu n'as pas besoin d'enregistrer tes variables en dehors de DS. Tu peux les valider dedans, et même changer leur valeur via script par exemple (assez facilement).

Après pour faire des quêtes un peu procédurale comme ça, ça voudrait peut être le coup de jeter un coup d'oeil à Quest Machine (qui peut marcher en tandem avec DS). La grosse feature, c'est justement pouvoir faire des quêtes procédurales.

----------


## LDiCesare

J'ai vu Quest Machine, mais c'est vraiment des quetes à la Diablo, attachées à un donneur de quetes, et le moteur est interessant dans la mesure où il permet de faire qu'un donneur de quete va generer une quete si (tel ou tel parametre). C'est plutot bien fait dans la mesure où il y a des sortes de motivations pour savoir si tu vas donner telle ou telle quete, mais c'est pas du tout ce que je veux. Je cherche pas tant du procédural que du paramétrique.

Ce que j'ai c'est par exemple une quête de type "intrigue", qui prend en paramètre 2 villes, un antagoniste, quelques paramètres (texte, objet, récompenses, valeurs de réputation minimum pour déclencher des actions), que je voudrais pouvoir copier-coller en plusieurs villes (e.g. j'en ai une à Bayonne pour t'envoyer à Bordeaux en évitant le sire d'Albret et une à Dijon pour t'envoyer à Lille en esquivant les Orléans). Chaque quête a ses propres variables/état de progression. Ainsi je peux décliner plusieurs "intrigues" entre certaines villes et plusieurs autres types de quête, et potentiellement en avoir plusieurs en parallèle (parce que si j'en ai une seule, suffit de changer les paramètres au début).
Et pour le coup, je veux importer les variables du jeu car la réputation ici est externe à DS, mais a priori DS sait faire ça bien.

Articy me permet de faire ce genre de quête template, mais faudrait que je regarde l'intégration dans Unity plus en détail tant que j'ai le droit de m'en servir (la licence d'évaluation ne durant que 2 semaines).

----------


## LDiCesare

Après plus de recherches et si ça peut servir à quelqu'un d'autre :
ZA/UM a utilisé Dialogue System et Articy draft. Difficile de dire comment ils ont réparti les rôles, mais l'impression que j'ai c'est que le plugin d'import d'arcity vers Unity date de 2019 et donc qu'avant ça on était obligé de passer par Dialogue System pour le faire.
J'ai bien vu quelques autres outils, mais ils ne sont pas très convaincants: Discourse n'a que des revues négatives depuis 1 an, et Arcweave parait prometteur mais l'import ne gère ni le scripting ni les branches pour le moment.

----------


## Sifr

Je viens de tomber sur un truc sans doute de débutant mais que je n’arrive pas à expliquer.
J’utilise une fonction de recherche du navmesh -> sampleposition pour vérifier que mes unités peuvent bien se déplacer à tel endroit.

J’ai deux nav meshs, un pour l’eau appelé Water et un autre pour le ciel appelé Sky - c’est les noms visibles dans la liste des Area de l’onglet navigation là où on trouve aussi les poids de chaque navmesh.

Quand je fais mon test initial j’ai utilisé le int des meshs area par NavMesh.allAreas et ça passe tout seul.
Mais du coup les bateaux accédent au navmesh des hélicos et veulent se retrouver au milieu d’une ile... ce qui plante la logique de regroupement.

Donc j’ai utilisé GetAreaFromName. Sauf que si j’utilise Water ou Sky je ne trouve aucun nav mesh.

C’est pas la bonne fonction pour identifier les Navmesh par leur nom d’area ?

----------


## schouffy

C'est un masque un peu comme les LayerMask, tu as bien fait 1 << ?

https://docs.unity3d.com/ScriptRefer...aFromName.html

----------


## Sifr

Ca vient sans doute de là. Je vais tester. Merci.

A tous les coups je me suis fait avoir car le masklayer int n'a pas besoin de ce 1 << quand je l utilise.

----------


## Sifr

> C'est un masque un peu comme les LayerMask, tu as bien fait 1 << ?
> 
> https://docs.unity3d.com/ScriptRefer...aFromName.html


C’était bien ça  :;): 

Du coup je me suis pris une flanquée de comportements zarbis en paufinant la fonction  ::XD:: 

C’est beau la programmation. Tout est rentré dans l’ordre et ça bataille sec  ::ninja::

----------


## Sifr

Vu que mon truc tourne sans trop de soucis et que la seule véritable chose où je vais me retourner le cerveau c’est de coder le principe des captures de banque d’Act of War je me fais une petite pause et je retourne dans les fondamentaux de mon code qui me plaisent que moyennement côté ergonomie.

Notamment je suis pas satisfait de la réactivité multi sélections au double clic.

Je suis toujours avec un bout de code générique/méthode qu’on trouve partout où le double clic est géré via un timer très court.

Ça fonctionne pas tout le temps - et sur leur nouvel input system y’en a qui râlent disant qu’on peut toujours pas gérer le double click correctement.

Vous connaissez d’autres méthodes pour une identification de double click qui marche ?

----------


## schouffy

Je connais pas le nouveau système d'input, mais un clic suivi d'un autre clic dans la fenêtre d'un timer, c'est du code de détection de double clic infaillible. Je pense que ton problème vient d'ailleurs.

----------


## Sifr

> Je connais pas le nouveau système d'input, mais un clic suivi d'un autre clic dans la fenêtre d'un timer, c'est du code de détection de double clic infaillible. Je pense que ton problème vient d'ailleurs.


Effectivement le code était bon mais pas la logique...  ::): 

Je validais le fait que le double click était bon puis je traitais le click simple ce qui parfois mélangeait les deux.

Alors que la bonne démarche qui fonctionne parfaitement est de déterminer si on est dans une situation de double click et si et seulement si on a dépassé la période de double click alors on exécute le code du clic simple, ce qui assure qu’ils ne se chevauchent jamais.

Je suis content, ça me fait une ergonomie propre. Merci  :;): 

Et puis je pense aussi que je vais abandonner la déformation de mon mesh de surface d’océan.
Ça apporte pas grande chose et depuis j’ai découvert un usage du Voronoi node dans shadergraph qui me permet de faire des effets de lumière dans l’eau ( et dans les boucliers énergétiques), ça compense largement la disparition de la micro déformation sachant que j’ai déjà les textures normales qui font le job.

Hormis l’arbre de recherche, mon objectif était d’atteindre le contenu technique et l’ergonomie d’un Forged Battalion en terme de STR, je pense que je me positionne pas mal par rapport à cette cible, sans compter les trucs hérités des autres STR. 
C’est quand même vraiment sympa Unity comme moteur et possibilités.
Je pensais pas que la version de base m’aurait permis de faire tout ça.

----------


## Sifr

Décidément j’ai encore une question...

J’ai mon menu de sélection des camps etc qui est dans une scène.
Je charge la map ensuite dans une autre scène.

Unity le dit que j’ai deux event system... c’est un warning mais j’aime pas quand c’est pas propre.
Pourtant quand je suis dans ma scène de map j’en ai qu’un.

Il vient d’où ce message ? J’ai essayé de killer l’eventsystem du menu au loading mais ça ne change rien.

----------


## Grosnours

Tu as un script EventManager sur un gameobject quelque part, et je suppose qu'il est DontDestroyOnLoad, c'est cela ?
Il faut juste que tu sois sur que tu n'appelles pas deux fois ce script, il ne doit être présent que dans la toute première scène (ou à partir du moment où tu en as besoin). Vérifier le nombre de références au script devrait faire le blot.

----------


## schouffy

Perso j'aime pas du tout mixer plusieurs scènes, je préfère avoir un préfab "Systems" qui contient tout ce qui est UI, event manager,...

----------


## Molina

Pour l'Event manager, perso je préfère en avoir 1 dans chaque scène (mais pour une raison qui m'est spécifique, mais j'ai oublié pourquoi. :D).

Je crois que c'est parce qu'Unity a tendance a en créer un à chaque fois.

----------


## Grosnours

Par défaut les Event Manager sont effectivement automatiquement crées dans les nouvelles scènes (ou introduit automatiquement quand on ajoute un objet spécifique, je ne sais plus).

C'est le dilemme classique avec l'organisation en scènes et les données:
- si tu divises en scènes logiquement tu va devoir assurer une pérennité de certains types de données qui sont transversales à l'appli, ce qui se fait typiquement via des singleton ou objets dontdestroyonload. Ce n'est pas très propre programmatiquement parlant.
- si tu n'as qu'une seule scène tu n'as plus ce soucis de données mais si le soft devient complexe cela risque de devenir un beau bordel assez lourd.

Perso les singletons sont mes amis, mais je comprends que cela puisse hérisser.

----------


## Sifr

Le problème est réglé, j’avais bien un eventsystem en trop qui venait de l’écran de chargement intermédiaire.  ::): 
Il vient à être ajouté automatiquement dès qu’on ajoute un canvas.
J’ai dû dupliquer la scène à l’époque au début et pas comprendre que ça posait ensuite d’office ce truc.

Moi je sais pas ce qui est le mieux et j’ai sans doute hêritê de biais de débutant dans ma démarche initial.
Ce qui en soit actuellement me donne ça :

Une scène contenant le menu principal et le menu de sélection classique type STR : map, teams, factions, vue carte.
Une scène de chargement avec un truc qui clignote   ::ninja::   (sans doute que je pourrais merger ça avec la précédente)
Et ensuite une scène par map.
J’ai une autre « scene » que je charge sur la scene de la map et qui contient toute la partie technique IA, cameras, scripts, UI etc... avec des singletons.
Du coup dans chaque scene map, j’ai le décor, les effets climatiques, et les points de spawn, ressources, batiments capturables etc...

Ca se range bien dans ma tête comme structure  ::P: 

Je doute pas qu’on puisse encore optimiser.
Quand je vois que j’ai gagné 30 fps en execution sous Unity alors que j’étais déjà fluide en build mais pas assez pour gérer toute la balistique quand l’IA s’énerve, je pense avoir encore beaucoup de marge d’apprentissage  ::XD::

----------


## Grosnours

Comme tu le dis, c'est en terme d'optimisation de FPS/temps d’exécution qu'il faut chercher, parce que logiquement ta structure est tout aussi valide qu'une autre.
Est-ce que tu peux gagner du temps d’exécution en regroupant quelques scènes ensemble, et est-ce du temps d’exécution dont tu as besoin ? Parce que sinon autant ne rien toucher. En optimisation, le mieux est souvent l'ennemi du bien.  ::):

----------


## Sifr

Surtout que des fois l’optimisation pousse à faire des trucs chelous.

J’avais un beau système de détection ligne de vue avec des sphereoverlaps, ça fonctionnait nickel, et parce que je pouvais pas lancer 500 chasseurs en même temps de mes portes avions sans toussotements des fps, j’ai tout passé sous un système de raycasts qui tapent dans des colliders servant de zone de vision aux unités.
J’ai retourné tout mon système en fait en terme de logique, et si ça marche, j’avoue que j’en suis encore assez étonné  ::ninja:: 

Du coup vu que j’ai ce que je voulais - je laisse l’optimisation de côté et j’ai eu le malheur de vouloir que les hélicos se penchent en avançant pour faire plus classe... malheur m’en a pris j’ai mis les doigts dans les fonctions d’animator and co...  ::wacko:: 
C’est encore un truc bien fun ça...

----------


## Sifr

Le HDRP c’est relou mais des fois ça fait le café  ::lol:: 
C’est énorme les custom pass pour intégrer des visuels et des effets dans une map que ce soit local ou global.

Je commençais à douter de ce pipeline mais finalement ça permet de faire des trucs en quelques clics et fonctions alors que je pensais que j’allais galérer à gérer des trucs de visuels de base.

Et même plus besoin de gérer plusieurs caméras et rendus pour faire de la superposition !

----------


## Sariyah

Salut les Canards,

Suite rapide de mon aventure en reprise d'étude et notre projet casse gueule sur Unity !

Pour les plus curieux, j'ai mis en ligne le jeu sur le playstore (pas en ligne sur l'appstore par contre) et vous le trouvez en recherche exacte avec "Secret of Annecy". 
Il reste quelques ajustements avant la soutenance dans 3 semaines. Si vous avez des retours...  ::P:

----------


## schouffy

Roh vous êtes à Annecy la chance <3

----------


## Sariyah

> Roh vous êtes à Annecy la chance <3


Ouai enfin pour ma part j'habite à 20 min, à la campagne.  ::P:  Mais oui pour une ville c'est très beau !

----------


## Sifr

Toujours dans l’idée d’affiner certains trucs, j’ai depuis le début une création de mes icônes d’unités via une micro scène où je fais défiler mes modèles 3D pour faire des screenshots que je balance dans une texture par unité et pareil pour les bâtiments. Ça m’évite d’investir dans du dessin d’icones.

Par contre mes modèles étant pas toujours de la même taille je dois y adjoindre pour chacun un scale factor spécifique pour qu’ils rentrent dans le cadre.

Y’a une fonction déterminée existante ou une idée qui permettrait de fitter la caméra aux limites du modèle automatiquement ?

----------


## Grosnours

J'ai fait toutes mes miniatures de bâtiments à la pogne. Tous les prefabs aux même coordonnées, tous désactivés sauf 1 qui donnera le screenshot et avec quelques gameobjects judicieusement choisi pour faire une base fixe et commune. On règle à la pogne le scale de chaque instance de prefab pour qu'elle rentre "dans le cadre" harmonieusement et qu'on ait une collection au final bien régulière et proportionnée. On garde un gameobject vide orienté exactement dans la même direction que la caméra et à la même distance au cas où celle-ci se dérègle pour un raison X ou Y.

Long et chiant mais simple et efficace.

Maintenant si quelqu'un a d'autre méthodes, je suis tout ouïe.

----------


## Grhyll

Il y a les Bounds des meshes qui peuvent être utilisé pour en déterminer la taille, et via quelques calculs de trigo, les mettre au bon scale pour rentrer dans le champs  ::):

----------


## Sifr

Si je fais un remix du coup je vais tenter un truc comme ça :

Vu que toutes mes unités et mes batiments ont un collider, je recupère le bound avec center et mix / max size.
Ensuite je pose sur le fond de ma scène de capture un collider de reference qui correspond a la taille de mon fond d’icone.

Ensuite je spawn le gameobject et je tire quatre raycast aux quatre coins de mon collider d’object unité ou batiment.
J’incremente le scale factor et je raycast dans une boucle. 

Quand l’un des raycast ne trouve plus le collider d’icone, c’est que mon modèle est plus grand que l’image. Donc je m’arrête juste avant avec une marge définie pour avoir toujours le game object bien calé.

----------


## Grosnours

Bien entendu comme d'habitude avec Unity il existe un asset pour cela : https://assetstore.unity.com/package...52#description

----------


## Sifr

> Bien entendu comme d'habitude avec Unity il existe un asset pour cela : https://assetstore.unity.com/package...52#description


Mais 13 euros...  :tired: 

Pour le moment j'ai investi 30 euros pour des assets sons et musiques pour me faire plaisir.
Le reste c'est tout gratuit - Juste Unity et MagicaVoxel.

Non vaut mieux bidouiller deux cents lignes de code et avoir l'effet désiré que de péter la balance et l'objectif initial d'investir quasi rien.  ::happy2::

----------


## Molina

> Mais 13 euros... 
> 
> Pour le moment j'ai investi 30 euros pour des assets sons et musiques pour me faire plaisir.
> Le reste c'est tout gratuit - Juste Unity et MagicaVoxel.
> 
> Non vaut mieux bidouiller deux cents lignes de code et avoir l'effet désiré que de péter la balance et l'objectif initial d'investir quasi rien.


Si tu prends ne serait ce que le smic horaire... et que tu écris tes 200 lignes de codes en plus d'1h30, t'es pas gagnant. Après, perso, je suis devenu assez chill avec l'asset store (maintenant que je ne suis plus étudiant), le plus important c'est que le jeu avance.

----------


## Sifr

Je suis en phase avec ta vision si c’est une activité principale.
Comme hobby ça se discute.

Si je reniais mon principe de tout faire moi-même, étant donné que je suis à peu près hors campagne et multi entre un C&C3 et un Act of War en terme de contenu/fonctions, si je poussais à faire un peu de beautifull à coups d’assets qui claquent et investir un peu pour des modèles plus réalistes basés sur ma DA alors ça s’emballerait et la facture monterait rapidement.

Je rentrerais alors dans une réflexion de me dire qu’autant que de faire tout ça autant se lancer réellement et là ce serait le pas de trop direction prises de tête en tous genres.

Je vais garder ma limitation initiale - ça évite l’emballement  ::): 

Par contre si je tombe un jour sur un asset qui prouve qu’en quelques manips je peux réellement passer d’un solo à de la fonction multi, même pour 100 euros j’y réfléchirai quand męme rien que pour la curiosité d’avoir un feedback de testeurs dans ce type de conditions.
Ca changerait par rapport à ma vision uniquement skirmish.

----------


## Grosnours

> Par contre si je tombe un jour sur un asset qui prouve qu’*en quelques manips* je peux réellement passer d’un solo à de la fonction multi,


 :^_^: 
On va dire que j'ai des doutes.
Là on a fini un city builder multi, on en a bavé des ronds de chapeaux sur la partie multi (totalement faite in-house) pour la faire fonctionner correctement et les bugs qu'on nous remonte et qui sont absolument non-reproductibles chez nous viennent sans doute de là (ou de souci de connexion serveur ce qui revient au même).

----------


## babarti

Vous avez fait votre propre lib réseau ?  ::o:  Super intéressant comme choix (très courageux aussi) !  Par curiosité, pourquoi ne pas être passé par un Photon ou équivalent ?

Perso, même si parfois je pleure un peu à les utiliser en usage pro (notamment en ce moment avec les bugs d'ownership qui trainent dans leur lib) et que je n'ai pas trouvé égal en puissance au framework multi d'Unreal, ça reste quand même globalement bien pratique et "simple" (en dehors de la complexité inhérente au multi, j'entends).

Mais je suis curieux du coup, à quel moment ça devient envisageable d'écrire sa propre couche réseau et si avec le recul vous le referiez ? Vous êtes une grosse équipe de dev ?

----------


## Grosnours

On est 3 (1 spécialiste réseau/web, 1 spé Unity et moi  ::P: ). Je voulais contrôler de A à Z comment tout cela allait fonctionner vu que le multi était une première pour nous et de manière générale un truc assez peu commun (les city builders multi ne courent pas les rues). Donc pour une fois on a évité de passer par la case asset pour faire les choses nous-mêmes.
On a donc crée un backend plus un frontend visible via browser dans Unity en plus des dialogues backend<>Unity. Ce que je ne vais plus faire pour les futures itérations d'ailleurs, désormais ce sera uniquement Unity <> backend (et solo la plupart du temps). Le browser in-game apporte plus d’inconvénients que d'avantages au final.

Attention on avait en tête la fonctionnalité et la simplicité, pas la performance, même si au final le tout tient bien la charge de dizaines et dizaines d'utilisateurs simultanés. On a pas du tout la prétention d'avoir écrit une couche réseau de haut vol, mais cela fonctionne correctement.

----------


## babarti

Hyper intéressant, merci pour le retour d'expérience !
Le browser in game au sens navigateur web ?

En tout cas bravo, belle performance :D Je me demande d'ailleurs si pour un city builder, du networking basé sur du HTTP permet pas de faire le taff tout en se reposant sur des frameworks robustes niveau backend (ça rend plus compliqué la communication backend -> Unity par contre).

Ça a dû être bien intéressant à dev en tout cas, même si j'imagine sans peine des moments perte de cheveux !

----------


## Grosnours

Merci!  :;): 

Tu as un asset qui permet d'avoir un Chromium dans Unity : https://assetstore.unity.com/package...-browser-55459. Si tu en as vraiment besoin (le si est très important), c'est un excellent outil.
Le plus pénible a été de bien s'assurer que tout le monde reste parfaitement synchronisé in-game à la seconde près tout en gardant (et diffusant) sur le serveur les traces de toutes les diffs de chacun. Mais comme tu le disais, c'était une expérience riche et intéressante.

----------


## Molina

> Je suis en phase avec ta vision si c’est une activité principale.
> Comme hobby ça se discute.
> 
> Si je reniais mon principe de tout faire moi-même, étant donné que je suis à peu près hors campagne et multi entre un C&C3 et un Act of War en terme de contenu/fonctions, si je poussais à faire un peu de beautifull à coups d’assets qui claquent et investir un peu pour des modèles plus réalistes basés sur ma DA alors ça s’emballerait et la facture monterait rapidement.
> 
> Je rentrerais alors dans une réflexion de me dire qu’autant que de faire tout ça autant se lancer réellement et là ce serait le pas de trop direction prises de tête en tous genres.
> 
> Je vais garder ma limitation initiale - ça évite l’emballement 
> 
> ...


Non mais je comprends dans l'absolu. Après, je pense que c'est du cas par cas. Là, pour avoir des icônes. 13 € c'est 2 kebabs pour être tranquille et pouvoir faire autre chose à la place... Après si tu penses que tu ne pourrais pas t'arrêter, je peux comprendre. Même si je t'assure qu'au delà d'un certain prix, tu réfléchis quand même à deux fois.

----------


## LDiCesare

> c'était une expérience riche et intéressante.


Marrant, comme remarque. Ca me rappelle quand je devais faire des algos de gestion de lag dans un MMO. On utilisait une superbe lib C++ qui avait eu la bonne idée de redéfinir le symbole "main". Que du bonheur tout ça.

----------


## Grosnours

::lol:: 
Le commentaire n'était pas ironique en fait, mais j'avoue que lire "expérience riche et intéressante" en ce qui concerne du code fait tout de suite penser au pire.  ::P:

----------


## Sifr

Sur mon STR j’ai repris l’idée de l’attrition qui endommage progressivement les unités ennemies quand elles sont proches de la base.
C’est une mécanique sympa pour éviter le rush de petites unités et quand même permettre de forcer le danger si on est vraiment en décalage par rapport à l’opposant. Au fur et à mesure qu’on progresse, son effet s’amoindrit car les unités sont plus puissantes. Bref grand classique.

Par contre pour le moment j’ai juste des balises de lumière qui montrent le périmètre de la zone.
Je voudrais rendre ça plus joli comme une sorte de bandeau lumineux tiré entre chaque marqueur.
Un peu comme un bandeau de police qu’on voit dans les jeux en mode holographique.

Par contre j’ai aucune idée de ce qui peut me permettre de faire ça pour s’adapter aux nombres de points du périmètre.
J’avais dans l’idée d’utiliser un linerenderer bien large mais j’ai pas l’impression qu’on puisse forcer la verticalité pour l’effet bandeau.

Une idée / astuce ?

----------


## Grosnours

Au débotté une paire d'idées :
- tu crée un asset 3D morceau de ligne avec mesh et matériel façon bandeau de police et tu en places autant qu'il faut entre les points, avec le scale qui s'ajuste à la distance
- tu crée dynamiquement à la volée un mesh qui va bien avec le nombre de points et tu lui donne le matériel ci-dessus. Un peu comme sont crées les imposteurs dodécahèdriques.

----------


## Sifr

Merci pour les idées. Je galère dans la mise en oeuvre...

Mais à force de m'énerver, je me suis défoulé sur un autre truc qui me tenait en haleine depuis quelques semaines et j'ai finalement compris comment marchait la déformation par les shader graphs :

C'est pour le moment subtilement pas sexy côté remous mais ça marche - les super armes déforment enfin ma surface d'océan - c'est useless mais c'est tellement bon  :Bave: 

L'eau est verte car le biome est radioactif  ::ninja::

----------


## Grosnours

Classe  :;): .

Là je suis super content car je commence enfin à maîtriser Blender ce qui me permet de réaliser mon rêve de matériel unique. Les perfs vont décoller un peu beaucoup.
Le schéma au milieu de cette page résume bien le principe général. 

Je passe tous mes assets à la moulinette Blender (pour ajuster les UV sur ma texture unique) et à la moulinette MeshBuilder (pour fusionner les meshs) et le résultat fonctionne bien. Par contre je m'embarque encore dans une aventure en décidant d'avoir des bâtiments upgradables (avec au moins 8 upgrades différentes). Je procède en prenant le bâtiment final full upgradé et en mettant chaque upgrade via blender dans un matériel différent (ce qui donne un sous-mesh dans Unity). Ensuite dans Unity j'affecte dynamiquement ou le matériel unique ou un matériel transparent selon que je veuille activer ou non l'upgrade.
Seule contrainte : l'ordre des sous-meshs (et donc des matériels et donc des upgrades) doit être rigoureusement identique pour tous les bâtiments.

Un seul mesh (enfin avec 8 sous mesh), un seul matériel (enfin 2 avec le transparent), 256 possibilités différentes. Comme en plus je fais 6 variantes de couleurs par bâtiment + 3 formes de base possibles (le tout choisi aléatoirement à l'instanciation), je vous laisse calculer au final le nombre de variantes pour une seule classe de bâtiment. Mes villes ne seront pas monotones, c'est certain.  ::P:

----------


## LDiCesare

Et si tu disable le sous-mesh plutot que lui mettre un matériau transparent, ça va pas plus vite?
Remarque, je sais pas si on peut faire ça, c'est une idée en l'air.

----------


## Casimir

Grosnours, au bout de combien de temps tu as maitrisé Blender? Je suis sur Maya, et je galère toujours a créer des personnages corrects(l'animation j'en parle meme pas).

----------


## Grosnours

J'avais essayé une première fois il y a quelques mois et je pataugeais vaguement. Résultats très limités et décourageants.
Puis la semaine dernière j'ai repris en ayant cette fois une idée très précise de ce que je voulais et au fur et à mesure j'ai trouvé des tutos sur tout ce dont j'avais besoin ce qui m'a ouvert d'autres portes et d'autres besoins pour les quels j'ai trouvé d'autres tutos. J'ai toujours l'impression que Blender est une horrible usine à gaz avec une UX diabolique, mais si tu ne pars pas de zéro, si tu sais exactement ce que tu cherches à faire et que ton google-fu est au point, tu peux arriver à faire exactement ce que tu veux avec ce soft.

Ceci dit je ne maitrise Blender que pour un usage très très limité, à savoir modifier à volonté et la géométrie de mes assets (rajouter/enlever des étages d'un immeuble par exemple) et leur UV map.
Je n'ai jamais essayé de partir de zéro, j'ai une confiance très limitée en mon talent artistique de toute façon.  ::P: 

Par contre je n'ai jamais essayé de faire de l'animation non plus, je n'en ai pas encore eu besoin pour l'instant.

Ma vidéo point de départ était celle-ci : https://www.youtube.com/watch?v=PcmQhqZC_Oo
J'ai appliqué ce qu'il disait et de fil en aiguille j'ai trouvé d'autres vidéos qui m'ont permis de faire de plus en plus.




> Et si tu disable le sous-mesh plutot que lui mettre un matériau transparent, ça va pas plus vite?
> Remarque, je sais pas si on peut faire ça, c'est une idée en l'air.


Via code je suppose ? Merci, je vais essayer cela, c'est vrai que cela coute moins cher qu'avoir un matériel transparent.  :;): 
Alternativement j'ai aussi vu que tu pouvais mettre un shader qui va écraser la géométrie et ne faire aucun rendu. Mais cela fera toujours un draw call.
J'ai plein de trucs à tester on dirait....

----------


## Sifr

Je suis curieux du principe et de votre histoire de draw call… en quoi est ce à prendre en compte - perfo ?

Pour ma part quand je fais un modèle modulaire avec des upgrades, je fais juste une liste de renderers que je désactive/active au besoin.

----------


## Grosnours

En gros moins tu as de draw call et mieux c'est, le lien de gamedev guru que j'avais mis plus haut résume la situation. L'onglet stat de la fenêtre Game et plus précisément le Frame Debugger permettent de savoir où tu en es niveau draw calls/batching. 
Quand tu parles de modèle modulaire, c'est plusieurs meshs que tu actives/désactives ou un seul mesh avec des submeshs ?

----------


## Grosnours

Attention, gros test incoming.

Tout d'abord commençons par créer un modèle qui est un gameobject qui contient tout une série de gameobjects avec chacun un mesh et un matériel, tous différents. On affiche et cache en activant et désactivant les gamobjects correspondants.

La solution la moins optimisée donc.

Prenons ensuite la même chose mais en fusionnant tous les meshs, On obtient un seul mesh avec plusieurs submesh chacun ayant son propre matériel.

Cela va un tout petit peu mieux.

Je passe l’étape suivante qui est d'attribuer le même matériel à tous les submesh, cela passe par un éditeur d'image pour créer une texture unique qui va agréger toutes les textures, par blender pour retravailler tous les mesh d'origine et leur attribuer la texture unique puis enfin par Unity pour re-fusionner les meshs.

Au passage on en profite pour ajouter de la variété au modèles en les déclinant en plusieurs couleurs, mais c'est un détail avec 0 impact sur les perfs.
Affichons donc 15 de ces maisons optimisées avec le renderer classique, toutes options allumées :

C'est le meilleur des cas pour ces maisons là puisque tous les matériels sont identiques, l'optimisation bat son plein.

Maintenant écrivons un custom render pour n'afficher que les submeshs que l'on désire:


```
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class MyCustomRenderer : MonoBehaviour
{
    public Material MyUniqueMaterial;

    public bool bool_Building_Material_1 = true;
    public bool bool_Windows_Material_2 = true;
    public bool bool_Grass_Material_3 = true;
    public bool bool_Garage_Material_4 = true;
    public bool bool_Water_Barrel_Material_5 = true;
    public bool bool_Water_Tank_Material_6 = true;
    public bool bool_Vegetation_Material_7 = true;
    public bool bool_Solar_Panel_Material_8 = true;

    public Camera MyCamera;

    private Mesh MyMesh;
    private Vector3 MyPosition;
    private Quaternion MyRotation;
    private MaterialPropertyBlock MyMaterialPropertyBlock;

    // Start is called before the first frame update
    void Start()
    {
        MyMesh = GetComponent<MeshFilter>().mesh;
        MyPosition = transform.position;
        MyRotation = transform.rotation;
        MyMaterialPropertyBlock = new MaterialPropertyBlock();
    }

    // Update is called once per frame
    void Update()
    {
        if (bool_Building_Material_1)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 0, MyMaterialPropertyBlock, true, true, true);
        }
        if (bool_Windows_Material_2)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 1, MyMaterialPropertyBlock, true, true, true);
        }
        if (bool_Grass_Material_3)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 2, MyMaterialPropertyBlock, true, true, true);
        }
        if (bool_Garage_Material_4)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 3, MyMaterialPropertyBlock, true, true, true);
        }
        if (bool_Water_Barrel_Material_5)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 4, MyMaterialPropertyBlock, true, true, true);
        }
        if (bool_Water_Tank_Material_6)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 5, MyMaterialPropertyBlock, true, true, true);
        }
        if (bool_Vegetation_Material_7)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 6, MyMaterialPropertyBlock, true, true, true);
        }
        if (bool_Solar_Panel_Material_8)
        {
            Graphics.DrawMesh(MyMesh, MyPosition, MyRotation, MyUniqueMaterial, 0, MyCamera, 7, MyMaterialPropertyBlock, true, true, true);
        }
    }
}
```

C'est grossier mais cela fait le taf.

Affichons le même nombre de maison dans la même situation avec ce renderer :

Bien entendu il s'agit du pire cas possible pour ce renderer puisqu'aucun sub mesh n'est desactivé.
On notera quand même que DrawMesh fait moins bien que le renderer de base.


On change les choses en n'affichant désormais que 3 des submesh possibles. Les maisons avant toute amélioration, ce qui sera un cas d'usage très courant, bien plus courant que de les afficher toutes.
Pour les maisons avec renderer classique, cela veut dire assigner le matériel transparent aux bons submeshs :



Avec le renderer maison, cela signifie décocher quelques cases:




Les résultats sont là à mon sens et sans trop de surprise : le renderer custom donne de meilleurs résultats quand il s'agit de ne pas afficher certaines upgrades que le render classique et on a la situation inverse lorsqu'il s'agit de tout afficher.
Certains trucs m'intriguent par contre, comme le fait d'avoir de meilleurs perfs (FPS) mais plus de drawcall pour le custom render dans le dernier cas.
Il faut que j'essaie 1) avec bien plus de maisons, 2) avec le shader maison qui écrase la géométrie et qu'on affectera au matériel transparent.


Note au passage, comme j'utilise GPUInstancer (qui fonctionne merveilleusement bien), cela me fait un peu chier d'utiliser un renderer custon, puisque GPUInstancer active et désactive dynamiquement les mesh renderer des objets dont il s'occupe et cela voudrait dire qu'il faudrait que je trifouille le code de GPUInstancer pour le rendre compatible avec mon renderer custom. Mais c'est un détail.


EDIT : en utilisant le shader custom qui écrase la géométrie les perfs du render classiques sont bien bien meilleures dans le pire de cas pour lui. Pas aussi bonne que le renderer custom, mais on s'en rapproche.

----------


## Sifr

Ma foi pour ma part je suis avec des gameobjects par module d’upgrade et je désactive juste le renderer quand j’en ai pas besoin.
Peut-être une mauvaise pratique…

Ceci dit de mon côté, c’est pas le visuel qui me pompe les FPS mais les scripts… que j’ai 10 ou 500 unités ça change pas grand chose si les scripts sont inactifs.

----------


## Grosnours

En optimisation il est très difficile de donner des règles absolues et générales qui ne sont pas triviales. Tout dépend exactement du projet de son implémentation, les goulots d’étranglement sont souvent radicalement différents entre deux jeux.
De plus optimiser est rarement une sinécure, et passer des mois pour un truc qui te fera gagner 5% de perfs pas forcement l’idée du siècle.

----------


## Sifr

Y’en a qui ont déjà travaillé une surface d’eau et qui arrivent à maitriser la zone de « reflet » de lumière ?

J’ai une lumière directionnelle pour l’illumination globale et j’ai l’impression de pas pouvoir maitriser la taille de l’halo qui est couplé à la smoothness.

Ca le parait bizarre qu’on puisse pas mieux contrôler cela.

----------


## Grosnours

C'est pas dans ton shader (ici de l'eau) que tu es cens contrôler la réfraction et la réflexion ?

----------


## schouffy

Faudrait un screenshot avec des explications pour être sûr de bien comprendre le problème, mais en général oui tout ça se paramètre par le shader, et si c'est pas un shader custom, par la smoothness ou metalness.

----------


## Sifr

Dans l'éditeur (j'ai retiré le terrain) :

Vue standard



Vue avec rotation 180 de la vue éditeur (on voit clairement l'halo mais comment régler son diamètre?) :



Le shader graph hérité de multiples tutoriels et raccourcis persos :

En gros deux textures normales dont une fixe et l'autre mouvante / la smoothness pilotée par un float et la normal power par un autre float.
Le reste ne touche à rien : l'émission n'a pas de paramètre.



Ce qui est restitué ingame via la vue caméra - je trouve l'effet bien plus minimisé que ce que l'on voit en mode éditeur :



Ce qui est vu en mode éditeur durant l'exécution avec l'angle de 70° directionnel en X :

Même non attaché à la caméra, la lumière semble suivre la vue.
Je comprends le principe des rayons // sur la base d'une lumière source type soleil, mais pourquoi l'halo suit la camera si la source lumineuse est à l'infini?
On devrait pouvoir maitriser la position de l'halo sur la surface.



Ce qui se passe avec un angle faible de 10° :



Je ne vois aucun paramètre qui me permette dans la light de maitriser la taille de l'halo ni piloter finement la smoothness (en dehors de mon float dans le shader) et c'est sans doute une lacune de compréhension/connaissance de mon côté.

----------


## Grosnours

Je dirais que ce n'est pas la lumière qu'il faut changer (ou pas seulement) mais ton shader et comment il la traite. Là j'avoue que ce n'est pas mon point fort surtout en HDRP.  ::unsure:: 
Des discussions/ressources connexes qui t'aideront peut-être : 
https://forum.unity.com/threads/is-t...ghting.555631/
https://unitywatershader.wordpress.com/

Ceci dit la réponse à ton problème m'intéresse, je pourrais peut-être en avoir besoin d'ici quelques mois.  ::):

----------


## schouffy

Je suis pas du tout expert mais je vais dire des trucs qui me semblent avoir du sens.
La directional light n'a pas de diamètre, je ne vois pas pourquoi le halo aurait un diamètre, sans parler de régler sa taille. Il sera appliqué uniformément sur toute la surface de l'eau.
Ce qui fait, je pense, que le halo semble suivre la caméra, c'est que la lumière rebondit sur les irrégularités de ta normal map (présentes dans toutes les directions) et est renvoyée vers la caméra.
Donc à mon avis, pour régler la taille de ton halo, il faut agir sur ta normal map pour que certaines parties (en fonction de l'orientation de la caméra, bonne chance) présentent plus de relief que d'autres. Regarde du côté des Fresnel, je suis pas bien capable d'en dire plus.

----------


## Sifr

Ca a l'air bien chaud à faire tout ça  ::(: 

J'ai du coup l'idée suivante mais je ne sais pas si c'est faisable : on sait affecter un gradient ou une couleur à partir d'un certain offset d'une normal map ?

Je m'explique - on contrôle le pseudo relief avec la normal map et on peut la moduler avec un float.
Si je pouvais mettre un gradient entre 0 et 1 pour gérer un fake d'illumination en fonction du pseudo Y, ça pourrait gérer une luminosité en désactivant la smoothness.

----------


## schouffy

Je te conseillerais déjà de paramétrer l'intensité de ta normal map (dans sa globalité) pour vérifier que ça a bien l'effet attendu sur le rendu (=diminuer la réverbération en gros). Si ça se trouve c'est pas ça du tout et t'auras pas perdu trop de temps au moins.
Si ça marche, tu peux, je pense, ajouter une texture type dégradé radial (en niveaux de gris) que tu multiplies à ta texture de normal map avant de l'appliquer, et en mettant un paramètre float qui clamp la texture de dégradé radial pour que tu puisses tweaker l'intensité de l'effet au runtime.
Y'a sûrement plein de raccourcis erronés dans ce que je dis mais c'est juste pour l'idée  ::happy2::

----------


## Sifr

Y'a un peu de communauté avec mon problème mais moi j'ai bien le paramètre normal :

https://gamedev.stackexchange.com/qu...g-a-normal-map

Si je vire la smoothness et le normal strength j'ai bien un halo type soleil.
C'est donc bien la normal strength qui étend et dilue l'halo.

OK pour l'idée - je vais tester l'application à la texture.

J'ai ajouté une EVA à mon jeu en exploitant un text to speech gratos (on fait avec les moyens du bord) : ça remonte le moral quand tout parle et qu'on entend "super weapon launch detected" avant de se prendre la purée  ::ninja::

----------


## Casimir

Question très facile mais dont j'ai du mal a trouver la réponse sur google, comment on donne une aire d'effet a une arme? J'ai modélisé une épé au lieu de mon arc, et j'aimerai que l'épée touche a 50 cm d'elle. J'avais pensé a réduire la raycast mais il y'a pas une autre solution?

----------


## Grosnours

Ben ça dépend comment tu calcules tes collisions sur ton épée. Si c'est via un mesh collider, il suffit de lui en donner un qui correspondent à la zone d'action que tu souhaites. Tu peux utiliser Probuilder ou Blender pour définir ton nouveau mesh en partant du mesh de l'épée et le passer en collider.

----------


## schouffy

Pour des objets a mouvement rapide comme une épée ou un projectile, je te recommande de faire des raycast ou des spherecast, sinon tu risques de ne pas enregistrer de collision si elle a lieu entre 2 frames.
Pour résoudre ton problème, tu aurais juste à augmenter le rayon de ton spherecast.

----------


## Casimir

Merci pour les tips, je vais essayer par spherecast donc.

----------


## Sifr

Bon après une vue assez explicite de la surface de la Méditerranée irl, il est pas si mal mon shader….
Surtout quand je me suis rendu compte que effectivement en me tournant dans la flotte y’avait quand même un reflet du soleil sur certains côtés que je trouvais zarbi sur Unity.

J’ai rentabilisé les vacances  ::ninja::

----------


## Grosnours

Un phénomène familier, aussi connu sous le nom de "le mieux est l'ennemi du bien"...  ::P:

----------


## Sifr

> Un phénomène familier, aussi connu sous le nom de "le mieux est l'ennemi du bien"...


Quel bel adage effectivement…
Dorénavant certaines unités disposent d’une tech pour convertir leurs missiles sol - sol en sol - air et sol - sol.
Ca m’a creusé un peu le cerveau pour pas tout péter dans le code et gérer les distances de tir en fonction du homing sur les avions et leur distance d’approche par rapport à un bête face à face d’unités mais c’est mieux.

Et la faction initiale dans sa version Dark Age est effectivement dorénavant l’ennemi du bien  ::ninja:: 

Progrès quand tu nous tiens…

----------


## Sifr

Mon petit truc a survécu au passage à la dernière version de Unity et avec un gain de perfo à la clef  ::lol:: 

C'est l'occasion de lâcher un petit screenshot après la conversion d'une partie de mes modèles vers le nouveau rendu plus métallique :

Vue de débogage - les ressources sont aberrantes pour tester la prod des unités et la base est auto gen au début du coup y'a l'usine avancée qui mange un peu de terrain (le rayon de vérif est moins pointilleux qu'en mode classique de construction) :

Si vous avez des commentaires pour que j'améliore le rendu ou d'autres trucs je suis preneur !  ::P: 
Y'a aucun post processing

----------


## schouffy

Alors, déjà je trouve ça franchement très bien bravo !

Je vais te dire plusieurs choses qui me sautent aux yeux mais tu n'es pas obligé d'être d'accord, tout ça est assez subjectif. Je le fais parce que j'imagine que tu as le jeu sous les yeux depuis si longtemps que tu ne peux plus trop prendre de recul.

- Je trouve que ça manque de liant entre l'eau et les bâtiments. Tu peux rajouter une petite mousse blanche autour des points de contact des mesh dans l'eau par exemple.
- Tes bâtiments brillent trop amha. Je baisserais ça.
- Ils sont aussi abusé propres ! Rajoute un peu de caca dans tes textures, de la rouille, des rayures,..
- Met du post process même léger, je sais pas ce qu'il y a en HDRP mais je dirais que du tonemapping et une petite vignette aideraient déjà beaucoup.
- Ta lumière globale est un peu neutre. Tu pourrais peut-être la teinter (mais je sais pas en quoi, je suis pas artiste  :^_^: )
- Tu pourrais envoyer un gif ou une courte vidéo en mouvement pour qu'on se fasse une idée ? A mon avis, il te faudrait aussi des particules dans l'air, des mouettes de temps en temps, un truc qui donne un peu de vie.

----------


## Grosnours

Les critiques c'est mon truc.  :Cigare:   ::ninja:: 
Effectivement en l'état c'est fort bon.
Mais :
- l’héliport de la plate-forme en bas à gauche est déformé. Si c'est bien un héliport. Sinon il faut changer la forme du bâtiment.
- la forme des bâtiments trahi insuffisamment leur fonction. A vue d’œil je suis incapable de dire qui fait quoi et ce qui les différencie à quelques évidences (héliport, piste de décollage, rade) près.
- Je ne suis pas sur que les bâtiments aient tous exactement la même échelle (une de mes marottes et obsession, ça). Genre les constructions de celui tout en bas ont l'air bien plus petites que celui du milieu.
- Il faudrait peut-être insister plus avec les codes couleurs, là c'est un peu trop subtil. Ta plate forme d'extraction (je pense) en bas à gauche est bleue, mais à peine. Pareil pour le bâtiment tout en haut à gauche.

----------


## Sifr

Merci pour vos commentaires  ::): 

Sur le screen on voit :
- l’aéroport avec un lancement d’avions comme Act of War
- le QG au centre
- le centre de recherche en bas à droite
- l’usine légère en bas à gauche
- l’hélipad en bas
- l’usine lourde au design pas fini en haut à gauche
- une tourelle à gauche
- une plateforme de ravitaillement en haut

Je suis pas très à l’aise avec les textures, ça prend beaucoup de temps, du coup je suis parti surtout sur une couleur = une zone du modèle.
Je vais tenter de glisser un peu de texture avec un noise en grayscale pour voir ce que cela donne.

La lumière globale est clairement neutre, effectivement y’a sans doute à trouver pour faire des trucs plus cools.
J’avais tenté un crépuscule c’était sympa mais du coup ça poussait le besoin d’avoir des projo sur les batiments et les unités.

Là d’ailleurs j’ai pris le screen quand les nuages et le brouillard sont pas là car normalement y’a des nuages qui circulent pour donner un peu de dynamisme à l’ensemble en plus de l’eau.

C’est vrai qu’en mouvement ça donne différemment forcément, je vais essayer une courte vidéo.
Et une structure de base complète car on voit pas tout sur ce mode debug.

C’est sans doute aussi que du coup ça nuit à la logique des bâtiments vu qu’avec la liste qui s’affiche en sélectionnant les constructeurs on a direct le lien visu - fonction.

Pour les proportions c’est un grand débat intérieur : faut un truc qui donne la visu et la fonction quitte à être énorme à l’écran ou un truc plus réduit et joli, qu’on reconnait au coup d’oeil mais qui du coup casse un peu l’échelle… la main du Nod pour l’infanterie et la tour aérienne du nod pour les bombardiers est un bon exemple, pas à l’échelle mais visuellement explicite.

D’un autre côté les unités doivent au moins sortir d’un truc qui le permet et y’a que l’helipad qui spawne direct dans l’air alors que les autres sortent des usines.

Le code couleur des factions c’est :
- age sombre : noir gris rouge bleu
- age d’or : gris orange jaune blanc
- les ressources : extracteur de petrole : orange gris / banque : blanc vert / reseau informatique : beige rouge / points de capture : bleu blanc orange

Après reste la minimap qui donne une couleur unique par point d’intérêt.

----------


## Grosnours

> J’avais tenté un crépuscule c’était sympa mais du coup ça poussait le besoin d’avoir des projo sur les batiments et les unités.


Conseil du jour :
1) Bâtiment par bâtiment, les illuminer dans un scène à part et bake la lightmap résultante dans le préfab. Pan, tu as une version totalement éclairée du bâtiment pour pas un rond
2) Tu as été malin et *tous* tes modèles partagent le même matériel, et donc le même texture. Si c'est le cas, prendre le fichier image de la texture, le noircir entièrement sauf aux endroits qu'on veut illuminer qu'on laissera intact. Prendre l'image résultante comme source d'émission dans le matériel

Bravo, tu as une illumination nocturne complète pour pas un FPS (ou presque).

----------


## Sifr

Une courte vidéo illustrative dispo via Streamable : https://streamable.com/0mrnu7

Y'a un peu de tout ce qui traine sur une map sur le 1 tiers de techno, joué par les IA, mais sans l'exhaustivité de tous les bâtiments/unités  ::P: 

Mode debug donc sans fog of war et production accélérée.

Et pour la petite histoire le « tac tac » qu’on entend à un moment c’est les unités d’assaut en zodiak de capture de bâtiment de ressources (pas visibles ici) mais le son est pas équilibré par rapport au reste… normalement il était censé servir juste pour les combats dans le bâtiment mais ça fait une unité de défense finalement pour pas cher au début donc je l’ai laissé avec la possibilité d’attaquer les autres unités même si un coup de canon et c’est fini  ::ninja::

----------


## schouffy

Coincoin,
J'ai acheté un asset avec des rig et modèles déjà animés que j'utilise pour prototyper, mais j'aimerais ajouter des animations. Ce serait quoi la meilleure méthode pour faire ça ? Les imports fbx dans blender, ça se passe pas toujours bien chez moi.
Si vous avez de la doc relative à ça je suis très preneur !

----------


## Grosnours

Perso je fais tout via Blender, mais je me frotte assez peu aux animations de rigs et models, désolé de ne pouvoir t'aider.


Sinon j'avais dit par ici que tout mettre dans une seule texture et donc un seul matériel était optimal (tout à fait exact) et qu'en plus tout mettre dans un seul mesh avec submesh était mieux. Là par contre, pas sur du tout.
Comme d'habitude cela dépend et il y a un tradeoff.
Un seul mesh avec plusieurs submesh => c'est mieux pour le CPU car il y a moins de gameobjects et donc moins d'overhead.
Plusieurs mesh => c'est moins bon pour le CPU mais le culling sera meilleur ce qui peut amener à une réduction des sacro-saints drawcalls. Certains trucs sont aussi plus faciles à faire avec un seul matériel par mesh.

Bref, je vais changer mon fusil d'épaule et séparer mes submeshs. Heureusement que dans Blender c'est aussi facile que importer->menu mesh->séparer par matériel->exporter. Une minute par mesh max, tant mieux j'en ai une centaine...  ::P:

----------


## Sifr

Je cherche une méthode pour faire un truc simple mais aussi le faire simplement et c’est moins cool tout de suite.

En gros je voudrais que mes collecteurs suivent des routes mais ce que je vois sur le net c’est soit de faire un mesh special pour les routes soit de faire avec d’autres outils que le système de navigation de base.

Y’en a qui ont des techniques en tête ? Ca serait cool si on pouvait faire une route et son navmesh direct par texture différente.

J’ai modifié mon truc en repartant de la base avec tous les scripts, cette fois sur URP, exit les bateaux et l’eau, direction une carte tactique grand format, des unités microscopiques et de la construction de base. Du coup ça me donne l’envie de voir les collecteurs suivre sagement les routes vers les points de collecte. Ca rendait pas mal dans RUSE du coup je me dis que cela se tente  ::):

----------


## Grosnours

Elle est fixe ou autogénérée ta carte ?
Si elle est fixe tu as les solutions que tu décris, si elle est aléatoire/seedée il faut rajouter une couche à ton algo de génération pour tracer des routes correctes.
Bien entendu tu as toute liberté pour utiliser des navmeshs ou autre chose comme une solution custom.

----------


## Sifr

Pour le moment c’est une carte fixe, mon idée est d’avoir rapidement des maps avec des cartes topos prises en terrain réel et donc d’appliquer la heightmap sur un terrain. Ensuite je choisis une DA minimaliste en mode détecteur pour me simplifier les visuels.

Et du coup je cherche la facon la plus simple de poser des routes.
Je pense partir sur ton idée de surcouche en utilisant le principe des splines et des scripts qui permettent d’en tirer un mesh ce qui devrait me permettre de poser le navmesh avec un poids de navigation favorable.

----------


## Sifr

J’ai toujours détesté les micro unités dans les STR et finalement … je trouve ça excellent en terme de rapidité de développement et de définition de modèles.  ::XD:: 

5 min clef en main pour faire un modèle et le rendre opérationnel dans Unity.

Bon ça progresse, grâce à mon dév précédent en HDRP j’ai une perfo excellente en URP.
Encore quelques jours et j’aurais ma réponse pour savoir si des mécaniques de Ruse avec les bases d’Act of War fonctionnent sur un terrain de type Wargame/Warno.

Et puis je pourrais tester une visu sur les optiques  ::trollface::

----------


## schouffy

> Moi je galère un peu sur la partie son à multi gérer toutes les sources pour que ça forme pas un pic de sonorité ou des parasites.


J'ai trop d'idées  ::XD::  je t'écris ça plus tard dans la journée je suis sur un truc là.

----------


## Sifr

Pour répondre à la question de la conception actuelle :

J'ai un audiolistener qui est positionné sur le terrain avec un raycast depuis la caméra pour suivre sa position. Ca me permet de positionner l'écoute en fonction de la position sur la map.
A la caméra j'ai attaché une audiosource pour émettre la musique qui est donc captée par l'audio listener.
Pour la musique j'ai un sous mixer du mixer général pour adapter le volume de la musique
Pour les batiments j'ai aussi une audiosource en boucle pour les bruits d'ambiance locaux genre industrie ou même je pense rajouter pour les forêts par exemple quand les troupes se planquent dedans.

Chaque objet porte une audiosource qui est rattaché au sous mixer SFX du mixer général (ça permet de manager un peu la multitude de sons mais y'a encore des parasites et des cumules dans les batailles).
J'ai en détail :
- une audio source sur chaque unité = bruit de moteur quand en mouvement
- une audio source sur l'objet arme = bruit du tir
- une audio source sur l'objet projectile (puisque tout tir est modélisé par une trajectoire) pour le bruit type missile en mouvement par exemple
- une audio source sur l'objet particle d'impact = bruit d'impact
- une audio source sur l'objet effet explosion/mort etc...
Bref chaque action porte une audio source - c'est sans doute bourrin par rapport à ce qu'on pourrait faire avec un peu d'expérience.

J'ai tenté de créer par exemple un micro décalage de lancement de son quand on sélectionne plusieurs chars ou hélicos pour éviter le cumule de son mais ça marche que moyennement.
J'avais l'idée de faire qu'une lecture de son en fonction du type d'unités sélectionnées mais ça me semblait compliqué de faire un manager à côté.

J'ai lu aussi que le PlayClipAtPoint n'était pas forcément pertinent pour une multitude de sources en terme de perfos - c'est pour ça que je suis en mode une action = un objet = une audiosource

EDIT : ce que j'ai oublié aussi de rajouter c'est que chaque projectile ayant une modélisation ça veut dire qu'un soldat équipé d'une arme auto peut vider son chargeur et que chaque balle émet du coup un son donc s'il tire en burst bah j'empile rapidement une dizaine d'audiosources à quelques milli secondes d'intervalles.
Je pourrais créer un son unique type gatling en boucle pour le burst mais ça change la logique où un son = un proj = il me faudrait un truc pour jouer le son et à côté compter le nombre de balles avant de rejouer.
C'est le pire des cas.

Après un MLRS c'est moins problématique parce que les rockets sont lancées à 0.2 sec d'intervalle donc y'a pas cet effet de cumule.

----------


## schouffy

J'ai lu ce que tu as fait, et c'est ce que j'appellerais l'approche naïve et sans doute celle vers laquelle je serais allé initialement.

Tout ce que je vais dire est à prendre avec avec des pincettes parce que je ne suis aucunement un expert dans la partie audio d'Unity et encore moins un sound designer.

Je pense que dans ton cas il y a deux objectifs: Diminuer le nombre d'audiosources, et diminuer le nombre de sons joués en simultané.

Le fait d'avoir un audiolistener situé au niveau du terrain et qui se déplace avec ta caméra, je pense que c'est très bien.

Ensuite, je conseillerais d'avoir une seul audiosource par unité. Dans un STR, tu n'as pas besoin de ce niveau de précision sonore, et tu n'es pas obligé pour une même unité de jouer un son de déplacement et de tir simultanément par exemple. Tu n'as pas besoin que le son de ton missile suive ton missile, le joueur s'en tape amha. Un projectile aura un bruit à sa source (unité qui tire), et un bruit à sa destination (unité qui reçoit les dégâts). Tes audiosources pourraient avoir un falloff très rapide pour éviter que les sons en dehors du centre de l'action ne viennent perturber l'action.


Mais en fait, dans ton cas, je pense que je ferais quelque chose d'encore plus drastique qui me permettrait de gérer aussi bien la quantité d'AudioSource (qui ne dépendrait plus du nombre d'unités) ainsi que centraliser la gestion des sons que tu souhaites jouer en fonction de tout ce qui est déjà en train d'être joué. J'explique.
Tu pourrais avoir, autour de ton audiolistener, quelques audiosources disséminés sur ton terrain (principalement pour gérer la spacialisation), qui se déplacent également avec ta caméra. Quand n'importe quel élément de ton monde (unité, projectile, batiment,...) veut jouer un son, il va juste appeler SFXManager.Instance.PlaySound(AudioClip clip, Vector3 position). Cette méthode va déterminer l'audiosource le plus proche sur lequel jouer le son, ainsi que la nécessité de jouer ce son (Hors screen? Nope. Même son de tir déjà joué il y a 10 ms? Nope. Trop de sons joués actuellement? Nope. etc...)


Pour gérer les autres sont que ceux émis par ce qui est sous tes yeux, tu peux aussi avoir un AudioSource 2d avec une haute priorité qui jouera les sons "destinés au commandant" (unité terminée, batiment important attaqué) ou gérer ça via des AudioMixer en les splittant par exemple: SFX ingame bataille/SFX ingame notifications/SFX UI/Musique.

----------


## Sifr

Je suis pas tout à fait d’accord avec l’approche de la réduction de sources sonores.

C’est ce qui donne l’ambiance et le feedback de l’action, y compris off screen car ça permet de savoir si y’a un truc qui barde pas loin.

Ca m’a toujours gonflé de voir les obus ou rockets des artilleries tirer mais n’avoir que le bruit d’impact sur certains STR parce que l’unité est off screen.

Mais j’ai réduit la voilure quand même, j’ai fait un pool audio avec un objet source et je le pose à la bonne position et ainsi de suite avec une limite de sources.
Ca m’a réglé un vieux truc qui me faisait couper un son avant qu’il soit fini quand je désactivais un projectile.
Du coup je peux enfin profiter des sons à réverbérations comme les snipers  :Bave: 
Et pour les moteurs je teste si le son est déjà lancé et j’en lance qu’un ou deux tout au plus.

----------


## Sifr

Ca y est : j ai bouclé un système audio potable.
Approved by un test de 100 unités avec des smg et des MLRS en face  :Bave: 
Plus aucune saturation.

Je suis parti sur un pool d’audioobjects, un dictionnaire pour compter les occurrences actives et mettre une limite par type puis globale et j’ai tuné la distance de son.

Ca rend bien et effectivement passé un seuil de 5 sons identiques ça se perçoit plus visuellement donc ca va côté charge.

Et puis j’ai affiné pour trois fois rien avec les cams overlay mon fog of war  ::):

----------


## Molina

Vous pensez que c'est compliqué de porter son jeu pour la steamdeck ?
J'ai pas réfléchi outre mesure si unity marche sur Linux

----------


## Grosnours

J'ai jamais essayé mais tu as en natif l'option de compiler pour Linux (ou Mac ou Windows). Donc non, cela ne devrait pas être compliqué et relativement transparent si tu as installé l’éditeur avec les bonnes options par contre cela ne sera peut être pas non plus totalement sans effort.
Faut essayer et tester.
C'est pour cela que je ne fais jamais de build Mac pour mes jeux, comme je n'en ai pas je ne peux pas tester. D’expérience sur un vieux projet (au temps où un de mes collaborateurs en avait un), si avec le même projet changer de plateforme a la compilation est facile, obtenir le même résultat par tout est bien plus complexe.

----------


## Sifr

Bon, après une énième rage sur les fps qui s’effondraient au delà d’un certain stade de combat, genre 50 unités contre 50  sur des escarmouches locales x par le nombre de points d’affrontements ce qui était quand même pas bien gros à mon sens et surtout pas fun si je devais mettre une limite à la population, j’ai finalement viré tous mes colliders pour tout gerer à la distance via sqrmagnitude.

J’ai gardé les colliders que pour les hitbox et les objects d’impact d’arme.

Et c’est le miracle : même chargé à 4000 unités sur le terrain je descends pas en dessous de 30fps dans Unity et cela même en end game avec de la mitraille de partout.

Y’a que les brochettes de forces spéciales qui tirent comme des tarés qui m’impactent un peu mon framerate de confort.
Mais ça je peux le traiter en réduisant la frequence de balles reelles et modifier l’effet pour simuler plusieurs tirs factices.

Par contre ça a cassé mon module d’infiltration en forêt, on peut pas gagner à tous les coups, va falloir encore un peu bosser  ::): 

D’ailleurs j’avais introduit un système vision + radar soit deux range de possibilite de détection.
En bidouillant j’ai étendu cela à une liste en fonction du type d’unité via un dictionnaire.
Et je suis tombé à peu près sur un système qui simule les optiques type Wargame/Warno.
C’est rigolo. J’ai pas poussé l’implémentation vu que je cherche à retrouver l’accessibilité du STR bien propre mais ça m’en laisse sous le coude si ça le reste marche bien.

----------


## schouffy

Tu as profilé pour être sur que le problème vient bien de la physique? ça me surprend parce que 50 contre 50 c'est pas non plus énormissime.

----------


## Sifr

Oui c’était bien les colliders dans le profiler,
Pour preuve vérifiée, c’est que tant que les unités n’étaient pas dans leur zone respective de vue/action, j’avais aucune perte de fps et dès que le contact était établi, ça ramait un max.
J’avais déjà levé une partie de l’anomalie en changeant les colliders et leurs layers pour faire un test.
Après y’a sans doute des subtilités d’experts que je choppe pas, mais dans ma logique, j’ai atteint le seuil pour plus m’embêter à penser perfos avec tout ce que j’ai rajouté.

Je me concentre sur la visu et l’équilibrage, un peu de création de sympa de map et ça tournera assez pour que je m’amuse sans être obligé de renier un critère qualité qui serait pas passé sur un jeu officiel  ::):

----------


## Sifr

J'ai une question bien basique et je me demande encore comment c'est possible que j'ai pas rencontré ce problème avant  ::XD:: 

En fait, au début je mettais des petits bâtiments pour simuler des villes/villages mais c'est pas très chouette parce que j'avais pas de dalles et trottoirs + route.
La route c'était en fait la texture de terrain direct en dessous.

Donc j'ai rajouté un plan à la base de mes bâtiments avec un bord noir et des pointillés pour la route de sorte que ça fasse des tuiles et donc des routes à la connexion.
Avec un algo je génère des randoms de mes modèles de base et ça me fait vite fait bien fait des villes/villages pas si déconnants.

Mais le truc idiot, c'est que ma route (= mon socle de batiment) à Y=0 se mélange avec mon terrain lui aussi à Y=0 dans les zones planes.

J'ai pas ce problème avec mes bâtiments de base car ils cachent le terrain donc ça pose pas de problème vu qu'ils sont plus hauts et n'ont pas de socle.

J'ai cherché sur le net et je trouve pas trop de choses explicites.
Souvent la map des villes est générée sans terrain ou le paysage fait partie du mesh global donc pas de superposition. Voir le socle a lui même une épaisseur du coup pas de risque de "mélange" qui clignote.

C'est quoi la bonne manière d'aborder ça ?  ::huh::

----------


## schouffy

> J'ai une question bien basique et je me demande encore comment c'est possible que j'ai pas rencontré ce problème avant 
> 
> En fait, au début je mettais des petits bâtiments pour simuler des villes mais c'est pas très chouette parce que j'avais pas de dalles et trottoirs + route.
> La route c'était en fait la texture de terrain direct en dessous.
> 
> Donc j'ai rajouté un plan à la base de mes bâtiments avec un bord noir et des pointillés pour la route de sorte que ça fasse des tuiles et donc des routes à la connexion.
> Avec un algo je génère des randoms de mes modèles de base et ça me fait vite fait bien fait des villes/villages pas si déconnants.
> 
> Mais le truc idiot, c'est que ma route (= mon socle de batiment) à Y=0 se mélange avec mon terrain lui aussi à Y=0 dans les zones planes.
> ...


Ça s'appelle le z-fighting et la bonne manière de l'aborder c'est de faire des volumes "réels", par exemple des socles avec des épaisseurs sur tes bâtiments.
Fais en sorte que ta route ait une petite épaisseur, ou fais un prefab pour que ton plan ait un léger offset par rapport au y=0.

----------


## Grosnours

Oui, le Z-fighting c'est super courant.
Il suffit d'éradiquer la cause, c'est à dire les objets placés à la même hauteur. De manière générale, il vaut toujours mieux donner une épaisseur aux choses (les routes) mais si ce n'est pas possible tu peux introduire de très légères variations aléatoires de hauteur à l’instanciation de l'objet, invisibles à l’œil nu mais qui feront disparaître le Z-fighting. Satisfactory procède ainsi.
Perso tous mes objets ont une hauteur, mais ce n'est pas une obligation canonique.

----------


## Sifr

Je suis parti donc sur le micro changement de hauteur.
Ca résout le problème effectivement mais je pensais qu’il existait un truc plus technique.

Bon maintenant je cherche des idées pour « modéliser » la disponibilité des unités et sortir du carcan classique du STR.
J’aimerai bien y ajouter un plus pour le fun.
Pour le moment je me vois mal produire des unités et n’en donner le contrôle au joueur qu’à X% d’un taux d’opérationnabilité.
Je voulais baser ça sur la logistique d’appro.

Mais si je mets juste un batiment d’appro x X points c’est juste de la limitation de pop.
Si je tente la conséquence, ça pourrait être une réduction de puissance de feu sur le matériel mecanique mais c’est un peu léger.

Je pensais aussi sinon fournir un batiment qui produit tout seul des unités détruites par le passé à un rythme Y en fonction d’un taux de rentré de pognon - mais ça perd de sa symbolique initiale.

A l’occaz’ pour la gloire si quelqu’un a une idée magique à tester…

----------


## Sifr

Je comprends de plus en plus les gens qui gueulent contre le niveau de finition de Unity…

Je suis passé à la dernière LTS… je build et ça prend des plombes par rapport à avant.
Genre 10x le temps de build.

Je regarde, il crée plein de variants de shaders.
OK sur le forum y’a un thread qui dit qu’ils ont crée pleins de features géniales et donc que ça pourrit le temps de build.
Heureusement ils proposent des options pour l’inutile.

Mais non, elles sont déjà cochées et sont finalement inopérantes vue les réponses au thread.

C’est des champions - ça m’a coulé l’envie de continuer pour un bon moment…  ::sad::

----------


## Grosnours

Passer de 2019 à 2021 cela fait effectivement très très mal.
Heureusement on a passé totalement 2020 pour conserver notre santé mentale.

Par contre Plastic >>>> collab, ce qui n'était pas non plus très difficile. Au passage il vaut mieux utiliser le plugin de Plastic dans Unity le moins possible et passer par le client externe.

----------


## Molina

Je suis en train d'essayer d'utiliser Unreal Engine (Je ne conseille pas du tout de faire le switch si tu comptes un jour finir ton jeu !  ::P: ).
C'est... Agréable pour plein de petites features. C'est relou pour tout le reste, surtout parce que j'ai l'impression qu'Unreal demande d'être beaucoup plus carré. Et il faut réapprendre la logique du moteur. Et apprendre soit C++ soit leur blueprint. 

Mais en même temps... C'est agréable en termes de leveldesign. Je trouve tout beaucoup plus simple en fait d'utilisation. Et bien entendu, mettre à jour le moteur ne casse pas complètement ton projet. Et c'est facile parce qu'il y a plein de truc tout fait pour les FPS. 

Je voulais essayer pour faire joujou avec le RTX et leur machin qui permet de ne plus réfléchir au nombre de vertices de tes assets ( ::ninja:: ). Je me tâte à rester du coup.

----------


## Grosnours

Aucun risque pour moi de changer vu que :
- j'ai investi le PIB du Zimbabwe dans des assets du store
- je hais profondément et infiniment le C++
- on ne fera jamais de FPS
- on a tendance au contraire à faire des trucs de niche


Par contre j'ai un *énorme doute* sur "mettre à jour le moteur ne casse pas complètement ton projet". C'est simplement qu'il y a bien moins de versions majeures chez Epic, ce qui n'est pas un mal. Par contre va passer ton gros projet d'UE3 à UE5 et on va voir si rien ne casse. On peut demander à Psyonix, cela fait des années qu'ils bossent dessus. A l’intérieur même d'une version l’évolution est facile mais c'est kif-kif pour Unity.

En ce qui concerne le RTX c'est dispo pour Unity aussi (HDRP sur 2022 je crois), mais je suis toujours sceptique d’implémenter un truc dont bénéficiera un petit (voire infime pour moi) pourcentage des utilisateurs. Pour nanite et le fait de ne plus avoir besoin de LOS, je ne sais pas, je demande à voir dans le temps des retours d’expérience. Ce qui est plus bluffant pour moi c'est l'illumination globale de lumen, mais là aussi je demande à voir dans le temps.

----------


## schouffy

J'ai deux questions sur UE:
- Il faut toujours quitter et relancer l'éditeur quand tu modifies ton C++ ?
- L'éditeur fait toujours souffler ta machine dès le moment où tu le lances ?

@Sifr: C'est clair que les temps de build sont de plus en plus longs... Et puis c'est buggé, parce qu'en général si tu relances l'éditeur ça devient plus rapide pendant un moment.
J'ai mis ça en place sur mon projet qui a quand même pas mal réduit les temps de build.

----------


## Grosnours

Au passage si Unity vous pop souvent pendant que vous l'utilisez (juste après avoir sauvé un truc habituellement) un message à propos de la mise à jour des assemblies, un simple ALT+TAB sur VS et un CTRL+S (même s'il n'y a rien de neuf à sauver) règle le problème.

----------


## Sifr

Un autre truc que je comprends pas dans les builds : avant j’avais l’impression qu’il faisait du différentiel mais là je prends le temps de faire le build qui dure des plombs et à la seconde fois juste derrière il me met exactement les mêmes actions et donc ces variants de shader…

Je suivais les versions à chaque publi mais je crois que je vais tenter une dernière fois de migrer vers la dernière 2022 quitte à tout péter si c’est pas compatible.

----------


## schouffy

Y'a des trucs un peu dangereux à monter de version aussi... Genre tu updates de 2021.1 à 2021.3 et ton package Android passe de 60 à 70 Mo.. Ou bien tu perds 5 fps au passage.. Ou ça change la version min supportée d'Android...
Faut vraiment le faire pendant la préprod uniquement je pense, et ensuite le considérer seulement si une feature est un must-have pour ton projet.

----------


## Grosnours

La dernière vraie version confort pour moi était la 2019 LTS.
Maintenant si tu as vraiment besoin des nouvelles fonctionnalités (genre le RTX pour le HDRP), alors effectivement tu peux monter sur la 2022. Mais franchement je ne le conseillerais pas vu qu'elle vient tout juste de sortir de bêta est ne sera pas LTS avant un bail.
Ceci dit, passer la semaine dernière de 2021.3.1 à 2021.3.2 m'avait provoqué des erreurs quantiques (Unity qui se plaint d'une bibliothèque présente et dans Assets et dans Packages alors qu'avant 0 souci), donc même en LTS on est plus à l'abri de l'exotique.

----------


## Sifr

C’est con quand même leur truc :
- tu builds après pas mal de temps ça prend des plombes dont les shaders variants ;
- avant de builder tu éteins le pc et tu redémarres une session toute propre et là le temps de build est classiquement supportable  :ouaiouai: 

Bon la bonne blague sinon histoire de se foutre de la gueule du noob en Unity : pourquoi d’un coup mon jeu a plus le même tête en build qu’en lancement sous l’éditeur… ? Prise de tête garantie jusqu’à je me rende compte que oui dans les jeux les graphics settings ça se gère et non je l’ai jamais mis en place du coup sous Unity en mode ultra et en build, je sais pas pourquoi par défaut dorénavant en low…
Simple à résoudre mais bête comme chou.  ::siffle:: 

C’est bien la peine de passer un tiers du temps de dév sur l’IA et pas être fichu de penser aux graphics settings.

----------


## Grosnours

> - avant de builder tu éteins le pc et tu redémarres une session toute propre et là le temps de build est classiquement supportable


Il faudra que j'essaye pour voir.

----------


## Sifr

Est ce que vous avez un petit soft gratuit à me conseiller pour configurer une installation sous windows avec possibilité propre de désinstallation pour déployer un jeu Unity ?

Par le passé j’avais un soft qui était sympa quand je déployais des mods mais impossible de remettre la main dessus… en même temps ça fait au moins quinze ans que j’ai pas retenté le truc  ::P:

----------


## schouffy

C'est pas wix et inno setup les plus populaires ? ça marche avec tout, peu importe que ce soit du Unity ou pas.

----------


## Sifr

Je vais regarder merci  ::): 

Ce jour fut l’objet d’une décision sauvage : tout tournait bien, bien net, propre et précis - donc logique j’ai tout cassé pour refaire le système de gestion de ressources…. Oh joie de galères en galères…  ::lol::  et les collecteurs s’acharnent dorénavant sur des points de ressources vides  ::sad::

----------


## Sifr

Je pense fortement pousser un build dans la nature pour avoir un feedback réel pour le fun par contre me reviennent les questions en suspend associées à cette étape :
- vous prenez en compte le risque de décompilation ? Il semble que sur Unity ça soit assez accessible.On doit s’en inquiéter ?
- les debug.log vous les neutralisez ou y’a une option spéciale pour éviter de générique du baratin chez le user ?
- vous gérez comment les crédits via l’asset store ? J’ai fait un panel avec le nom du package et l’auteur pour les musiques et les sons + une ou deux textures. Ca suffit ?

----------


## Grosnours

1) tous mes jeux sont en CC BY-NC-SA (ou une variante) donc je m'en tape assez largement. Il suffit de demander poliment et les gens auront le code source, s'ils veulent à la place se décarcasser à le décompiler, chacun son truc.
2) j'évite que mes jeux plantent  ::ninja:: 
3) à toi de voir, mais comme j'ai payé avec mon pognon les assets que j'utilise, je ne me sens obligé de rien. Par contre si tu utilises des assets gratuits ou open sous quelques licence que ce soit, les mettre dans les credits me parait la moindre des choses. La démarche souhaitée est toujours indiquée dans la license de toutes manières.

----------


## Sifr

> 2) j'évite que mes jeux plantent 
> .


Moi j’ai mille raisons que ça plante  ::ninja:: 
Surtout avec des idées comme celle que je suis en train d’implanter où je rajoute une couche de guerre électronique avec des hackers planqués dans leur sous-sol.
Ça me refait une surcouche que j’avais pas prévu mais je cherchais à mettre en place depuis le début cette composante.

Donc l’issue de la stabilité reste incertaine  ::lol::

----------


## Sifr

Petite question complémentaire : les terrains une fois qu'ils ont un navmesh, on est bien d'accord qu'ils peuvent se connecter entre eux si on les spawn au début d'une partie ?

Genre je veux faire un terrain carré de 25x25 avec des carrés élémentaires en prefab qui possèdent un navmesh ils vont se connecter entre eux au chargement et ce sera comme si j'ai un seul et unique terrain non ?

De ce fait je pourrais avoir une carte auto générée à chaque démarrage, en garantissant la cohérence des positions et des passages ?

----------


## war-p

> Petite question complémentaire : les terrains une fois qu'ils ont un navmesh, on est bien d'accord qu'ils peuvent se connecter entre eux si on les spawn au début d'une partie ?
> 
> Genre je veux faire un terrain carré de 25x25 avec des carrés élémentaires en prefab qui possèdent un navmesh ils vont se connecter entre eux au chargement et ce sera comme si j'ai un seul et unique terrain non ?
> 
> De ce fait je pourrais avoir une carte auto générée à chaque démarrage, en garantissant la cohérence des positions et des passages ?


Ça répond pas vraiment a te question, mais t'as un script qui permet de générer des navmesh au runtime.

----------


## Grosnours

Je crois que cela repond plutôt bien à la question en fait.  ::):

----------


## Molina

> dans les credits me parait la moindre des choses. La démarche souhaitée est toujours indiquée dans la license de toutes manières.


Et c'est à ce moment que je m'en veux de ne pas avoir tenu un registre il y a des années de ça...

----------


## Sifr

> Je crois que cela repond plutôt bien à la question en fait.


En attendant, au lieu de licencier les types qui bossent sur l’IA chez Unity, ils feraient bien de renforcer leur module de pathfinding et ouvrir un peu plus à des techniques avancées.

- - - Mise à jour - - -




> Et c'est à ce moment que je m'en veux de ne pas avoir tenu un registre il y a des années de ça...


Ca y est il est prêt à sortir le jeu ?  ::):

----------


## war-p

> Je crois que cela repond plutôt bien à la question en fait.


C'est un enfer à faire fonctionner correctement si tu veux faire des trucs un peu évolué (là je suis un jeu de course, et le pathfinding est jamais parfait, sans compter que le pathfinding de base de unity est en mousse : je m'oriente de plus en plus vers une solution custom/hybride, mais j'ai la flemme)

----------


## Grosnours

Perso c'est ce que je fais aussi, du custom et du Navmesh que dans les cas plus simples.
Après avec le custom comme d'hab cela depend totalement des cas et que c'est difficile à recommander san bien connaitre tous les tenants et aboutissants de la situation.

----------


## Ornithorix

Je me suis relancé sur Unity il y a quelque temps et j'ai réactivé un de mes projets qui dormait:



Effectivement le navmesh et nav-agent fournit par unity fonctionne correctement pour un comportement basique, par contre faut travailler pour donner un comportement de tank/camion et éviter la savonnette.

----------


## Molina

> Ca y est il est prêt à sortir le jeu ?


Haha.

No. Ca fait quelques mois que je n'ai plus retouché à mon build. Mais là, je me suis remis au sound design, et c'est vraiment ma partie préférée. Donc je m'y remets petit à petit.

----------


## Sifr

Bon la sortie de Regiments m'a remotivé pour bossé la tête de mes maps quand j'ai vu le peu d'écart de ce qu'il proposait en terme de fonctions implémentées.
Sans compter que moi j'ai de la construction de bases  ::trollface:: 

J'ai pas de campagne, pas de book de maps, mais le reste tient la route.

Et j'ai honteusement craqué pour la promo de gaia 2021 à 20 euros, de quoi jouer avec les stamps et faire des collines et paysages un peu plus géologiquement viables.
Au moins ça reste toujours du bidouillage mais c'est plus beau  ::ninja::

----------


## Grosnours

Très utile Gaia. Il s'intègre très bien avec d'autres comme R.A.M. ou Gena.

----------


## Molina

Effectivement, Gaia a l'air robuste et dans les parages depuis des années, avec toujours de bons retours. 

"Le reste" c'est AMHA le plus important. C'est quand j'ai fait mon menu, mon UI, mes aides aux joueurs (journal de quêtes, map) que j'ai senti que j'avais un jeu en face de moi. Ca aide à la motivation je trouve, même si le moins "fun" à faire.

----------


## Sifr

> Très utile Gaia. Il s'intègre très bien avec d'autres comme R.A.M. ou Gena.


Gena me fait de l’oeil pour poser les routes parce que j’obtiens pas de bons résultats avec ce que je fais = je sais faire mais je peaufine pas assez pour que ce soit qualitativement joli même si techniquement ça fonctionne.
D’ailleurs pour le moment j’ai viré les routes du coup l’IA attaque comme elle veut et c’est plus fun.

- - - Mise à jour - - -




> Effectivement, Gaia a l'air robuste et dans les parages depuis des années, avec toujours de bons retours. 
> 
> "Le reste" c'est AMHA le plus important. C'est quand j'ai fait mon menu, mon UI, mes aides aux joueurs (journal de quêtes, map) que j'ai senti que j'avais un jeu en face de moi. Ca aide à la motivation je trouve, même si le moins "fun" à faire.


Le « reste » occupe pas mal aussi quand c’est plein de bugs  ::lol:: 
D’ailleurs j’écluse des bugs en ce moment aussi… c’est d’un fun… et je sais toujours pas pourquoi je continue.  ::ninja::

----------


## Sifr

Note pour plus tard : toujours vérifier que la caméra importée d'un projet précédent en HDRP est bien nettoyée des composants pas compatibles en URP...

Purée, ça fait des mois que je peste contre un rendu terne et pauvre et que je viens de me rendre compte que j avais un composant tonemapping dans le post processing qui est incompatible de l'URP.

Les vraies couleurs de mes effets et de toute la scène sont enfin restaurés.

J'enrage de ces détails pas visibles par un simple check de compatibilité.

----------


## honu

Hello

Pour un projet pédagogique, je commence à m’intéresser à Unity (après avoir aussi regardé Unreal et Godot).

Le problème est que je souhaiterais travailler dans un premier temps à la construction de l’interface de contrôle, la gestion de l’utilisateur et les HUD de contrôle. Or, l’immense majorité des tutos que j’ai trouvé concerne des applications directes « Fais ton jeu de xxx » (remplacer xxx par FPS, RPG, etc), ou au mieux 3 petits menus (Jouer\Quitter). Je trouve ça très curieux de n’avoir rien sur les interfaces alors que dans les jeux Unity connus, elles sont plutôt bien foutues.

Est-ce que vous auriez des liens vers des tutos ou ressources qui concernent plus spécifiquement les interfaces de contrôle, mais aussi la gestion de l'utilisateur (progression) et HUD divers affichés pendant le jeu ? 

(merci à Deathdigger de m’avoir redirigé sur ce topic  :;):  )

----------


## Grosnours

Le mot que tu cherches est GUI (Graphical User Interface) ou UI. Tu trouveras beaucoup de ressources à propos des UI/GUI à commencer par celles fournies par Unity eux-mêmes dans le creative core.
En tout cas cela recouvre ce que tu appelles interface de contrôle et divers HUD.

Par contre je ne suis pas sur de ce que tu veux dire par gestion de l'utilisateur mais si j'ai bien pigé il s'agit d'un autre domaine, celui de la logique interne du jeu.

----------


## honu

Oui.
Merci pour ces pistes.
J’ai conscience que c’était vraiment une question de newbie, mais il fallait en passer par là. Rendez-vous dans 6 mois quand j’aurai réussi à aligner 30 lignes de code à montrer  :^_^:

----------


## Grosnours

La bonne nouvelle est que pour tout ce qui concerne l'UI une grosse partie du travail pourra se faire via l'interface graphique de Unity sans avoir à trop pondre de code (un peu quand même), donc tu peux faire pas mal avec 30 lignes en fait !

----------


## honu

Ooo, ça c’est enthousiasmant !

Ce qui m’avait un peu choqué, c’était de voir des tutos pour pondre 3 boutons de menus vraiment basiques (genre des comme ça j’en veux pas dans mon appli pédagogique), alors que dans les jeux il existe des interf.. euh des GUI avec une belle couche graphique (par exemple pour la gestion d’inventaire, ou des roues superposées à l’action pour le choix des armes, etc.).

Bon, on sent bien que c’est pas simple à faire, mais c’est ce qui rend l’expérience attractive pour l’utilisateur.

----------


## Sifr

En fait tout le visuel c’est codeless, mais derrière tu auras toujours le code pour gérer les choses qui te sont propres.
Après l’avantage c’est que tous les connecteurs sont déjà là. Tu as juste à dire que le click va activer f(x) par sélection. Et ensuite à toi de coder f(x).
Tu peux même faire en sorte que x soit dépendant de l’interface ou de la scène sans code.

Et puis les boutons stylés, c’est juste l’image que tu définis pour le représenter qui donne l’effet cool.
En soi, tu peux décorer comme tu veux, y’a pas de limite hormis le talent perso.

----------


## Sifr

Tiens d'ailleurs histoire de coloriser le topic, j'ai enfin atteint la maturité de mes modèles en voxel en me limitant uniquement à moins de 10 couleurs par faction histoire d'avoir l'homogénéité de visuels.

Une petite tourelle pliée en moins d'une heure qui fait le job :



A la distance de vue assez éloignée on voit même plus les voxels et on dirait un modèle classique from Blender.  ::P:

----------


## Grosnours

Joli.  ::): 
Moi j'ai fini par apprendre (un peu) Blender à force de devoir modifier les modèles que je me procurais (lire en les achetant 95% du temps) donc je continue sur ma lancée. Cela fait assez fortement le café (et l'aspirateur et la cuisine et... et...) Blender il faut bien dire.

----------


## Sifr

J’ai compris pourquoi j’étais assez mauvais en rendement de création de modèle en voxel.
En fait dès le début je pinaillais pout les détails et puis quand je suis passé aux micro modèles j’ai fait des trucs très grossiers parce que c’était tellement petit que ça donnait la forme pour la reconnaissance mais pas besoin de plus.
Après j’ai voulu faire au moins les batiments plus classes donc j’ai repris tous mes modèles et j’ai fait un x2 dans MagikaVoxel.

Ca m’a obligé à travailler sur une base et ne faire que les vrais détails sans me perdre dans la structure complète.
Du coup maintenant je sors un bon gros bloc à la forme de base et après j’accrois le nombre de voxel sur cette structure et j’affine.

C’est cool comme process et ça permet de sortir des trucs bien propres.

EDIT : et puis comble de la joie j’ai pu récupérer pleins d’effets de ma version en HdRP car les shaders mobiles sont transposables entre URP et HDRP ce qui fait qu’on peut traiter tout un tas de trucs de manière indifférenciée.

----------


## Sadhill

> Pour un projet pédagogique, je commence à m’intéresser à Unity (après avoir aussi regardé Unreal et Godot).


(pas tout à fait mais) un peu dans le même cas, du coup question encore plus Noob : je pensais aussi fortement à Unity mais les news de CPC (rachat, régie pub, malwares planqués dans les launchers,...)  me font poser cette question :
Unity ou Godot ?
(je précise : pour explorer personnellement, voire développer mes jeux, mais aussi pour apprendre un moteur ce que je pourrais éventuellement mettre à profit avec des élèves plus tard quand je m'en sentirais capable/légitime)

----------


## Sifr

> (pas tout à fait mais) un peu dans le même cas, du coup question encore plus Noob : je pensais aussi fortement à Unity mais les news de CPC (rachat, régie pub, malwares planqués dans les launchers,...)  me font poser cette question :
> Unity ou Godot ?
> (je précise : pour explorer personnellement, voire développer mes jeux, mais aussi pour apprendre un moteur ce que je pourrais éventuellement mettre à profit avec des élèves plus tard quand je m'en sentirais capable/légitime)


Le complotisme a le vent en poupe mais faut rester les pieds sur terre  ::): 

Unity n’installe pas des malwares, ils ont juste pris un partenariat avec une société qui a une technologie issue de ce type d’activité mais qui a tourné la barre vers les micro transactions.
Et l’un de leurs axes est de renforcer les outils des dévs pour gérer tout ce qui est monétisation sur le périmètre du jeu mobile donc les régies, ça vient avec.
Les rachats, c’est courant, y’aura tout le temps des news et des volontés sur un acteur majeur.

Ensuite Unity c’est du solide, y’a des acteurs majeurs dans l’aventure et pas que du jeu.
Des constructeurs automobiles l’utilisent pour les simulations de systèmes autonomes, de la validation numérique en traffic etc…
Y’a de la réalité virtuelle dans les formations médicales
Ils sont aussi implantés dans l’usine virtuelle.
Etc…

Bref c’est pas un truc qui va se prendre les pieds dans le tapis fait au fond d’un garage.

Ca ne retire rien de l’intérêt de GODOT sur lequel je ne me prononce pas.

Mais Unity c’est un investissement sur le temps et l’avenir. Et multi domaine.
Y’a un bon potentiel dans un milieu éducatif.

----------


## honu

Merci de toutes ces infos (j’avais pas reçu les avis de nouveaux posts).

La tourelle est vraiment bien ! Tu as la possibilité de nous montrer dans quel environnement ça s’insère ?

----------


## Sifr

> La tourelle est vraiment bien ! Tu as la possibilité de nous montrer dans quel environnement ça s’insère ?


Pas dans l’immédiat car je me suis rendu compte que j’avais des distances trop grandes dans ma carte de référence et ça nuisait à la dynamique générale, je voulais ça avec plus de répondant sur les différentes actions.
Donc j’ai remis à plat mon terrain, réduit de 30% la surface et je suis en train de refaire ma map.

Je bénéficie aussi d’une meilleure compréhension de l’outil terrain et donc comme d’hab je fais des trucs plus jolis qu’avant  ::): 

Mais un jour je vais bien finir par poser une version testable pour avoir un feedback sur les performances.
Mon PC est pas tout jeune et ça tourne au poil.
Un petit feedback critique général pour le fun c’est toujours bénéfique.

----------


## LDiCesare

Quelqu'un sait pourquoi on a des trucs complètement différents quand on lance dans l'éditeur et qu'on fait un build?
Du genre tous mes sprites sont corrompus (mélange de sprites, inversion, genre les adresses dans l'atlas sont pas bonnes).
Accessoirement j'ai aussi des gameobjects qui ne se comportent pas pareil, etc.
Je croyais qu'il y avait un output.txt ou similaire dans le répertoire _Data du build mais non. Je n'arrive pas à voir comment forcer la création du fichier de log ou alors je ne cherche pas au bon endroit?

----------


## Grosnours

Pourquoi tu ne compiles pas un build avec console de debug ?

----------


## LDiCesare

Parce que je ne connais pas l'option. 
Tu fais ça comment?

Edit: Apparemment cocher Development build permet d'avoir une console.
Par contre c'est tellement petit que c'est illisible. Un fichier serait tellement mieux...

Re-edit: Y a un bouton open log file (pareil, c'est tout petit et illisible) donc ça devrait être déboguable maintenant.
Merci de m'avoir poussé dans la bonne direction.

----------


## SalsifiNoir

> Quelqu'un sait pourquoi on a des trucs complètement différents quand on lance dans l'éditeur et qu'on fait un build?
> Du genre tous mes sprites sont corrompus (mélange de sprites, inversion, genre les adresses dans l'atlas sont pas bonnes).
> Accessoirement j'ai aussi des gameobjects qui ne se comportent pas pareil, etc.
> Je croyais qu'il y avait un output.txt ou similaire dans le répertoire _Data du build mais non. Je n'arrive pas à voir comment forcer la création du fichier de log ou alors je ne cherche pas au bon endroit?


Si tu as ce phénomène c’est que tu n’as pas codé correctement les awake, start, voir la création d’une fonction init() qui affecte ce qu’il faut au bon moment avant l’usage de tes objets là où il le faut effectivement.

Tu n’as réellement le même comportement entre l’éditeur et le build que lorsque c’est codé dans les règles de l’art.

As-tu mis en place dans l’éditeur un debug.log qui print à chaque étape de ton chargement pour vérifier que l’ordre d’initialisation de ta scène correspond bien à ce que tu souhaites techniquement ?

----------


## Grosnours

> Tu n’as réellement le même comportement entre l’éditeur et le build que lorsque c’est codé dans les règles de l’art.


Oui, voilà.
Tu as des trucs qui sont spécifiquement uniquement dans l'éditeur (et c'est clairement codé/indiqué ainsi) mais grosso modo si tu vois des différences notables entre ta scène dans l'éditeur et une fois compilée c'est qu'il y a une couille dans le potage dans ton code quelque part plus qu'un problème latent de la part d'Unity.

----------


## LDiCesare

En fait j'avais plusieurs problèmes.
Un Start au lieu d'un Awake qui faisait que la transition de scène fonctionnait dans l'éditeur mais pas dans le build. En fait, la scène d'arrivée ne fonctionnait plus non plus dans l'éditeur si on la lançait directement.
L'utilisation du sprite atlas: L'éditeur s'en fout complètement, donc si on ne met pas les bonnes options dans l'atlas (dans mon cas interdire la rotation entre autres), on ne le voit qu'après un build.
Enfin j'avais un appel sur OnValidate() et là c'est moi qui suis juste débile, vu que c'est un appel fait pour mettre à jour mon inventaire quand je le modifie via l'éditeur, donc forcément si je fais pas un appel équivalent dans Awake() ou autre, en build ça marche pas.

J'avais surtout pas anticipé le coup de l'atlas. Pour le reste, effectivement, je sens que je vais devoir me taper des traces d'initialisation pour m'assurer que tout se passe dans le bon ordre. En tous cas, je suis content d'avoir fait un vrai build relativement tôt dans mon dev, ça m'aura évité de me prendre une tonne de problèmes d'un coup le jour où j'essaierai de mettre tout ensemble.

----------


## Cmos

Coinjour,

voilà peu de temps que je bidouille Unity (en 3D seulement, et c'est génial!) et je profite de ma découverte de ce sous-forum pour vous poser une question en bon françois parce que je bute sur un truc qui me prend la tête. (Je suppose qu'il vaut mieux poster dans ce fil plutôt que d'en créer un nouveau ::unsure:: )

Le contexte :


Spoiler Alert! 


Pour poser le contexte, je faits des essais divers autour d'un projet basique de TPS tel qu'on pouvait en voir tout début 2000. 
je me suis attelé à la mise en place du système régissant les interactions entre le joueur et le groupe d'objets utilisables. L'idée c'est que quand on trouve un de ces objets, on peut choisir quoi en faire/ne rien faire via un menu dédié. Donc je m'approche de l'objet, le menu surgit, je choisi quoi faire et... et c'est là que je me gratte la tête pour dire "vas y objet déroule ton code":

> Ma première idée était de positionner une variable publique dans le script du joueur selon l'action choisie à travers le menu surgissant et d'autre part, dans le script de l'objet, lire cette variable et agir selon la valeur (en gros 0=rien faire, 1=faire action1; 2=faire action alternative).  Mais j'ai revu ma copie de peur de vite finir en mode spaghetti code avec des variables de partout. 

> Ensuite je suis parti sur des unityevents pour transmettre les ordres. C'est plus propre, plus limpide, on regarde l'inspecteur et on sait déjà qui affecte quoi. Mais voilà, c'était trop beau. Les unityevents ne permettent pas d'aller chercher une info. Juste de déclarer à qui veut l'entendre... un événement. En gros ça fait ce que c'est sensé faire et ça fonctionne pour 90% des cas (ici, ouvrir/fermer une porte, faire péter du C4, switcher un appareil, en gros tout ce qui marche sans feedback entre objet et joueur). 

> Finalement je me suis dit que je pourrait envoyer les infos nécessaire si besoin à l'objet via unityevent en même temps que je demande à l'objet d'agir, en le passant en paramètre. Soit techniquement AVANT que l'objet n'en ai besoin et ça me paraît pas super logique et ça m'embrouille un peu.

Donc retour case départ avec la lecture d'une variable publique... 

PS: en plus j'arrive pas à me contenter d'une solution que je considère bancale même si c'est temporaire en attendant de trouver mieux du coup j'avance pas ^^




Ma question est simple : Quelle est la méthode d'échange d'infos entre scripts de GameObject séparés de manière propre et rigoureuse sans finir en plat de spaghetti ? Quel est l'état de l'art à ce sujet (j'imagine que balancer des var publique de partout n'en fait pas partie, si)?

----------


## yodaxy

Y a pas mal de méthodes mais je pense que tu peux continuer d'utiliser les UnityEvents et complémenter avec des Scriptable Objects, qui permettent à la fois d'être ajouté dans l'inspecteur (et donc dans un event) et de stocker des valeurs diverses dans des assets, du coup pour envoyer des infos vers un autre script c'est nickel.

Une bonne vidéo à leur sujet :



Sinon dans les interactions physiques (OntriggerEnter / OncollisionEnter) tu peux récupérer tout un tas d'infos sur n'importe quel objet avec lequel ton Player entre en contact, ou exécuter des méthodes dans celui-ci. En général dans ces méthodes tu peux faire un "GetComponent<ClassAvecLaquelleJeVeuxInterragir>()  .MethodeQueJeVeuxLancer" sur l'objet en collision.

----------


## DarwinMorkai

Coin ! 
Je ne sais pas si ca va répondre a ta question, mais dans cette vidéo, il a l'air d'expliquer ce que tu cherches, mais je crois en passant pas une variable comme tu le dis, mais il donne plusieurs astuces
https://www.youtube.com/watch?v=yLLRO7KqnX4


J'espère que ça t'aidera !

----------


## Grosnours

Les scriptables objects c'est très bien, mangez-en.
Maintenant si tu veux définir des variables ou constantes qui seront disponibles pour tous les GameObjects dans toutes les scènes, une méthode classique est de faire appel à un singleton don't destroy on load qui contiendra toutes ces variables.

----------


## Cmos

Je ne connaissait pas les scriptable objects. Je vois que dans mon cas l'intérêt serait d'utiliser ça en tant qu'intermédiaire entre les différents scripts. A creuser c'est encore très flou. 
Le singleton oui mais s'il ne peut y en avoir qu'un mieux vaut réserver ça à la gestion globale du jeu, j'imagine.

Merci pour vos suggestions en tout cas.

----------


## yodaxy

> Le singleton oui mais s'il ne peut y en avoir qu'un mieux vaut réserver ça à la gestion globale du jeu, j'imagine.


Tu peux totalement avoir plusieurs Singletons, mais il faut juste qu'il n'y ait qu'une seule instance de la même classe (sinon ça s'appelle un Multiton). 
Tu peux avoir un Singleton GameManager, un LevelManager, un ItemManager, etc.

Bon après perso je dirais qu'il il faut éviter d'en faire trop parce que ça peut vite devenir le bordel  ::ninja::

----------


## schouffy

J'ai réfléchi vite fait et à priori je partirais comme ça :

Un MonoBehaviour avec :
- OnTriggerEnter et OnTriggerExit pour pop in/out ton menu d'actions
- Un array d'objets name/UnityEvent pour que tu puisses ajouter tes items directement via l'inspecteur

Sur un autre MonoBehaviour tu crées l'implémentation de chacune de tes actions, et tu le met sur le même game object. En fonction de tes actions, tu peux sans doute réutiliser des MonoBehaviour génériques. Par exemple "ramasser" ça peut être une action générique que tu met sur plusieurs GameObjects différents. Raccorde les UnityEvents dont je parle plus haut à chaque implémentation.

Quand tu entres dans ta zone trigger, affiche le menu avec les actions. Quand tu sélectionnes une action, execute le UnityEvent associé.

----------


## Cmos

> Tu peux totalement avoir plusieurs Singletons, mais il faut juste qu'il n'y ait qu'une seule instance de la même classe (sinon ça s'appelle un Multiton). 
> Tu peux avoir un Singleton GameManager, un LevelManager, un ItemManager, etc.
> 
> Bon après perso je dirais qu'il il faut éviter d'en faire trop parce que ça peut vite devenir le bordel


Ah ben c'est bon à savoir ça merci!


Bon en fait mon histoire d'unity event est foireux puisqu'en fait ça m'oblige à drag/drop chaque item... Je sais pas pourquoi je m'étais mis en tête que je n'avais qu'à drag/drop un prefab pour que ça s'applique à tous du même type... 
Mais bon là j'arrête pour le moment je peut pas me concentrer (migraine).

edit: 



> J'ai réfléchi vite fait et à priori je partirais comme ça :
> 
> Un MonoBehaviour avec :
> - OnTriggerEnter et OnTriggerExit pour pop in/out ton menu d'actions
> - Un array d'objets name/UnityEvent pour que tu puisses ajouter tes items directement via l'inspecteur
> 
> Sur un autre MonoBehaviour tu crées l'implémentation de chacune de tes actions, et tu le met sur le même game object. En fonction de tes actions, tu peux sans doute réutiliser des MonoBehaviour génériques. Par exemple "ramasser" ça peut être une action générique que tu met sur plusieurs GameObjects différents. Raccorde les UnityEvents dont je parle plus haut à chaque implémentation.
> 
> Quand tu entres dans ta zone trigger, affiche le menu avec les actions. Quand tu sélectionnes une action, execute le UnityEvent associé.


 Merci je prends note, je verrai ça à tête reposé  :;):

----------


## SalsifiNoir

Je viens de passer à la toute dernière version officielle la 2022.2 et ils ont basculé le système de navigation au dernier jus de ce qui était sous github.

Ca marche presque bien en conversion mais il y a une évolution avec les nav mesh obstacles.

Avant le trou dans le nav mesh se limitait au bord de l’obstacle défini par la box verte.
Maintenant il y a en plus une box blanche avec une sorte de tolérance encore plus loin.

Ce qui fait que tous les ajustements précédents ne sont plus atteignables car le trou dans le nav mesh est bien plus grand.

Savez vous où on peut ajuster cette box de tolérance sans changer la box d’obstacle initiale ?
J’ai rien trouvé sur ça.

----------


## Grosnours

Désolé, aucune idée vu que j'essaie de me limiter aux LTS.
Mais j'ai une question pour toi vu que tu as le goût du risque: tu as toujours sur 2022 les horribles temps d'attente de 2021 dès que tu fais un truc du genre changement de scène avec les boite de messages "Hold On" ou ils ont corrigé cela ?

----------


## schouffy

C'est pas juste qu'ils ont pris en compte l'agent radius dans le navmesh obstacle ?

----------


## SalsifiNoir

> C'est pas juste qu'ils ont pris en compte l'agent radius dans le navmesh obstacle ?


C'est effectivement ça, après avoir fait quelques tests sur cette idée.
C'est moche car c'est plus compliqué qu'avant car il faut jouer avec le radius qu'on peut ignorer pour espérer avoir un objet passer ou atteindre un bon endroit.
Donc impossible de valider sans lancer et tester ingame alors que sur un prefab on posait l'obstacle et on savait que c'était bon.
Pas un progrès...

- - - Mise à jour - - -




> Désolé, aucune idée vu que j'essaie de me limiter aux LTS.
> Mais j'ai une question pour toi vu que tu as le goût du risque: tu as toujours sur 2022 les horribles temps d'attente de 2021 dès que tu fais un truc du genre changement de scène avec les boite de messages "Hold On" ou ils ont corrigé cela ?


Pour le moment, pas vu cet effet, mais mon projet est très petit.

----------


## LDiCesare

Ca me parait normal de rajouter le rayon de ton objet quand tu fais tes navmeshes. Surtout si le même jeu d'obstacles peut servir à des mobiles de tailles différentes.

----------


## SalsifiNoir

Oui mais on le visualise pas dans un prefab, donc impossible de caler les points d’accès à un drop par exemple précisément ou alors ils ont introduit un truc pas encore vu.

Par contre dans la 2022 ils ont ajouté les spherecast, boxcast etc… asynchrones et c’est super pour les perfos.

----------


## SalsifiNoir

Question bête : en quoi la taille des objets influence sur les perfos en dehors du nombre de noeuds d’un mesh ?
Y’a une conversion d’unité à l’import vers unity, mais si je fais une scène avec une taille de 10 de 100 ou de 1000 les objets sont plus gros mais est ce que cela change les performances ? Du genre une sphère cast est forcement plus grande en rayon de même sur l’overlaps de la sphère.
Donc distance plus grande du rayon donc volume plus grand. C’est bien dit que le raycast par exemple est sensible à la distance mais de l’échelle globale ou de la distance réelle ?
On prend un asset de caillou, ça fait quasiment une montagne sur une tuile de terrain par défaut.
On prend un autre asset d’arbre, on dirait un cure dent au milieu de la même tuile…

Y’a une règle qui dit quelle dimension de scène est optimale ?

----------


## Grosnours

Les dimensions n'ont aucune importance si tous tes assets ont exactement la même échelle.
Il m'arrive souvent d'avoir des assets de tailles totalement différentes et je dois passer par une étape de mise à l'échelle dans leur préfab. Mais la taille de leur modèle, je m'en tape. L'interface de déplacement de Blender (et dans une moindre mesure Unity auss) est un poil plus facile à utiliser avec des modèles plus grands, donc il ne vaut mieux pas faire dans le liliputien non plus.

Après si tu as des invariants genre terrains, là par contre l'augmentation démesurée de leur taille n'est pas gratuite en terme de perf. Cela guidera donc tes choix d'échelles.

Perso je me préfère toujours avoir une tuile de grid qui correspond à une de mes unités de base (maison ou perso, ou ce qui est l'unité de base du jeu en question).




> Question bête : en quoi la taille des objets influence sur les perfos *en dehors du nombre de noeuds d’un mesh* ?


Là par contre je n'ai pas bien compris ce que tu veux dire.

----------


## SalsifiNoir

Oui ma phrase était pas claire mais en l’état j’ai quand même une réponse explicite  ::): 
Je voulais surtout parler de l’augmentation de taille d’un objet sans augmenter le nombre d’éléments dans le maillage.

----------


## Grosnours

Points/arrêtes/faces (vertex/edge/face) sont les mots que tu cherchais alors.  ::): 

Ceci dit il est très important d'avoir les modèles en différentes versions si tu utilises le concept de LOD. Car tu assigneras dans le LOD Group un tel modèle à une telle distance de vue, ce qui te permet de d'adapter dynamiquement le nombre de triangles à l'écran.

D'ailleurs c'est un de mes soucis en ce moment, acheter des modèles et les personnaliser c'est très bien mais je suis obligé de me taper à la pogne (quand les algos de ruines de mesh sont à la tue, càd souvent) la ruine de mes meshs pour les points de vue plus éloignés. Ce qui n'est pas trivial et peut prendre beaucoup de temps, surtout si tu veux offrir des transitions entre modèles les meilleures possibles. 
Alors que si tu avais développé (ou fait développer) le modèle toi-même, tu aurais déjà différents modèles avec différents niveaux de détails naturellement, car le process de design part habituellement d'une version plus sobre/sommaire pour ensuite évoluer dans les détails (et donc le nombre de triangles).

----------

