Discussion :

[Gregouar]

Bonjour à tous,

Il y a quelques temps, je vous présentais ici un projet de "moteur graphique" (pas vraiment un moteur, plutôt un prototype soyons honnête ) 2.5D. J'avais en tête de faire un prototype de jeu Lovecraftien dessus, mais je me suis assez vite rendu compte que mes talents artistiques étaient fort limités, et je me retrouvai donc dans l'impossibilité de produire des assets graphiques convaincant pour aller avec. J'ai donc décidé d'expérimenter dans une autre direction qui me demanderait beaucoup moins d'effort pour produire des assets, et je suis parti sur l'idée de faire un prototype de jeu en vue du dessus et pixel art, où les animations seraient principalement procédurales (dans le sens où je ne fais que des transformations sur mes sprites pour animer, ainsi je ne dois même pas dessiner d'animation en pixel-art; ce que je serais incapable de faire aussi ! ). De plus, cela devrait me permettre d'ajouter facilement beaucoup de contenu (il suffit de dessiner un sprite par pièce d'équipement, le rêve !). Certain éléments seraient en 3D quand-même, surtout pour les murs.

Etant donné que le projet est en bonne voie, le gameplay se précisant et le code avançant de façon satisfaisante, j'ai décidé de venir vous présenter les résultats actuels. Puisque le projet est assez fort expérimental, peu de chose sont réellement fixées et donc je ne peux pas vous vendre plus que ça le jeu, si ce n'est que c'est un jeu d'action/aventure multijoueur en vue du dessus, dans la même veine qu'un Terraria. J'espère obtenir un côté action/hack'n'slash ave plus poussé, avec de l'exploration de donjons et des combats plus techniques, si j'y arrive . Bien sûr, j'ai un peu plus d'idées que ça, mais je pense que ça ne sert à rien de trop en parler avant d'avoir été plus loin et vérifié si ça ressemble à quelque chose. C'est déjà beaucoup de blabla sans image, alors voici à quoi ça ressemble pour le moment:

(oui j'ai honteusement repompé le design des lanterns de Black Skylands)

Techniquement parlant c'est du C++ avec Vulkan pour la partie graphique (en vrai c'est la même base que la version Vulkan de mon propotype de moteur 2.5D) et Fmod pour le son. Du coup, c'est un peu fou (et inutile), mais oui c'est de l'éclairage PBR sur du pixel-art. Mais je pense que ça rend plutôt bien:

Les normal maps des sprites sont générées avec Laigter.
Je rajouterai probablement plus d'effets plus tard (des ombres pour les lumières omni, du bloom, du SSAO et peu-être d'autres fantaisies selon mes envies).

Pour le moment, je travaille sur l'ajout d'une couche réseau (j'ai retenu la leçon avec Holyspirit, ne pas essayer de mettre du réseau à la fin sur un moteur de jeu qui a été pensé solo !) que j'ai décidé de coder basé sur les tutoriaux de Glenn Fiedler. Le côté "bas-niveau" (ie. connexion client/serveur, envoi de données fiable ou non, gros packet de données, etc) est grosso modo fini et semble stable, et donc je suis en train d'expérimenter avec le côté plus haut niveau pour synchroniser le serveur et les clients. Je suis pour le moment sur l'idée d'un serveur autoritaire et de clients prédictifs, mais étant donné que c'est un jeu probablement uniquement solo, je changerai peut-être pour que les clients s'occupent de leur propre position, collisions et dégats (ça permet quand-même un gameplay beaucoup plus fluide, et la triche n'a pas trop d'importance pour ce genre de jeu qui se joue surtout entre amis, je pense). Voilà pour le moment ce que ça donne dans des conditions de réseau médiocre (250ms lag, 10% de perte de paquets + 10% de paquets corrompus, simulé avec Clumsy):

Si ça vous intéresse, je reviendrai vers vous quand j'aurai du nouveau ! N'hésitez pas à laisser vos commentaires ou suggestions, le projet étant fort ouvert je peux me laisser influencer.

Ah oui, et j'ai oublié de le dire, mais évidemment c'est open-source, avec les sources ici.

[Bousk]

Sympa, bonne chance !
FYI, les articles de Glenn sont disponibles traduits ici https://bousk.developpez.com/#page_traduction
Sur le même lien tu as des articles sur l'écriture d'un moteur réseau.
Je trouve personnellement qu'ajouter du réseau sur un jeu solo est une bonne chose : tu n'as pas de merdes un peu partout qui essayent de faire du réseau de manière bancale
Il faut par contre que le moteur soit suffisamment bien ouvert pour pouvoir le manipuler depuis les handler réseau.
BTW, l'écriture du cours me permet de (re)créer un tel moteur, que tu trouveras aussi sur github https://github.com/Bousk/Net. Si cela t'intéresse, je serais intéressé à collaborer, afin d'appliquer, continuer à debugger et promouvoir celui-ci. Ça te débarrasserait des problèmes plus bas niveau pour te concentrer sur le process des messages et non sur comment ils sont envoyés.

[Gregouar]

Merci pour les liens !
Le soucis, c'est que je ne pense pas coder de façon assez bien pensée et organisée pour qu'ajouter une couche réseau après soit facile. Au moins avec mon approche actuelle je peux m'assurer que toute fonctionnalité que j'ajoute s'adapte bien au réseau.
Par contre, je pense avoir découplé suffisamment la couche réseau bas-niveau pour pouvoir switcher vers quelque chose de plus propre/stable/mûr/sécurisé plus tard si le besoin s'en fait ressentir. Mais pour le moment ce que j'ai tapé semble fonctionner correctement et être stable. C'est plutôt à "haut-niveau" que c'est parfois moins clair de comment procéder.

[Bousk]

En ce cas les prochains articles du cours devraient t'intéresser.
Mais je ne sais pas quand ils seront disponibles

[Guntha]

Salut,

J'aurais bien sûr adoré voir arriver un jeu avec le style graphique de l'autre topic, mais ce que tu nous présente là, avec les animations et la lumière qui font bien propre , c'est presque assez pour faire le trailer d'un jeu vendable

[Gregouar]

Merci !

Typiquement, pour le moment je réfléchi à comment synchroniser la vie et dégâts des mobs. Puisque je suis parti sur un serveur autoritaire, on est obligé d'avoir sa confirmation. Si j'attends bêtement celle-ci, cela induit un sale lag désagréable qui fait que le joueur ne voit pas l'effet de son attaque avant que celle-ci ne soit terminée, ce qui est très désagréable.
Du coup, je prédis les dégâts en calculant la collision au niveau du client. Ensuite, je remets à jour la vie du mob en fonction de ce que je reçois du serveur. Bien sûr, ça ne suffit pas, parce que si le lag est assez important, le mob peut subir des dégâts prédits, puis être régénéré car il reçoit de l'information sur son état d'avant, puis resubit les dégâts.
Une solution possible serait d'enregistrer les dégats prédit dans le futur, ainsi, on ne met à jour que quand on reçoit l'état du serveur dans suffisamment longtemps pour que les dégâts ait été infligés côté serveur (sauf si bien sûr il y aurait eu désynchro et que les dégâts n'auraient pas été réellement infligés). C'est presque parfait sauf si deux joueurs tapent en même temps sur le monstre, vu que le client va prédire ses dégâts, voir l'animation de l'autre joueur attaquer, et voir les dégâts de l'autre joueur s'afficher seulement plus tard de part la synchro du serveur. Ou alors, il faut que je "prédisse" aussi les dégâts des autres joueurs.
Une autre solution serait de ne pas synchroniser simplement la vie des mobs, mais synchroniser les événements, ainsi je pourrais savoir combien de dégâts ont été infligés (et peut-être quand) et surtout par qui. Mais alors ça veut dire encombrer encore plus le réseau. Peut-être que pour peu qu'il n'y ait pas trop d'action, ça resterait raisonnable.
Finalement, encore une autre solution serait de laisser tomber le serveur autoritaire (ce n'est pas si important que ça l'anti-triche dans un jeu de coop pve de ce style plutôt imaginé pour être joué entre amis, qu'en pensez-vous ?). Cela permettrait un gameplay complètement fluide pour les joueurs, avec aucune désynchro au niveau des attaques.

[Bryce de Mouriès]

Welcome back Gregouar !

J'étais bluffé par ton précédent topic, c'était très impressionant les démos de lumières, refractions en 2.5D, ton nouveau projet ne lui rend pas encore hommage

Sinon, un traumatisme dans l'enfance avec les canards ?

[Gregouar]

Les réflexions pourraient bien revenir.. vu que tout est là, c'est presque que du code à décommenter pour les faire revenir. Mais je ne suis pas convaincu que le coût en perfs en vaille la peine. D'autant plus étant donné la vue utilisée. Peut-être qu'avec le retour des effets d'eau...
Par contre, je devrais probablement ajouter du bloom, et peut-être du SSAO, ça pourrait être sympa !

Les canards, c'est uniquement parce que j'ai adopté deux bébé canards de salon en même temps que j'avais besoin d'un mob de base pour les tests, donc ils m'ont inspiré.

Par rapport à mes problèmes de réseau, j'ai finalement craqué pour la dernière solution: j'ai abandonné l'idée de faire un serveur purement autoritaire. Après tout, si Bungie ne le fait pas pour Destiny, c'est que ce n'est pas si important que ça.
Blague à part, ça offre une expérience PVE beaucoup plus agréable (aucune chance de se faire stun/toucher par un enemi invisible, ni de rater un enemi que vous auriez du toucher, pas de retour en arrière, tout est fluide !). Les mobs sont quand-même géré par le serveur qui est autoritaire pour eux, avec les clients qui prédissent et essaient en permanence de converger vers la version envoyée par le serveur. Je suis assez content car ça m'a permis de garder l'effet que les mobs sont poussés quand on les touche (avec la version serveur autoritaire, je n'ai jamais réussi à obtenir un résultat correct pour ça).
Par contre, je sais que ça ouvre la porte à la tricherie facile, mais puisque mon objectif est avant tout un jeu coop entre amis, je pense que ce n'est pas si grave.

Vous pouvez voir le résultat actuel ici:

Au passage, vous pourrez aussi admirer ma tentative pour faire une animation de roulade. Je ne suis pas convaincu que ça soit vraiment bien, mais je pense que ça donne plus de dynamisme que mon ancien dash sans animation.

[Gregouar]

Salut les gens,

J'ai effectué pas mal de travail depuis la dernière fois, en plus d'avoir travaillé à améliorer la synchronisation entre les joueur, j'ai ajouté de la compression LZ4 sur les gros paquets (permettant de diminuer le temps de chargement pour recevoir les infos sur la map depuis le serveur). J'ai aussi enfin ajouté un partitionnement du monde en carrés, afin de pouvoir gérer des grandes maps sans perte de performances. Et finalement, j'ai ajouté du rendu de texte en utilisant FreeType, en générant du bitmaps au vol que je stocke dans une texture atlas.

Voilà un petit extrait de jeu en ligne avec mon frère:

Et voilà un extrait du menu basique que j'ai implémenté pour pouvoir faire des tests avec mes amis (c'était pas sympa de leur demander d'entrer mon IP dans la console ! )

Si jamais des gens veulent tester, les sources et binaries sont dispos sur GitHub: https://github.com/gregouar/PouEngine

[LoicJoint]

Ca a l'air très sympa tout ça ! Vivement la suite, en tout cas c'est déjà très classe

[Gregouar]

J'en ai un peu marre du réseau pour le moment, et ça fonctionne a peu près bien, donc j'ai décidé de m'attaquer à quelque chose d'autre qui devenait indispensable: la physique.
J'aime beaucoup les sensations du jeu Nox, où le joueur pouvait se balader en poussant les meubles dans le donjons. Du coup, j'ai envie de retrouver ce côté là en intégrant un peu de physique des corps solides.

Pour le moment, j'ai implémenté une gestion basique des rectangles (pivotés) et disques rigides, en 2D. Pour l'occasion, j'ai même dessiné/modélisé un baril pour les tests, que vous pouvez admirer:

D'un point de vue technique, je calcule la différence de Minkowski dans le repère du rectangle, puis je calcule le point sur le bord le plus proche de l'origine. Ca me donne le vecteur de translation minimal, que j'utilise pour pousser les objets à part en fonction de leur masse.

Je voudrais encore ajouter la possibilité de mettre des contraintes, tels que frottement et points d'attache, afin de pouvoir faire des portes qui s'ouvre quand on passe dedans.

[Gregouar]

Maintenant qu'il y a des collisions, il me fallait empêcher les mobs de se coincer dans le décor. Du coup, j'ai commencé à m'attaquer à du pathfinding. Vu que je ne travaille pas avec une grille, utiliser A* était hors de questions. Peut-être pourrais-je générer une grille et faire du Theta*, mais ça ne m'avait pas l'air top. Générer des meshes de navigation me semblait assez galère aussi au final. Du coup, j'ai décidé d'expérimenter avec un algo maison basé sur du lancé de rayons. Voilà le résultat actuel:

En gros, l'idée est de lancer des rayons, et si on a un obstacle, on ajoutes des nouveaux noeuds à explorer aux coins de l'obstacle pour tenter de le contourner. Ensuite, dès qu'on a réussi à tracer un chemin jusqu'à la cible, on le simplifie en lançant des rayons entre les noeuds qui le constitue, et si on ne touche rien on enlève les noeuds intermédiaires. Si ça vous intéresse d'avoir plus de détails, j'en ai donné ici (en anglais). J'ai aussi mis 2-3 détails en plus sur comment je gère la physique ici (en anglais). Si vous me dites "me no comprende anglais" et que ça v

[Gregouar]

Cette semaine, j'ai travaillé sur la génération de terrain aléatoire:


L'idée est que mon biome est représenté par un arbre de types de couches de terrain, me permettant de déterminer quel terrain peut apparaitre au dessus de quel autre. J'ajoute aussi quelques données supplémentaires, comme la probabilité de spawn le terrain ainsi que la probabilité qu'il s'étende dans le voisinage:


Ensuite, je génère une grille ou chaque case contient un type de terrain. Pour ça, je parcours mon arbre de la racine jusqu'aux feuilles, en générant et expandant le terrain en cours seulement sur les cases qui contiennent la couche parente. Typiquement, les fleures ne peuvent être mise que là où il y a de l'herbe. Ensuite, je passe 2-3 itérations pour réduire le bruit avec un automate cellulaire. Au final, j'ai ma grille de types de terrain que je veux dessiner, donc transformer en tiles de mon tileset:


Pour ça, je considère que chaque case de ma grille est en fait le coin partagé par 4 tiles. De plus, je considère que si une case contient un type de terrain (par exemple fleur), alors la case contient aussi les parents (herbe et terre). Finalement, j'ajoute mes sprites en lisant ces types de terrain depuis le plus bas jusqu'au plus haut, en ne dessinant rien, un coin de 1/4, un côté, un coin de 3/4, deux coin d'1/4 opposé ou un tile plein, dépendamment du nombre (et de la position) des coins contenant le type de terrain concerné:


Finalement, je partage ça sur le réseau en envoyant simplement les paramètres de génération et le seed, ce qui est extrêmement léger.
Pour l'avenir, en plus d'essayer d'ajouter plus de paramètres pour controller la génération du terrain, je voudrais ajouter la possibilité de générer des entités/groupes d'entités en fonction du type de terrain (typiquement, je ne veux pas d'arbre sur la terre, et plus d'arbres sur l'herbe foncée). Puis ajouter des "points d'intérêts", c'est-à-dire des morceaux de carte préfabriqués à la main (typiquement une entrée de donjon, une ferme, un arbre spécial, ...) et faire des routes/chemins pour en relier certains. D'autre part, je voudrais aussi expérimenter avec la génération de grottes et donjons aléatoires.

[Bryce de Mouriès]

J'aime bien cette technique de Tile avec un type par coin et une notion de couche, je l'avais découverte dans l'éditeur de Warcraft 3. Sans la génération aléatoire par contre,ça se fait à la main (quoique ça pourrait être codé via l'éditeur). Par contre ce que je trouvais pas mal, c'était la possibilité de définir l'ordre des tuiles, on pouvait décider d'afficher la Terre au dessus ou en dessous de l'herbe. Ca a du sens pour les tuiles de "villes", pavés gris, pavés noires, pierre lisses etc.

Pour rendre ton système encore plus générique, j'aurais aussi mis des probabilités entre parent / enfant pour les tuiles, comme ce que tu proposes pour les objets, les tuiles fleurs ont par exemple 2% de chances d'être sur de la pierre, 10% sur de l'herbe et 20% sur l'herbe haute. Je trouve ça dommage de ne pas du tout avoir de la pierre avec quelques fleurs, ou de l'herbe haute entourée de pierre, sur une falaise c'est peu probable mais ça arrive quand même et ça rend bien en général.

[Gregouar]

Ah mais rien n'empêche d'avoir plusieurs fois le même élément avec des paramètres de génération différents à différents endroits de l'arbre. Donc tu peux très bien avoir Terre (100%) -> Herbe (50%) -> Terre (10%) par exemple (après je n'ai pas dessiné de bordure de terre pour le moment donc là tout de suite ce n'est pas possible )

[Bryce de Mouriès]

Pas bête, avec plusieurs fois la même tuile, on peut la retrouver sur plusieurs couches. Aller au boulot pour la terre

En revoyant la capture d'écran In-game, ça fait bizarre d'avoir des tuiles inversées sur l'axe x côte à côte, comme un effet miroir.

[Gregouar]

Bien vu ! Au départ, je m'étais dit qu'en ayant suffisamment de diversité, ça ne se verrait pas. Mais en fait, dès que tu as deux tiles en miroir, ça choque toujours. Du coup, maintenant je sépare si possible mes tiles en deux piles, et je pioche dedans en fonction de la valeur x+y. Je réfléchirai à mettre au point une meilleure solution plus tard, mais ça devrait déjà moins choquer:


Par contre, du coup, je vais devoir changer mes coins de 3/4 sinon il utilise toujours l'un pour la diagonal dans un sens, et l'autre pour l'autre.

[Bryce de Mouriès]

Ouais là ça passe nickel. C'est une bonne idée d'utiliser la symétrie pour avoir plus de tuiles. Après ça sera gênant si t'as de l'ombre sur certaines tuiles (avec des cailloux par exemple), pour le moment l'illusion est parfaite.

[Gregouar]

De toute façon je dois éviter les ombres et avoir un maximum un éclairage du dessus, vu que j'ajoute de l'éclairage dynamique par dessus.

[Gregouar]

Je n'ai pas vraiment beaucoup à montrer, mais je progresse sur la génération de cartes aléatoires. Voilà le genre de choses que j'obtiens pour le moment:


J'ai notamment revu ma façon de placer les entités sur la carte. Plutôt que de faire une bête distribution uniforme (qui peut amener à des résultats gênant, comme plein d'entités collées ou bien des grandes zones vides), je suis passé à un bruit bleu (de type poisson disque, implémentant cet algorithme). Cela me génère un nuage de points, où les points ne peuvent pas être plus proche qu'une certaine distance minimale précisée. C'est bien, parce qu'en générant des distributions pour différentes distance, je peux avoir des objets dense (comme des touffes d'herbe), moins dense (comme des arbres) et éloignés (comme des groupes de monstres). Voilà un exemple de distribution:


Après, inspiré par le talk de Jaap van Muijden:

(à propos de la distribution d'entités dans le monde de Horizon Zero Dawn), je change la probabilité de générer tel ou tel entité à tel point de ma distribution en fonction de type de sol. Par exemple, je peux mettre 100% de chances de générer une touffe d'herbe sur l'herbe foncée:


Comme mentionné plus haut, je peux aussi demander de générer non pas une entité, mais un groupe d'entité à un point de spawn. Typiquement, pour générer des groupes de monstres. Je peux aussi jouer avec jitter pour modifier un peu la position, l'orientation, la couleur, etc. Typiquement, pour générer mes groupes de canard, le code ressemble à ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
<distribution type="poisson" distance=500 sectionSize=5000 spawnType="unsafe">
	<spawnPoint  spawnProbability=.35>
			<character path="../duck/duckXML.txt" amount="[1,3]" />
			<modifier type="position" rng="uniform" x="[-100,100]" y="[-100,100]" />
	</spawnPoint>
	<spawnPoint  spawnProbability=.15>
		<character path="../duck/duckXML.txt" amount="[3,5]" />
		<modifier type="position" rng="uniform" x="[-100,100]" y="[-100,100]" />
	</spawnPoint>
</distribution>

Ce qui me permet d'avoir un groupe entre 1 et 5 canards (avec plus de chance d'en avoir entre 1 et 3) réparti uniformément autour d'un point de spawn (qui lui est déterminé par la distribution de poisson disque). Le moteur physique s'occupe de séparer les entités si elles sont placées trop près l'une de l'autre (ou dans un mur) au runtime.

Au passage, j'en ai aussi profité pour ajouter le fait que si un mob sélectionne une cible, alors il la partage à ses alliés qui n'ont pas encore de cible qui sont à côté d'eux. En vidéo, ça donne ça:

Pour le moment, je suis en train de travailler sur la génération des points d'intérêts qui demandent un traitement un peu particulier. Pour comprendre cela, laissez moi partager avec vous un peu plus mes ambitions:

Si tout se passe bien, l'idée serait d'avoir une carte du monde divisée en multiple régions/biomes. Dans ces régions, il est possible de faire des expéditions. Ceci génère un niveau aléatoirement dans la région, où on démarre au centre en arrivant par montgolfière. Il faut alors explorer la carte à la recherche de ressources et matériaux. En explorant, il est possible de trouver des points d'intérêts, qui peuvent être multiple: un simple décor un peu spécial, une ressource particulière comme une mine/carrière, des traces d'autres explorateurs, une entrée de donjon et encore une antre de boss.
Tuer des ennemis à la surface et ramasser certaines ressources permettent de gagner des "points de ressources" (j'y reviendrai plus tard), tandis que combattre les boss et ramasser d'autres types de ressources permettent d'obtenir des matériaux de craft.
Explorer les donjons, par contre, permet de récupérer des trésors (ie. de l'argent) et de trouver des schémas de craft (et pourquoi pas trouver d'autres babioles utiles).
L'idée étant donc qu'on alterne entre de l'exploration de donjons pour trouver les schémas, puis de la récolte de ressources à la surface pour fabriquer du nouvel équipement ou autre.
Quand on a fini d'explorer une carte, ou qu'on en a marre, il suffit de retourner à la montgolfière pour lancer une autre expédition.
Par ailleurs, quand on amasse suffisamment de ressources dans une région, il devient possible de capturer un territoire. Pour cela, rien de plus simple, il suffit de lancer une expédition, puis si la carte nous plait, on peut l'acheter. Cela débloque alors la possibilité de construire des bâtiments sur la carte, ainsi que de lancer des expéditions dans les nouvelles régions adjacentes
Dans chaque régions, il y a une liste de PNJ qu'il est possible d'attirer. Pour cela, il faut leur construire une maison qui leur plait. Typiquement, il faudrait un certain niveau de confort. Cela s'obtient en fabriquant des décors/meubles et en les plaçant dans la maison (j'envisage même la possibilité de faire des "combos d'harmonie" à la manière d'objets de set), ainsi qu'en éventuellement plaçant l'un ou l'autre objet spécifique pour le type de PNJ (typiquement, un forgeron a besoin d'une forge). Les PNJ peuvent, dépendant leur métier, proposer tout un tas de services (fabrication d'objets de niveau plus élevé, récolte de ressources, ...).
Certain points d'intérêts deviennent alors intéressant, puisqu'ils ne s'activent qu'une fois qu'un certain type de PNJ arrive dans la région (typiquement un mineur pour la mine, rapportant des ressources et matériaux de craft)
(Tout ceci est bien sûr en cours de réflexion et viendra probablement à changer)

Et en cadeau, voilà un premier art pour la montgolfière (qui m'a juste pris une après-midi entière à dessiner ):